Re: AW: License proposal

My thoughts are that many of the open source licenses, including GPL and 
LGPL, are legally ambiguous when applied to Java code. These licenses 
were created with the thought that you would be compiling source code to 
binary executables or objects that are able to be linked into other 
executables. When applied to Java the licenses can become somewhat vague 
and confusing. As I was looking around I found that Enhydra actually ran 
into the same problem (though they also had some other requirements) and 
so created the Enhydra Public License, based on the Mozilla License. 
Here's the page I found:

    http://pauillac.inria.fr/~lang/hotlist/free/licence/lutris/

One license I have become increasingly intrigued by is the Common Public 
License by IBM. This is the license used for the Eclipse project as well 
as related projects such as Eclipse Web Tools Platform, Eclipse 
Technology, and Eclipse Tools.

Here are some sites I found with various license comparisons:

    http://www.croftsoft.com/library/tutorials/opensource/
    http://zooko.com/license_quick_ref.html

And probably the best easy-to-read table I have seen so far with a good 
number of licenses:

    http://developer.kde.org/documentation/licensing/licenses_summary.html

I initially thought the LGPL was a good choice but after some additional 
research I think we should steer clear from it. The general consensus I 
have gathered is that LGPL for Java is no different than GPL. This is 
where I have seen some people recommend the CPL instead.

Another thing to keep in mind, this time relating to copyright 
ownership, is I believe that should we ever need to change the license 
in the future we will need express consent from all contributors. If we 
aren't able to get in contact with any contributors then their code (and 
possibly derivative code as well) will need to be removed from the project.

Again, I am not a lawyer so everything I have said may or may not be 
completely accurate.

-shawn

Christian Cryder wrote:

> Just an additional comment...
> 
> The text of the LGPL can be found here:
> http://www.opensource.org/licenses/lgpl-license.php
> The text of the BSD license can be found here:
> http://www.opensource.org/licenses/bsd-license.php
> 
> I was originally thinking of a dual license, using both LGPL and BSD. One of
> the ObjectWeb guys commented on this, and I found his reply helpful...
> 
> 
>>Hi Christian,
>>
>>I don't quite understand what your intention is wrt licensing.
>>You may technically release Barracuda under both BSD and LGPL.  You
>>probably have a good reason,  which I'm not aware of, to investigate this
>>possibility. The thing is, BSD is so permissive, anybody has the right to
>>license derivative works of BSD'ed software under another license,
>>including LGPL. On the other hand, LGPL requires that derivative works be
>>distributed under an LGPL-compatible license, which BSD is not.
>>This means that BSD software does not need to be licensed under LGPL,
>>since the rights granted by BSD are a superset of those given by LGPL.
>>Conversely, modifications in LGPL software cannot be contributed to the
> 
> BSD
> 
>>version, because they are required to remain under LGPL.
>>
>>The BSD license is distinct from the Apache Public License. A main
>>difference is that if you opt for the BSD, you remain the owner of all
>>copyrights, whereas if you chose APL, you transfer the copyrights to the
>>Apache Software Foundation. This latter option is not appropriate
>>in your case.
> 
> 
> So from my perspective, we definitely want the copyright ownership to stay
> with the original authors (that keeps everything protected from any one
> group co-opting the project in a direction that might not be beneficial to
> everyone else). So, both LGPL and BSD would fit that bill, whereas something
> like Apache Public License would not.
> 
> The second thing we want to require is for extensions and improvements to be
> submitted back to the community. LGPL requires this, at least in the sense
> that it requires the source for any derived works to be made available under
> the same terms.
> 
> The only real question I have about LGPL centers on "derivative works." As I
> read the license, if you extend of modify Barracuda, you would need to make
> those changes available under LGPL as well.
> 
> -- (LGPL snippet) --
> 2. You may modify your copy or copies of the Library or any portion of it,
> thus forming a work based on the Library, and copy and distribute such
> modifications or work under the terms of Section 1 above, provided that you
> also meet all of these conditions:
> 
>     a) The modified work must itself be a software library.
> 
>     b) You must cause the files modified to carry prominent notices stating
> that you changed the files and the date of any change.
> 
>     c) You must cause the whole of the work to be licensed at no charge to
> all third parties under the terms of this License.
> --------------------
> 
> So my question is: what about derived work where you simply _extend_ the
> underlying library classes? For instance, what if someone creates their own
> version of the ApplicationGateway? If they change the class itself, then
> that clearly constitutes a derivative work. But what if they merely extend
> it? I am tempted to say that's a derivative work as well, except for the
> fact that there are many places in Barracuda which are designed to be
> extended by the user.
> 
> For instance, what about things like abstract classes (think event handlers,
> in particular) that MUST be extended in the end user application. In a case
> like this, I certainly DONT think that extending/implementing a Barracuda
> event handler constitutes creating a derivative work; if it did, then
> section c could be construed to mean any app which uses Barracuda must
> itself be licensed under LGPL.
> 
> SO...I'd like some input on the whole derivative work thing...is there
> anyone who has done real legal analysis of LGPL implications? My question
> here really boils down to "what constitutes a derivative work?" Especially
> in an OO language like Java where you are designing things to be extended.
> Maybe the answer is that "as long as your class simply _extends_ an LGPL
> class, you are fine"...I'm ok with that. But does the LGPL license say that?
> Or does it say more than that?
> 
> Perhaps someone at ObjectWeb can comment on this (Christophe, Francois,
> Matthieu, Alfred?)
> 
> Christian
> ----------------------------------------------
> Christian Cryder
> Internet Architect, ATMReports.com
> Project Chair, BarracudaMVC - http://barracudamvc.org
> ----------------------------------------------
> "Coffee? I could quit anytime, just not today"
> 
> 
> 
>>-----Original Message-----
>>From: [email protected]
>>[mailto:[email protected]]On Behalf Of Thelmo Loisio
>>Sent: Tuesday, January 06, 2004 1:40 PM
>>To: [email protected]
>>Subject: Re: AW: [Barracuda] License proposal
>>
>>
>>On Tue, 2004-01-06 at 13:34, Madl Alfred wrote:
>>
>>>LGPL is "sticky" where BSD is not. Means: LGPL code ALWAYS has to stay
>>>LGPL. No closed source derivations are allowed of LGPL code. BSD allows
>>>closed source forking (like IBM or Sun are doing with Apache and Tomcat
>>>which are based on the Apache license which also allows that). I think
>>>this is the main difference...
>>
>>That could prevent some private (company) to found the development of
>>the project.
>>
>>I don't know how the license issue was addressed by two projects on OW
>>(ASM and JOTM) which was recently licensed under BSD license to make
>>them compatible with the Apache foundation. I even don't know which was
>>their license before.
>>
>>But this is the only real issue. If it possible, desirable or
>>undesirable to have this opportunity.
>>
>>Regards
>>--
>>Thelmo
>>
>>_______________________________________________
>>Barracuda mailing list
>>[email protected]
>>http://barracudamvc.org/lists/listinfo/barracuda
> 
> 
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda