octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

proposed FAQ entries about licensing


From: John W. Eaton
Subject: proposed FAQ entries about licensing
Date: Tue, 24 Mar 2009 13:30:18 -0400

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]