Re: GPL and Copyright Law (Was: Eclipse 3.0 Running ILLEGALY on Kaffe)
Etienne Gagnon wrote:
[OK. One "past-last" message, as Dalibor does deserve an answer to his
nice message.]
Dalibor Topic wrote:
Can you interpret shell scripts without GNU Bash? Can you interpret
makefiles without GNU Make?
As far as I can tell, from reading the law and the GPL, the bash script
is simply data to GNU Bash, so you do so as you wish as long as the
license of the script permits it.
And that's precisely what Eclipse is to Kaffe, the interpreter.
Also, the FSF's interpretation of its own GNU GPL license, according to
its GPL license FAQ is:
If a programming language interpreter is released under the GPL, does
that mean programs written to be interpreted by it must be under
GPL-compatible licenses?
When the interpreter just interprets a language, the answer is no. The
interpreted program, to the interpreter, is just data; a free software
license like the GPL, based on copyright law, cannot limit what data
you use the interpreter on. You can run it on any data (interpreted
program), any way you like, and there are no requirements about
licensing that data to anyone.
Absolutely. You can clearly see how the GPL of Kaffe, the interpreter,
does not impose any requirements on Eclipse.
Again in the FSF's GPL FAQ:
Can I use GPL-covered editors such as GNU Emacs to develop non-free
programs? Can I use GPL-covered tools such as GCC to compile them?
Yes, because the copyright on the editors and tools does not cover the
code you write. Using them does not place any restrictions, legally, on
the license you use for your code.
Some programs copy parts of themselves into the output for technical
reasons--for example, Bison copies a standard parser program into its
output file. In such cases, the copied text in the output is covered by
the same license that covers it in the source code. Meanwhile, the part
of the output which is derived from the program's input inherits the
copyright status of the input.
Precisely. Why does not Kaffe running Eclipse violating the GPL? Because
running a GPLd program is fine for any use, on any input. And as Kaffe
generates no output, when it's interpreting Eclipse, everything is just
fine.
If you take a brief look at the copyrights file, the FSF grants no
special exception for bash scripts, or makefiles. Must all of SableVM
be GPLd now, too, if it depends on GNU Make and GNU bash to build on
Debian?
Actually, SableVM's license (LGPL) does have a provision, when you build
an executable from its source code, that allows for not including bash &
all as part of its source code:
However, as a special exception, the materials to be distributed need
not include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on) of
the operating system on which the executable runs, unless that
component itself accompanies the executable.
Without this exception, your reasoning would probably be right.
Well, under your interpretation, GNU Bash's GPL automatically propagates
to all shell scripts just because GNU Bash incorporates GNU readline
(binding to native facility). SableVM couldn't give an exception to such
an overreaching ueber-GPL that imposes restrictions on its input, as you
are not the copyright holder of GNU Bash.
If that's the case, as your interpretation says it is, then SableVM's
bash scripts, makefiles and all that must be GPLd, and as SableVM would
incorporate GPLd works as verbatim copies, so must be SableVM.
Eclipse is data to Kaffe which acts as a filter on it.
I think that this is exactly where we disagree. My understanding of the
law and of the GPL does lead me to interpret the terms of the GNU GPL in
a very similar way to the FSF's interpretation in the GPL FAQ; your
interpretation is different, and I do respect this.
Actually, I will cite the FSF's GPL FAQ relevant parts, first:
However, when the interpreter is extended to provide "bindings" to
other facilities (often, but not necessarily, libraries), the
interpreted program is effectively linked to the facilities it uses
through these bindings. So if these facilities are released under the
GPL, the interpreted program that uses them must be released in a
GPL-compatible way. The JNI or Java Native Interface is an example of
such a binding mechanism; libraries that are accessed in this way are
linked dynamically with the Java programs that call them. These
libraries are also linked with the interpreter. If the interpreter is
linked statically with these libraries, or if it is designed to link
dynamically with these specific libraries, then it too needs to be
released in a GPL-compatible way.
Another similar and very common case is to provide libraries with the
interpreter which are themselves interpreted. For instance, Perl comes
with many Perl modules, and a Java implementation comes with many Java
classes. These libraries and the programs that call them are always
dynamically linked together.
A consequence is that if you choose to use GPL'd Perl modules or Java
classes in your program, you must release the program in a
GPL-compatible way, regardless of the license used in the Perl or Java
interpreter that the combined Perl or Java program will run on.
You may reasonably disagree with the FSF's interpretation, as the GPL is
quite "fuzzy" about the exact boundary of what constitutes "mere
aggregation". Remember, though, that it is this "mere aggregation"
exception that grants you rights by license (according to the law).
I don't disagree at all with FSF's interpretation. It's perfectly
reasonable. I kindly disagree with your interpretation of this FAQ.
That's a major difference.
Since you joined late in the discussion, and didn't ahve a chance to
make yourself familiar with the arguments that have been laid out
already, let me try to help. Gadek already made the claim that FSF
interpretation of the GPL was different from mine at
http://article.gmane.org/gmane.linux.debian.devel.legal/18562
I'll use a verbatim copy of my post to take apart your and Gadek's
claim. Please do not take the heat of the debate as a personal affront.
It's not meant to hurt. I very much appreciate your civility in your
e-mail messages, which are a refreshing change from the pissing match so
far, to which I've contributed a good amount of heat. I hope you can
forgive me for letting my annoyance with the whole matter show so much,
after it has dragged on for almost a week across several debian mailing
lists.
"Which part of "other facilities" do you fail to comprehend?
A GPLd intrepreter can not, because of what the GPL and copyright law
actually say, instead of what you may wish they said, impose
restrictions of the GPL unto the data it interprets. It can bind to
*itself* until it gets blue in its face, but *the interpreter* still
can't impose restrictions on its *input* or *use*.
The clause is there to state that even though a work A may be used on a
GPLd interpreter, the GPL of the interpreter does not 'preempt'/fullfill
the GPL of other works that A derives from. In simple words, for you, so
that you can finally get it: You can't create a work that derives from a
GPld work, and use a GPLd interpreter to work around the GPL of the work
your work derives from, because the interpreter has no business in
shielding you from it, even though it doesn't 'propagate' its own GPL on
your work that you are using with it.
Confusing? That's probably why the FSF put it in a FAQ. I guess someone
tried to circumvent the GPL using a GPLd interpreter to 'shield' them,
and then the FSF had to make sure people understood how things work.
How Kaffe, the GPld interpreter, goes about loading GPLd parts of
*itself* into memory, whether it uses JNI, KNI, dlopen, FFI, libtool, or
other "bindings", or whether it asks the user to tilt switches on an
array of light bulbs is irrelevant to the copyright law. The GPld
interpreter still can't impose restrictions on its input or use. Just
like a GPLd garbage collector going off in the background of my text
editor when I'm composing a reply doesn't suddendly make this reply
message GPLd.
Now, before you go off ranting about Kaffe's native libraries, please
take a moment to let the fact sink in that while these native libraries
are the result of Kaffe developers being a somewhat clever bunch at
developing software and having heard about benefits of seperating one's
program into sepearte modules, those modules are nevertheless *a part of
the interpreter*, and as the copyright law law says, the GPLd
interpreter can't impose restrictions on its input. They even get
compiled in statically on Debian for debian's kaffe package.
Would you please, please stop regurgitating this nonsense. The FSF's FAQ
is perfectly fine. It's your casual reading of it that it wrong."
The problem is, afaict, that you are reading the FAQ entry on the GPLd
interpreter casually, picking the parts that suit your interpretation,
and apparently ignoring entries that don't.
The paragraphs in the FAQ are not connected via 'xor', they are
connected via 'and', afaict ;) The 'native bindings' paragraph does not
conflict with the first paragraph, as you seem to believe. None of the
paragraphs conflict with each other, afaict.
Actually, the FSF's FAQ even tells about the possible ambiguity:
What is the difference between "mere aggregation" and "combining two
modules into one program"?
Mere aggregation of two programs means putting them side by side on the
same CD-ROM or hard disk. We use this term in the case where they are
separate programs, not parts of a single program. [...]
Combining two modules means connecting them together so that they form
a single larger program. If either part is covered by the GPL, the
whole combination must also be released under the GPL--if you can't, or
won't, do that, you may not combine them.
What constitutes combining two parts into one program? This is a legal
question, which ultimately judges will decide. We believe that a proper
criterion depends both on the mechanism of communication (exec, pipes,
rpc, function calls within a shared address space, etc.) and the
semantics of the communication (what kinds of information are
interchanged). [...]
So, in other terms, what constitutes mere aggregation (or not) is
something to be decided on a case-by-case basis in a court of law. This
is similar to many other "corner" cases found (often intentionally) in
laws.
Again, the situation for Kaffe is precisely the same as for GNU Bash,
which doesn't have an extra exception either, nor does it need one for
works that are not derived works of GNU Bash.
Debian never distributes Kaffe and Eclipse as a single program, any more
than it distributes GNU Bash and Eclipse as a single program.
'kaffe eclipse' is no different then 'less eclipse', where less is a
facinatingly cool interpreter for the ASCII programming language,
licensed under the GPL as well. The mere possibility that you can run
Kaffe on Eclipse as its data does not in any way constitute an
infringement of the GPL, as GPL lets you run GPLd programs for
anything on anything.
Your assumption, here, is that Kaffe as a whole (interpreter +
class-lib) is a program, and any application that runs on it is simply
data to it.
My assumption is that Eclipse needs to be combined with a class library
to run, much like C programs need to link with a class library to run.
But unlike C programs, no copyrightable, GPLd expression ever ends up in
the resulting bytecode for the standard Java class library symbol names,
afaict.
There are a lot of reason why what ends up there is not copyrightable,
one of them being that the authors of the few GPLd classes implementing
standard Java apis in Kaffe's class library are not the original authors
of those symbol names, and no creative effort went into them. These
names are defined by well-known specifications that had them way before
you and I started toying with Java.
A copyright holder for Kaffe's few GPld classes could not claim
copyright and GPL's restrictions propagating on 'java/lang/String' in
HelloWorld.class any more than he could claim the same for
'java/lang/String' in libsablevm.so. Just because someone can feed
libsablevm.so to Kaffe as data and that makes Kaffe load some native
libraries, doesn't mean that SableVM must be GPLd.
To me, such an interpretation of the GPL seems pretty bizarre.
We could debate this endlessly. I propose that we agree to disagree on
this matter.
That's what I proposed all along, as I don't think this pissing match
benefits anyone.
Look, I really didn't want this to turn out into a 'My GPL
interpretation is longer than yours' contest. I think it's very
infantile, blown way out of proportion and it wastes my time, and your
time and Gadek's time that could be much better spent writing free
software, and working together with you and Gadek to bring SableVM and
Kaffe closer together, to kick more packages into main together. We do
it most of the days of the year, except on a few days when we all go
emotionally soft and on a GPL interpretation crusade.
You know that I think that SableVM is pretty darn cool, that I value you
and Gadek as my peers, and that I believe that all GNU Classpath
runtimes are in this together, so that I see no value in whacking each
other silly, in particular not in public. You also know that I think you
and Gadek are kick-ass developers and as huggable hackers as it gets. I
regard you as my partners, collaborators, and reliable mates in the
struggle to liberate as many java programs as possible out of the java trap.
What annoyed me was that Gadek started yelling at people for running
Eclipse on Kaffe on debian-java and accused them of doing illegal acts
by pointing to your own SableVM licensing FAQ without mentioning that
the FAQ is just your, not legally binding, interpretation of FSF's FAQ
and Kaffe's license, and that there are Kaffe developers like me that
very much, constructively disagree with that interpretation and offer an
alternative interpetation of the GPL that also matches the text of the
license and the FAQs. He accused the packagers of wasting everyone's
time and all that.
It's perfectly fine for Gadek to yell at SableVM users on your web site
or mailing lists, but it's not nice to do so to Kaffe users and
packagers on debian-java, and to create an impression that Kaffe users
are doing illegal things without having proof, rather then evidence.
"IANAL, but what if GPL worked like this ..." doesn't cut it for me. We
can yell at each other all day on private mailing lists, but when we
take our actually very small licensing interpretation dispute out into
the public, all sorts of people jump on the bandwagon and start the
fire, and it just leads nowehere. We've been there before a couple of
times. I don't want to have to go through all this again in a few
months, and I'm sure you don't want it either.
That was debunked already in November 2003.
Actually, you seem to interpret Andrew Suffield message as meaning that
that C programs distributed by Debian, and intended to link with GNU
LibC at run time, could be licensed under LGPL-incompatible terms, as
long as other companies such as Microsoft, HP, and others have developed
equivalent standard libraries.
Andrew didn't talk about C. I say nothing about C. Let's not have a
hypothetical discussion.
The GPL does not spread to all your e-mails, code, and so on just
because someone used your name in a GPLd piece of text. Feeling lucky?
Good ;)
No, but without my permission, you may not redistribute all of my emails
without my permission. Copyright law is quite clear on this. Copyright
law (at least the Canadian one) does say "the work or any substantial
part thereof". So, there's no copyright on simple words, or even
(maybe) a single paragraph. But if I write a small poem, I might very
well claim copyright on it, and slap the GPL on it.
Yes! The wonderful concept of copyrightablity. I knew we would agree in
the end on something.
You can claim copyright on what's your own original work. Words usually
aren't. Equivalently to your poem example, you can have the copyright on
the complete implementation of java/lang/System.java and put the GPL on
it. You don't have the copyright on those parts of the work you didn't
come up with, which are just enforced by external factors, just like you
don't have the copyright on single words.
In System.java, there is a lot of things that are actually not
copyrightable by the author. The whitespace, semi-colons and other
syntactical elements of the language are not copyrightable because of
scenes a faire. So I can't claim copyright on " " and go on to bother
you because you use whitespace, too ;)
The method, field, class and interface names of a standard Java class
are not original work of the authors of a GPLd reimplementation of that
class, so they can't claim copyright on them. All that ends up in the
output when you are compiling against a GPLd class library for Java
using a bytecode compiler, though, are such names alone. If your code is
using just the standard Java APIs, no GPLd, copyrightable content from
the GPLd class library ever ends up in the class files. Yes, the string
java/lang/String may be in there, but that's not work copyrightable by
me. It's a word invented by someone else. GPL can not work its magic
onto files that do not contain any GPLd, copyrightable content. If it
could, GPL would not be a free software license.
That does not preclude any other reason why a class file could be
derived work from a GPLd class library. It simply means that there is no
automatism taking place, just because the class file contains a sequence
of characters that's also in the GPLd portion of the class library, as
you seem to believe. One needs to examine the resulting package for
copyrightable parts of the GPLd work, and to prove that they came from
it. Evidence is no proof. ;)
See also SCO's claims about owning Linux through errno.h, or having
ownership of Linux because Linux implements Unix APIs, or there is 'int
a;' in Linux source ode, and so on. Your line of reasoning about the
effect of GPL of Kaffe without respect for copyrightability of an
expression is not very different, afaict. As Debian for all I know
disagrees with SCO's linux ownership claims, I don't see why it should
agree to this intepretation.
After building a Java program using a bytecode compiler against
Kaffe's classes, all that ends up from Kaffe's clas libraries in
compiler's output are expressions that are, in general, not
copyrightable.
This is probably, as I said above, something a judge would have to decide.
Sure, but there is no judge. There is no case. I have no idea whether
there ever will be a case. I'd doubt it. I don't even know what about it
would be, as I fail to understand what precisely in Kaffe's license gets
violated when one runs Eclipse on it. To me the GPL's explicit
permission to run Kaffe for any purpose sounds convincing enough to kick
out any such claim out of court instantly.
But given Debian's decision to ignore the fascinating ideas about
copyright without respect for copyrightability from SCO in an ongoing
legal battle, full blown with lawyers and all that, I don't see why it
would make a difference for a strikingly similar interpretation of the
GPL regarding Kaffe, without a case, even.
The GPL can not propagate accross something that's not copyrightable.
This goes back to our disagreement on whether Eclipse does combine or
not with the class library, at run time.
What would prevent me from taking, let say, libreadline, slap a
"standard" interface on it, then claim that my application does not
combine with libreadline, just with a non-copyrightable "standard"
interface?
Every shell script that runs on GNU Bash 'combines' with libreadline, as
GNU Bash includes a verbatim copy of it. That does not automatically
mean that every shell script is a derivative work of GPLd libreadline,
and therefore must be GPLd. As long as the shell script is not a derived
work of libreadline, it doesn't become one by the act of being run on an
interpreter that happens to use libreadline internally.
I don't think an interpretation of the GPL is valid, where the license
of the input to a GPLd interpreter depends on what the interpreter does
internally while it goes about its business of interpreting the data fed
into it.
To give you a more Java-oriented example:
public class UseAllMem {
private static void main (String [] args) {
/* loop forever creating new objects. */
while (true) {
new Object();
}
}
}
Depending on the internals of a JVM implementation, the garbage
collector usally kicks in after a while, to collect all the uselessly
created new objects. Some JVM implementations may be clever enough to
detect that the new Objects can actually be discarded right after they
are being created, and to push and pop them off the stack, never
triggering a garbage collector at all.
Now, under your interpretation of the GPL, just because a GPLd
intepreter has a GPLd garbage collector, this code must be GPLd when its
used on a GPLd interpreter from the moment on the garbage collector
kicks in, but not before, as it's not using a GPLd facility through a
standard interface before that. On the other hand, the class file does
not have to be GPLd when it's used on a GPLd interpreter clever enough
not to bother a GPLd garbage collector at all and do it all one the stack.
There is no difference between the garbage collector and a different
part of the GPLd interpreter. If the GPL does not magically kick in just
for running the GPLd garbage collector, it can't magically kick in just
for running a different native part of the interpeter, like the
interpreter's native libraries implementing parts class library that are
a part of the interpreter. Kaffe's native libraries are a part of the
interpreter.
The interpretation I propose is on the "safe" side. The one you propose
is on the "more dangerous" side. Both have merits. As evidence: Your
opinion seems shared by many non-FSF people; mine seems shared by the
FSF and other people.
Well, I don't think it is shared by the FSF, as their FAQ seems to say a
very different thing, as I've explained above. Essentially, we disagree
whether all of the interpreter part of the GPL FAQ is valid at once, or
whether the paragraphs contradict each other, allowing people to pick
parts that suit their interpretation. I'm for the former, you seem to be
for the latter, as far as I understand your argument.
As I said before, I'll work with the FSF once I'm done with the GNU
Classpath merge, i.e. in a few weeks, to fix whatever unclarities remain
in the FAQ.
If you have a proof to the contrary, please give me file and line in
the Eclipse package, and file and line in the Kaffe package, and we'll
see. Serious requests only, please. I have my hands full with this
nonsense already.
I would use as proof the implicit "extends java.lang.Object", but you
would disagree. See above for the reason our of disagreement.
Yes. But we both can amically agree to disagree on that one for java
bytecode.
Note that I fully agree with you for ahead-of-time compiled Java
code/pre-inlined bytecode, since then whole copyrightable expressions of
the class library end up in the resulting output.
Otherwise, under your fascinating view of copyright law without care
for copyrightability of an expression, SableVM, as it contains parts
of the VM specification copied verbatim in itself, like
VirtualMachine, java, lang, String, etc. is therefore a derived work
of Sun's VM specification, and therefore must go to non-free, as the
VM specification license is non-free.
I do not claim that Eclipse derives from Kaffe because of the interface;
I claim that if it can only run by being combined with a GPL-licensed
module (namely kaffe's class libs), then the combination falls under the
terms of the GPL.
For the eclipse packages, that's not the case, though. They have been
reported to run just fine with Sun's JDK as well, so there seems to be
no dependency on Kaffe's GPLd class library in the built packages.
See
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Copyright.doc.html
for details.
Again, it's up to sun to uphold that its copyright on the API
specification extends to independent implementations of this API.
Copyright does not protect "ideas" expressed in a specification. (That's
the role of patents). Sun could sue me if a copied the API descriptive
documentation text in the javadoc comments of my class library. But,
Sun would have a much harder time claiming that the method names, in
themselves are a "substantial" part of their copyrighted
specifications. Again, this is my personal opinion. If Sun sues me, I
will have to argue this in court.
That's precisely what I'm saying for the case of Java bytecode compiled
against a GPL'd class library.
I don't think one can have it both ways: either the class name
java/lang/String is copyrightable, "a substantial part" of SableVM and
what not, and then Sun probably has Debian by the throat anyway, in
Canada, at least, or its not, and then Kaffe's or SableVM's copyright
holders have no chance of enforcing the GPL just on the basis of
"java/lang/String" ending up in other people's class files, as its not
copyrightable.
I don't think an intepretation of copyright law in which it's OK for
Debian to be relaxed about the string java/lang/String in SableVM becase
noone sued, but it's necessary for Debian to go into panic mode about
the string java/lang/String in Eclipse packages, although noone sued, is
consistent.
I personally think that the consistent, sane interpretation for Debian
is that the sequence of characters java/lang/String is not
copyrightable, any more than "http://";, "URL", or ";" are.
Anyway, this is really my last message on this thread. I do respect the
fact that you disagree to my views, and I see no good reason for any of
us to change his view, as both views have merits. While I am confident
my view is the safest, I can see why you can sincerely think that your
view is correct.
I'm glad that we can agree to disagree. And I see how you honestly think
that your interpetation of the GPL is correct. I'd like to apologize
here in public if I made an impression of suggesting otherwise. I hope
you can accept that.
I'm more than happy to bury this hatchet and go back to real work with
you guys ;) Please urge Gadek a bit more to release SableVM 1.1.9 with
the updated class libraries from GNU Classpath, so that eclipse can go
to main on both Kaffe and SableVM, benefitting Debian users way more
than this endless discussion.
At last, I insist that my views are shared, as far as I can tell, by the
FSF (no surprise, as actually, they are based on clarifications I got
from Richard Stallman a while ago), and so, you may decide to disregard
it, but in doing so, you are *probably* also disregarding the opinion of
the author of the GNU GPL. Of course, you can rightfully claim that the
important opinion is that of the Copyright holders, but, in the case of
Kaffe, it would seem pretty difficult to get a clear statement of all of
them, given the fate of Transvirtual. :(
Yes, that's why I'm not very keen on doing heaps of work on relicensing
Kaffe without a very, very good reason. Some of the copyright holders
are dead, actually. Whoever wants to have a go at it, if they believe
that to be necessary, can do it, though. Just fork, and go for it, i.e.
get a permission to relicense from all copyright holders from the last,
uh, eight years.
I can't claim to have the privilege of having discussed the effects of
the GPL on an interpreter with Richard, and I'd rather not waste his
time with all this as long as Kaffe is not fully merged with GNU
Classpath as I know he is very busy with important things, and this is
essentialy a brief temporary storm in a cup ;)
From what I can see from how the FSF is licensing their interpreters
(bash, make, maybe others), without specific exceptions, and my repeated
reading of the FAQ and the GPL, I can't find a problem with my
interpretion of the GPL. But I'm sure the FSF will set me straight when
we get to discuss it, after the GNU Classpath merge is done.
I've also outlined why I believe that an affirmative interpretation of
copyrightability of standard signatures found in Java APIs to be of no
advantage to anyone writing a free software, clean-room interpreter for
the Java programming language, or distributing them.
Dalibor, have fun going back to hacking. I will. See you as usual on
IRC for fun discussions and collaboration.[1]
Etienne
[1] While this could sound strange to some debian-legal folks, after
reading this long flamewar thread, kaffe, sablevm, and many other jvm
and java classlib hackers do discuss and collaborate regularly.
360 days a year, actually. Etienne, Gadek and me take 5 days each year
to whack another senseless, but most of time we enjoy kicking the crap
out of non-free VMs. Well, I guess we have to practise *somewhere* ;)
cheers,
dalibor topic
Reply to: