On 8/21/07, John Locke <..hidden..> wrote:
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.
What about deriving code from database structures? To what extent do they contain original copyrightable content? If they are subject to copyright does this mean that any code which generates PHP classes based on those structures creates a derivative work? If they are not subject to copyright does this mean that schema-only dumps of table structures are not protected either?
Worse: Is there any reason to believe that different jurisdictions won't rule on these things differently?
These are questions that I would like some answers to. Hence the desire to hire an attourney.
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).
IANAL, but I would think that such an exception would probably only pertain to the interfaces present in the licensed content.
I.e. an additional component seeking to take advantage of the rider could not use other interfaces elsewhere in the program and hide behind the rider. I argue this because I don't think that derivation is transitive (
i.e. just because A is derivative of B and B is derivative of C, you can't necessarily say that A is derivative of C-- A could be merely derivative of new components of B).
> 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.
If we want to get into a debate of PHP's "include" and Perl's "use..." I will just point out that this is not about copying but would have to be about something else.
>
> 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.
My concern is not about commercial add-ons. Personally I pledge to never release code relating in any way to the project under terms less free than the agreed-upon license of the project. My concern relates to interop add-ons derived in part from other FOSS under incompatible licenses (MPL, for example).
Heck, my only concern about limiting it to OSI-approved licenses is that there is increasing concern about license proliferation which may mean that could become another arbitrary line which may be extremely difficult to change later on.
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.
As much as I would like to see such a rider, I feel inclined to correct this point.
Services are not subject to restrictions under the GPL :-). If the tax table update code is released under a Free license, this does not prevent agreements relating to the service itself from imposing other requirements by any interpretation of the GPL I have ever read. There might be limits here, but I would expect them to fall under normal contract law stuff and I don't know if you could distribute GPL'd software to customers with service contracts only under service contracts that prevented use of GPL permissions. Anyone who might try to do this would not be a good community member at least though and would probably at very least be shamed by the community or put out of business by someone wasn't so contractually restrictive. IANAL, though.