help-octave
[Top][All Lists]
Advanced

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

Re: Private company and code salvation


From: dbateman
Subject: Re: Private company and code salvation
Date: Mon, 29 Sep 2008 11:09:15 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

On Sun, Sep 28, 2008 at 11:18:20PM -0400, Jordi Guti?rrez Hermoso wrote:
> 2008/9/28 dbateman <address@hidden>:
> > 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.
> 
> The GPL already allows commercial distribution of the code, unless by
> "commercial" you don't mean "selling" or anything implying money, but
> rather "closing it up".

No I meant the third path. The ability for a user to write code for 
distribution that isn't required to be GPLed. Octave is a language like 
C/C++, and code that just happens to be to be compiled with GCC/G++ is 
not required to fall under the GPL and the same should be turn of 
Octave. However, if a user writes code that modifies GCC/G++ itself then 
rightly they are required to distribute their modifications if they 
share their version of GCC/G++. We are in a similar situat?ion with Octave,
where the m-files and mex-files written by users are fully distributable, 
but oct-files aren't, so their is an incoherence in what is writing code 
for the Octave language and what counts as modifying Octave itself.


Some of us make a living from the code we write and in that context the 
GPL makes lots of sense for the code that we need to make our living but 
can't make a profit from. That basically includes all of the tools, and 
its in our interest that we reduce the cost of development and 
commoditize these tools so that we reduce our costs, and the GPL fits 
that bill perfectly. Which is why you see lots of companies writing 
GPLed, so that they themselves can use it but also profit from any 
additional code written but someone else. Think of all the GPLed code 
that IBM for example has written.

However that also means that some of the high value code that we write 
must be maintained in complete control of the author/owner of that code, 
so that we can feed our kids with the effort we put into writing it.

> > 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,
> 
> As a tactical matter, an LGPL here might be acceptable... although
> personally it makes me a little uncomfortable. And since jwe is I
> think the major copyright holder, I doubt he'd agree to it.

I've already expressed personally to John my belief that some sort of 
API/ABI to Octave that allows distribution of the "user" code, not octave
itself, is a limiting factor to companies uptake of Octave. John himself even 
suggested offline a mex-like interface to Octave under such a license, 
though that seems to be limiting for the code write. The current situation 
where the freely distributable API to Octave is mex is a bit stupid, 
though its the choice that FreeMat made and if Octave chooses to go that 
way, then optimizing that interface becomes a priority.

Jordi, given the amount of GPLed code I've contributed in my life, I 
don't think anyone could call me anti-GPL. Though, I'm a realist when it 
comes to the needs of individuals to live off of their effort and so 
will support the position of corporate/commerical/industrial users of 
Octave and their need for some control of the code they write. Let them 
take control of Octave though NEVER, which is why the GPL for Octave is 
so important.


Regards
David






> 
> - Jordi G. H.


reply via email to

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