|
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:
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?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).
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.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 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@hiddenMotorola 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
[Prev in Thread] | Current Thread | [Next in Thread] |