More efficient MEX or MEX-like interface (was: Re: Private company and code salvation)

[John W. Eaton]

On 29-Sep-2008, address@hidden wrote:

| I've already expressed personally to John my belief that some sort of 
| API/ABI to Octave that allows distribution of the "user" code, not octave
| itself, is a limiting factor to companies uptake of Octave. John himself even 
| suggested offline a mex-like interface to Octave under such a license, 
| though that seems to be limiting for the code writer.

The issues with defining such an API mostly have to do with what
access should be provided to the user.  Allowing complete access to
all of liboctave is far too much (for practical as well as legal
reasons).  It seems clear to me that if a plugin uses Octave-specific
objects and interfaces defined in liboctave, then it is a derivative
work, so must be distributed under terms that are compatible with the
GPL no matter how the link step is performed.

The proper way to allow linking with non-free plugins is to use an
exception to the GPL.  However, that means changing the license of
Octave, and I'm not sure that we can do that given the number of
contributors and the fact that we have not been collecting copyright
disclaimers or assignments for some time now (I started out by doing
that, but then decided to stop in an effort to make development go
faster, and to attract more contributors).  Also, if we use an
exception, we must consider how that affects the licensing situation
with respect to all the dependencies that are linked with Octave.

| The current situation 
| where the freely distributable API to Octave is mex is a bit stupid,

I'm not sure I would call it the "freely distributable API".  Maybe
you mean the API that (apparently) allows non-free plugins (since we
can't really claim that a MEX file was written specifically for
Octave)?

But in any case, the current situation with Octave is that a MEX file
must be compiled and linked specifically for Octave since MEX files
compiled for Matlab are linked with Matlab libraries, so couldn't be
used directly in Octave (unless we provide stubs for those libraries,
I suppose).  Also, I seem to recall that on some systems, MEX files
built for Matlab are actually linked with the Matlab executable.  But
I guess these are two separate issues: (1) distribution of binary MEX
files for Octave (2) using binary MEX files built for Matlab with
Octave.
 
| though its the choice that FreeMat made and if Octave chooses to go that 
| way, then optimizing that interface becomes a priority.

One of the primary sources of efficiency problems for the MEX
interface is the difference in the way Octave handles data
internally.  For example, Octave stores complex data in arrays of
pairs of real and imaginary values while Matlab stores them in
separate real and imaginary arrays.  Since the MEX interface allows
direct access to the pointers to the real and imaginary arrays,
passing data in that arrangement forces a copy in Octave but not in
Matlab.  So if we want better effiency with this interface, I think we
have to rewrite much of the internals of Octave to store complex data
differently.

OTOH, we could maybe define a similar simplistic interface that
provides similar capabilities to the MEX interface but that is
efficient for the internals of Octave, but taht doesn't actually
expose the internals of Octave.  In that sense, it would just be a
slightly extended MEX interface.  Could we apply an exception to the
GPL for this interface?  I'm not sure.

In any case, discussions about how best to do this are probably more
appropriate for the maintainers list.

jwe