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-----