Re: Further on MEX

[David Bateman]

Jaroslav Hajek wrote:
> On Tue, Jan 6, 2009 at 7:33 AM, Aravindh Krishnamoorthy
> <address@hidden> wrote:
>
>   
> > Unfortunately, not all buy the argument that source code must be free.
> > If by allowing this, we're extending the reach of Octave and at the
> > same time ensuring that core parts + toolboxes of Octave don't end up
> > being non-free; trouble? (Of course, there's no guarantee that we
> > ensure this!!!)
> > People I talk to around here (who protect their sources using MEX) do
> > not use Octave for the GPL reason. This is a way to push Octave's
> > usage to them, now that you've brought it [Octave] in a very good
> > shape => from 3.0.x Octave is _so_ much compatible with Matlab.
> >
> >     
>
> IMHO, unless some company sponsors the creation of such an API, it
> will stay in the land of thoughts.
> It brings no direct advantage for us free software developers, so we
> obviously lack the motivation.
>   
Some free software developers work for companies with a lot of 
proprietary code and so I think there is no issue in finding some one to 
write the code.. The API/ABI exists already in the form of MEX. We only 
have to optimize that a bit to avoid some of the current copying of data 
in the Octave MEX implementation. For example with functions to get/set 
C99 complex values, and avoid the copy when an octave_value is converted 
to an mxArray if the MEX api is greater than v4....

However it serves nothing to do that if the resulting ABI falls under 
the GPL. The API already doesn't. So a clear statement such such an ABI 
that doesn't fall under the GPL is needed. Note alternatively some one 
might try to create a fully Matlab compatible MEX ABI for Octave, though 
to get all of the platforms supported would be difficult and what about 
the platform Matlab doesn't support? Though the code implementing the 
ABI would be under the GPL, the compiled MEX functions wouldn't. How 
could you say that a compiled MEX file that could be used with Octave or 
Matlab be subject to the GPL?

For the hell of it I tried

cd examples
mkoctfile --mex myhello.c
nm -C --dynamic myhello.mex

and the only unresolved symbols in the compiled mex-file are 
mxCreateDoubleMatrix and mxGetPr, maybe even getting a compatible ABI 
wouldn't be that hard either... It is also clear that there is no direct 
use of any Octave internal class, function or method..

Since we already have an API to Octave that doesn't invoke the GPL and 
there exists a technical means to get an ABI that doesn't invoke the GPL 
for the distribution of compiled MEX files, why should we make a fuss 
about just accepting that the existing Octave MEX ABI itself doesn't 
invoke the GPL for the distribution of compiled MEX files?

D.



> regards
>
>
>   


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