[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Further on MEX
From: |
David Bateman |
Subject: |
Re: Further on MEX |
Date: |
Tue, 06 Jan 2009 01:08:59 +0100 |
User-agent: |
Mozilla-Thunderbird 2.0.0.17 (X11/20081018) |
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 address@hidden
35 rue Gambetta +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob)
- Further on MEX, Aravindh Krishnamoorthy, 2009/01/04
- Re: Further on MEX, Søren Hauberg, 2009/01/04
- Re: Further on MEX, David Bateman, 2009/01/04
- Re: Further on MEX, Aravindh Krishnamoorthy, 2009/01/05
- Re: Further on MEX, John W. Eaton, 2009/01/05
- Re: Further on MEX,
David Bateman <=
- Re: Further on MEX, Aravindh Krishnamoorthy, 2009/01/06
- Re: Further on MEX, John W. Eaton, 2009/01/06
- Re: Further on MEX, Aravindh Krishnamoorthy, 2009/01/06
- Re: Further on MEX, Jaroslav Hajek, 2009/01/06
- Re: Further on MEX, David Bateman, 2009/01/06
- Re: Further on MEX, John W. Eaton, 2009/01/06
- Re: Further on MEX, Aravindh Krishnamoorthy, 2009/01/07
- Re: Further on MEX, John W. Eaton, 2009/01/07
- Re: Further on MEX, Aravindh Krishnamoorthy, 2009/01/07
- Re: Further on MEX, David Bateman, 2009/01/07