Re: [binc] What license should we use for Binc IMAP in the future?

Kyle Wheeler <[email protected]> Mon, 8 Aug 2005 09:41:49 -0500
Newsgroups gmane.mail.imap.binc.general
Message-ID <[email protected]>
On Monday, August  8 at 08:29 AM, quoth Andreas Aardal Hanssen:
>>> 3) I want the business world to feel good about using and modifying 
>>> Binc IMAP. 
>> This, I'm guessing, is why you decided to re-evaluate the issue. Why 
>> would a business not feel good about using or modifying BincIMAP 
>> currently? Are any modifications okay for any purpose, or do you want to 
>> require those modifications to be available to the community? May a 
>> company sell modified BincIMAP binaries (say, as part of an embedded 
>> webmail turnkey-device, for example)?
>
> Of course they can; but they must provide the source code for it. And if 
> someone who has obtained a binary asks them for the source, they must 
> provide it. I would claim the reason many companies are afraid of the GPL 
> is that they don't know the license. They only read headlines of diverse 
> GPL-unfriendly articles ;-), and share nosense during lunch breaks. 
> Sharing the source code of something that is already open source is, of 
> course, not a competitive advantage.
>
> But with the GPL, companies can not create a proprietary back-end without 
> sharing the source. And I am pretty sure that Google, for example, 
> wouldn't want to share details about their back-end with the OS community.

True, but Google isn't exactly making their IMAP server available for 
download either.

I get your point, though. I would posit that perhaps what would need to 
happen (if you wanted to make it so people could make their own 
backends) is that Binc needs a backend API: make it modular, so that 
backends can be loaded rather than requiring them to be built in. This 
allows improvements to the frontend to be required-to-be-shared, while 
backends can be developed separately and kept secret.

>>> GPL is a little strict on adding stuff (backends, extensions). Maybe 
>>> LGPL is an alternative?
>> Specifically, what behavior does the GPL prohibit that you (or anyone 
>> else) feels should not be prohibited?
>
> Adding a mailbox format, adding a depot format, adding in-house 
> extensions, authentication modules, and so on. As long as it's GPL (and 
> once GPL, always GPL), any intern who can get a hold of the software can 
> distribute it. And that's food for lawyers of course, but it's scary 
> enough to shake away many businessmen.

I think modularity is probably the way to go if that's what you want to 
encourage.

~Kyle
-- 
Truth is not determined by a majority vote.
                                                    -- Pope Benedict XVI
signature.asc (application/pgp-signature, 196 B)
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iD8DBQFC928tBkIOoMqOI14RAqIrAKCibx7QpsxZw49E2jfSAWZTxCCiZgCgiSCG
UAF9pLKPSp3m5ky4mo4/3EA=
=L/Ub
-----END PGP SIGNATURE-----