Further on MEX

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Further on MEX

Aravindh Krishnamoorthy
Dear,

It was quite embarrassing to find that the MEX issue pointed out in
the earlier mail (octave-bugs) were fixed about six months ago on the
development archive.
Unrelated, here are some specific questions related to the MEX support:

1. [source-code] There are two lists for maintaining shared libraries:
src/dynamic-ld.cc: octave_shlib_list, octave_mex_file_list, while one
would have sufficed. This one (single list, if it existed) could be
extended to support Matlab styled 'loadlibrary', etc. functions. Why
are two lists maintained?

2. [feature-req] What is the take on supporting 'mexext' extensions
(mexw32 for Win32, mexglx for Linux32, etc.) ?

3. [feature-req] What is the take on supporting 'loadlibrary', etc
functions in Octave?

Also on a related note:
4. [matter-of-taste] I'd have liked a liboctavemex.so (with mx... MEX
functions) released under LGPL, but I'm not sure how strong supporters
of software-freedom and GPL the Octave team is. Would you pls. comment
on this?

Based on your response, I'd like to take up items 1-4 above.

Yours sincerely,
Aravindh Krishnamoorthy
Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

Søren Hauberg
Hi,
  I cannot comment on points 1-3, but

søn, 04 01 2009 kl. 15:27 +0530, skrev Aravindh Krishnamoorthy:
> Also on a related note:
> 4. [matter-of-taste] I'd have liked a liboctavemex.so (with mx... MEX
> functions) released under LGPL, but I'm not sure how strong supporters
> of software-freedom and GPL the Octave team is. Would you pls. comment
> on this?

I think people have different feelings about this. The GPL encourages
freedom much more than the LGPL, which IMHO is a good thing. But LGPL
would have some practical benefits, such as being able to link with
libraries that are Free, but not GPL compatible.

That being said, I doubt that a move to LGPL is possible as it would
require getting permission to relicense code written by many
contributors. This is a tedious and time-consuming task, that also would
require legal expertise. I doubt that anybody would want to work on such
a task, even if it was decided that LGPL would be good. Also, Octave
links to quite a few libraries that are only GPL, which makes Octave
"inherit" this license.

Søren


Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

David Bateman-2
Søren Hauberg wrote:

> Hi,
>   I cannot comment on points 1-3, but
>
> søn, 04 01 2009 kl. 15:27 +0530, skrev Aravindh Krishnamoorthy:
>  
>> Also on a related note:
>> 4. [matter-of-taste] I'd have liked a liboctavemex.so (with mx... MEX
>> functions) released under LGPL, but I'm not sure how strong supporters
>> of software-freedom and GPL the Octave team is. Would you pls. comment
>> on this?
>>    
>
> I think people have different feelings about this. The GPL encourages
> freedom much more than the LGPL, which IMHO is a good thing. But LGPL
> would have some practical benefits, such as being able to link with
> libraries that are Free, but not GPL compatible.
>
> That being said, I doubt that a move to LGPL is possible as it would
> require getting permission to relicense code written by many
> contributors. This is a tedious and time-consuming task, that also would
> require legal expertise. I doubt that anybody would want to work on such
> a task, even if it was decided that LGPL would be good. Also, Octave
> links to quite a few libraries that are only GPL, which makes Octave
> "inherit" this license.
>
> Søren
>
>
>
>  
The thread contains some of the thought along these lines.

http://www.nabble.com/Private-company-and-code-salvation-to19676490.html

also

http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2008-September/008674.html

contain thoughts along these lines

D.


--
David Bateman                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

Michael Goffioul
In reply to this post by Aravindh Krishnamoorthy
On Sun, Jan 4, 2009 at 9:57 AM, Aravindh Krishnamoorthy
<[hidden email]> wrote:
> 3. [feature-req] What is the take on supporting 'loadlibrary', etc
> functions in Octave?

Calling a foreign function in binary form (that is, without a compilation
step) will inevitably involve some assembly coding and will be
processor specific. I've worked on this in the past to bridge LISP
with foreign C code and it's not a straightforward job (it's more
than just loading a shared library; you have to know how to pass
arguments to functions, in which registers, in which order, how
to clean up the stack...). There are probably some libraries out there
to ease this task (IIRC one was named fficall).

