octave-maintainers
[Top][All Lists]
Advanced

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

Re: Private company and code salvation


From: David Bateman
Subject: Re: Private company and code salvation
Date: Tue, 30 Sep 2008 11:54:50 +0200
User-agent: Thunderbird 2.0.0.17 (X11/20080926)

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                                address@hidden
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



reply via email to

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