Gents, I nearly had ABCL into an upcoming project, until I checked the license. I should have looked at this before I embarked down this path, but for some reason assumed that since ABCL is a relatively young implementation it was using Apache/MIT/BSD or something similar. Here's the opensource clause from the contract:
1.1 OPEN SOURCE SOFTWARE. To the extent that the Company develops orprovides any software to <Customer> under this Agreement, without <Customer’s> priorwritten consent, that <Customer> may grant or withhold in its sole discretion, nosuch deliverable shall incorporate, link to or call upon any Open SourceSoftware. “Open Source Software” means any software that is generally availableto the public in source code form under (i) licenses substantially similar tothose approved by the Open Source Initiative and listed athttp://www.opensource.org/licenses, or (ii) any copyleft license (including aReciprocal License), or (iii) any other license that contains terms thatrequire, whether or not conditionally, disclosure of any source code.
This clause, or one very much like it, has been in every contract for the last 10 years or so, or at least since the BusyBox debacle. Most of the time companies have a list of pre-approved licenses, with MIT/Apache/BSD almost always being on it. Note the specific exclusion "any copyleft license" and any license in any form that might cause disclosure of source code. Reading the ABCL FAQ and web page, it seems the intention is to avoid compelling a company from releasing their source code:
The use of Armed Bear Common Lisp (ABCL) is covered by the GNU General Public License with Classpath exception, meaning that you can use ABCL in your application without the requirement to open the sources to your application.
However there's a few problem with this: - It has the words "GNU General Public License", which rings loud alarm bells with corporate lawyers (and is disqualified by clauses ii/iii anyway) - Whilst the intention is to allow ABCL to be mixed with proprietary code, the IP equivalent of ambulance chasing lawyers may still see it as an opportunity for profit. It's worth reading the BusyBox saga if you're not familiar with it.
- It's never been tested in court The last point is worth elaborating on. I once cornered a friendly corporate lawyer at one of our company drinks functions and showed him the LLGPL and asked what he thought. His response put it all in perspective. He said:
"It looks fine to me, but it's never been tested in court. Would you take an open source project and deploy it to production and bet the company's livelihood on it, without testing it first?" I guess I can't blame them really. Would you want stick your neck out for something with potentially catastrophic consequences, when there's plenty of alternatives? Lisp has enough of an uphill climb just on the technology front, this is the nail in the coffin.
Questions: - Would the current maintainers of ABCL consider relicensing it under a MIT, BSD or Apache license? - If so, do we have a list of all the contributors? - If so, how many are there and are they contactable?
On Aug 7, 2020, at 14:27, Steven Nunez steve_nunez@yahoo.com wrote:
Gents,
I nearly had ABCL into an upcoming project, until I checked the license. I should have looked at this before I embarked down this path, but for some reason assumed that since ABCL is a relatively young implementation it was using Apache/MIT/BSD or something similar.
I don’t think ABCL qualifies as “a relatively young implementation”, as the ABCL sources go back to the releases of the J editor as of 2002.
[1]: https://sourceforge.net/projects/armedbear-j/files/j/0.15.0/
[…]
However there's a few problem with this: • It has the words "GNU General Public License", which rings loud alarm bells with corporate lawyers (and is disqualified by clauses ii/iii anyway) • Whilst the intention is to allow ABCL to be mixed with proprietary code, the IP equivalent of ambulance chasing lawyers may still see it as an opportunity for profit. It's worth reading the BusyBox saga if you're not familiar with it. • It's never been tested in court The last point is worth elaborating on. I once cornered a friendly corporate lawyer at one of our company drinks functions and showed him the LLGPL and asked what he thought. His response put it all in perspective. He said:
"It looks fine to me, but it's never been tested in court. Would you take an open source project and deploy it to production and bet the company's livelihood on it, without testing it first?"
I guess I can't blame them really. Would you want stick your neck out for something with potentially catastrophic consequences, when there's plenty of alternatives? Lisp has enough of an uphill climb just on the technology front, this is the nail in the coffin.
[…]
ABCL is [licensed under the GPL v2 with the classpath exception][2], not the LLGPL.
[2]: https://en.wikipedia.org/wiki/GPL_linking_exception
That the GPL has “never been tested in court” is certainly not true: it has been successfully defended multiple times, and has proved to be one of the stronger means of enforcing software freedom.
[3]: https://www.fsf.org/news/wallace-vs-fsf [4]: https://en.wikipedia.org/wiki/GNU_General_Public_License#Legal_status
One is free to provide the resources to overcome the percieved problem of “[betting] the company’s livelihood on it, without testing it first”. I fail to see how changing the license for ABCL will somehow make it more tested, especially wrt. to the commercial liabilities that are specific to your desired usage.
[4]: https://abcl.org/commercial-support.shtml
Questions: • Would the current maintainers of ABCL consider relicensing it under a MIT, BSD or Apache license? • If so, do we have a list of all the contributors? • If so, how many are there and are they contactable?
When we released ABCL 1.0 way back in 2011, the current maintainers informally agreed to attempt to preserve the spirit of original copyright holder (Peter Graves) of having a core implementation which others were able to create software licensed under terms of their choosing. The current licensing scheme for ABCL continues to preserve such freedom.
Nevertheless, if you were willing to provide the necessary financial and legal resources, I would be ammendable to beginning such an effort that would somehow preserve the promised freedom that all previous contributors to ABCL have labored towards. But from your not checking the ABCL license before you even entertained the notion of using it under such legal conditions, your having induced Alessio to provide a substantial contributions towards your desired usage, and to your new request for further unpaid work to utilize ABCL for your commercial contract, I fear that you have a fundamental misunderstanding of what working with “free” software actually entails.
Sincerely, Mark
On Saturday, August 8, 2020, 3:13:06 PM GMT+8, Mark Evenson evenson@panix.com wrote:
On Aug 7, 2020, at 14:27, Steven Nunez steve_nunez@yahoo.com wrote:
However there's a few problem with this: • It has the words "GNU General Public License", which rings loud alarm bells with corporate lawyers (and is disqualified by clauses ii/iii anyway) • Whilst the intention is to allow ABCL to be mixed with proprietary code, the IP equivalent of ambulance chasing lawyers may still see it as an opportunity for profit. It's worth reading the BusyBox saga if you're not familiar with it. • It's never been tested in court The last point is worth elaborating on. I once cornered a friendly corporate lawyer at one of our company drinks functions and showed him the LLGPL and asked what he thought. His response put it all in perspective. He said:
"It looks fine to me, but it's never been tested in court. Would you take an open source project and deploy it to production and bet the company's livelihood on it, without testing it first?"
I guess I can't blame them really. Would you want stick your neck out for something with potentially catastrophic consequences, when there's plenty of alternatives? Lisp has enough of an uphill climb just on the technology front, this is the nail in the coffin.
[…]
ABCL is [licensed under the GPL v2 with the classpath exception][2], not the LLGPL. I'm aware of that, however it wasn't the license I thought of when I had the opportunity to ask the question. I believe his concerns of risk are still valid in this situation.
[2]: https://en.wikipedia.org/wiki/GPL_linking_exception
That the GPL has “never been tested in court” is certainly not true: it has been successfully defended multiple times, and has proved to be one of the stronger means of enforcing software freedom.
[3]: https://www.fsf.org/news/wallace-vs-fsf [4]: https://en.wikipedia.org/wiki/GNU_General_Public_License#Legal_status What has never been tested in court is the protection of the classpath exception. If the class path exception has been successfully defended and the customer has not had to release their code, I'd be very keen to read and pursue it as an option here.
One is free to provide the resources to overcome the percieved problem of “[betting] the company’s livelihood on it, without testing it first”. I fail to see how changing the license for ABCL will somehow make it more tested, especially wrt. to the commercial liabilities that are specific to your desired usage.
[4]: https://abcl.org/commercial-support.shtml Changing ABCL to one of the commonly allowed licenses for commercial settings will make it possible to use it in projects that have contract clauses similar to the one I provided. BTW: it's not a matter of what I perceive, it's what the lawyers on both sides of the contract perceive. I don't make the rules; I just obey them.
Questions: • Would the current maintainers of ABCL consider relicensing it under a MIT, BSD or Apache license? • If so, do we have a list of all the contributors? • If so, how many are there and are they contactable?
When we released ABCL 1.0 way back in 2011, the current maintainers informally agreed to attempt to preserve the spirit of original copyright holder (Peter Graves) of having a core implementation which others were able to create software licensed under terms of their choosing. The current licensing scheme for ABCL continues to preserve such freedom.
Nevertheless, if you were willing to provide the necessary financial and legal resources, I would be ammendable to beginning such an effort that would somehow preserve the promised freedom that all previous contributors to ABCL have labored towards. But from your not checking the ABCL license before you even entertained the notion of using it under such legal conditions, your having induced Alessio to provide a substantial contributions towards your desired usage, and to your new request for further unpaid work to utilize ABCL for your commercial contract, I fear that you have a fundamental misunderstanding of what working with “free” software actually entails.
That's OK, I think I have my answer. I'm well aware of what it means to work with 'free' software, in all forms of 'free'. This wasn't intended to debate the philosophy or moral rights of software freedoms; it was intended to see if there was a practical solution to the use of ABCL in a commercial environment, given the contractual constraints. Providing 'financial and legal resources' isn't an option, so we'll end up following the path of least resistance. I just thought I'd put this out to the ABCL community to test the waters, and it's clear the waters are decidedly cold. Personally, I think non-GNU licenses are great for software communities, precisely because they do allow commercial entities to use the code and, today, most companies are happy to outsource their development costs to upstream maintainers; look at the commercial contributions to FreeBSD for example. It's a win-win that was unimaginable in Stallman's time.
On Aug 8, 2020, at 10:21, Steven Nunez steve_nunez@yahoo.com wrote:
[…]
BTW: it's not a matter of what I perceive, it's what the lawyers on both sides of the contract perceive. I don't make the rules; I just obey them.
I think you mistate your own responsiblities and potential for agency. You certainly didn’t obey the rules of your contract when you prototyped software with a forbidden license. And now you attempting to persuade others to change rules that you chose not to obey.
Nevertheless, if you were willing to provide the necessary financial and legal resources, I would be ammendable to beginning such an effort that would somehow preserve the promised freedom that all previous contributors to ABCL have labored towards. But from your not checking the ABCL license before you even entertained the notion of using it under such legal conditions, your having induced Alessio to provide a substantial contributions towards your desired usage, and to your new request for further unpaid work to utilize ABCL for your commercial contract, I fear that you have a fundamental misunderstanding of what working with “free” software actually entails.
That's OK, I think I have my answer. I'm well aware of what it means to work with 'free' software, in all forms of 'free'. This wasn't intended to debate the philosophy or moral rights of software freedoms; it was intended to see if there was a practical solution to the use of ABCL in a commercial environment, given the contractual constraints. Providing 'financial and legal resources' isn't an option, so we'll end up following the path of least resistance. I just thought I'd put this out to the ABCL community to test the waters, and it's clear the waters are decidedly cold.
Describing my offer to be willing consider relicensing ABCL with proper financial and legal support for the work it would entail is hardly “cold”. If you derive commercial value from something, you should be prepared to partake in the externality costs involved in the creating the financial value you seek to extract.
Personally, I think non-GNU licenses are great for software communities, precisely because they do allow commercial entities to use the code and, today, most companies are happy to outsource their development costs to upstream maintainers; look at the commercial contributions to FreeBSD for example. It's a win-win that was unimaginable in Stallman's time.
Many companies successfully use GNU copylefted software everyday, deriving substansial financial profit. Linux, a GNU copylefted software system, has powered more commercially used systems than its closest competitors for more than a decade now. The expansive world afforded by the internetworking of human genius provides ample space for both kinds of licensing to exist, and prosper.
The BSD licensing arrangement was largely contemporanous with “Stallman’s time” (late 1980s), for which there were many successful commercial utlizations esp. in the field of networking appliances (e.g. F5). Arguing that it was “unimaginable” is not at all persuasive. Looking back, if anything, the commercial success of GNU licensing terms is more unbelievable.
I have utililized, maintained, and originated many BSD-licensed codebases for commercial entities. But I didn’t originate ABCL and am unable to provide the resources to undertake its potential relicensing. If that’s cold, that’s because it is reality.
On Sun, 9 Aug 2020 at 11:59, Mark Evenson evenson@panix.com wrote:
Describing my offer to be willing consider relicensing ABCL with proper financial and legal support for the work it would entail is hardly “cold”. If you derive commercial value from something, you should be prepared to partake in the externality costs involved in the creating the financial value you seek to extract.
Greetings. My contributions to ABCL are not up for relicensing to bsd/mit/apache; they were written under the expectation that ABCL is and will remain GPL.
Thank you, and have a nice day.
I second what Erik and Ville said.
I would be happy for ABCL to be used in a commercial project, and I would not be personally against releasing a version of ABCL, including my contributions, under a commercial license (whose profits could go towards improving ABCL). But relicensing it under a permissive license, just so that some business can make money from it for free without any form of compensation, would be unfair in my opinion. I mean, Oracle itself applies the very same licensing scheme to Java and the JVM: GPL with classpath exception for OpenJDK, and a commercial license for Oracle JDK.
Cheers, Alessio
On Sun, Aug 9, 2020, 11:32 Ville Voutilainen ville.voutilainen@gmail.com wrote:
On Sun, 9 Aug 2020 at 11:59, Mark Evenson evenson@panix.com wrote:
Describing my offer to be willing consider relicensing ABCL with proper financial and legal support for the work it would entail is hardly
“cold”. If
you derive commercial value from something, you should be prepared to
partake
in the externality costs involved in the creating the financial value
you seek
to extract.
Greetings. My contributions to ABCL are not up for relicensing to bsd/mit/apache; they were written under the expectation that ABCL is and will remain GPL.
Thank you, and have a nice day.
I'll offer my own view, with complete respect for the view Ville promotes. In my case, when I worked for Science Commons, we chose to license software using BSD because in our view getting the ideas out to the widest audience was the biggest win. The situation with ABCL is different in a couple of ways that do matter. In our case we were promoting new semweb tech, and we were not working with a code base with a long lineage of contributors who had participated under the premise of ABCL's license choice. As Ville's view exemplifies, it woild be difficult, at this point, to relicense ABCL.
Still, I believe the goal of wide dissemination and use is part of the ethos, so I would search for a way to somehow make it possible to use the project. To that end I have a few suggestions. 1) To the extent that the testing of the classpath clause is an unknown, perhaps we (ABCL's developers) could offer a memorandum of understanding that clarifies that we will not initiate legal action if the provisions of the license are followed, regardless of future legal developments. 2) Steve, you could budget at least a relatively small sum of money for support of the project. There is a fund that Mark set up to which I have and will continue to contribute. 3) I have had a decent amount of experience (despite that IANAL) with talking with legal and business types about use of free software, and successfully lobbied a pharmaceutical company I work with to both use GPL software and subsequently release software I wrote while working there, when I left the company. If you would like to contact me privately we can discuss the specifics of your situation and ways you might approach gaining consent to use ABCL under it's current license.
Regards, Alan
On Sunday, August 9, 2020, Ville Voutilainen ville.voutilainen@gmail.com wrote:
On Sun, 9 Aug 2020 at 11:59, Mark Evenson evenson@panix.com wrote:
Describing my offer to be willing consider relicensing ABCL with proper financial and legal support for the work it would entail is hardly
“cold”. If
you derive commercial value from something, you should be prepared to
partake
in the externality costs involved in the creating the financial value
you seek
to extract.
Greetings. My contributions to ABCL are not up for relicensing to bsd/mit/apache; they were written under the expectation that ABCL is and will remain GPL.
Thank you, and have a nice day.
I have ABCL installed in my system using brew:
% brew info abcl abcl: stable 1.7.1 (bottled), HEAD Armed Bear Common Lisp: a full implementation of Common Lisp https://abcl.org/ /usr/local/Cellar/abcl/1.7.1_1 (8 files, 11.0MB) * Poured from bottle on 2020-08-28 at 13:42:31 From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/abcl.rb License: GPL-2.0-or-later with Classpath-exception-2.0 ==> Dependencies Required: ant ✔, openjdk ✔, rlwrap ✔ ==> Options --HEAD Install HEAD version ==> Analytics install: 59 (30 days), 211 (90 days), 486 (365 days) install-on-request: 53 (30 days), 190 (90 days), 437 (365 days) build-error: 0 (30 days)
But until now, it was working fine, but now, after the update I am getting the error below. I looks like the openjdk used to compile was not updated in brew, any solution?
ar@leme bin % abcl Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.UnsupportedClassVersionError: org/armedbear/lisp/Main has been compiled by a more recent version of the Java Runtime (class file version 58.0), this version of the Java Runtime only recognizes class file versions up to 52.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:756) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:468) at java.net.URLClassLoader.access$100(URLClassLoader.java:74) at java.net.URLClassLoader$1.run(URLClassLoader.java:369) at java.net.URLClassLoader$1.run(URLClassLoader.java:363) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:362) at java.lang.ClassLoader.loadClass(ClassLoader.java:418) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355) at java.lang.ClassLoader.loadClass(ClassLoader.java:351) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
On Aug 28, 2020, at 21:24, Alexandre Rademaker arademaker@gmail.com wrote:
I have ABCL installed in my system using brew:
% brew info abcl abcl: stable 1.7.1 (bottled), HEAD Armed Bear Common Lisp: a full implementation of Common Lisp https://abcl.org/ /usr/local/Cellar/abcl/1.7.1_1 (8 files, 11.0MB) * Poured from bottle on 2020-08-28 at 13:42:31 From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/abcl.rb License: GPL-2.0-or-later with Classpath-exception-2.0 ==> Dependencies Required: ant ✔, openjdk ✔, rlwrap ✔ ==> Options --HEAD Install HEAD version ==> Analytics install: 59 (30 days), 211 (90 days), 486 (365 days) install-on-request: 53 (30 days), 190 (90 days), 437 (365 days) build-error: 0 (30 days)
But until now, it was working fine, but now, after the update I am getting the error below. I looks like the openjdk used to compile was not updated in brew, any solution?
ar@leme bin % abcl Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.UnsupportedClassVersionError: org/armedbear/lisp/Main has been compiled by a more recent version of the Java Runtime (class file version 58.0), this version of the Java Runtime only recognizes class file versions up to 52.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:756) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:468) at java.net.URLClassLoader.access$100(URLClassLoader.java:74) at java.net.URLClassLoader$1.run(URLClassLoader.java:369) at java.net.URLClassLoader$1.run(URLClassLoader.java:363) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:362) at java.lang.ClassLoader.loadClass(ClassLoader.java:418) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355) at java.lang.ClassLoader.loadClass(ClassLoader.java:351) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
The brew recipe you reference seemingly specifies using openjdk14 to compile which is why the class version of org/armedbear/lisp/Main is reported as 58.0. But it seems that the `abcl` script is attempting to start ABCL with an Java 8 runtime (which has class file version 52.0).
I don’t really use Homebrew, so don’t really know how it manages the Java runtime infrastructure used by its installation of recipes, but here’s how I would diagnose your setup.
1) Check the contents of the `abcl` script to see what version of Java it is trying to use.
2) Possibly start abcl with the `—-noinit` flag to see if that makes a difference.
On Saturday, August 8, 2020, 6:10:03 PM GMT+8, Mark Evenson evenson@panix.com wrote:
On Aug 8, 2020, at 10:21, Steven Nunez steve_nunez@yahoo.com wrote:
[…]
BTW: it's not a matter of what I perceive, it's what the lawyers on both sides of the contract perceive. I don't make the rules; I just obey them.
I think you mistate your own responsiblities and potential for agency. You certainly didn’t obey the rules of your contract when you prototyped software with a forbidden license. And now you attempting to persuade others to change rules that you chose not to obey.
You are making several false assumptions here without any knowledge of the facts of my motivations, responsibilities or 'agency'.
Nevertheless, if you were willing to provide the necessary financial and legal resources, I would be ammendable to beginning such an effort that would somehow preserve the promised freedom that all previous contributors to ABCL have labored towards. But from your not checking the ABCL license before you even entertained the notion of using it under such legal conditions, your having induced Alessio to provide a substantial contributions towards your desired usage, and to your new request for further unpaid work to utilize ABCL for your commercial contract, I fear that you have a fundamental misunderstanding of what working with “free” software actually entails.
That's OK, I think I have my answer. I'm well aware of what it means to work with 'free' software, in all forms of 'free'. This wasn't intended to debate the philosophy or moral rights of software freedoms; it was intended to see if there was a practical solution to the use of ABCL in a commercial environment, given the contractual constraints. Providing 'financial and legal resources' isn't an option, so we'll end up following the path of least resistance. I just thought I'd put this out to the ABCL community to test the waters, and it's clear the waters are decidedly cold.
Describing my offer to be willing consider relicensing ABCL with proper financial and legal support for the work it would entail is hardly “cold”. If you derive commercial value from something, you should be prepared to partake in the externality costs involved in the creating the financial value you seek to extract.
Perhaps it was your combative tone, demand for money and resources and jumping to false conclusions that lead me to say it was cold. The facts actually are that I gain no commercial value from using ABCL; only the day to day satisfaction of using a language that doesn't suck. I was willing to contribute my own personal time and effort to tracking down contributors and attempting to persuade them to agree to a license change, if there was interest.
[non-sequitur FreeBSD comments removed]
This conversation is over. Ville's message makes the conversation moot; not that it looked like it was ever going to be a constructive, rational discussion in the first place.
armedbear-devel@common-lisp.net
-
Alan Ruttenberg -
Alessio Stalla -
Alexandre Rademaker -
Mark Evenson -
Steven Nunez -
Ville Voutilainen