On 23-Feb-2006, Michael Creel wrote:
| When the modified code is compiled, I think that this sort of "intimate
| coupling" will happen. We may need to tune down our Bayesian spam
| filters at this point :-)
|
| Well, I just read the GPL another time. As I read section 3,
| distribution of anything derived from the above code in compiled form
| would require the release of the MATLAB source code. Private use of
| compiled versions is ok, as long as it's in a bedroom with the shades
| drawn. So is distribution of modified source code.
This is essentially the case of having a GPL plug-in for a proprietary
program. The GPL FAQ has a section or two about this case. Probably
the two you are most interested in are
Can I apply the GPL when writing a plug-in for a non-free program?
If the program uses fork and exec to invoke plug-ins, then the
plug-ins are separate programs, so the license for the main
program makes no requirements for them. So you can use the GPL for
a plug-in, and there are no special requirements.
If the program dynamically links plug-ins, and they make function
calls to each other and share data structures, we believe they
form a single program, which must be treated as an extension of
both the main program and the plug-ins. This means that
combination of the GPL-covered plug-in with the non-free main
program would violate the GPL. However, you can resolve that legal
problem by adding an exception to your plug-in's license, giving
permission to link it with the non-free main program.
Can I release a non-free program that's designed to load a
GPL-covered plug-in?
It depends on how the program invokes its plug-ins. If the program
uses fork and exec to invoke plug-ins, then the plug-ins are
separate programs, so the license of the plug-in makes no
requirements about the main program.
If the program dynamically links plug-ins, and they make function
calls to each other and share data structures, we believe they
form a single program, which must be treated as an extension of
both the main program and the plug-ins. In order to use the
GPL-covered plug-ins, the main program must be released under the
GPL or a GPL-compatible free software license, and that the terms
of the GPL must be followed when the main program is distributed
for use with these plug-ins.
If the program dynamically links plug-ins, but the communication
between them is limited to invoking the `main' function of the
plug-in with some options and waiting for it to return, that is a
borderline case.
So it really depends on the details of what you want to do.
If you have an external function that does not depend on liboctave or
other strictly GPL code, then you should be able to structure your
interface to Octave like this:
DEFUN_DLD (foo, args, nargout, "doc string for foo")
{
// decode and gather data from args.
// call external (i.e. non-liboctave-dependent) function.
// gather results and return value(s).
}
and also write a similar "native" Matlab MEX interface (if all it has
to do is decode data to make a function call and then gather results
from the call, that should be fairly simple to do).
Even if the external code is covered by the GPL, that is probably one
of those borderline cases, *provided* that it simply does some
numerical computation and then returns and does not make function
calls to Octave or Matlab internals to do its thing. I don't think it
is clear whether the GPL prohibits this case. It is probably best to
ask the authors of the external code whether they would object to this
use, and if not, to perhaps add an exception to the license to give
permission to link with a non-free main program.
If the external code does make calls to Octave or Matlab, then you are
best off asking the authors of the extnernal function to consider
adding an exception to the license to give permission to link with a
non-free main program.
My intent here is not to promote non-free software (I would prefer
that you use free software to accomplish your goals) but to show how
you can avoid violating the terms of the GPL in this case.
jwe