Re: Clarification about the octave-gpcl licensing conditions
On 10-Nov-2006, Rafael Laboissiere wrote: | I tend to think that such a change in Octave would be beneficial in many | aspects, including for fostering the use of Octave in academia. I have | already written Octave bindings for the CGAL (www.cgal.org) and the | Cubpack++ (www.cs.kuleuven.ac.be/~nines/software/cubpack/) libraries, but I | am afraid of releasing them, because of the potential GPL infringement. I am happy with using the GPL for Octave. Aside from that, there 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. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Clarification about the octave-gpcl licensing conditions
On 10-Nov-2006, Rafael Laboissiere wrote: | 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. 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. But, IANAL, so if you really want to pursue this, it might be best to ask the FSF. | The two libraries mentioned above are great and are "free" enough, besides | the infamous "non-commercial applications" clause. I sincerely think that | the upstream authors are confused, but we must understand their motivation | for imposing this licensing constraint. 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. jwe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Clarification about the octave-gpcl licensing conditions
* Rafael Laboissiere <[EMAIL PROTECTED]> [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. I tend to think that such a change in Octave would be beneficial in many aspects, including for fostering the use of Octave in academia. I have already written Octave bindings for the CGAL (www.cgal.org) and the Cubpack++ (www.cs.kuleuven.ac.be/~nines/software/cubpack/) libraries, but I am afraid of releasing them, because of the potential GPL infringement. The two libraries mentioned above are great and are "free" enough, besides the infamous "non-commercial applications" clause. I sincerely think that the upstream authors are confused, but we must understand their motivation for imposing this licensing constraint. [ Please, keep Cc: to debian-legal@lists.debian.org, as my original message was posted there. I hope the cross-posting is not abusive. M-F-T set accordingly. Cc:ed to Dirk Eddelbuettel, the maintainer of the R Debian packages. Dirk: this is just FYI. ] -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Clarification about the octave-gpcl licensing conditions
I am confused about the the licensing conditions of the octave-gpcl package and I need some advise from the debian-legalers. I am both the upstream author and the maintainer of octave-gpcl. This package provides the Octave (www.octave.org) binding for the General Polygon Clipper library (http://www.cs.man.ac.uk/~toby/alan/software/). The GPC library is released under a non-free license and is also packaged for Debian by me (libgpcl0 and libgpcl-dev). The problem arises because the octave-gpcl packages produces a loadable module (or plugin) in the form of a *.oct file that is loaded by Octave at run-time. However, Octave is released under the GPL (not the LGPL) meaning that it is not allowed to link any non-GPL compatible product against it and redistribute the whole thing. The situation seems to be similar to that of the readline library. My questions are: (1) should I move the octave-gpcl package from contrib to non-free? (2) If I could keep octave-gpcl under a GPL-compatible license (although it links against a non-free library), wouldn't that be an infringement of the GPL, which is Octave's license? (3) In any event, would it be legal at all to distribute Octave add-ons that link against non-free external libraries? (4) How would the situation be if Octave were released under the LGPL? [Please, keep Cc: to [EMAIL PROTECTED] I hope the cross-posting is not abusive. M-F-T set accordingly.] Thanks, -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
