Re: Further on MEX

[David Bateman]

Aravindh Krishnamoorthy wrote:
> 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!
>   
I don't see why that is a surprise. If an m-file is released under the 
GPL then if it is used in another m-file, necessarily the other is 
GPLed.. But the Octave syntax even for the majority of the Octave-forge 
packages duplicates the same functionality and API of the equivalent 
matlab function, so the user can  legitimately say their code targeted 
matlab and just incidentally worked in Octave, which effectively 
circumvents this. This however is not true of functions that  are only 
in octave or octave-forge under the GPL.

> > 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
>   
I'm not sure that is needed in the case of the MEX ABI however, which is 
why I've recently suggest uses that as the means of giving proprietary 
code users of Octave at least some chance of distributing binary mex-files.

> 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 :-)]
>   

Yes sick and slow... Better to go for a fully matlab compatible MEX ABI 
and fall under the same argument as distribution of MEX code as source 
code.. That is of course if  we can't just consider that the current 
Octave MEX ABI isn't already  separate enough from Octave and closer to 
matlab that it doesn't already fall under the same argument.

Hey I consider myself an Octave developer and suspect others here do to, 
and I've advocated this position for quite a while.

D.


--
David Bateman                                address@hidden
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)