Re: [OctDev] Octave-forge packaging

[Dan McMahill]

On Sat, Apr 23, 2005 at 10:16:48AM -0400, John W. Eaton wrote:
> On 23-Apr-2005, Dmitri A. Sergatskov <address@hidden> wrote:
> 
> | Quentin Spencer wrote:
> | ...
> | > anyone out there tell me how this is done for Debian? Furthermore, I 
> | > wonder if it wouldn't be better to make the nonfree part a separate 
> | > package or remove it from octave-forge--does anyone even use it?
> | > 
> | 
> | I like csaps (from nonfree/splines/). The only non-free file there
> | is gcvsplf.f (taken from netlib). I could not find any license info
> | on netlib, but octave-forge has  LICENSE.gcvsplf which pretty much
> | prohibits commercial use of the software (not commercial distribution,
> | as far as I can tell -- IANAL).
> 
> Isn't commercial distribution a commercial use?  It depends on
> precisely what is meant by "use".  But in any case, a license that
> prohibits commercial use (in any sense) would be incompatible with the
> GPL, so it could not be linked with and distributed as part of Octave.
> 
> Since Octave is distributed under the plain GPL with no exceptions, it
> doesn't allow non-free plugins.  So if the code is linked with Octave
> as a plugin (through the DEFUN_DLD interface or by any other means), I
> would ask that you stop distributing it.
> 
> My interpretation of the GPL is essentially the same as that of the
> FSF when it comes to plugins.  You can find more information in the
> GPL FAQ.  Now, I do see that the following question and answer
> 
>   http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
> 
> says
> 
>   If a program released under the GPL uses plug-ins, what are the
>   requirements for the licenses of a plug-in?
> 
>   It depends on how the program invokes its plug-ins. If the program
>   uses fork and exec to invoke plug-ins, then the plug-ins are separate
>   programs, so the license for the main program makes no requirements
>   for them.
> 
>   If the program dynamically links plug-ins, and they make function
>   calls to each other and share data structures, we believe they form a
>   single program, which must be treated as an extension of both the main
>   program and the plug-ins. This means the plug-ins must be released
>   under the GPL or a GPL-compatible free software license, and that the
>   terms of the GPL must be followed when those plug-ins are
>   distributed.

yuck.  so a BSD licensed library which provides a mex interface to it
would not be compatible with this.  It would be unfortunate if the GPL
prevented the distribution of free software which included a mex
frontend.

>   If the program dynamically links plug-ins, but the communication
>   between them is limited to invoking the `main' function of the plug-in
>   with some options and waiting for it to return, that is a borderline
>   case.

Or perhaps you view a mex interface more in this category?  The interface
seems fairly well defined.  In other words its not like octave and
a mex plugin make lots of random function calls.

> So the distribution of some non-free plugins with Octave may fall into
> the borderline category mentioned in the final paragraph of the
> answer.

I usually avoid the GPL vs BSD license flamewar, but, by 'non-free'
here its really 'non-GPL'.  Certainly BSD licensed software is free,
but the GPL would seem to prevent use of BSD licensed plug-ins.


> In any case, as a practical matter, it is not a good thing to write
> interfaces to non-free software for Octave.  The reason is that it
> tends to delay the creation of free software to solve the same
> problem.

But the reality is that sometimes the effort of writing an octave
interface to non-GPL software is 1% of the effort of replacing the
other tool.  An example would be:

- an octave frontend to Berkeley SPICE.  I don't think anyone has
written one, but it probably wouldn't be too hard and certainly
much much less work than writing your own GPL simulator.  In fact
the size of the problem is why the NG-spice project backed off
from their original goal of a complete rewrite as a GPL program.

> Finally, the above only applies to code that is linked with Octave.
> If the package consists entirely of .m files, then it does not violate
> the Octave license terms if it has a non-free license.  But it is
> still much better if the package uses a free software license.
 
In general, I think the plug-in licensing ideas here are unfortunate.
I could easily envision a company which already provides a matlab mex
interface to one of their products wanting to release an octave mex
version too.  The amount of extra work for them is minimal and it may
make some of their customers happy.  What it does is prevent people
who may want to use octave and even contribute improvements from
using it if they're tied, due to the GPL no less, to using matlab.


-Dan


--