Robert Osfield wrote: > Most plugins are OSGPL, but some are GPL and some are LGPL. The 3ds > plugin has always been based on LGPL code, and the new rev hasn't > changed this. > > If you want to use LGPL plugins you have to use dynamic linking. >> This comes as a surprise. > > In the src/osgPlugins/3ds directory there is a README that explains > the LGPL license, this README has been in place since the inception of > this plugin, nearly a decade now. So the "matter of fact" is that I'm > not disclosing any new information that hasn't been avaiexlable to > everybody since the very earliest days of the OSG project. > > Now one could try and formalize the licensing of plugins, perhaps even > make it possible in CMake to select the license and prevent > compilation of the components that don't fit with that license. I'm > not a Cmake guru so can't point to an clean and easy way to do this > right out the way, I'm open to suggest though.
It might suffice to simply elevate a listing of plugin licenses (and the admonition against static linking LGPL plugins) to a top-level document like our own LICENSE.txt. There could also be a community project to enumerate the LGPL plugins and seek out their projects to request a specific LGPL static link exemption, such as many projects have already done: http://teem.sourceforge.net/lgpl.html Also from that page: "It is also interesting to note, however, that while the text of the GPL and LGPL assert that linking with the library creates a derived work, some legal experts believe that linking creates a compilation, in the copyright sense, and not a derived work." Depending on interpretation, this might render the LGPL static link issue moot. I personally (IANAL) believe that it probably does produce a compilation rather than a derived work. http://en.wikipedia.org/wiki/Derivative_work Basically, my take is that to be derivative, it must "transformatively" modify the original, which obviously linking does not. It merely includes it unmodified. However, I believe the FSF's original intention was COUNTER to this interpretation, and they explicitly claim LGPL static linked works are derivative works. I understand FSF's motivation -- they want to keep software modularized so that the LGPL portion of the library can be seamlessly upgraded by the end user, preserving the freedom to fix problems. However, I also acknowledge that except for extremely minor fixes, this technique is hardly ever feasible with modern code due to function signature changes and base class data alterations. It might have worked fine on Linux, with C-only code or with extremely simple fixes with no new functionality, but in the Real World, C++, Windows, OSX and major fixes or functional improvements make this eseentially a pipe dream. So: If you screwed up and statically linked LGPL code in a plugin, you might be going against FSF's wishes, and you might or might not be legally infringing the copyright holder of the original plugin code. However, it might still be possible to get an LGPL-static exemption from the original copyright holders, which seems like a worthy endeavour, given OSG's goals to be open source, yet freely usable commercially without glitches. Discussion? Anyone want to step forward to do a non-technical project of summarizing the license and maybe approaching 3rd party contributors about an exemption? > Robert. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
