proposed FAQ entries about licensing

[John W. Eaton-3]

Following this discussion:

  https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-January/010066.html

I asked the FSF about licensing for MEX.  The results of the FSF
response to my question are the following proposed FAQ entries.

  Q:  If I write code using Octave do I have to release it under the
      GPL?

  A:  The answer depends on precisely how the code is written and how it
      works.

      Code written entirely in the scripting language of Octave
      (interpreted code in .m files) may be released under the terms of
      whatever license you choose.

      Code written using Octave's native plug-in interface (also known
      as a .oct file) necessarily links with Octave internals and is
      considered a derivative work of Octave and therefore must be
      released under terms that are compatible with the GPL.

      Code written using Octave's implementation of the Matlab MEX
      interface may be released under the terms of whatever license you
      choose, provided that the following conditions are met:

      1. The plugin should not use any bindings that are specific to
         Octave.  In other words, the MEX file must use the MEX
         interface only, and not also call on other Octave internals.
         It should be possible in principle to use the MEX file with
         other programs that implement the MEX interface (e.g., Matlab).

      2. The MEX file should not be distributed together with Octave in
         such a way that they effectively create a single work.  For
         example, you should not distribute the MEX file and Octave
         together in a single package such that Octave automatically
         loads and runs the MEX file when it starts up.  There are other
         possible ways that you might effectively create a single work;
         this is just one example.

      A program that embeds the Octave interpreter (e.g., by calling the
      "octave_main" function), or that calls functions from Octave's
      libraries (e.g., liboctinterp, liboctave, or libcruft) is
      considered a derivative work of Octave and therefore must be
      released under terms that are compatible with the GPL.


  Q:  Since the MEX interface allows plugins to be distributed under
      terms that are incompatible with the GPL, does this mean that you
      are encouraging people to to write non-free software for Octave?

  A:  No.  The original reason for implementing the MEX interface for
      Octave was to allow Octave to run free software that uses MEX
      files (the particular goal was to run SundialsTB in Octave).  The
      intent was to liberate that software from Matlab and increase the
      amount of free software available to Octave users, not to enable
      people to write proprietary code for Octave.  For the good of the
      community, we strongly encourage users of Octave to release the
      code they write for Octave under terms that are compatible with
      the GPL.


  Q:  I wrote a program that links with Octave libraries and I don't
      want to release it under the terms of the GPL.  Will you change
      the license of the Octave libraries for me?

  A:  No.  Instead of asking us to change the licensing terms for
      Octave, we recommend that you release your program under terms
      that are compatible with the GPL so that the free software
      community can benefit from your work the same as you have
      benefitted from the work of all the people who have contributed to
      Octave.


If you have comments, post them here.

Thanks,

jwe

[Svante Signell]

Sorry for intruding, I'm one of the lurkers on this list. Question
below.

On Tue, 2009-03-24 at 13:30 -0400, John W. Eaton wrote:

> Following this discussion:
>
>   https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-January/010066.html
>
> I asked the FSF about licensing for MEX.  The results of the FSF
> response to my question are the following proposed FAQ entries.
>
>   Q:  If I write code using Octave do I have to release it under the
>       GPL?
>
>   A:  The answer depends on precisely how the code is written and how it
>       works.
>
>       Code written entirely in the scripting language of Octave
>       (interpreted code in .m files) may be released under the terms of
>       whatever license you choose.
>
>       Code written using Octave's native plug-in interface (also known
>       as a .oct file) necessarily links with Octave internals and is
>       considered a derivative work of Octave and therefore must be
>       released under terms that are compatible with the GPL.
>

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?

Thanks,
Svante

[Ben Abbott]

On Mar 25, 2009, at 3:32 AM, Svante Signell wrote:

> Sorry for intruding, I'm one of the lurkers on this list. Question
> below.
>
> On Tue, 2009-03-24 at 13:30 -0400, John W. Eaton wrote:
>> Following this discussion:
>>
>>  https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-January/010066.html
>>
>> I asked the FSF about licensing for MEX.  The results of the FSF
>> response to my question are the following proposed FAQ entries.
>>
>>  Q:  If I write code using Octave do I have to release it under the
>>      GPL?
>>
>>  A:  The answer depends on precisely how the code is written and  
>> how it
>>      works.
>>
>>      Code written entirely in the scripting language of Octave
>>      (interpreted code in .m files) may be released under the terms  
>> of
>>      whatever license you choose.
>>
>>      Code written using Octave's native plug-in interface (also known
>>      as a .oct file) necessarily links with Octave internals and is
>>      considered a derivative work of Octave and therefore must be
>>      released under terms that are compatible with the GPL.
>>
> 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?
>
> Thanks,
> Svante

