Re: [OctDev] Octave-forge packaging

[John W. E. <jw...@be...>]

On 23-Apr-2005, Dmitri A. Sergatskov <das...@gm...> 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.

  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.

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

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.

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.

jwe