Re: Further on MEX

[Aravindh Krishnamoorthy]

Dear John,

2009/1/6 John W. Eaton <address@hidden>:
> On  6-Jan-2009, Aravindh Krishnamoorthy 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.
>
> How does that help us, if they are not willing to share their work
> with us?  If they view Octave as a one-way charity project in which
> we are giving something to them and they are simply using it without
> contributing their work back to us?

1. Non-free numerical computation software cost quite a bit. Companies
_may_ be willing to sponsor the development?
2. Increased user base (non-contributing but perhaps they'll report
bugs?) -- what's your take increasing non-contributing user base?
3. Alongside M-code compatibility, Octave will also be an alternative
for MEX execution (non-free.)

>
> | => The MEX file writer links only against libmymex.so which is under LGPL.
> | => Octave uses mymex.h which is under LGPL.
>
> But once they are all linked together, the terms of the GPL apply.

Plugins of this sort stand on the border:
http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins

There's sure no dearth of ideas. But it must be made sure that the
terms aren't so open that mainstream Octave development may
potentially become non-free.

[Just to table an idea] Consider a binary protocol for mxArray
exchange -- something like X protocol. Consider a [server] side that's
linked to Octave which parses the protocol and performs various Octave
operations. When invoked to run a MEX file, this [server] side sets up
proper FDs for communication (pipes, etc) and fork/exec the client
side program.
Client side library is (say) under LGPL which translates it's mxArray
structure to the binary protocol above + provides main! and MEX
routines, and communicates with the server using FDs. The non-free MEX
file (client side program) is compiled against client side library. In
essence, this is like a binary M-code (execution environment
independent but platform dependent), but one that just supporting
mxArray transfer.

Octave [dynamic linking] mymexserver <- fork / file descriptors /
binary protocol -> mymexclient [dynamic linking] non-free code.

This method provides an alternate working environment for non-free MEX
code within Octave and may also be used in other numerical computation
applications.

Jaroslav Hajek said:
> 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.

Indeed. Perhaps this step attracts some corporations?
I'm willing to take this up -- but first I've to clarify a few terms
with my employer.

--

Hope you see a value addition to Octave with non-free MEX support.

-- ARK