Re: Further on MEX

[Aravindh Krishnamoorthy]

Dear David,

>
> Or are you saying that if that m-file depends on a function that is only in
> Octave, and so can only run in Octave then its distribution is covered by
> the GPL? That position is perhaps more valid, but this hasn't been what I'd
> understood as being the licensing position on m-files in the past, and makes
> thing a real minefield for development with Octave for any one that works in
> Industry.

GNU GPL FAQ on interpreted files:
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
Also there's a note on using M-files that are distributed under GPL in
another M-file (last two paragraphs) -- which was quite a surprise to
me!

>
> We clearly can't take a position that an oct-file doesn't fall under the GPL
> as that exposes the entirety of Octave's internal outside the context of the
> protection of the GPL. I totally agree than an oct-file is and always will
> be covered by the GPL. What I'd like to see is that the MEX ABI is
> considered like the m-file API as being part of the Octave Octave language
> rather than the program and being outside the GPL.

IMHO, this isn't possible at the moment. As Octave is "Copyright (C)
2007 John W. Eaton and others." [_others_] and since John mentioned
(in the other thread) that he stopped collecting copyright related
information from contributors, I'm not sure even if an excessive audit
can separate the contributed code and re-license Octave under the
modified license.
http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface

>

One of the options that remains, however, is to convert MEX code to a
separate self-contained program (separate process) which communicates
with Octave for data exchange.

[One could stick with border-line plug-in cases but that would be
tricky and with re-definition of mxArray + will continue to be a
border-line case even then.]

If one were pressed to use their non-free MEX C/C++ code with code, he
will undoubtedly come out with a solution. You must be knowing the
many Linux embedded system developers that hide their proprietary
device driver code by using signals, mmap and writing their whole
device driver as a user-mode module.

This method [non-free linux dev drivers] is of course sick, and slow,
and so will be the options that allow MEX interaction with Octave.
Thing is -- I volunteered to write this code, but I won't because
there's opposition from John and other Octave developers. [I am
wanting to do some good development for Octave -- can't make enemies
here :-)]

Yours sincerely,
Aravindh Krishnamoorthy