Re: Further on MEX

[John W. Eaton]

Before I respond to your points, I want to say that my reason for
improving Paul Kienzle's original MEX interface code and including it
in Octave was to allow Octave to run free software that uses MEX files
(my particular goal was to run SundialsTB in Octave).  The point was
to liberate that software from Matlab and increase the amount of free
software available to Octave users, not to enable people to write
proprietary code for Octave.  Regardless of what we decide for MEX
files, I still would not encourage anyone to write proprietary
additions to Octave.

On  7-Jan-2009, David Bateman wrote:

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

No.  The GPL FAQ covers this topic in the question:

  Q:  If a programming language interpreter is released under the GPL,
  does that mean programs written to be interpreted by it must be
  under GPL-compatible licenses?

  A:  When the interpreter just interprets a language, the answer is
  no. The interpreted program, to the interpreter, is just data; a
  free software license like the GPL, based on copyright law, cannot
  limit what data you use the interpreter on. You can run it on any
  data (interpreted program), any way you like, and there are no
  requirements about licensing that data to anyone.

The answer for this question goes on to discuss what happens when
linking with software that is not merely interpreted:

  However, when the interpreter is extended to provide ?bindings? to
  other facilities (often, but not necessarily, libraries), the
  interpreted program is effectively linked to the facilities it uses
  through these bindings. So if these facilities are released under the
  GPL, the interpreted program that uses them must be released in a
  GPL-compatible way. The JNI or Java Native Interface is an example of
  such a binding mechanism; libraries that are accessed in this way are
  linked dynamically with the Java programs that call them. These
  libraries are also linked with the interpreter. If the interpreter is
  linked statically with these libraries, or if it is designed to link
  dynamically with these specific libraries, then it too needs to be
  released in a GPL-compatible way.

However, as you point out, the details of the MEX interface raise some
interesting issues.

  * The MEX interface is not unique to Octave (it's not even our
    interface).

  * It is easy enough to write and compile MEX files that do not even
    include mex.h or link to any Octave- or Matlab-specific libraries
    and that can be loaded and run by either program.  You don't even
    need Matlab or Octave on a computer in order to build a
    functioning MEX file.

  * Except for a small number of functions (mexCallMATLAB,
    mexEvalString, mexGetVariable, mexPutVariable, etc.) all a MEX
    file can do is

      - accept some data in mxArray format (not unique to Octave)
      - manipulate it via the mxFOO functions
      - call mexFOO functions
      - return data in the mxArray format.

  * Even the mexFOO functions (mexCallMATLAB, mexEvalString, etc.)
    only permit doing things that could be done in the scripting
    language itself (call functions, evaluation scripting language
    code, get/set variable values, etc.).

  * The MEX interface does not allow access to arbitrary internal
    functions of MATLAB (or Octave, in the Octave implementation).

OK.  Hmm.  It does seem to me that claiming a MEX file as a
derivative work of Octave is a bit of a stretch given the specifics of
this case.  But before we decide, I'd like to know what the FSF
position is for this case (I'll ask).

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

OK.  Changing this would be OK for me.  Should we even bother to try
to support code that uses the older interface?  Should mexproto.h
include a prototype for mexFunction so that we enforce the const
interface?

jwe