Re: License questions part 2: Interop issues?

[John Locke <..hidden..>]

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