Michael.
Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

Aravindh Krishnamoorthy
Dear Michael,

You're pointing to: libffi. BSD licensed libffi can handle calls +
parameter passing. Thanks.

Also, of course, we'd like to restrict the shared-object's to the
respective platform: Linux .so's from Linux, Windows .DLLs from
Windows. Sensible?

Also, Matlab requires a header file (with c-signatures) to be passed
during 'loadlibrary' call which is parsed using perl (best I can
remember.) ATM, I don't know how we mirror that to Octave.

Yours sincerely,
Aravindh

2009/1/5 Michael Goffioul <[hidden email]>:

> On Sun, Jan 4, 2009 at 9:57 AM, Aravindh Krishnamoorthy
> <[hidden email]> wrote:
>> 3. [feature-req] What is the take on supporting 'loadlibrary', etc
>> functions in Octave?
>
> Calling a foreign function in binary form (that is, without a compilation
> step) will inevitably involve some assembly coding and will be
> processor specific. I've worked on this in the past to bridge LISP
> with foreign C code and it's not a straightforward job (it's more
> than just loading a shared library; you have to know how to pass
> arguments to functions, in which registers, in which order, how
> to clean up the stack...). There are probably some libraries out there
> to ease this task (IIRC one was named fficall).
>
> Michael.
>
Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

Aravindh Krishnamoorthy
In reply to this post by David Bateman-2
Dear David,

Informative threads, thank you for the links.

Some points:
1. The idea of the exercise must be to allow "controlled" interaction
of MEX with Octave => To aid execution of non-free MEX software
(required in some practical cases), and not to circumvent the freedom
granted in GPL. IMHO doing so [MEX] increases the reception of Octave.

2. Extending the option of linking non-free software with Octave's OCT
(even if it's done) is bad => Makes room for binary-blobs in core
Octave and toolboxes.

Also:
I can understand that re-licensing Octave under LGPL is not practical,
not even good.

Kindly comment on the method below:
1. An independent library with MEX functionality (under LGPL or BSD
license) is used to link the non-free code.
2. The 'calllib' call is implemented in Octave and is extended to
allow exchange of mxArray arguments in a call to 'mexFunction.' =>
equivalent of a mex call.

This method is obviously slow and is not a replacement for rewriting
Octave's toolbox functions as much it is a desperate measure to run
non-free code within Octave.

What do you think?

-- ARK

2009/1/5 David Bateman <[hidden email]>:

> Søren Hauberg wrote:
>>
>> Hi,
>>  I cannot comment on points 1-3, but
>>
>> søn, 04 01 2009 kl. 15:27 +0530, skrev Aravindh Krishnamoorthy:
>>
>>>
>>> Also on a related note:
>>> 4. [matter-of-taste] I'd have liked a liboctavemex.so (with mx... MEX
>>> functions) released under LGPL, but I'm not sure how strong supporters
>>> of software-freedom and GPL the Octave team is. Would you pls. comment
>>> on this?
>>>
>>
>> I think people have different feelings about this. The GPL encourages
>> freedom much more than the LGPL, which IMHO is a good thing. But LGPL
>> would have some practical benefits, such as being able to link with
>> libraries that are Free, but not GPL compatible.
>>
>> That being said, I doubt that a move to LGPL is possible as it would
>> require getting permission to relicense code written by many
>> contributors. This is a tedious and time-consuming task, that also would
>> require legal expertise. I doubt that anybody would want to work on such
>> a task, even if it was decided that LGPL would be good. Also, Octave
>> links to quite a few libraries that are only GPL, which makes Octave
>> "inherit" this license.
>>
>> Søren
>>
>>
>>
>>
>
> The thread contains some of the thought along these lines.
>
> http://www.nabble.com/Private-company-and-code-salvation-to19676490.html
>
> also
>
> http://www-old.cae.wisc.edu/pipermail/octave-maintainers/2008-September/008674.html
>
> contain thoughts along these lines
>
> D.
>
>
> --
> David Bateman                                [hidden email]
> 35 rue Gambetta                              +33 1 46 04 02 18 (Home)
> 92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