A C file would need to be of the MEX variety.

A C/C++ file would need to be of the MEX or .oct variety.

Or do you mean something else?

Ben


 

[John W. Eaton-3]

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.

jwe

[Svante Signell]

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.

Thanks,
Svante

[Søren Hauberg]

fre, 27 03 2009 kl. 08:43 +0100, skrev Svante Signell:
> 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.

>From what I understand the Matlab p-files can easily be reverse
engineered, so the amount of protection you would get that way is close
to zero. I also think you'll end up annoying your users more in this
way. So, using p-files (IMHO) has the effect of annoying users while not
preventing anybody from actually reading the code.

You could put some of your m-code under a non-commercial license. That
being said, I doubt you'll find much sympathy for such actions on this
list. A lot of people do a lot of volunteer work to ensure scientists
(and users in general) have Free access to the source code of Octave.
What you are requesting is a way of preventing us from reading your
code, while you get to read ours. I can understand your reasoning, but
it's really fair what you're asking for.

Søren

[Jaroslav Hajek-2]

On Fri, Mar 27, 2009 at 8:43 AM, Svante Signell
<svante.signell@...> 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

[John W. Eaton-3]

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

[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

[dbateman]

Svante Signell wrote:

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

Why doesn't it make sense? A commerical copyrighted file still has all of the protection given by the copyright even if it is readable.. The parallel is a book which is always readable but still protected by copyright... So go ahead and distribute the majority of your code with GPL and the rest with a commerical license. The only protection you'll miss is that plagarism becomes easier, but still illegal.

- 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?

Because a set of code might have a limited user base, that doesn't make it useless... Any code that is freely distributed out there is eventually useful to someone.

D.

[John W. Eaton-3]

On  7-Apr-2009, Svante Signell wrote:

| 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

Please don't confuse commercial and proprietary.  The GPL allows
commercial uses.  What it does not allow is making proprietary
derivative works.

| - 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?

I'm having trouble deciphering the above.  What do you mean by "It
does not matter in Matlab and Octave developers don't want it?"?   I'm
certainly interested in seeing more free software become available.

jwe

[Judd Storrs]

Since octave is a GNU project, I assume it is now GPLv3 only? Does
this mean that we can't share .oct interfaces to GPLv2 only libraries
because of GPLv2/v3 incompatibility?

--judd


On Tue, Mar 24, 2009 at 1:30 PM, John W. Eaton <jwe@...> wrote:

> Following this discussion:
>
>  https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-January/010066.html
>
> I asked the FSF about licensing for MEX.  The results of the FSF
> response to my question are the following proposed FAQ entries.
>
>  Q:  If I write code using Octave do I have to release it under the
>      GPL?
>
>  A:  The answer depends on precisely how the code is written and how it
>      works.
>
>      Code written entirely in the scripting language of Octave
>      (interpreted code in .m files) may be released under the terms of
>      whatever license you choose.
>
>      Code written using Octave's native plug-in interface (also known
>      as a .oct file) necessarily links with Octave internals and is
>      considered a derivative work of Octave and therefore must be
>      released under terms that are compatible with the GPL.
>
>      Code written using Octave's implementation of the Matlab MEX
>      interface may be released under the terms of whatever license you
>      choose, provided that the following conditions are met:
>
>      1. The plugin should not use any bindings that are specific to
>         Octave.  In other words, the MEX file must use the MEX
>         interface only, and not also call on other Octave internals.
>         It should be possible in principle to use the MEX file with
>         other programs that implement the MEX interface (e.g., Matlab).
>
>      2. The MEX file should not be distributed together with Octave in
>         such a way that they effectively create a single work.  For
>         example, you should not distribute the MEX file and Octave
>         together in a single package such that Octave automatically
>         loads and runs the MEX file when it starts up.  There are other
>         possible ways that you might effectively create a single work;
>         this is just one example.
>
>      A program that embeds the Octave interpreter (e.g., by calling the
>      "octave_main" function), or that calls functions from Octave's
>      libraries (e.g., liboctinterp, liboctave, or libcruft) is
>      considered a derivative work of Octave and therefore must be
>      released under terms that are compatible with the GPL.
>
>
>  Q:  Since the MEX interface allows plugins to be distributed under
>      terms that are incompatible with the GPL, does this mean that you
>      are encouraging people to to write non-free software for Octave?
>
>  A:  No.  The original reason for implementing the MEX interface for
>      Octave was to allow Octave to run free software that uses MEX
>      files (the particular goal was to run SundialsTB in Octave).  The
>      intent was to liberate that software from Matlab and increase the
>      amount of free software available to Octave users, not to enable
>      people to write proprietary code for Octave.  For the good of the
>      community, we strongly encourage users of Octave to release the
>      code they write for Octave under terms that are compatible with
>      the GPL.
>
>
>  Q:  I wrote a program that links with Octave libraries and I don't
>      want to release it under the terms of the GPL.  Will you change
>      the license of the Octave libraries for me?
>
>  A:  No.  Instead of asking us to change the licensing terms for
>      Octave, we recommend that you release your program under terms
>      that are compatible with the GPL so that the free software
>      community can benefit from your work the same as you have
>      benefitted from the work of all the people who have contributed to
>      Octave.
>
>
> If you have comments, post them here.
>
> Thanks,
>
> jwe
>

