Jaroslav Hajek wrote: > First the legal thing: > I'm afraid GPL can't be worked around as easily as you think (if it > could, dozens of companies would instantly do it). If you use Octave's > C++ API within your code, your code becomes a derived work of Octave > and hence its license needs to comply with GPL, use of LGPL is not > possible. It doesn't matter that the Octave-derived part can be > switched off by a directive. Even if it was commented out, GPL would > still apply. > In the present form, it can only be included in OctaveForge if you > accept changing the license to GPL. > If you really want a LGPL part, a possible way out is to isolate the > library from the Octave interface and distribute them separately > (In OctaveForge, they can be put together, but the license will become GPL).
What you are saying is that the files distributed with Octave become GPL, regardless of their unmodified copyright banners displaying other licenses such as LGPL, BSD, public domain, etc. Having chosen LGPL, we are of course implicitly granting Octave this right. However, as the copyright holders, we can separately contribute our original code (without GPL modifications) to other open source projects under LGPL, right? The LGPL banner/switch was intended to advertise that this other licensing option exists, and to make it easier to track changes between the two (e.g. if someone wanted to contribute the same patch to both branches). I can see that the CL2BP_STANDALONE directive may be intertwining those branches a little too intimately. If you prefer, I can separate cl2bp.cc into two files -- one with an LGPL license doesn't reference Octave at all, and one with an explicit GPL license that contains the Octave wrapper. Would that satisfy your concerns? > Then the technical thing: > is rmmult really doing a matrix-matrix multiply? If yes, what are the > typical dimensions? For anything bigger than small (left vague), it > will probably be worth to defer this operation to BLAS to gain > performance. You are right that an optimized matrix library might improve performance. However, the library would need to be compatible with the LGPL license, and it would need to be relatively small and portable. (I think BLAS is a little "baroque" for our needs.) Also, this change is nontrivial programming work that we probably won't be able to do right away. But I'm open to suggestions. Thanks for your comments. Cheers, -Pete ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
