RE: Re: AW: License proposal (Summary)

Ok, so there's been a lot of discussion. I'm going to attempt to summarize
what we know thus far.

First, regarding copyrights...

1. All original authors of code retain the copyrights to that code (which is
why we have to ask your permission to change the license). The only
exception to that was me, since I worked for Lutris - all code I wrote while
working for them (most of the original Barracuda code base) belonged to
them. ATMReports has since purchased those rights to donate them to the
community. Technically, they now own the copyrights, but I could probably
ask them to transfer them back to me, just so all copyrights are owned
solely by the original authors.

2. Now, when you contribute code to an open source project, you license
other people to use (and even change!) your code. The specific
rights/requirements depend on the license, and no one can change the terms
of that license except for you the copyright holder.

3. If you have one entity that owns the copyright, then technically the
could change the license at any time they see fit - this was always one of
the concerns w/Lutris (and I suppose even Apache could do this if they
desired?).

So in my opinion, I think its important to see copyrights continue to be
owned by the original authors - that serves as a source of stability by
making it difficult for any one person/entity to co-opt the project.

Of course this brings us to our second issue: licensing. Once we pick a
license, we really are stuck with it for the long haul...so its important we
do it right.

1. Picking the wrong license _can_ be a serious deterrent from adopting a
technology. Many companies won't touch stuff that's GPL because of its viral
implications. Those of you who were here from the early days may recall that
one of the biggest concerns people had for NOT adopting XMLC, Enhydra, and
to a lesser extent Barracuda was the fact that a) it was based on a
proprietary open source license (EPL), and b) some developers were
distrustful of the company behind the license (Lutris). All this to say we
need a license that is standard, and which won't be a disincentive in any
way; we want people to make their decisions about Barracuda based on its
technical merits, not its license.

2. Our basic options (at least those we know will work with ObjectWeb) are
BSD and LGPL. And I think both of those are reasonably safe solutions.

2a. The advantage of BSD
(http://www.opensource.org/licenses/bsd-license.php) is that it is about as
non-restrictive as you can get: use it, do whatever you want with it, but
you must continue to mention us in the copyright section. The disadvantage
is that you don't require people to donate back. [Note: some have voiced a
concern that some corporate entity could fork the project by taking the
Barracuda code base and applying enough money. This really isn't a concern
to me - I just don't seeing it happen, and even if it did, I fail to see how
it could hurt us.]

2b. The advantage of LGPL
(http://www.opensource.org/licenses/lgpl-license.php) is that it requires
people to submit their changes back to the project (in the sense of making
them public). Both licenses protect against liability - no one can come and
sue you because code you wrote for Barracuda had a bug in it. LGPL goes a
step further and also tries to protect developers from patent abuse on the
open source code (this is good, but I'm not sure I understand exactly what
the license means in this area).

The one significant disadvantage, IMHO, is that in an effort to control
distribution, LGPL describes libraries/applications rather archaically (in
ways that don't seem to correspond directly to Java and webapps);
furthermore, it also uses vague terminology about derivative works, in
certain instances requiring them to be licensed LGPL.

We've already discussed this on the list - viewed charitably, it seems
reasonable that as long as you don't actually modify the LGPL source, then
you can use the library, and even if you make modifications, all you have to
provide is the modified LGPL source, not your proprietary project that uses
it. This would seem to allow for commercial products that leverage or extend
Barracuda, and more importantly, for developers to import LGPL libraries,
extend LGPL classes (since as Alfred aptly pointed out, Java classes allow
authors to _prevent_ extension if so desired), etc, without ever having
their end applications falling under LGPL.

Now, in describing it this way, I've used the term "viewed charitably,"
since this particular interpretation is coming from all of us developers
reading the license somewhat sympathically. At the very least (as
demonstrated by the widespread discussions about Java and LGPL), there is
some measure of fuzziness out there. My concern is that when I go back and
actually _read closely_ the LGPL license, the fuzziness doesn't get clearer.

So what if we try and view the LGPL more "skeptically"? It seems that one
possible abuse would be for someone to try and apply the derivative works
clause to any Java code that uses LGPL must itself be released as LGPL. I am
playing devil's advocate here: what if Joe Coder writes an online auction
system built on an LGPL version of Barracuda, and then sells this
application to vertical markets (thereby redistributing his application
along w/Barracuda .jar). Let's say EBay's notices and decides they want his
market. Could they file a suit claiming that because his application extends
LGPL classes, he must "release" the whole thing? Joe obviously can't do
this, because it would eliminate his competitive advantage. So the only
recourse would be to stop using LGPL technology, or to spend a whole lot of
money fighting a lawsuit.

I'm not saying this interpretation is valid, but it does seem to be a
_possible_ interpretation of the LGPL (so it wouldn't get thrown out of
court immediately). And the LGPL has not been tested in court, so the
outcome is not entirely certain. My concern then is that the fuzziness of
LGPL's "derivative work" clause could be leveraged by a company-with-money
to pull the rug out from underneath a less-well-financed competitor. If
that's a possiblity, that would in turn be a disincentive for companies to
adopt LGPL.

Now, I've just painted the picture as bleakly as possible just to make sure
we're not overlooking something here. I'd like to hear comments on this. Of
course we need to keep in mind that LGPL is a _very_ widely accepted
license, and the dark side interpretation I've just suggested has not
actually been used by anyone (although SCO is doing something similar in
regards to challenging Linux and GPL). My guess is that it would be very
unlikely for a court to uphold such a claim in court (the ramifications
would be simply enormous). That said, we need to make sure that we don't
pick a license which leaves developers open to legal challenges. To that
extent, the BSD license seems a little safer.

In conclusion, I'd like to suggest that everyone take a few minutes and
_read_ the LGPL over again, closely - looking at what it says about
derivative works. I think I will send an email to Free Software Foundation
and see if I can get any clarification of these issues. What we need to come
up with is a clear answer from the license that refutes the above scenario
I've described. Alternately, we may want to consider if it might not be
safer (for companies using Barracuda) just to go with BSD (or should we be
considering some other alternative from http://www.opensource.org/licenses/
...if we really think some 3rd option is best, we could always ask OW if
they'll accept it).

Comments and feedback welcome, but lets all start looking for a way to wrap
this discussion up (eg. what do we need to resolve in order to make the best
decision one way or the other). Hopefully we can reach some kind of
conclusion early next week.

Cheers,
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 Xue-Feng Yang
> Sent: Friday, January 09, 2004 12:15 PM
> To: [email protected]
> Subject: Re: [Barracuda] Re: AW: License proposal
>
>
> I have one more question about a commercial J2EE
> component vendor.
>
> Normally, J2EE components are divided into a few
> layers, for instance, core layer, solution layer, and
> domain layer. In general, the core layer and the
> solution layer are coded into library for sale and
> domain layer belongs to the customer. So the domain
> layer will be given with source. However, the core
> layer and the solution layer will be only given as
> binary.
>
> If the classes in the core layer and the solution
> layer extend a LGPLed software, they have to be
> LGPLed, too, since they are the extended library. Am I
> right?
>
> Xue-Feng
>
>
>
> ______________________________________________________________________
> Post your free ad now! http://personals.yahoo.ca
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda