Re: Octave Compiler

[JD Cole]

John W. Eaton wrote:

> On 18-Feb-2004, JD Cole <address@hidden> wrote:
>
> | I agree with you here, and it was definitely one of the reasons  octave 
> | -> C++ would be cool. As an intermediate step, it may not be "too" 
> | difficult to convert directly to Octave-based stand alone functions, 
> | however, since we'd be linking with the Octave libraries, the generated 
> | code would still fall under GPL since the whole of Octave source is GPL. 
> | (As opposed to LGPL. If you're not clear on this I'd be happy to explain 
> | more.) A similar problem would arise when you tried to convert a script 
> | file which makes use of other scripts which also fall under 
> | GPL...especially so if those were .oct files which could also be 
> | converted using the compiler.
>
> Yes, any translated Octave code or any code that depends on the Octave
> libraries would be a derivative work, so it would have to be licensed
> under terms that are compatible with the GPL.
>  
I should mention that even with this "restriction" the benefit of pure 
C++ or C++/Octave would still be a spectacular advance for the user 
community, even if they couldn't distribute it as closed source. It also 
should go with out saying that the Octave -> pure C++ will still be 
greatly aided by a utility which adds stubs to converted code which the 
user must later fill in depending on their target use. If it's a closed 
source proprietary thing...then you have to do some more footwork and 
implement your own fft, convolutions, etc. if it's just for your local 
experimentation existing Octave modules can be used.

On the part of licensing how would such derivative could be referred to 
in terms of licensing? For example I have two .m's, one from, say, 
octave-forge the other is of my own creation. When I go to distribute my 
code as a derivative work it would include a GPL for me, and of course, 
the GPL for the octave-forge code? This maybe isn't so clear, sorry.

JD