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.
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.
> Can you compile C programs without gcc?
To GCC, your C program is just data. But, your compiled C program does need to be combined with a module such as GNU LibC to run; so you cannot disregard the license of the standard library as irrelevant. The fact that Sun, Microsoft, IBM and others do provide other implementations of the library do not excuse a distributor of distributing a LGPL-incompatible C binary program on a system where it is intended to be combined with GNU LibC to run. e.g.
apt-get install capp # where capp depends on gnulibc
would be a copyright infringement.
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.
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.
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).
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.
[Take, as example the difference between "stealing" and "borrowing". While there is a generally clear distinction criteria between the two (e.g. permission), I am pretty confident that the precise boundary for corner cases is left unspecified in the law of many countries. Just imagine a case where somebody had a plausible reason to think he had "implicit" permission to borrow something, but where the lender did not think so.]
'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.
We could debate this endlessly. I propose that we agree to disagree on this matter.
Under your interpretation, GPLd programs would automatically impose the GPL on their input. [...]
False. I did address this earlier in this message.
Now, let's actually look at building Eclipse. If you require the presence of Kaffe's class libraries to build eclipse, you get into further trouble, as Kaffe's class libraries (as a whole) are licensed under the GNU GPL (see my previous mail titled "Some missing facts").
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.
I think that this is line of reasoning is erroneous. I think that it would be OK to link such programs with GNU LibC as a "last minute" decision by the user, as long as he had the actual choice of linking with some other library that did not conflict with the C program license. In other words, the Debian project, as a distributor, could very easily claim, in court, that it has made all efforts to respect the licensing terms of the C program, by shipping a package that was intended to link with a license compatible class library, and that it was the *user's* decision to use GNU LibC instead.
Nothing in the law, or the licenses involved, forces Debian to make it impossible for the user to use GNU LibC; but a judge could smell "bad intention" if the LGPL compatible C app had a "depends: gnulibc". On the other hand, if "libc" was a virtual package implemented by both "gnulibc" and "publicdomain-libc", and the C app had a "depends: libc", and if the C app was actually runnable using both, I definitely think that Debian would be on the safe side of the law.
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.
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.
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?
Actually, Sun's API is a moving target, and a careful inspection of the Java community process shows a strong Veto power in the hands of a single entity: Sun. So, I see no reason for my "standard" libreadline interface to be "less" standard than the Java API.
You see: there is no clear cut. A judge would study the context and make an appropriate decision.
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.
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.
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.
Of course, as I said above, this depends of your interpretation of what is the strict boundary of combining works. Does depending a specific standard library (regardless of the standardization of its interface) constitute a combination or a simple aggregation is a subject of deep disagreement between your view and mine.
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.
One final point. One CANNOT claim that in the case of any Free JVM using GNU Classpath, currently found in the Debian system, that a virtual machine "merely" executes its class library.
Of course one can. as that's precisely what an interpreter does. It processes data. Just like Bash, Make, and so on, Kaffe processes data. A part of the procesed data is its input, another part of that data are its class libraries. The GPL of Kaffe puts no restrictions on the data it processes. Same for Bash. Same for Make. Read the fine GPL.
That was a clear statement of our differing view of what constitutes the "kaffe interpreter", i.e. does it include the class libraries as base "interpretation" primitives or not.
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.
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. :(
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.
-- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
