Hi, Chris Travers wrote: > > One of the problems that we run into is that our internal data > structures are defined in the db, and it is unlikely that any other > applications using our stored procedure interfaces might well be > considered to be derivatives of our work. This might include: > > 1) Interop routines between LedgerSMB and other PostgreSQL-based > applications under non-compatible OSI-approved licenses. > 2) Interop routines between LedgerSMB using our stored procedures or > RESTful interfaces. > > My suggestion is that we may want to look at defining acceptable > interop points for products under incompatible licenses and add > licensing exception to those areas of the new framework. As an > alternative, we may want to specify specific permissions to use our > API for programs of any license. > The Joomla project has been going through a similar discussion. They came to the conclusion that to create a Joomla add-on component, module, or plug-in, you had to use Joomla code, and thus all such add-ons were derivative works.
One of the contributers had added a rider to the license to specifically grant an exception for these add-ons, to allow for commercial add-ons. This rider was later removed due to unclear legal authority to change the license. Joomla is also GPL v2, and a fork of an earlier project (Mambo). > Even if I am wrong in my reading of the derivative works standard, I > am not the first to raise this question. From the Mono Licensing FAQ: > > 'Originally, the class libraries were released under the terms of the > GNU Library GPL (LGPL). The problem with the GNU LGPL is an outdated > wording related to "derived works". A derived work of the library must > be covered by the same license as the library itself. This definition > was fine before object oriented frameworks existed, but with the > introduction of object oriented frameworks, different people disagree > whether some code that uses object-oriented inheritance is an instance > of a "derived work".' That's exactly the conclusion the Joomla! project reached, in consultation with the FSF. > > My general feeling is that we should probably issue some additional > permissions to use our API under certain conditions and we should > probably discuss how we want to do this (perhaps hiring an attourney > in the final stages of drafting). Howecer, I also think that we > should think carefully about limiting the scope properly so that > people can't just package our code up in proprietary ways and deny us > the changes. > > Maybe something like: > > "Notwithstanding any concerns over derivative works, you have > permission to call LedgerSMB stored procedures and RESTful Web Service > APIs from any other work regardless of the license of that work." > I think that's a reasonable approach-- and I also think it's necessary to add such a rider to the license if the intent is to allow commercial add-ons to the project. I also happen to think that allowing commercial add-ons is okay (even though any add-ons I create will most likely be GPL or other open source license). But especially when it comes to providing something like a subscription tax table service, allowing others to add commercial modules is probably something that would only help the community grow. But that's another discussion--and probably something that needs to be determined before choosing a license... Cheers, -- John Locke "Open Source Solutions for Small Business Problems" published by Charles River Media, June 2004 http://www.freelock.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
