Re: proposed FAQ entries about licensing

[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 <address@hidden> 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
>