On Tue, 09 Aug 2005 16:21:15 -0400, Andreas Aardal Hanssen
<[EMAIL PROTECTED]> wrote:
On Mon, 8 Aug 2005, Bob Van Zant wrote:
An argument showing that at this point the most important thing for Binc
is to gain more corporate involvement would definitely sway me toward
advocating a BSD-style license (whereas now I'm just pointing out its
merits).
I'm sorry Bob, but the BSD license gives us nothing. The GPL says that
modified code can't be distributed in binary form without also shipping
the code, which strongly emphasizes that modifications are made public.
The BSD license is just "here, take it and use it as you like, I don't
care, just put my name in a comment somewhere". The only reason anyone
contributes to BSD licensed projects with their in-house developed
extensions is because they're nice guys. ;-).
Can we revisit the original framing for this discussion:
1) It's open source, for all that means.
2) I want to encourage everyone to send their patches back to the
community, so that others in the same position as you can make use of
your adaptations.
3) I want the business world to feel good about using and modifying Binc
IMAP.
4) I don't want the existing Binc IMAP community (yeah, you!) to feel that
any new license is of hindrance for them to make use of Binc IMAP 1.4.
Here is my take:
1) All proposed licences fall into the "open source" category.
2) This suggests GPL and LGPL since BSD style licences allow (encourage?)
modifiers/enhancers to not distribute their patches, particularly if
the modifiers feel it is going to compromise their competitive advantage
(or national security:-).
3) This one is a little bit tricky. What do you really mean by this
statement?
Do you mean for internal applications that do not get redistributed
outside
of the organization? In this case, most any open source licence is
sufficeint,
provided the organization takes the time to read and understand the
licence.
The real problem is that these licences require input (and elaboration)
from
ALL three of the business, technical and legal departments. Missing
input
often results in the adoption of conservative or erroneous assumptions,
particularly in the case of GPL. However, I think that this will
change over
time as the world becomes more educated in open source licences (and
the FUD
is dispelled).
However, if you want to encourage the development of commercial
applications
built on top of Binc, then a BSD style licence is more favorable
because it
gives the commercial organization more control over their intellectual
property
(a valued asset to a software company). The value to us (really to
Andreas)
would be the prestige (and associated marketability) that would come
from Binc
becoming popular as a platform for commercial products developed by
companies
that won't accept GPL type licences.
4) I am comfortable with using software under most open source licences.
My
preference for contributing (what little) software to Binc would be
under a
GPL style licence, although I would be comfortable with BSD and Perl
Artistic
style licences (and maybe a few others).
Summing up, I believe staying with a GPL style licence best meets the
stated
objectives, unless I am mistaken in my understanding that you/we can accept
that companies might choose other IMAP servers, becuase of licencing
issues,
as the basis for their commercial products.
By the way, I have two questions:
1) Is your list of objectives complete?
2) Do the different objectives have different levels of importance? If so,
what are the relative differences?
The GPL does not define distribution. It also does not cover linking, or
C/C++ headers/prototypes with inlined code. It doesn't even cover
interpreting, or JIT compilation, or any of these things that are
becoming
very common today. More importantly, it does not define plugins or
extensions. It's all GPL, and then it's all GPL. Discussions are going on
the web about whether non-GPL licensed Java bytecode compiled classes can
be used when writing GPL code. Or whether MySQL's GPL plugin API can be
used to write closed source database handles. Can I write a backend for
Binc IMAP and keep it closed? If you change Binc's sources, _no_. Not if
you distribute it.
The vagueness of the term "distribution" is terrible. If a consultant
writes an extension to Binc IMAP for a 20000 employee company operating
in
20 countries, and this server is copied in binary form and sold to all
its
divisions, you could still say it's not distribution because it's inside
the same company.
My point, for Binc IMAP, is that the GPL does not allow companies to
write
backends for the server and distribute that backend (or the whole
modified
product) in binary form, and that's regardless of how well defined our
API
is. And I'd like for them to be able to do that.
This might contradict the assumption in my summary above.
Regards,
Henry:-)
Andy :-)
PS: This is why GTK and KDElibs are LGPL, and why Qt is GPL with an
exception that allows linking against other libraries. Believe me, if
these libs could have been pure-GPL licensed then they probably would
have
been.
--
Andreas Aardal Hanssen | http://www.andreas.hanssen.name/gpg
Author of Binc IMAP | "It is better not to do something
http://www.bincimap.org/ | than to do it poorly."
--
Henry Baragar
Instantiated Software Inc.
http://www.instantiated.ca