[Svante Signell]

On Tue, 2009-04-07 at 15:45 -0400, John W. Eaton wrote:

> On  7-Apr-2009, Svante Signell wrote:
>
> | 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
>
> Please don't confuse commercial and proprietary.  The GPL allows
> commercial uses.  What it does not allow is making proprietary
> derivative works.

OK, I should have written proprietary instead of commercial.

> | - 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?
>
> I'm having trouble deciphering the above.  What do you mean by "It
> does not matter in Matlab and Octave developers don't want it?"?   I'm
> certainly interested in seeing more free software become available.

I'll try to clarify: If we develop entirely for use in Matlab and not in
Octave it doesn't matter much if the library code is GPLed or not. We
would probably be fully proprietary then, an no .m files or .mex files
would be free. There is not much difference if the code only runs in
Matlab. This is not our wish however, and we would like to make the
toolbox run in both Matlab and Octave as well as in *nix and PC
environments.

> jwe

[Jaroslav Hajek-2]

On Tue, Apr 7, 2009 at 10:46 PM, Judd Storrs <storrsjm@...> wrote:
> Since octave is a GNU project, I assume it is now GPLv3 only? Does
> this mean that we can't share .oct interfaces to GPLv2 only libraries
> because of GPLv2/v3 incompatibility?
>
> --judd
>

GPLv2 can be automatically promoted to GPLv3. So yes, you can
distribute them, but they will be covered by GPLv3. Assuming they link
to the newest interface, of course. Those linking to old interface may
remain under GPLv2.

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

[Søren Hauberg]

ons, 08 04 2009 kl. 11:08 +0200, skrev Jaroslav Hajek:
> GPLv2 can be automatically promoted to GPLv3.

Is that true? Doesn't that require the library to be licensed as "GPLv2
or later" ?

Søren

[Jaroslav Hajek-2]

On Wed, Apr 8, 2009 at 10:57 AM, Svante Signell
<svante.signell@...> wrote:

> On Tue, 2009-04-07 at 15:45 -0400, John W. Eaton wrote:
>> On  7-Apr-2009, Svante Signell wrote:
>>
>> | 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
>>
>> Please don't confuse commercial and proprietary.  The GPL allows
>> commercial uses.  What it does not allow is making proprietary
>> derivative works.
>
> OK, I should have written proprietary instead of commercial.
>
>> | - 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?
>>
>> I'm having trouble deciphering the above.  What do you mean by "It
>> does not matter in Matlab and Octave developers don't want it?"?   I'm
>> certainly interested in seeing more free software become available.
>
> I'll try to clarify: If we develop entirely for use in Matlab and not in
> Octave it doesn't matter much if the library code is GPLed or not. We
> would probably be fully proprietary then, an no .m files or .mex files
> would be free.

That choice is up to you, of course.

> This is not our wish however, and we would like to make the
> toolbox run in both Matlab and Octave as well as in *nix and PC
> environments.

