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

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