I will take this issue - thanks for re-posting WXW - hang on for a few days.
sA At 11:03 AM 4/1/02 -0800, William X Walsh wrote: >I'm reposting this now, because when I originally posted it, the ICANN >meeting was going on, and it didn't get much attention. I'd like to >see some discussion on this.... > > > > >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]> >-- Scott Allan Director OpenSRS [EMAIL PROTECTED]