John W. Eaton
Administrator
On  5-Jan-2009, Aravindh Krishnamoorthy wrote:

| Kindly comment on the method below:
| 1. An independent library with MEX functionality (under LGPL or BSD
| license) is used to link the non-free code.
| 2. The 'calllib' call is implemented in Octave and is extended to
| allow exchange of mxArray arguments in a call to 'mexFunction.' =>
| equivalent of a mex call.

Please don't look for technical ways to try to circumvent the GPL.
Simply inserting some code that is covered by the LGPL in between code
that is covered by the GPL and code that uses some incompatible
license does not allow you to aovid the terms of the GPL.  If all the
parts are combined in a single work, the terms of the GPL must be
followed.

| This method is obviously slow and is not a replacement for rewriting
| Octave's toolbox functions as much it is a desperate measure to run
| non-free code within Octave.

Instead of desparate measures to run non-free code in Octave, I think
it would be better to find ways to create free software that does the
job of the non-free code.  That way, the free softare community
benefits from the work.

jwe

__
A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?
Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

David Bateman-2
John W. Eaton wrote:

> On  5-Jan-2009, Aravindh Krishnamoorthy wrote:
>
> | Kindly comment on the method below:
> | 1. An independent library with MEX functionality (under LGPL or BSD
> | license) is used to link the non-free code.
> | 2. The 'calllib' call is implemented in Octave and is extended to
> | allow exchange of mxArray arguments in a call to 'mexFunction.' =>
> | equivalent of a mex call.
>
> Please don't look for technical ways to try to circumvent the GPL.
> Simply inserting some code that is covered by the LGPL in between code
> that is covered by the GPL and code that uses some incompatible
> license does not allow you to aovid the terms of the GPL.  If all the
> parts are combined in a single work, the terms of the GPL must be
> followed.
>  
An API and ABIs are different beasts... MEX as an API doesn't invoke the
GPL as we can't legitimately say the code is for Octave when it is in
source form... Link it to Octave through Octave's ABI implementation of
MEX and your interpretation of GPL certainly means that the resulting
binary is under the GPL.

A close parallel is GCC compiling a proprietary piece of code. The GPLed
GCC generates binary code from the users proprietary code and  links to
the system libraries, where gnu's libc is under the LGPL... So the
compiling of the MEX code to a binary form with GCC doesn't invoke the
GPL, but linking to liboctave and liboctinterp does.

I see no way around this unless there is an official tolerance in that
MEX binaries for Octave can be distributed without falling under the GPL.

> | This method is obviously slow and is not a replacement for rewriting
> | Octave's toolbox functions as much it is a desperate measure to run
> | non-free code within Octave.
>
> Instead of desparate measures to run non-free code in Octave, I think
> it would be better to find ways to create free software that does the
> job of the non-free code.  That way, the free softare community
> benefits from the work.
>  
I agree in principal, but unfortunately that is not always an option for
those people in companies. There are numerous reasons from a desire to
protect certain  key pieces of company knowledge, to "that heap of shit
proprietary code that we all use was first written by the boss" (an
before you ask I haven't personally come across the second case).

There are certainly risks in accepting a MEX like ABI for Octave that
doesn't fall under the GPL, though it would expose any of liboctave or
liboctinterp. However I believe it would be a selling point for Octave
in certain circumstances

D.


> jwe
>
> __
> A: Yes.
>  > Q: Are you sure?
>  >> A: Because it reverses the logical flow of conversation.
>  >>> Q: Why is top posting annoying in email?
>
>  


--
David Bateman                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

Aravindh Krishnamoorthy
2009/1/6 David Bateman <[hidden email]>:

