Re: Clarification about the octave-gpcl licensing conditions

[Rafael Laboissiere]

[I am grouping Dirk's and John's replies below.  I apologize if it is too
long.  Feel free to create separate threads to discuss the sub-issues.]

* Dirk Eddelbuettel <address@hidden> [2006-11-10 12:14]:

> [ Huge IANAL disclaimer here ... I also stripped debian-legal as I wouldn't
> be able to follow up on threads there for lack of time and a missing
> inclination for legal introspection and self-flagellation.  Rafael, feel free
> to summarize there if you feel so inclined. ]

No problem.  There seems to be no reaction from the people in debian-legal.
I think that we can pursue the discussion in address@hidden, since
the issue is of more interest to the Octave crowds, anyway.

> Yep -- R defines its API through a set of exporting headers that are meant
> to be stable [ as opposed to some internal headers subject to change etc]. 
> AFAIK these headers are LGPL to impose fewer restriction even though the
> (much larger) rest of R, as well as the (and I am guestimating here) majority
> of the 800+ packages on cran.r-project.org and its mirrors.
> 
> On Debian these headers are in /usr/share/R/include; others may have them in
> /usr/(local)?/lib/R/include/.  Eg R.h has a clean LGPL header dated "2000,
> 2001".

I am still a little bit perplex that it is so simple to circumvent the GPL.
As John wrote:

* John W. Eaton <address@hidden> [2006-11-10 13:11]:

> My reading of this is that the R group thinks that it is possible to
> insert an LGPL layer in between software released under the terms of
> the GPL and software released under terms that would be incompatible
> with the GPL, and that makes everything OK.  I'm not sure that this is
> a valid way to avoid the terms of the GPL since once the entire
> program is linked together, the GPL-incompatible bits are linked with
> the GPL parts, and the GPL requires that it must be possible to
> distribute the whole program under terms compatible with the GPL.

I am afraid John is right.  This would be a huge problem for the R
developers.

Now, I think that this issue must be cleared.  It may be indeed the case
that it is simple to introduce a LGPL layer in Octave, which would address
the following issue raised by John:

* John W. Eaton <address@hidden> [2006-11-10 13:16]:

> [T]here are some practical problems to making a change in the license.
> First, there are many people who have contributed code under the terms of
> the GPL and who have not assigned changes to me, so we would need to
> contact all of them and get approval for changing the license. Second,
> Octave links with and includes directly code that is distributed under the
> terms of the GPL (various functions have been adapted from bash (and also I
> think Emacs) over the years, so we would need to deal with those parts as
> well.

Anyway, who should I contact to get further clarification on the issue?
John suggest the FSF.  Is there a specific e-mail address for enquiring
about such things?  Dirk suggested to contact Douglas Bates.  Should I do it?

* John W. Eaton <address@hidden> [2006-11-10 13:11]:

> Unfortunately, an additional restriction such as this is still an
> additional restriction, and that is not allowed by the GPL.  The GPL
> attempts to protect all users, not just those who wish to use the
> software for non-commercial purposes.

I fully understand this philosophical point of view, which is defended by
the FSF.  However, let me cite Richard Stallman's (in his essay "Why you
shouldn't use the Library GPL for your next library" [1]):

    Using the ordinary GPL is not advantageous for every library. There are
    reasons that can make it better to use the Library 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 Library GPL for that library.

I cannot resist to draw a parallel between the hypothetical situation above
with the actual situation of Octave and its commercial competitor.  Making a
way to get Octave to broaden its field of application would do more good
than worse, IMHO.  The usual IANAL disclaimer applies here.

[1] http://www.fsf.org/licensing/licenses/why-not-lgpl.html
 
-- 
Rafael