Re: Swig works (Re: Octave and databases)

[John W. Eaton]

On  8-Sep-2010, Jordi Gutiérrez Hermoso wrote:

| On 8 September 2010 16:00, Xavier Delacour <address@hidden> wrote:
| > Using mex would be advantageous because the mex interface is more
| > simple/stable/static and better documented, and because it would allow
| > swig-generated wrappers to work with matlab.
| 
| I have no idea what I'm talking about, so take my question with a
| grain of salt, but are there any licensing issues to take into account
| here, e.g. GPL linking?

>From the current FAQ file in the Octave sources:

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

  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.

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

  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.

jwe