Hi Bob and all, Long, uncomfortable response below ...
On Mar 12, 2007, at 8:41 PM, Bob Delaney wrote: > Tim, > > I guess I'm interpreting this statement wrongly: > > "... (although using data in a commercial > product produced by a program that used NTL is fine)." You are - that statement implies that if someone generates data with a product (application) using the NTL routines and then uses that generated data within a commercial app, that commercial app is not required to be GPL. However, when you compile the NTL code into your plugin, your plugin becomes GPL'd. Then, when we compile your plugin into a RB app, by reference, because your plugin is under GPL the application including your plugin must also be GPL'd. > My plugin produces data generated by NTL. The > statement seems to say it's OK for a commercial > product to use this data. NTL is not directly > connected as a new class to REALbasic through my > plugin. Only a small part of NTL is available. It > took considerable effort to devise new classes > for RB which conveyed RR (ExtFloat) and ZZ > (ExtInteger) types via my plugin back and forth > between RB and NTL. I had to put in many > overflow, etc. tests so that no invalid data was > presented to NTL. Else NTL would ExitToShell, and > any application made with my Extended Plugin > might quit without warning. No one has yet > complained of this, so I guess I did a good job > there. To make this work the way that you are thinking (and the way Victor's caveat statement reads), the NTL routines would need to be in a separate standalone application (not a linked library or shared library) - think md5sum. My application would send my numbers to your plugin - which would then execute the NTL app and accept back the results and pass those results back to my application. If you compile ANY part of Victor's code into your plugin, by default, your plugin becomes GPL'd. > But I repeat that I'm not at all an expert in > interpreting the GPL. Now I'm not sure I should > have included that NTL Copyright. But we are as close to experts as you can be on the GPL. Before we started producing BRU for Linux (1994), we paid a rather well placed IP legal team to clarify the religious document that is the GPL-2 into something that more closely resembled a true license. The results is very simple - if you use any portion of a GPL code base within your application, your application is now legally bound to the GPL itself. This is also why the LGPL license exists - the Lesser GPL is designed for libraries and shared modules that an application may link against that does not require that the linked application be released as GPL. Therefore, if we could contact Victor and ask him to re-release a new version of NTL under the LGPL, this issue would go away. Unfortunately, unless that is done, or you get Victor to provide you with a special license just for your use within your plugins that is non-GPL such as BSD, MPL, QPL, or even a commercial license (he can do that), your plugin is also locked under the GPL. I'm sorry if this has raised a sh*tstorm for anyone, but the FSF has started going after GPL violations with gusto over the past 15 or so months. If we compiled a commercial application against your plugins, that application would be required to be released in source code format under the terms of the GPL. This is why MANY folks in the commercial world refuse to touch Linux as a release platform. In fact, one major graphic arts company referred the license as a "virus" rather than a license back in 1998 when they initially looked at porting their suits... Tim -- Tim Jones [EMAIL PROTECTED] _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