If you want to take advantage of any GPL-covered software, including
Octave, you need to honor the GPL (of course this means legally comply
with its terms, but I also think that you shouldn't use it if you
disagree with it's spirit). GPL protects free software from being
"proprietarized" in the precise sense you (maybe) look for.
You can, of course, use any other free software license for your code,
that doesn't impose GPL's strict copyleft requirements, but then you
can't make your code dependent on Octave, for instance, by using the
C++ interface, or by distributing binaries linked against Octave.

regards

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

[Jaroslav Hajek-2]

On Wed, Apr 8, 2009 at 11:12 AM, Søren Hauberg <soren@...> wrote:
> ons, 08 04 2009 kl. 11:08 +0200, skrev Jaroslav Hajek:
>> GPLv2 can be automatically promoted to GPLv3.
>
> Is that true? Doesn't that require the library to be licensed as "GPLv2
> or later" ?
>
> Søren
>

Right, it's not strictly true. What I meant is that the "standard
license header", as advised by FSF (gpl-howto) contains the
auto-promotion clause, so it's very likely to be the case for the code
Judd is referring to.


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

[dbateman2]

Jaroslav Hajek wrote:

> If you want to take advantage of any GPL-covered software, including
> Octave, you need to honor the GPL (of course this means legally comply
> with its terms, but I also think that you shouldn't use it if you
> disagree with it's spirit). GPL protects free software from being
> "proprietarized" in the precise sense you (maybe) look for.
> You can, of course, use any other free software license for your code,
> that doesn't impose GPL's strict copyleft requirements, but then you
> can't make your code dependent on Octave, for instance, by using the
> C++ interface, or by distributing binaries linked against Octave.
>
>  

In fact MEX binaries can theoretically be used with both Octave and
Matlab. In practice they can't at the moment but that doesn't change the
fact you can distribute MEX binaries for Octave under whatever license
you want as long as you don't distribute them in such a way that Octave
and the proprietary MEX files become a single product..

Regards
David



--
David Bateman                                dbateman@...
35 rue Gambetta                              [phone] (Home)
92100 Boulogne-Billancourt FRANCE            [phone] (Mob)

[Jaroslav Hajek-2]

On Wed, Apr 8, 2009 at 2:03 PM, David Bateman <dbateman@...> wrote:

> Jaroslav Hajek wrote:
>>
>> If you want to take advantage of any GPL-covered software, including
>> Octave, you need to honor the GPL (of course this means legally comply
>> with its terms, but I also think that you shouldn't use it if you
>> disagree with it's spirit). GPL protects free software from being
>> "proprietarized" in the precise sense you (maybe) look for.
>> You can, of course, use any other free software license for your code,
>> that doesn't impose GPL's strict copyleft requirements, but then you
>> can't make your code dependent on Octave, for instance, by using the
>> C++ interface, or by distributing binaries linked against Octave.
>>
>>
>
> In fact MEX binaries can theoretically be used with both Octave and Matlab.
> In practice they can't at the moment but that doesn't change the fact you
> can distribute MEX binaries for Octave under whatever license you want as
> long as you don't distribute them in such a way that Octave and the
> proprietary MEX files become a single product..
>
> Regards
> David
>
>

I'm not sure about Windows, but under Linux even MEX compiled files
contain links to libcruft, liboctave & liboctinterp, which IMHO makes
them derivatives of Octave. The sources can be distributed under any
license, if they don't contain Octave-specific stuff.


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

[dbateman2]

Jaroslav Hajek wrote:
> I'm not sure about Windows, but under Linux even MEX compiled files
> contain links to libcruft, liboctave & liboctinterp, which IMHO makes
> them derivatives of Octave. The sources can be distributed under any
> license, if they don't contain Octave-specific stuff.
>
>  
Yes, but theoretically the MEX compiled for Octave can be used with
Matlab, and thus can be licensed which any license. This is like browser
plugins, and is what is explicitly written in the FAQ clause propose by
John. See clause 1 for the conditions of using a MEX...

<quote>

      Code written using Octave's implementation of the Matlab MEX
      interface may be released under the terms of whatever license you
      choose, provided that the following conditions are met:

      1. The plugin should not use any bindings that are specific to
         Octave.  In other words, the MEX file must use the MEX
         interface only, and not also call on other Octave internals.
         It should be possible in principle to use the MEX file with
         other programs that implement the MEX interface (e.g., Matlab).

      2. The MEX file should not be distributed together with Octave in
         such a way that they effectively create a single work.  For
         example, you should not distribute the MEX file and Octave
         together in a single package such that Octave automatically
         loads and runs the MEX file when it starts up.  There are other
         possible ways that you might effectively create a single work;
         this is just one example.

</quote>

D.

--
David Bateman                                dbateman@...
35 rue Gambetta                              [phone] (Home)
92100 Boulogne-Billancourt FRANCE            [phone] (Mob)