License questions part 2: Interop issues?

["Chris Travers" <..hidden..>]

Hi all;

The discussion about the GPL v3 has caused me to think about one other key area we probably all need to consider:  Are there portions of our appliction that may require additional permissions (beyond the GPL v2 or later) in order to facilitate interop with other systems.   I hope everyone here knows IANAL....

Contrary to the FSF's FAQ, the GPL v2 does not define any linking standard of derivation.  Instead it leaves this open to interpretation by local jurisdictions relating to local copyright laws and traditions.  The line relating to linking vs. communicating with pipes is thus largely an arbitary one, but the general reasoning seems to be that C applications depend on intimate knowledge of data structures when linking and that this intimate knowledge implies derivation.  
I.e. it is the use of a program's internal data structures that makes it derivative.  Though I had argued that a similar standard applies to the GPL v2 before the GPL v3 was released, the GPL v3 specifies this more clearly in the definition of corresponding source ("
dynamically linked subprograms
that the work is specifically designed to require, such as by complex
data communication or control flow between those subprograms and other
parts of the work").  Linking is not defined in the GPL under any version.

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.

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".'

Basically the question is the same-- how much intimate knowledge of data internals is required for something to be "derivative?"  Furthermore since the GPL leaves this in the hands of local laws and courts, there is probably no single answer to this question.  Even in the US, the tests of derivation differ from circuit to circuit.

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."

Best Wishes,
Chris Travers