From help-request at octave dot org Thu Feb 23 07:50:29 2006 Subject: Re: licensing question From: Michael Creel To: "John W. Eaton" Cc: Francesco Potorti` , Help-Octave List Date: Thu, 23 Feb 2006 14:47:05 +0000 Actually, I'm the author of the code, which is in octave-forge. Someone asked about how they might use my code with Matlab. I just wanted to give an accurate warning of what's acceptable if they decide to port the code. My code is used to create .oct files, and includes oct.h. The port would create .mex files (?) This is dynamic linking and sharing of data structures, right? So, as I understand it, this person could distribute ported source code, but not the resulting .mex files. Michael John W. Eaton wrote: >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 > > ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html -------------------------------------------------------------