octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Further on MEX


From: David Bateman
Subject: Re: Further on MEX
Date: Tue, 06 Jan 2009 22:51:20 +0100
User-agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018)

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)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]