Re: Private company and code salvation

[Levente Torok]

On Tuesday 30 September 2008, Olaf Till wrote:
> On Tue, Sep 30, 2008 at 12:49:09PM +0200, David Bateman wrote:
> > Jaroslav Hajek wrote:
> > >Well, maybe we do. It's true, after all.
> > >One of the key points of GPL is providing advantage for other
> > >developers of GPL-compatible software. That's how GPL differs from BSD
> > >(or LGPL etc). That's the "viral nature" of GPL (quoting W. Gates).
> > >And that's precisely the case we're talking about now: GPL developers
> > >have the advantage of oct-file API, while non-GPL developers don't.
> > >The GPL is doing here just what it's supposed to do. I say, if we
> > >(community) are unhappy with it, trying to trick the GPL is stupid
> > >(and may not work legally well); we just need a different license.
> > >Just to clarify my personal position, I'm quite happy with this
> > >situation, and I don't want to substitute GPL for another license.
> > >Though I would probably honor the community's decision and arrange
> > >re-licensing of all my contributed sources if needed.
> > >  
> > In fact I don't disagree that we'd prefer to see code GPLed and 
> > contributed to Octave. However, we are shooting ourselves in the foot if 
> > we force away people that have a need to distribute code not under the 
> > GPL for use with Octave. Given this discussion I propose the following 
> > compromise
> > 
> > 1) No change in license as that is basically impossible,
> > 
> > 2) Clarify (in the FAQ and manual) that the Octave community considers 
> > that any code linked against Octave falls under the GPL, but
> > 
> > 3) Code written and distributed as source code using the mex API, can be 
> > licensed under whatever license the user wants,
> > 
> > 4) Add API's
> > 
> > extern OCTINTERP_API Complex *mxGetPz (const mxArray *ptr);
> > extern OCTINTERP_API void *mxGetComplexData (const mxArray *ptr);
> > 
> > to the mex API,
> > 
> > 5) document this change in the Octave manual clearly, in particular 
> > making it clear that the above APIs can improve the efficiency of the 
> > code, and
> > 
> > 6) Try and improve the efficiency of the mex interface in the longer 
> > term. The areas targeted being no need to copy const mxArray **prhs 
> > values from the corresponding octave_values. Means of avoid copy of plhs 
> > values on exit due to memory allocation with mxCalloc, etc.
> > 
> 
> Maybe I am wrong, but if a company distributes proprietary mex-source
> code that compiles and runs with Octave, the company must surely claim
> that this is accidental, and the code is intended for Matlab. If they
> admit that the code is intended to run with Octave, they admit to
> violate the GPL. If the company provides funding or other support to
> Octave (wasn't this the original argument?) in order to keep their
> code running, how can they claim the code is not for Octave?
> 
> Olaf
> 

Hi Olaf, 

Surely you are wrong.
GPL does not cover compatibility but the operational environment. 
We stopped linking octave to this product before the acquizition.
This part of the service still runs on matlab.
( a few months ago the related service was stopped )
We are doing a lot of research inside the company.
After the acquisition we use octave for research purposes.
This is why I would find it desirable to give support.
Most guys here use R, and an academic partner use Scilab.
I am the one propagating octave largely inside the company.

L


-- 
Blogger of http://fapuma.blogspot.com