I've been delaying the deployment and publication of my own OpenSRS client code while I try and figure out how to stay in compliance with the licensing issues.
While I found a solution, it certainly isn't a pretty one. At the heart of the problem is this: http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL So the calls to OpenSRS's API modules are GPL, not LGPL, so any program that directly calls them would have to be covered under the GPL. The solution is to create an entirely separate program that does all the calls to the OpenSRS function modules, and release it under the GPL, and then have the client code call that program using a forking process, as covered in: http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF As I said, it's not clean, but it stays within the requirements of the licensing. I notice a lot (almost all) of OpenSRS second party developers are not worrying about remaining in compliance with their commercial package. That just means that they have no recourse if someone purchases their product and then turns around and releases it to the public, and thus negates the need for dealing with the developer. While this will work, it isn't pretty. The other solution is for OpenSRS to rerelease just the perl modules under the LGPL license, and thus help to encourage the ability of developers of control panels and other software geared towards providers into integrating OpenSRS registration ability into their software products. Any comments on this? -- Best regards, William X Walsh <[EMAIL PROTECTED]> --
