[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: |
Mon, 5 Jan 2009 23:58:22 +0530 |
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 <address@hidden>:
> 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 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 <=
- Re: Further on MEX, John W. Eaton, 2009/01/05
- Re: Further on MEX, David Bateman, 2009/01/05
- 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