octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Clarification about the octave-gpcl licensing conditions


From: Dirk Eddelbuettel
Subject: Re: Clarification about the octave-gpcl licensing conditions
Date: Fri, 10 Nov 2006 12:14:33 -0600

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

On 10 November 2006 at 18:46, Rafael Laboissiere wrote:
| * Rafael Laboissiere <address@hidden> [2006-11-09 10:59]:
| 
| > (4) How would the situation be if Octave were released under the LGPL?
| 
| I investigated this issue further and discovered that R (www.r-project.org),
| which is released under the GPL, faced the same problem years ago.  R
| operates under the same way as Octave, with modules written as dynamically
| loaded plugins.  For instance, the R binding for the GPC library that I
| mentioned in my previous post is packaged as a module and distributed at
| CRAN:
| 
|     http://cran.stat.ucla.edu/src/contrib/Descriptions/gpclib.html
| 
| This is possible thanks to the changes made in the R licensing terms. From
| the announcement of the change (2001-Feb-05):
| 
|     It came to our attention that some projects are interpreting GPL to
|     mean that compiling against the header files or linking against a
|     Windows import library brings the compiled code under the scope of
|     GPL.  This would mean it would be impossible to distribute binary
|     versions of non-GPL packages with compiled code which called entry
|     points in the R executable or DLL, of which there are many on CRAN.
| 
|     We encourage packages to be distributed under Open Source conditions,
|     but accept that this is not possible for some contributions.  Our
|     intention is that export files and import libraries be `accessors'
|     under clause 5 of the LGPL, so that in most cases no (additional)
|     restrictions are imposed by compiling a package using the LGPL-ed
|     components of R.
| 
|     To avoid any anomalies, the versions of the same files in R versions
|     1.0.0 to 1.2.1 may also be used under LGPL or GPL.

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".
     
>From what I see as a moderately outside outside observer, R Core takes the
GNU GPL rather seriously, but also aims to reach out which may have been the
motivation for this 'lesser' license of the interface.

For the mechanics of this and historical context, it may be easiest for John
to touch base with Doug Bates in person on the next visit to Madison.

Hth, Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison


reply via email to

[Prev in Thread] Current Thread [Next in Thread]