Salut Etienne, Etienne Gagnon wrote:
Dalibor Topic wrote:GPL says: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. ......As running is clearly not covered under GPL, your argument doesn't work.Modification *IS* covered by the GPL. (FYI, it's not my argument, it's Richard Stallman's).
Agreed.
Now, linking *is* a form of modification. Were it not, you could simply link your proprietary program with the GNU readline library. See http://www.gnu.org/licenses/why-not-lgpl.html if you have doubts about useability of a GPL library within proprietary code.
Agreed.
The fact that linking is done statically *or* dynamically is irrelevant; the result is that you have a combined work; all parts of the work must be licensed under terms that allow for the part to be combined with the other parts.
Agreed, in part. Static linking quite clearly forms a derived work, the contents of one work end up in another. But nobody does static linking in Java anyway, AFAIK.
Dynamic linking in Java, merely means inserting calls to some API into the bytecode, AFAIK. Now, if the API in question only has a GPLd implementation, I agree that the combined work in this case can be only created in connection of all parts it was derived from, and thus must follow the GPL.
But, there is no way, if the code in question uses an API with a GPLd and a non-GPLd implementation, for you to determine which implementation it is supposed to be linked to in order to create a combined work, as the generated linking bytecode is implementation independant. So Gadek's point about 'linking to GPLd runtime libraries during compilation' is moot, in my opinion. See my 'possibly GPL violating Hello.class' example.
It's an interesting philosophical, and probably legislative discussion, without much practical relevance, in my opinion.
In any case, that's not really relevant for debian, in my opinion, as debian is in the business of copying, modifying, and distributing works. So debian needs to figure out an interpretation of the GPL for java that they can live with between the two extremes (FSFs vs. mine), and make sure that they stick to it. That's the business of debian-legal, I guess, who has not been very responsive about it so far :( As long as debian-legal doesn't get involved and makes a decisive argument in favor of one interpretation or the other, it's a bit of a philosophical discussion.
In any case, I'd like to express my full support for SableVM in Debian: it's a cool VM, and I want to merge it parts of it into kaffe one day. It doesn't suffer from being 'more copyleft than it's good for it' by being LGPLd, so that this kind of discussion is be pointless for it. Beside, we all know each other from various free java mailing lists, IRC chats, and conferences [1], and have respect for each other's work. So sorry, no flamewars to be seen here ;)
My recommendation is to let debian-legal figure it out, and then either change nothing or make sure non-GPL compatible apps/libs don't have a 'Depends:' on kaffe, if debian-legal decides to adopt FSFs interpretation. Whatever happens, findjava shouldn't limit the user's capability to run a VM with some code, in my opinion.
cheers, dalibor topic[1] Etienne was the first free Java runtime hacker I met in person, during CC2000 in Berlin. He reignited my interest in creating a free java runtime back then with their cool work on Soot and Ashes.