www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <rdon...@apache.org>
Subject Re: Move log4cplus' license to ASL 2.0.
Date Mon, 10 Aug 2009 19:45:56 GMT
Hash: SHA1

Ceki Gulcu wrote:
> Ceki Gulcu wrote:
>> Robert Burrell Donkin wrote:
>>> Ceki Gulcu wrote:
>>> it took a lot of time and effort but AL2.0 and GPL3 settled the
>>> remaining licensing issues
>> Really? Does this mean that GPL3 and AL2.0 are compatible?
> Well, the FSF states [1] that the AL2.0 is considered compatible with
> GPL3 and by extension with LGPL3 as far as the FSF is concerned.  How
> about the LGPL being (in)compatible with AL2.0 from the ASF's point of
> view?

the ASF's position has been that the FSF are ones who decide whether the
LGPL is compatible with the apache licenses or not (apache policy for
our releases tends to go beyond legal compatibility)

> Which LGPL clause is preventing the ASF from considering the LGPL as a
> compatible license? Looking at [2,3], it seems that there should be no
> problem if an Apache project (written in Java or not) relied on an
> LGPLed library.
> According to [3], "Applications need only follow the requirements in
> section 6 of the LGPL: allow new versions of the library to be linked
> with the application; and allow reverse engineering to debug this."
> Linking with a new version of the library is a non-issue in Java. Just
> replace one jar file of the library with another jar. As for
> debugging, and reverse-engineering, the AL2.0 is an open source
> license which obviously allows for reverse-engineering.
> The only question is then about clients who repackage and republish
> Apache licensed software which happens to contain an LGPLed
> library. Why should the ASF protect clients who choose to *publish*
> their work under a closed license?
> I understand that the ASF does not wish to prevent software companies
> from building commercial and closed-source products on top of Apache
> licensed software.  However, if an Apache project, say P, decides to
> rely on LGPLed software, say L, and if some software company, say C,
> decides to build a product on top of P, then that's C's problem not
> P's. Project P should be free to use L. Project P should only be
> required to clearly state that they use LGPLed software but that
> should be it. If company C still wishes to build a product on top of
> P, then that's C's problem not P's.
> Isn't the ASF being more royalist than the king in this case?

it's this sort of license subtly that gives the original LGPL such a bad

the FSF interpretation of the original LGPL is problematic and disputed
by many organisations which use the LGPL. whether importing a java
package in source is sufficient to create a derivative work of the
original is debatable.

though the FSF interpretation does not insist that downstream
applications are LGPL'd they must be freely re-distributable and
modifiable. in order to enforce this interpretation, apache would have
to explicitly include an additional license clause effectively
preventing commercial applications.

- - robert
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message