GPL, LGPL, and copyleft

[Jordi Gutiérrez Hermoso]

2012/3/29 Daniel J Sebald <address@hidden>:
> On 03/29/2012 02:06 PM, Jordi Gutiérrez Hermoso wrote:
>>
>> On 29 March 2012 14:54, Daniel J Sebald<address@hidden>  wrote:
>>>
>>> The L of LGPL stands for "lesser".  I'm not sure what the difference is
>>> between the LGPL license and the GPL license, but apparently they are
>>> different:
>>
>>
>> This essay explains what the LGPL is and how it's meant to be used:
>>
>>     http://www.gnu.org/licenses/why-not-lgpl.html
>>
>> I noticed earlier in the discussion about GUI Octave that you seemed
>> surprised that the GPL doesn't allow certain things.
>
>
> I see GUI Octave as an aggregate.  Octave is not linked in the code space.

It is some sort recurrent fantasy that the precise way in which things
are combined matters. What matters is degree of how things are
combined and whether this constitutes "derivative work" or not. The
FSF believes that if the interaction between two components is
sufficiently complex, the combined work is a derivative work, even if
it's over pipes:

    http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

It's not clear if GU Octave is communicating with Octave in an
"intimate enough" way, but I think it is, starting with how the whole
program is pretty useless without Octave and how it needs to query
Octave to handle large matrices and arrays and data associated to
them.

>> Briefly, the LGPL explicitly allows linking with non-free works and
>> distributing the result, but the GPL doesn't:
>>
>>
>> http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License#Differences_from_the_GPL
>
>
> Yes, I see.  And it reads a bit like hypocritical condescension, in my
> opinion.  At the end of the description it says:

Just to be clear, you're quoting a different source than the link above.

> "Proprietary software developers, seeking to deny the free competition an
> important advantage, will try to convince authors not to contribute
> libraries to the GPL-covered collection. For example, they may appeal to the
> ego, promising “more users for this library” if we let them use the code in
> proprietary software products. Popularity is tempting, and it is easy for a
> library developer to rationalize the idea that boosting the popularity of
> that one library is what the community needs above all.
>
> But we should not listen to these temptations, because we can achieve much
> more if we stand together."
>
> All right.  ALL FOR ONE AND ONE FOR ALL!!
>
> But near the front of the description it reads:
>
> "Using the ordinary GPL is not advantageous for every library. There are
> reasons that can make it better to use the Lesser GPL in certain cases. The
> most common case is when a free library's features are readily available for
> proprietary software through other alternative libraries. In that case, the
> library cannot give free software any particular advantage, so it is better
> to use the Lesser GPL for that library.
>
> This is why we used the Lesser GPL for the GNU C library. After all, there
> are plenty of other C libraries; using the GPL for ours would have driven
> proprietary software developers to use another—no problem for them, only for
> us."
>
> Huh?  But, but... but you just said don't give in to the temptation.

What he's saying is that it's a matter of strategy. If your library
provides a unique facility, it is advantageous to make it LGPL, at the
expense of some popularity. If it's not unique, then the LGPL isn't an
advantage and would only drive people away. There's nothing unique
about libc (or wasn't, perhaps now there is, but the GPL has a system
library exception anyways), but other libraries may be more unique,
and keeping them GPL is better.

Octave's library for example is GPL, and in this case it's an
advantage, because for example (correct me if I'm wrong) it's the only
free implementation of the MEX interface, or perhaps the best free
implementation of MEX. It certainly is the only implementation of the
Octave API, which I find nicer than MEX. :-)

- Jordi G. H.