Re: proposed FAQ entries about licensing

[Svante Signell]

On Fri, 2009-03-27 at 13:38 -0400, John W. Eaton wrote:
> On 27-Mar-2009, Jaroslav Hajek wrote:
> 
> | You should also be aware that if you distribute these encrypted
> | sources together with the GPLed ones, so that they form a derivative
> | work, they must have a GPL-compatible license and you are thus obliged
> | by the GPL to provide the source codes for the encrypted files to any
> | user who asks for them, which IMHO defeats the whole purpose of the
> | encryption.
> | You need to distribute the encrypted files separately, and you need to
> | avoid any "hard-wired" dependency on the GPLed sources (which would
> | also constitute a derivative work).
> 
> I don't think separate distribution is a way to avoid the terms of the
> GPLv3.  See section 5(c) where it says the license applies to all the
> parts of the modified work "regardless of how they are packaged".
> 
> In any case, I have no interest in adding a p-code like capability to
> Octave (compatible with Matlab's p-code or not).  One of the major
> reasons for Octave's existence is to encourage free software.  I don't
> see how having this feature would help us.
> 
> jwe

Sorry for not continuing this thread earlier, but I have been too busy
recently (applying for funding) and then the home computer crashed... 

Summarizing up the comments the conclusions are: (correct me if I'm
wrong)

- No p-file support in Octave (not of much use anyway)
- Using the .mex interface is OK, for commercial use for some of the .m
file functions if needed. Works both in Matlab and Octave.
- Using the .oct file interface in Octave is not OK due to the
derivative work clause.

Some comments:
- Distribution of commercial and free .m-files does not make sense,
since the commercially licensed files are still readable in source code
form, c.f. Matlab toolboxes many years ago and now.

- We considered to release the noncommercial code of our application
(toolbox) under a free license, e.g. GPL v3, but according to your
answers the interest of the free part, it can be considered as a model a
library, would be low, at least from you developers? If this advice is
taken seriously by us, why make any .m-file code free?? It does not
matter in Matlab and Octave developers don't want it?

The situation might be different for the users since that code can be
used "as is" in other applications. additionally, the users can inspect
the code to find out what happens with the code they run. This is in
sharp contrast to compiled (or protected) library environments, where
the users don't know what's going on. They have to rely to the (often
inaccurate) users manual and the reference manual.

Thank you for your time,
Svante Signell