Re: proposed FAQ entries about licensing

[Jaroslav Hajek]

On Wed, Apr 8, 2009 at 9:15 PM, John W. Eaton <address@hidden> wrote:
> On  8-Apr-2009, Jaroslav Hajek wrote:
>
> | OK, I believe you, but I just don't understand the reasoning, then.
> | There is also the (albeit slight) possibility that the FSF people
> | missed some important detail.
>
> I think they understood the situation.
>
> | I see the link to liboctave et al. hard-wired in the produced mex
> | file and that seems to me to make it a derivative work of Octave.
> | There's certainly no liboctave in Matlab, so it's apparent the
> | executable is built to be linked to Octave.
>
> Yes, that's true now, but it is not necessary for Octave's MEX files
> to be linked with anything and they will still work (with Octave and
> probably with Matlab, even without having to recompile them).
>

John, pardon my ignorance about this, but I just don't understand how
this fact matters. I think the relation "is a derivative work of"
should not depend on how the work can be used with any third party
software - it should be uniquely determined by the fact how it was
*created*.

Suppose I write an m-script that uses Octave's unique features (like
specific block ends), which, according to a general agreement, will
then be a derivative work, and then later Matlab (or Scilab or
whatever) is updated so that the script can be run in Matlab, will it
cease to be Octave's derivative work?

>
> The only thing needed to create a MEX file that can work in both
> Octave and Matlab is a set of prototypes for the mx* and mex*
> functions you wish to use and a C compiler.  Since all operations on
> mxArray objects are performed by functions that take pointers to
> mxArray ojbects, you can use
>
>  typedef void mxArray
>
> and that's exactly what Octave's mex.h file does.
>
> The interface for MEX is not unique to Octave, so I don't think it is
> reasonable to claim that using it makes a MEX file a derivative work
> of Octave.
>

No, not the interface. I think that it is the internal link to
Octave's libraries that makes it a derivative work. Maybe it's a
nonsense, but I don't really understand how the situation is
different, say, from dynamic linking to GNU libc (assuming a program
does not use glibc-specific features). If such a link is not relevant,
then why is GNU libc under LGPL?

> | I think mex.h carries the GPL preamble, doesn't it?
>
> Yes, but maybe we should consider changing that.  Since someone else
> could just create their own file containing all the same mx* and mex*
> prototypes and place it in the public domain, I don't see that keeping
> Octave's mex.h file under the GPL has much of an effect.
>

But can it be done, when we distribute it along with GPLed sources?
Doesn't that make it automatically GPL-covered?


-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz