Re: proposed FAQ entries about licensing

[Jaroslav Hajek]

On Fri, Mar 27, 2009 at 8:43 AM, Svante Signell
<address@hidden> wrote:
> On Wed, 2009-03-25 at 10:30 -0400, John W. Eaton wrote:
>> On 25-Mar-2009, Svante Signell wrote:
>>
>> | What about replacing a .m file with a C/C++ function for execution speed
>> | purposes? Does this fall in the same category as an .m-file, i.e. no
>> | requirements on the license?
>>
>> The reason for writing the plug-in (.oct or MEX) doesn't change the
>> licensing requirements.  What is important is that you are linking
>> with Octave, so must follow the terms of the GPL.  Perhaps we should
>> also explain more clearly in the FAQ answer why a MEX file can be
>> licensed any way you choose, but the same is not true for .oct files.
>> We hint at it by saying that a .oct file necessarily links with Octave
>> internals, thus creating a derivative work, but it might not be clear
>> why a MEX file does not have the same restriction.
>>
>> For MEX files, the situation is different becuase we don't think that
>> a MEX file creates a derivative work, because the interface is not
>> specific to Octave.  Indeed, it is possible (even relatively easy) to
>> write and compile MEX files that do not even include any header files
>> or link to any Octave- or Matlab-specific libraries and that can be
>> loaded and run by either program.  You don't even need Matlab or
>> Octave on a computer in order to build a functioning MEX files (but
>> you need one or the other of those programs to use the resulting MEX
>> file function).  Because of this, the FSF doesn't think that MEX files
>> should fall under the same requirements of .oct files, provided that
>> you meet the requirements that are stated in the FAQ answer that I
>> posted.
>
> Another question about Octave. A method to (weakly?) protect some .m
> files they can be encrypted creating .p-files in MatLab. Is it possible
> to create .p-files in Octave, or if created in MatLab can they be run in
> Octave. (The answer to this is probably negative but I'll ask anyway).
>
> The background to this question is that we have developed a large
> package based solely on .m-files. It could be viewed as a toolbox. We
> have written it so it can be executed in both MatLab and Octave
> environments for PC and *nix to make it available in both environments.
>
> In order to commercialize it we will hand out most of the .m-files as
> GPL-ed code, but want to keep some essential .m-files protected. Of
> course this is mainly to be able to be able to sell the package and
> subsequently develop it further without risk of theft or cloning before
> we are established with our product.
>

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).


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