Re: GPL, LGPL, and copyleft

[Daniel J Sebald]

On 03/29/2012 03:36 PM, Jordi Gutiérrez Hermoso wrote:
> 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

Please quote what lines you are referring to.  I see what the definition 
of "aggregation" is (and interestingly the phrase "MereAggregation" is 
used).  But nowhere is this text suggesting that aggregation in some way 
is automatically considered derivative work or a modified version.  The 
following is all speculation as to what might constitute infringement:

"Where's the line between two separate programs, and one program with 
two parts? This is a legal question, which ultimately judges will 
decide. We believe that a proper criterion depends both on the mechanism 
of communication (exec, pipes, rpc, function calls within a shared 
address space, etc.) and the semantics of the communication (what kinds 
of information are interchanged).

If the modules are included in the same executable file, they are 
definitely combined in one program. If modules are designed to run 
linked together in a shared address space, that almost surely means 
combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication 
mechanisms normally used between two separate programs. So when they are 
used for communication, the modules normally are separate programs. But 
if the semantics of the communication are intimate enough, exchanging 
complex internal data structures, that too could be a basis to consider 
the two parts as combined into a larger program."


> 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.

I'm not sure that is true, especially in the case of Octave.  The 
problem is that there is this very similar program called Matlab with a 
duplicate command set.  GUI Octave could just as well run using Matlab 
as an engine without too much extra effort.


> > > 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.

I understand what he is saying, but yesterday's "unique" is tomorrow's 
"old hat".  This whole licensing thing with version 1, 2, 3 and the L 
appended to GPL has a sort of mission creep aspect to it.  Its playing a 
game which in itself sort of defeats the spirit of free software. 
Should the license be changed simply because the application becomes 
popular or not-so-popular?

I kind of like what I think of as the original specification of GPL 
which is that there is this source code.  You may use the source code: 
compile it, bundle the compilation, etc.  But if one alters the source 
code, those alterations must be made available.  That leaves out the 
emotional advantage here, advantage there concerns.

So, does GUI Octave alter any source code?  Not that I'm aware of.


> 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. :-)

The MEX interface?  Is that the method by which C files can be compiled 
and interfaced to Matlab?  GUI Octave uses a MEX interface?

Dan