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