www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: LGPL software behind an isolation layer
Date Thu, 27 Aug 2009 17:25:24 GMT

On Aug 27, 2009, at 9:15 AM, Ceki Gulcu wrote:

>
>
> Ralph Goers wrote:
>
>> So the question isn't whether the LGPL terms apply - they do - but  
>> whether we choose to have them imposed on us by distributing the  
>> software. We don't.
>
> It is not at all an established fact (to me!) that the LGPL terms  
> apply. In particular with respect to its 6th clause.

So it is clear you mean LGPL V2. Yes, that clause is as clear as mud  
and has been been debated endlessly. The FSF has their interpretation  
(see http://www.gnu.org/licenses/lgpl-java.html) and JBoss has theirs (http://www.jboss.com/pdf/Why_We_Use_the_LGPL.pdf

) and they don't quite agree. Apache has always used the FSF's  
interpretation which clearly spells out the requirement for reverse  
engineering.

However, I find your statement "It is not at all an established fact  
(to me!) that the LGPL terms apply." a bit scary. That implies that  
under some circumstances you can choose to ignore the terms of the  
license. That just isn't so. You must always abide by the terms of the  
license. It is just that in some circumstances (non-distribution) the  
restrictions don't come into play.


>> There are two parts to the GPL and LGPL that you seem to be missing.
>> 1. The LGPL and GPL clearly define a derivative work as anything  
>> that uses the software. The main difference between the LGPL and  
>> GPL is that the LGPL has an exception for derivative works that use  
>> the library.
>
> What does "uses" the software mean? If A uses B which uses C, is A
> using C?  Asked this way, the answer is, yes (by transitivity).
> However, the 6th clause of LGPL is pretty nonsensical (which it
> usually is anyway.)

See the FSF's link above. They spell it out as best as anyone has. If  
you still can't make sense of it then choose another license that is  
clearer and accomplishes what you really want. No one says you can't  
create your own. And there are plenty of licenses listed at OSI to  
pick from.

>
> If by using, one means has knowledge of as in linking or referencing,
> then in the case of software behind an isolation layer, AP (apache
> project) "knows/references" SLF4J, logback "knows/references" SLF4J
> but AP does not "know/reference" logback. I guess you cannot claim
> *not* to know/reference a given software if you also distribute it.

The FSF's definition of "derivative" applies to the whole distributed  
package. The whole thing is a derivative work, not just the component  
directly using the work. See the preamble - "When a program is linked  
with a library, whether statically or using a shared library, the  
combination of the two is legally speaking a combined work, a  
derivative of the original library.".  So when you see "work that uses  
the library" it means a) the library, b) everything else. Having a  
layer that separates one component from the LGPL'd work doesn't change  
anything in that regard. When you bundle it all together the LGPL  
applies to what was distributed - the work as a whole.


>
>> 2. Distribution is the trigger. The conditions of the GPL and LGPL  
>> pose no risk when an individual gets the software himself and then  
>> just uses it. There are no conditions that they have to adhere to.  
>> However, they do have certain rights - such as being able to obtain  
>> source code from wherever they obtained the binaries. However, if  
>> that individual then gives that software to their best friend the  
>> clauses in the GPL and LGPL become relevant. The friend has all the  
>> same rights as the first person and can require them to provide the  
>> same access to the source code that the first individual has.
>
> Indeed, distribution is the trigger, and regardless of the
> distributor. So on Linux, all HTTPD distributions which uses APR which
> uses glibc (on systems with glibc installed by default) are tainted by
> LGPL, right? It just so happens that the ASF is not the distributor.
> Which come to think of it, is fine.

If glibc is already installed on the system as a prerequisite than  
HTTPD did not distribute it and the restrictions do not apply. This is  
exactly the same as with Java itself.  That is why the ASF doesn't  
have a problem with that particular use case.

>
> Anyway, I wrote to the FSF asking for their legal opinion and intend
> to report the results back here.

Don't be surprised if they point you at the link above or at LGPL V3.

And FWIW, whatever opinion they may give you isn't going to change  
what the vast majority of corporate attorneys tell their software  
engineers. I know what mine tells me. While software that use a  
Category A license have been pretty much pre-approved for use by  
developers, every use of software under a different license (most  
notably, GPL and LGPL) must be approved on a case by case basis. This  
is fundamentally at the heart of why the ASF treats the LGPL the way  
it does.

Ralph


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


Mime
View raw message