Private company and code salvation

David Bateman David.Bateman at motorola.com
Tue Sep 30 04:54:50 CDT 2008


Thomas Weber wrote:
> Am Sonntag, den 28.09.2008, 01:55 -0700 schrieb dbateman:
>   
>> Frankly, for wider commercial acceptance of Octave I believe its necessary
>> for Octave to define an API for compiled code that allows commercial
>> distribution of the code. Never the binaries as they would link against
>> liboctave and liboctinterp and so fall under the GPL of those libraries, but
>> still an LGPL API to Octave would be greatly appreciated,
>>     
>
> Such an interface would be a lawyer bomb; just imagine the linkage to
> other libraries under GPL, that link with Octave (FFTW comes to my
> mind).
>   
I agree which is why I've always said API and not ABI. That is the 
source code of the user and not the binary compiled and linked to 
Octave, which at the point of the linking becomes subject to the GPL. 
There is nothing to stop me from distributing a package now with the 
source of a mex-file that acts nicely with the Octave pkg command under 
whatever license I want as Octave does not control the mex API. Though 
that is stupid as Octave will always be inefficient using this API as it 
reflects the internals of Matlab itself. So the Octave community is 
effectively saying to any developer of non GPL code that you're better 
off writing for Matlab... Is that the message we want to pass?

> Maybe it's possible, maybe it isnt; however, Sergei's hint about ALSA
> made me aware of a different point. Say a company ships some commercial
> code, built against a convenient-licensed API. Now, for whatever reason
> (speed, bugs, ...), we change the API, incompatibly. What will happen?
>
> I guess that the company will tell the customer to just stay with the
> old version. That means 2.1.50 again, the version that just doesn't die.
>   
If we choose to standardize behind the use of the mex API for commercial 
use, then if we just add a mxGetZ and mxGetComplexData API to the mex 
API I don't see the need for significant changes after that, or at least 
only changes that track those that matlab themselves make.

If a commercial vendor chooses to lock their code down to a single 
version of Octave that they support then they loose all benefits of a 
common GPLed code base (ie the commodity code is shared and developed in 
common). I also can't see that happening as someone sold on the benefits 
of the GPL wouldn't want to limit themselves in that manner.

Again note I'm not advocating that a commercial user forgoes their moral 
responsibility to support the Octave community if they make a profit 
from code written by the Octave community. Only that the circumstances 
can arrive where they need to restrict some of their own code.

Regards
David

-- 
David Bateman                                David.Bateman at motorola.com
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary



More information about the Octave-maintainers mailing list