octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Further on MEX


From: Aravindh Krishnamoorthy
Subject: Re: Further on MEX
Date: Tue, 6 Jan 2009 12:03:19 +0530

2009/1/6 David Bateman <address@hidden>:
> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]