Over the course of maintaining the Bear, it has become clear to me that we have pieces of code in trunk whose original licensing terms indicate that their author should be contacted as to their status, especially when they would conflict with the terms we distribute under, namely those of the GNU Public License.
Recently I discovered such a licensing lacunae [in working with Jorge Tavares to patch the CL:SORT and CL:STABLE-SORT routines][1], that 'sort.lisp' contains code that has both SBCL and ECL code attributions. Are we in violation of anything here? Dunno. But we certainly have *lots* of SBCL tucked into our tree…
We obviously need an estimate of our non-compliance. As a first step, it seems useful to construct/use a tool that allows us to establish provenance of all commits to ABCL trunk. With this history in hand, we can start figuring out the set of all authors to work through potential conflicts.
A fair amount of work for a non-specialist, but anyone who does this regularly should have an analysis toolset lying around that they could apply to [ABCL trunk][2].
Is there a language lawyer geek in the house?
[1]: http://trac.common-lisp.net/armedbear/ticket/196 [2]: https://code.google.com/p/abcl-dynamic-install/source/browse/
On Jun 10, 2012, at 9:14 , Mark Evenson wrote:
Over the course of maintaining the Bear, it has become clear to me that we have pieces of code in trunk whose original licensing terms indicate that their author should be contacted as to their status, especially when they would conflict with the terms we distribute under, namely those of the GNU Public License.
Recently I discovered such a licensing lacunae [in working with Jorge Tavares to patch the CL:SORT and CL:STABLE-SORT routines][1], that 'sort.lisp' contains code that has both SBCL and ECL code attributions. Are we in violation of anything here? Dunno. But we certainly have *lots* of SBCL tucked into our tree…
Taking SBCL code is not a problem as far as I can see. SBCL is released into the public domain, except that LOOP (which carries a notice of provenance in ABCL) and PCL (which we do not use, our clos is based on Closette and carries the attributions) are BSD-licensed by MIT and Xerox / Gerd Moellman, respectively. I believe a general acknowledgement in README and the manual would be in order, though.
ECL is released under the LGPL which doesn't create license conflicts with the GPL AFAIK, so if we keep attributions we should be ok.
Rudi
On Jun 11, 2012, at 11:42 , Rudi Schlatte wrote:
On Jun 10, 2012, at 9:14 , Mark Evenson wrote:
Over the course of maintaining the Bear, it has become clear to me that we have pieces of code in trunk whose original licensing terms indicate that their author should be contacted as to their status, especially when they would conflict with the terms we distribute under, namely those of the GNU Public License.
Recently I discovered such a licensing lacunae [in working with Jorge Tavares to patch the CL:SORT and CL:STABLE-SORT routines][1], that 'sort.lisp' contains code that has both SBCL and ECL code attributions. Are we in violation of anything here? Dunno. But we certainly have *lots* of SBCL tucked into our tree…
Taking SBCL code is not a problem as far as I can see. SBCL is released into the public domain, except that LOOP (which carries a notice of provenance in ABCL) and PCL (which we do not use, our clos is based on Closette and carries the attributions) are BSD-licensed by MIT and Xerox / Gerd Moellman, respectively. I believe a general acknowledgement in README and the manual would be in order, though.
ECL is released under the LGPL which doesn't create license conflicts with the GPL AFAIK, so if we keep attributions we should be ok.
Nice to have a plausible first-order explanation of the licensing terms: maybe it is not as much work as I feared.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 11 June 2012 14:35, Mark Evenson evenson@panix.com wrote:
ECL is released under the LGPL which doesn't create license conflicts with the GPL AFAIK, so if we keep attributions we should be ok.
Anything that's GPL is outside of our reach. We have the Classpath exception which is one-way incompatible with GPL. You can take Classpath+GPL code and put it into a GPL project. You can't take GPL code and put it into a Classpath+GPL code.
I'm not 100% sure about LGPLv2 -> GPL+Classpath, but it would seem to me that while the intent of LGPLv2 isn't violated by a GPL+Classpath combination, it's still not exactly ok because the wording in LGPLv2 says rather strictly that the linking leeway is provided under the terms of LGPLv2 only, and relicensing isn't allowed. GPL relicensing is explicitly ok, but GPL+Classpath is a different beast, it's not covered by LGPLv2 as being truly compatible.
GPLv3 is a bit different, it allows certain kinds of additional permissions to be added, but GPLv2 doesn't. The Classpath exception is such an additional permission, and GPLv2 does *not* allow it. I don't think LGPLv2 allows it either.
armedbear-devel@common-lisp.net
-
Mark Evenson -
Rudi Schlatte -
Ville Voutilainen