Private company and code salvation

[David Bateman]

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.

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