Re: Further on MEX

[David Bateman]

John W. Eaton wrote:
> On  6-Jan-2009, David Bateman wrote:
>
> | 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,
>
> It seems to me that if you add new functions that are only in Octave
> and then write code that uses those functions, that you have something
> that depends on Octave.
>   
But Octave, as well as being a program, is a numerical language. Your 
stand comes down to saying that any idea that is expressed in the Octave 
language is covered by the GPL... Thats not a reasonable position 
basically because if a person writes an m-file, that m-file might be run 
in Octave or Matlab and so clearly doesn't fall under the GPL.

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.

The argument we are having now is whether the line between Octave as a 
language and Octave as a program should be defined as falling somewhere 
where it is possible to write compiled code for Octave. In fact my 
position is that the introduction of MEX in to the core of Octave 
created a situation where there is a doubt of where that line falls.

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.

I propose to write an FAQ entry that will help clarify this..

> | and avoid the copy when an octave_value is converted 
> | to an mxArray if the MEX api is greater than v4....
>
> What is it that is dependent on the version?
>   
The API of mexFunction is different between v4 and v5.. That is  
"mxArray *prhs[]" is marked as const in V5 and later. So we can make the 
assumption that the RHS is const and use that to avoid a copy.
> | 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?
>
> My objection is that it is at least against the spirit of the GPL and
> I would not like to move further in this direction.  I have no
> interest in encouraging proprietary add-ons for Octave.
>
>   
What is an add-on to the Octave Program and what is an expression of an 
idea in the Octave language?

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)