> John W. Eaton wrote:
>>
>> On  5-Jan-2009, Aravindh Krishnamoorthy wrote:
>>
>> | Kindly comment on the method below:
>> | 1. An independent library with MEX functionality (under LGPL or BSD
>> | license) is used to link the non-free code.
>> | 2. The 'calllib' call is implemented in Octave and is extended to
>> | allow exchange of mxArray arguments in a call to 'mexFunction.' =>
>> | equivalent of a mex call.
>>
>> Please don't look for technical ways to try to circumvent the GPL.
>> Simply inserting some code that is covered by the LGPL in between code
>> that is covered by the GPL and code that uses some incompatible
>> license does not allow you to aovid the terms of the GPL.  If all the
>> parts are combined in a single work, the terms of the GPL must be
>> followed.
>>
>
> An API and ABIs are different beasts... MEX as an API doesn't invoke the GPL
> as we can't legitimately say the code is for Octave when it is in source
> form... Link it to Octave through Octave's ABI implementation of MEX and
> your interpretation of GPL certainly means that the resulting binary is
> under the GPL.
>
> A close parallel is GCC compiling a proprietary piece of code. The GPLed GCC
> generates binary code from the users proprietary code and  links to the
> system libraries, where gnu's libc is under the LGPL... So the compiling of
> the MEX code to a binary form with GCC doesn't invoke the GPL, but linking
> to liboctave and liboctinterp does.
>
> I see no way around this unless there is an official tolerance in that MEX
> binaries for Octave can be distributed without falling under the GPL.
>

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.

Here's more explanation about what I mean:
Say there's a library called libmymex.so which implements a reduced
subset of MEX routines (mxGetM/N, mxGetPr/Pi, mxCreateDoubleMatrix to
boot) and defines mxArray structure (mymex.h). Say the library is
under LGPL.

Say Octave includes mymex.h and provides a method for exchange of this
mxArray (using calllib, callmex, whatever), then in theory, Octave can
run the MEX function and get the results.

=> The MEX file writer links only against libmymex.so which is under LGPL.
=> Octave uses mymex.h which is under LGPL.

So you can't claim that either source or the resulting shared library
are generated for Octave, but Octave acts as a plugin holder [and so
does any other software that supports libmymex) Additionally no data
structures are shared between Octave and the MEX file (except
parameters). I agree that this distorts the view on what a MEX is, and
does not allow MEX routines that interact with Octave, but it allows
non-free C-code to be compiled to a MEX-like file which can run under
Octave.

=> Question is whether such a thing is good for Octave.
=> Also, question is whether GPL is still applicable. (My guess is 'no.')

>> | This method is obviously slow and is not a replacement for rewriting
>> | Octave's toolbox functions as much it is a desperate measure to run
>> | non-free code within Octave.
>>
>> Instead of desparate measures to run non-free code in Octave, I think
>> it would be better to find ways to create free software that does the
>> job of the non-free code.  That way, the free softare community
>> benefits from the work.
>>
>
> I agree in principal, but unfortunately that is not always an option for
> those people in companies. There are numerous reasons from a desire to
> protect certain  key pieces of company knowledge, to "that heap of shit
> proprietary code that we all use was first written by the boss" (an before
> you ask I haven't personally come across the second case).
>
> There are certainly risks in accepting a MEX like ABI for Octave that
> doesn't fall under the GPL, though it would expose any of liboctave or
> liboctinterp. However I believe it would be a selling point for Octave in
> certain circumstances

Would you please explain the risk in the point above?

-- ARK

Hmm.
>> __ A: Yes.
>>  > Q: Are you sure?
>>  >> A: Because it reverses the logical flow of conversation.
>>  >>> Q: Why is top posting annoying in email?
Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

John W. Eaton
Administrator
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?

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

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

Jaroslav Hajek-2
In reply to this post by Aravindh Krishnamoorthy
On Tue, Jan 6, 2009 at 7:33 AM, Aravindh Krishnamoorthy
<[hidden email]> 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.

regards


--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

Aravindh Krishnamoorthy
In reply to this post by John W. Eaton
Dear John,

2009/1/6 John W. Eaton <[hidden email]>:

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

David Bateman-2
In reply to this post by Jaroslav Hajek-2
Jaroslav Hajek wrote:

> On Tue, Jan 6, 2009 at 7:33 AM, Aravindh Krishnamoorthy
> <[hidden email]> 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                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

David Bateman-2
In reply to this post by Aravindh Krishnamoorthy
Aravindh Krishnamoorthy wrote:
>> There are certainly risks in accepting a MEX like ABI for Octave that
>> doesn't fall under the GPL, though it would expose any of liboctave or
>> liboctinterp. However I believe it would be a selling point for Octave in
>> certain circumstances
>>    
>
> Would you please explain the risk in the point above?
>  
 From Octave's point of view accepting that the Octave MEX ABI doesn't
invoke the GPL, might be considered as weakening the protection of
Octave under the GPL.

For the developer of a proprietary MEX file, can they be sure that a
previous developer of Octave might consider that the MEX ABI exclusion
might be illegitimate and take independent action against the MEX file
developer.

Frankly, the moment we included the MEX API in the core of Octave itself
and set the precedence that the MEX API effectively didn't invoke the
GPL, at that point there was good grounds for protection of any
proprietary distribution of MEX files for use with Octave.


D.

--
David Bateman                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

John W. Eaton
Administrator
In reply to this post by David Bateman-2
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.

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

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

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

Aravindh Krishnamoorthy
Dear John,

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

I was under the impression that you'd like to encourage proprietary
addons and found it useful so long as they didn't interfere with core
Octave development.

I don't want to circumvent the views of the Octave community (and GPL)
in implementing a feature -- non-free MEX support will be implemented
by me only if Octave community agrees to it. So, at the moment, NO.

However, I'll continue to contribute to Octave/C++. For numerical
computation code, I'll have to check employment terms regarding
open-source contribution.

Yours sincerely,
Aravindh
Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

John W. Eaton
Administrator
On  7-Jan-2009, Aravindh Krishnamoorthy wrote:

| I was under the impression that you'd like to encourage proprietary
| addons

Where did you ever get that idea?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

Aravindh Krishnamoorthy
Dear John,

On 07/01/2009, John W. Eaton <[hidden email]> wrote:
> On  7-Jan-2009, Aravindh Krishnamoorthy wrote:
>
> | I was under the impression that you'd like to encourage proprietary
> | addons
>
> Where did you ever get that idea?
>

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

My understanding from your earlier mails was different. But now I
understand exactly your thoughts about future of proprietary add-ons
for Octave.
I'm not going to work on the pipe-based binary bridge.

Yours sincerely,
Aravindh
Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

David Bateman-2
In reply to this post by John W. Eaton
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                                [hidden email]
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)

Reply | Threaded
Open this post in threaded view
|

Re: Further on MEX

Aravindh Krishnamoorthy
Dear David,

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

GNU GPL FAQ on interpreted files:
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
Also there's a note on using M-files that are distributed under GPL in
another M-file (last two paragraphs) -- which was quite a surprise to
me!

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

IMHO, this isn't possible at the moment. As Octave is "Copyright (C)
2007 John W. Eaton and others." [_others_] and since John mentioned
(in the other thread) that he stopped collecting copyright related
information from contributors, I'm not sure even if an excessive audit
can separate the contributed code and re-license Octave under the
modified license.
http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface

>

One of the options that remains, however, is to convert MEX code to a
separate self-contained program (separate process) which communicates
with Octave for data exchange.

[One could stick with border-line plug-in cases but that would be
tricky and with re-definition of mxArray + will continue to be a
border-line case even then.]

If one were pressed to use their non-free MEX C/C++ code with code, he
will undoubtedly come out with a solution. You must be knowing the
many Linux embedded system developers that hide their proprietary
device driver code by using signals, mmap and writing their whole
device driver as a user-mode module.

This method [non-free linux dev drivers] is of course sick, and slow,
and so will be the options that allow MEX interaction with Octave.
Thing is -- I volunteered to write this code, but I won't because
there's opposition from John and other Octave developers. [I am
wanting to do some good development for Octave -- can't make enemies
here :-)]

Yours sincerely,
Aravindh Krishnamoorthy
12