Camm Maguire's proposal for shifting GCL to the GPL:
<http://article.gmane.org/gmane.lisp.gcl.devel/1868>
Camm Maguire "would like to hear from as many GCL users as possible
regarding their opinions on how this would affect their work. My
understanding is that it would not affect GCL's current main users --
maxima, acl2, and axiom, at all."
I had earlier provided this response:
<http://article.gmane.org/gmane.lisp.gcl.devel/1861>
I'm merely a potentially future user of GCL, having only performed some
cursory private benchmarking and the most limited of testing. Note that in
this portion of my earlier response...
We're probably only having this discussion because you've been using
GPLed code to dump memory images. As you reminded me a main issue is
libbfd. I find this is a GPLed utility which is part of GNU binutils.
So long as you have a way of building GCL from source and the GPLed
code is not needed to use COMPILE-FILE it would seem that you could
remove it. I shudder at the technicalities but perhaps some of CMUCL or
SBCL's public domain/BSD-licensed code (without advertising clause)
could be used to eventually reimplement the dumping of arbitrary memory
images.
By the way (and I understand Stallman made this point earlier) it is
not sufficient for you [to] simply shift to the GPL with an exception.
You could only do that if you were the copyright holder of all the GPL
code you were using. Then you could grant whatever exceptions you felt
like. In the absence of this you either move to the GPL WITHOUT
exception or ask the copyright holders to grant you an exception.
The Common Lisp community generally understands the implications of
placing a CL implementation under the GPL without exception (it's
likely that any user code must be GPLed if distributed) and it is clear
few would use such an implementation or distribute their code compiled
for such an implementation.
In the absence of the FSF granting you a sufficiently broad exception
to the GPLed code you are presently using (and then shifting GCL to a
GPL+exception licence) you have compelling reasons to remove your
dependence upon the GPLed code.
...I thought it was addressing this issue:
http://article.gmane.org/gmane.lisp.gcl.devel/1834
I will do everything in my power to ensure that GCL's license will
never force a license onto projects that use it as a compiler. This is
not only achievable, but from my understanding, not even controversial
among the existing participants of this discussion. Please, everyone,
rest assured.
Camm's proposal appears to address this by not allowing many (binary only)
projects to access the compiler after they are distributed. The compiler
will be GPLed and for example:
Someone ships binary only .o files according to the license of their
choosing, as long as they reference only the LGPL'ed 'runtime'
functions and not the compiler, linker, or dumper. This is closest to
the model of proprietary binaries shipped for GNU/Linux systems today.
Here the user's running GCL is analogous to the OS, their execution of
the 'load' command to load the .o files analogous to the action of
ld.so in GNU/Linux, and the .o files' invocation of the common lisp
runtime functions analogous to proprietary binaries' calling libc
functions.
This is not a fully featured Lisp as I would understand it where the
compiler is available at runtime. It's a cut down version that one would
expect of an aggressively proprietary implementation. It is perhaps
noteworthy that some of the technical restrictions imposed by aggressively
proprietary and aggressively capital-F Free Lisp implementations may be
starting to converge.
Out of this shakeup CMUCL and SBCL may emerge as the Apache of the Lisp
world. Either that or we end up happy to use something much more abstract
than C but more limited than Lisp's potential (or more precisely, a
potential that can only be realised if all distributed code is released
under the GPL).
I for one am rooting for implementations designed to release Lisp's full
technical potential. Not those built to restrict Lisp's power in order to
conform with licensing restrictions designed by the Free Software
Foundation for the world of C.
Regards,
Adam
Hi Jan Rychter,
> Whenever GPL is being discussed, people tend to focus on the "binary
> distribution" issue -- will I have to give away the source code or not?
>
> Having worked with GPL software quite a bit, also in the commercial
> world, and having gotten some legal advice, I believe that the
> "anti-patent" clauses in the GPL and LGPL are quite possibly the biggest
> problem preventing the use of GPL'd software by commercial entities,
> much bigger than the "pass on the source and the rights" requirement.
Then you should note that GCL is already licensed under the GNU LGPL so
your contribution, while valuable, may not be the critical issue in this
case.
> An excerpt from the GPL:
>
> 7. If, as a consequence of a court judgment or allegation of patent
> infringement or for any other reason (not limited to patent issues),
> conditions are imposed on you (whether by court order, agreement or
> otherwise) that contradict the conditions of this License, they do
> not excuse you from the conditions of this License. If you cannot
> distribute so as to satisfy simultaneously your obligations under
> this License and any other pertinent obligations, then as a
> consequence you may not distribute the Program at all. For example,
> if a patent license would not permit royalty-free redistribution of
> the Program by all those who receive copies directly or indirectly
> through you, then the only way you could satisfy both it and this
> License would be to refrain entirely from distribution of the
> Program.
Refer clause 11 of the LGPL.
> [...]
> 8. If the distribution and/or use of the Program is restricted in
> certain countries either by patents or by copyrighted interfaces, the
> original copyright holder who places the Program under this License
> may add an explicit geographical distribution limitation excluding
> those countries, so that distribution is permitted only in or among
> countries not thus excluded. In such case, this License incorporates
> the limitation as if written in the body of this License.
Refer clause 12 of the LGPL.
> As I understand it (and as my legal counsel advises me) this effectively
> means that if I distribute GPL/LGPL code, I have to make sure that its
> distribution and re-distribution is not restricted by patents (or other
> restrictions).
>
> If the code in question contains parts which some patents lay claim to,
> restricting distribution, then I must not distribute the code at all.
> Furthermore, by distributing the code I breach the GPL and expose myself
> to legal threat of a lawsuit from the FSF.
While I wouldn't express it in these terms the clauses are intended to
create a situation of mutually assured destruction. Once cannot release
code that is ostensibly free by permissively licensing it (MIT, BSD-style
etc.) and then telling everyone that they can't distribute the code
without paying patent royalties.
Software patent royalties may cause the death of free software
development whether one is building permissively licensed or copylefted
software. Sure some companies may be able to scavenge something from the
carcass of present BSD-style projects but continuing within a free
distribution environment may no longer be possible.
This is a simple point that some (other) people don't seem to grok: one
can no longer have free software development and free software
distributions if one must pay royalties whenever the software is
distributed.
I've tried to address some of these issues in a more rigorous fashion with
my draft dynamic model of software adoption (corrections and comments
appreciated):
<https://macrology.co.nz/software-adoption.html>
<https://macrology.co.nz/software-adoption-print.pdf>
The PDF is much less load on the server as the graphs and many of the
equations in the HTML version are PNG bitmaps.
By the way, "expose myself to legal threat of a lawsuit from the FSF"
would be well down on my list of things to worry about. You're probably
more likely to experience royalty shakedowns long before you ever manage
to annoy the Free Software Foundation. And by the way this presupposes
that the code you use is even owned by the FSF. Why for example should you
expect to "breach the GPL and expose myself to legal threat of a lawsuit
from the FSF" if the codebase was the Linux kernel? Or some of the code I
have released? If it was my code you should be worried about exposing
yourself to legal threat of a lawsuit from Adam Warner. Scary ;-)
Currently the big licensing shakedown making headlines in New Zealand and
across the world is the claim that many New Zealand websites must pay a
$10,000 signing fee and 1.5 per cent of all sales in order to continue
conducting cross-border e-commerce transactions.
<http://www.canada.com/montreal/specials/business/story.html?id=B7BE57DC-1F41-4444-B779-F71914568E5E>
DET is now starting to flex its patent muscle, insisting it's time for
companies involved in e-commerce to pay it royalties.
Its first targets are in New Zealand, where DET's lawyers sent letters
to several Web sites two weeks ago warning they could be shut down if they
don't pay DET a $10,000 "signing fee," plus 1.5 per cent of all sales.
Several recipients balked, saying paying up would put them out of
business. They hired a law firm, contacted the media and set up a Fight
the Patent site to co-ordinate anti-DET efforts.
...
DET, a four-employee, private firm that moved to Quebec from Virginia
last year to be closer to Canadian investors, is sticking to its guns.
Chief executive Edward Pool said he and a partner developed their
process in the early 1990s, before the commercialization of the
Internet. "We invented this before Netscape was a company," Pool said.
In New Zealand, "we've exerted our legal rights and the damage clock is
running," he said. If they don't pay, "we will seek a ruling with the
International Trade Commission against infringing New Zealand companies,
and if we're successful, we'll have their goods seized."
This however is a business method patent.
Regards,
Adam
Hi Jan Rychter,
> Please consider the case in point, XviD code (http://www.xvid.org/). It
> is an implementation of the MPEG-4 standard, and the code is placed
> under the GPL. My company has made extensive improvements to the XviD
> code (namely, ported it to a DSP processor). We would like to bundle
> that code with our product, while paying the required royalties to
> whomever owns the patents and contributing the code to the XviD project.
> We can't do that. In fact, no one can redistribute XviD code without
> breaching the licensing terms, because some algorithms that it
> implements are patented in some countries.
...
> Also, please notice that I actually do want to pay the royalty fees. And
> I do want to distribute the source and to contribute to open-source
> projects. It's just that some licenses (notably the GPL and the LGPL)
> explicitly forbid me to redistribute code which is constrained by
> patents.
You have asked me to consider a case in point, MPEG-4 licensing. And you
want to contribute to an open source project while paying MPEG-4
royalties.
To convince me this is a consistent position please first obtain these
licensing conditions:
<http://www.mpegla.com/mpeg4v/>
<http://www.mpegla.com/mpeg4v/m4v_agreement.html>
Please e-mail your name, company and address to our Licensing
Department and a hardcopy of the MPEG-4 Visual Patent Portfolio License
will be sent to you promptly. If you do not receive your copy within
three business days, please call us at 301.986.6660.
Once you have obtained a copy of the licensing conditions please work
through them point by point and discuss whether each clause is consistent
with either the Debian Free Software Guidelines or the Open Source
Definition (the choice of guidelines or definition is up to you):
<http://www.debian.org/social_contract.html#guidelines>
<http://opensource.org/docs/definition.php>
I suspect you will soon discover that there is a large difference between
a licence being compatible with open source software and the combined
licences continuing to be open source software.
open source software + onerous licensing conditions
^ |
| |
=== |
| <--feedback |
+-------------------------------------------------+
How could you contribute to an open source project if the additional
licensing restrictions you sign up to could remove the project's open
source characteristics?
Regards,
Adam