On Fri, Oct 2, 2009 at 8:18 PM, Pete Gonzalez <[email protected]> wrote: > > > 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. >
It's not "of course" - you, as the author, choose licenses for your work. You *may* choose not to comply with GPL, but then you simply can not distribute the source. > 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). > No, it doesn't work this way. Once you create a derivative work of Octave (which your source is) and release it under GPL (which you need if you want to distribute it), you can't provide an option to "downgrade" the license. You can, of course, take the source you posted (because it is your work), strip away the Octave stuff, and then license it under LGPL. Users, however, cannot "unGPL" the code - only you can. This is an example of the "viral" nature of GPL that is often referred to. > 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? I think that would be OK. However, if it becomes part of OctaveForge, it will be covered by GPL. Anyone getting the file from OctaveForge will be bound by GPL. Anyone getting the same source from you directly will be allowed to use LGPL. >> 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. > As I said, it depends on the dimensions. If the dimensions are, say, 10x10, you'll gain little or nothing. If it's 100x100 or 1000x1000, you'll gain a lot. BLAS is today more of a standard interface than a library, so there's no licensing problem - you can use anything. If you use Octave's classes - say, Matrix and ColumnVector in your file, then Matrix*ColumnVector operation is already linked to BLAS. hth -- RNDr. Jaroslav Hajek computing expert & GNU Octave developer Aeronautical Research and Test Institute (VZLU) Prague, Czech Republic url: www.highegg.matfyz.cz ------------------------------------------------------------------------------ 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
