Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Combining X+Y in the way that you have described is anything but > mechanical: it is a task which typically takes a skilled programmer a > great amount of time and thought. Different programmers might do it > in different ways. I'm not referring here to the work done by ld, but > to the process of building a new program which has libfoo as a > component. > > Additionally, the program ultimately delivered to the user isn't X > with some minor bits of Y. It contains big chunks of Y -- one per > function used, at least -- directly copied. Just being in a different > memory space isn't enough to change the relationship between the > creative parts of the works. The program vim encompasses a copy of > libc. Wrong. A dynamically linked program in ELF format (the most common on Linux systems) contains a list of undefined symbols, and a list of sonames to search for those symbols. I have a hard time seeing how this would make a program derived from the library. If multiple independent implementations of the library exist, which would the program be derived from? The program vim contains a list of function names, all of which are found in the ISO C standard, or in one of POSIX, SuS etc. It also mentions a soname similar to libc.so.6. Please explain how that can form a copy of libc. In the case of Java, the binding is even looser. A class might contain references to other classes which the JVM is free to look for anywhere it pleases. AFAIK, Eclipse uses only the standard Java API as published by Sun, and will run equally well with any implementation of said interface. This whole discussion is something between ridiculous and hilarious, definitely not useful. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Lewis Jardine <[EMAIL PROTECTED]> writes: > >> Brian Thomas Sniffen wrote: >> >>> Combining X+Y in the way that you have described is anything but >>> mechanical: it is a task which typically takes a skilled programmer a >>> great amount of time and thought. Different programmers might do it >>> in different ways. I'm not referring here to the work done by ld, but >>> to the process of building a new program which has libfoo as a >>> component. >>> Additionally, the program ultimately delivered to the user isn't X >>> with some minor bits of Y. It contains big chunks of Y -- one per >>> function used, at least -- directly copied. Just being in a different >>> memory space isn't enough to change the relationship between the >>> creative parts of the works. The program vim encompasses a copy of >>> libc. >>> -Brian >>> >> What about the case where there's a common ABI, such as Java written >> against Sun's standard API, then compiled into Java Bytecode? >> >> In this case, writing against Y is creative, but when the end-user >> runs the program, is Java's run-time-linking creative or mechanical? > > What Java's doing is mechanical. But what Debian *instructed* it to > do, by shipping Y and the Java run-time together such that when you > ask for Y to be installed, you get Y and the JVM... that's clearly > creative. > >> Does this change when the program could also be linked with A, W, or >> Z, all of which implement the same ABI? > > No. But it does matter which one Debian ships it with. > >> Does this change if there's no way to tell which of A, W, Y or Z X was >> originally written against? > > The author's intent matters. If he writes against X, and Debian ships > with Z instead, then that is an artistic choice on the Project's > part. So if the author's intent isn't obvious, but it *could* be in > the set of legitimate intents, I don't see a problem. > >> Does this change if the program is aggregated with W and Z, but not Y? > > You've now lost me in letters, and I don't understand this question. > But the rest of these caused me to clarify my thinking on the matter, > and to realize that there's always a person in the system who's > imagining a combined work on an end-user system and taking action to > put it there. This might be the original author, Debian or some other > distributor, or the end-user. If it's anyone but the end-user, then > that combined work is being distributed. So you are basically saying that aiding or hinting the end-user to create these would-be derivative works is enough to be violating the license? Then how can things like thepiratebay.org be legal? It is also legal to sell all the ingredients for a bomb, along with instructions needed to build one. However, building and using the bomb is most likely illegal. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Thu, Jan 13, 2005 at 07:08:23PM +0100, M?ns Rullg?rd wrote: >> So you are basically saying that aiding or hinting the end-user to >> create these would-be derivative works is enough to be violating the >> license? > > That's overstated. It's enough to have to argue the point in court and > be unsure of the result, which is bad enough that we can't really go > there. > >> Then how can things like thepiratebay.org be legal? > > They aren't with any degree of certainty. It's certain enough that Microsoft have failed to shut them down. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Thu, Jan 13, 2005 at 04:11:22PM +0100, M?ns Rullg?rd wrote: >> Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: >> >> > Combining X+Y in the way that you have described is anything but >> > mechanical: it is a task which typically takes a skilled programmer a >> > great amount of time and thought. Different programmers might do it >> > in different ways. I'm not referring here to the work done by ld, but >> > to the process of building a new program which has libfoo as a >> > component. >> > >> > Additionally, the program ultimately delivered to the user isn't X >> > with some minor bits of Y. It contains big chunks of Y -- one per >> > function used, at least -- directly copied. Just being in a different >> > memory space isn't enough to change the relationship between the >> > creative parts of the works. The program vim encompasses a copy of >> > libc. >> >> Wrong. A dynamically linked program in ELF format (the most common on >> Linux systems) contains a list of undefined symbols, and a list of >> sonames to search for those symbols. I have a hard time seeing how >> this would make a program derived from the library. If multiple >> independent implementations of the library exist, which would the >> program be derived from? > > You've got the causality backwards here. The program is linked to the > libraries because it is a derivative of the libraries. Not the other > way around. > > Derivation is something that happens when you *write* the program. Not > when you build it. How many times does it have to be stated that *using* an API does not form a derivative work of *any* implementation of the API? Any other interpretation invariably leads to contradictions. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 19:02 +0100, Dalibor Topic wrote: >> Brian Thomas Sniffen wrote: >> > Måns Rullgård <[EMAIL PROTECTED]> writes: >> >> [large discussion of C snipped out] >> >> >>In the case of Java, the binding is even looser. A class might >> >>contain references to other classes which the JVM is free to look for >> >>anywhere it pleases. AFAIK, Eclipse uses only the standard Java API >> >>as published by Sun, and will run equally well with any implementation >> >>of said interface. >> > >> > >> > Great -- which implementation does Debian ship it with? That's all >> > that really matters. >> >> I disagree that it's all that matters. It also matters whether the >> implementation that Debian ships actually puts any restrictions on the >> license on its data, or whether it doesn't. Kaffe, being an interpreter, >> does not, afaict: >> >> "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."[1] >> >> As the GPL of the interpreter does not place any restrictions on the >> data, the incompatibility of intepreter's GPL and data's CPL does not >> matter, as the data never becomes limited by the GPL and the license >> conflict never happens. > > To cite Linus: > > "You are a weasel, and you are trying to make the world look the way you > want it to, rather than the way it _is_." > > If you at least went on and read next paragraph of the FAQ from which > you took the above. > > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > > "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." I fail to see the relevance of this paragraph to the discussion at hand. The alleged incompatibility was between the interpreter (JVM) and the program being interpreted. Does Eclipse make explicit use of libraries licensed under the GPL? > Plese stop claiming the black is white. Thanks. If you want it black, paint it black. Rewrite the GPL. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Thu, Jan 13, 2005 at 07:58:53PM +0100, M?ns Rullg?rd wrote: >> >> Then how can things like thepiratebay.org be legal? >> > >> > They aren't with any degree of certainty. >> >> It's certain enough that Microsoft have failed to shut them down. > > They haven't tried. All Microsoft have done to them so far is send > them some nastygrams in the mail. And for some reason you believe Microsoft would be content with that, if they believed they had any real chance to stop them? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 19:55 +0100, Måns Rullgård wrote: >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> > If you at least went on and read next paragraph of the FAQ from which >> > you took the above. >> > >> > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL >> > >> > "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." >> >> I fail to see the relevance of this paragraph to the discussion at >> hand. The alleged incompatibility was between the interpreter (JVM) >> and the program being interpreted. Does Eclipse make explicit use of >> libraries licensed under the GPL? > > It surely does explicitely call java.lang.Object.wait() quite often java.lang.Object is part of the standard Java API published by Sun (http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html). > (as any multithreaded java program), which in turn calls the JVM, Quite so. > which is purely GPLed. Incorrect. There exists a GPL JVM for sure, but there also exist other JVM implementations (e.g. Sun's) equally capable of running Eclipse. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 20:15 +0100, Måns Rullgård wrote: >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> >> > On Thu, 2005-13-01 at 19:55 +0100, Måns Rullgård wrote: >> >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> >> I fail to see the relevance of this paragraph to the discussion at >> >> hand. The alleged incompatibility was between the interpreter (JVM) >> >> and the program being interpreted. Does Eclipse make explicit use of >> >> libraries licensed under the GPL? >> > >> > It surely does explicitely call java.lang.Object.wait() quite often >> >> java.lang.Object is part of the standard Java API published by Sun >> (http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html). >> >> > (as any multithreaded java program), which in turn calls the JVM, >> >> Quite so. >> >> > which is purely GPLed. >> >> Incorrect. There exists a GPL JVM for sure, but there also exist >> other JVM implementations (e.g. Sun's) equally capable of running >> Eclipse. > > Please don't get that theorhetical. What we have here is an explicit > usage, Eclipse does not explicitly use *anything* from *any* JVM/class library. Saying java.lang.Object doesn't say anything about which implementation shall be used. > not pure "possibilities", if there exist another implementations > then use it and do not infridge on the GPL. The Eclipse authors do not tell you which JVM to use. > Now, in our case, Eclipse is linked agains a libraries that ARE GPLed. No, it is being interpreted by an interpreter that is covered by the GPL. Even the FSF admits that this does not create a derived work. > We are compiling GPL-incompatible code against purely GPLed headers. Who is compiling what code? Since when does Java have headers? > Please see Linus's email I cited in my other emails for more info. > > Would it have been compiled against a differently licensed library, > this particular problem would be solved. Wouldn't it? It is compiled against an interface, not an implementation. Which particular implementation was used while compiling is irrelevant. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 20:58 +0100, Måns Rullgård wrote: >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> > Now, in our case, Eclipse is linked agains a libraries that ARE GPLed. >> >> No, it is being interpreted by an interpreter that is covered by the >> GPL. Even the FSF admits that this does not create a derived work. > > You really should reread FSF FAQ: > > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > > "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." > > Do you understand that an interpreter for Java IS such an interpreter > that provides "bindings" to other facilities? The paragraph above concerns JNI interfaces to libraries *separate* from the interpreter. For instance, one could imagine a JNI binding to GNU readline. The use of such bindings is independent of the JVM being used (bindings might not exist for all JVM implementations, but that's irrelevant). The existence of a binding facility does not make a program using them derived from the interpreter. In FSF logic, it is derived from the bound libraries, no more, no less. > Do you understand that a program being interpreted is effectively > linked to these facilities it uses thru these bindings? Yes. Which bindings does Eclipse use? > Do you understand that in case we're discussing these facilities are > released under the GPL? We are discussing the case where the interpreter is released under the GPL, nothing has been said about third-party library bindings. > Do you understand that in case we're discussing even the java library > itself is under GPL? (or at least parts of it, which is about the same) Doesn't matter. There exist other implementations, and a program can't possibly be derived from more than one. Don't you see the inconsistency? >> > We are compiling GPL-incompatible code against purely GPLed headers. >> >> Who is compiling what code? Since when does Java have headers? > > Either you're not capable of abstracting notion of headers as they're > used in C, or not willing to do so. What do you think, in Java, > provides you with the informations that you're given thru headers in C? > >> > Please see Linus's email I cited in my other emails for more info. >> > >> > Would it have been compiled against a differently licensed library, >> > this particular problem would be solved. Wouldn't it? >> >> It is compiled against an interface, not an implementation. Which >> particular implementation was used while compiling is irrelevant. > > Ok, so please compile Eclipse agains an *interface* which is not its > implementation (covered by GPL, in our case). Sure, if you use ie. > some stubs covered by IPC-compatible license, I won't say a word. If the implementations are fully compatible, the compiled bytecode should be bit-identical no matter which one was used. > But in our case you're using an implementation that also at the same > time defines the interface (this if functional equivalent of header > files). You cannot simply take a GPL implementation, compile against it > (never mind whether it's C, Java, Python or whatever), and they claim > you just didn't create a derivative work of the implementation you used. That's precisely what I am claiming, and several court cases support my claim. > Please look at FSF FAQ once again, please try to understand what the Reading the same FUD over and over again isn't going to alter the logic of the universe. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Måns Rullgård <[EMAIL PROTECTED]> writes: > >> The Eclipse authors do not tell you which JVM to use. > > But Debian does, when it says: > Depends: j2re1.4 | j2re1.3 | java2-runtime > > So the eclipse-platform distributed by Debian *does* call on a > particular JVM. And it isn't kaffe, it's Sun's. Then why on earth does the license of Kaffe have any relevance whatsoever to Eclipse? > We do document the technical fact that you can programatically > substitute kaffe for any java-runtime. So? How does this make Eclipse a derivative of Kaffe? >> It is compiled against an interface, not an implementation. Which >> particular implementation was used while compiling is irrelevant. > > Can you support this assertion? The program, including its libraries, > which the developer intends to put on end-user systems appears quite > relevant to me. If I write a program in Java (it has happened), I intend for the end-user to run it under any JVM of his choice. I don't care which one chooses. The only reason I can see for suggesting a specific implementation is for support issues, e.g. "we only provide support for running our product under JVM implementation X". -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: >> It is not hard: Some distribution of Eclipse is only encumbered by the >> GPL if it requires a GPLed work to correctly operate. You may have >> some odd version of Eclipse, but the standard releases have no such >> requirement. > > While most of what you said seemed perfectly reasonable, this does > not. > > Some distribution of Eclipse is encumbered by the GPL if it, that > distribution, includes a copy of a GPL'd work (and it is not mere > aggregation, which this certainly isn't). So shipping Eclipse+Kaffe > is not OK. Shipping Eclipse+otherJVM is fine. Your definition of "include" appears to be a little broader than the one most of us use. > I do not think anyone will disagree with this. Can we now confine > this argument to whether a program distributed as a > package with Depends: jre | java-runtime contains a copy of a package > with Provides: java-runtime? > > I'm inclined to say no, that that is not the intended operating state, > merely an incidental of technically compatible packages -- and so even > if Eclipse had a Depends: some-non-kaffe-jvm | java-runtime and Kaffe > a Provides: java-runtime, there would be no conflict with the GPL here. You're starting to make sense. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 21:56 +0100, Måns Rullgård wrote: >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> >> > On Thu, 2005-13-01 at 20:58 +0100, Måns Rullgård wrote: >> >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> >> > Now, in our case, Eclipse is linked agains a libraries that ARE GPLed. >> >> >> >> No, it is being interpreted by an interpreter that is covered by the >> >> GPL. Even the FSF admits that this does not create a derived work. >> > >> > You really should reread FSF FAQ: >> > >> > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL >> > >> > "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." >> > >> > Do you understand that an interpreter for Java IS such an interpreter >> > that provides "bindings" to other facilities? >> >> The paragraph above concerns JNI interfaces to libraries *separate* >> from the interpreter. For instance, one could imagine a JNI binding >> to GNU readline. The use of such bindings is independent of the JVM >> being used (bindings might not exist for all JVM implementations, but >> that's irrelevant). The existence of a binding facility does not make >> a program using them derived from the interpreter. In FSF logic, it >> is derived from the bound libraries, no more, no less. > > It shows you have no idea how a JVM is organized. The "interpreter" > part on which you're hanging so strongly is only part of a JVM. The > part that actually gets to interpret the bytecode. But there's also > a lot of functionality (think about it as a VM-specific library) that > is being used from within java library, and via JNI bindings calls > library functions of a JVM. > > Yes. A JVM migh be seen as an interpter + a library of native calls > used by the java library. And in case we're discussing this native > library is GPLed. The license of the library does not matter. Eclipse is written to work with any implementation of the standard Java API. >> > Do you understand that a program being interpreted is effectively >> > linked to these facilities it uses thru these bindings? >> >> Yes. Which bindings does Eclipse use? > > I told you. Plenty. And if we're making Eclipse Build-depend on > a GPLed version of these, then we're explicitely forcing these bindings > to be GPLed. Guess what, Eclipse does not have a Build-depends on any GPLd JVM. It has a Build-depends on j2sdk1.3 | j2sdk1.4, which are virtual packages. Guess what else, Kaffe doesn't provide either of these. Surprised? I'm amused. >> >> > Please see Linus's email I cited in my other emails for more info. >> >> > >> >> > Would it have been compiled against a differently licensed library, >> >> > this particular problem would be solved. Wouldn't it? >> >> >> >> It is compiled against an interface, not an implementation. Which >> >> particular implementation was used while compiling is irrelevant. >> > >> > Ok, so please compile Eclipse agains an *interface* which is not its >> > implementation (covered by GPL, in our case). Sure, if you use ie. >> > some stubs covered by IPC-compatible license, I won't say a word. >> >> If the implementations are fully compatible, the compiled bytecode >> should be bit-identical no matter which one was used. > > Does it matter? What however IS different is the fact which actual > implementation you use as the interface against which you're compiling, > and also with which implementation of library an app will be us
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > Putting it differently: if that was allowed, then why do we need glibc > to be LGPLed, and not GPLed? After all the C language and its basic > libraries are also standarized to great extent. I can see no real reason. > But having glibc purely GPL just doesn't sound good, does it? It sounds like it would make for a lot of arguing with FSF, nothing else. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > "Michael K. Edwards" <[EMAIL PROTECTED]> writes: > >> [no longer relevant to debian-java, I think] >> >> On Thu, 13 Jan 2005 15:28:57 -0500, Brian Thomas Sniffen >> <[EMAIL PROTECTED]> wrote: >> [snip] >>> You are ignoring the >>> creative act performed by the programmer who arranged calls to >>> functions within libc. That was creative effort on his part which >>> critically involves a copy of libc. >> >> As is the creation of a critical essay on libc. But that's not a >> derivative work either. > > But an annotated edition of libc is. A program seems far more similar > to an annotated edition than to a critical essay -- since it includes > a copy of the library, after all, and pointers into it. Now you stopped making sense. A program includes only references to a library, not the library itself. A distribution, e.g. Debian, might include both the program and the library. I don't see a problem with distributing a collection of programs, where some of them can be combined in ways that violate some license, as long as all of them still have legitimate uses. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's stop feeding the NVidia cuckoo
Matthew Garrett <[EMAIL PROTECTED]> writes: > Programs exist that allow you to read in JPEGs and produce new pieces of > artwork. People use them on a regular basis. No comparable programs > exist for ELF binaries. The obvious conclusion is that derived works can > (in general) be produced from JPEGs, but (in general) not from ELF > files. I'll save this for next time someone claims that linking against a shared library (ELF file) creates a derived work. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL'ed programs and libraries
Philipp Kern <[EMAIL PROTECTED]> writes: > Dear Debian legal people, > > could you please link me to a FAQ about legal concerns which could > come up when using the GPL? The canonical answer is the GPL FAQ: http://www.gnu.org/licenses/gpl-faq.html > Concretely I want to ask against which kind of licenses libraries a > GPL program could link. That would be http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs > I know that there are some problems with GPL'ed projects and the > linking with OpenSSL. When is it problematic? The answer depends on who you ask, and on the precise definition of a "derived work". If you are writing a program, and want to link against a non-GPL library, it's probably safest to use a different license than the GPL for your program. Linking with 2-clause BSD or MIT licensed libraries is always OK. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL & Possible Derivative Work
Mike <[EMAIL PROTECTED]> writes: > Hello all, > > If I were to study GPL'ed source in order to understand a protocol > that it implements, would I need to and if so how would I cite this in > any program I create which uses any knowledge gained? Stating where you obtained the information is always a good idea. IIUC, you are intending to write your own implementation of the protocol, or perhaps write a client for a server. As long as you do not copy any code, you will not be creating a derived work, and hence will not be bound by the GPL in any way. There is, AFAIK, no dispute about this. IANAL, TINLA, etc. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Web application licenses
Raul Miller <[EMAIL PROTECTED]> writes: >> Well, I'm not reciting, dancing, or acting postfix. I'm not rendering >> it or playing it either, as far as I can tell. I don't even *see* its >> code, which seems quite different from music I'm playing or a dramatic >> work I'm rendering. > > "playing" is a rather generic word (example sentences from dictionary.com > include "The fountains played in the courtyard" and "played the matter > quietly"). I don't see that you're not playing it. > > Alternatively, you might want to argue that computer programs are not > copyrightable at all [based on arguments analogous to the one you're > presenting now]. > >> playing a CD or a player piano, I still don't see the output at all. >> I do not perceive the work in any way. > > I'll agree that you're not seeing the raw bits, but nobody ever sees > the raw bits. Instead, you see things resulting from those bits. You just defeated yourself. Nobody has ever tried to extend the copyright of a program to include output produced when running the program. Why would this be different when the program sends its output over a network? -- Måns Rullgård [EMAIL PROTECTED]
Re: Web application licenses
Don Armstrong <[EMAIL PROTECTED]> writes: > On Wed, 18 Aug 2004, Måns Rullgård wrote: >> Nobody has ever tried to extend the copyright of a program to >> include output produced when running the program. > > If no one has tried, it's because it's quite trivial to contruct a > case where a program's output is copyrightable and covered by the > copyright of the program. > > Consider a script that calls imagemagick to create an copyrightable > image steming entirely from information contained in the script. Or a > LaTeX "program" for that matter. OK, I forgot to mention those cases where the program includes parts of itself in the output. However, there is no way an email sent through postfix can be a work derived from the postfix code. The same reasons apply here as to compilers. The copyright of object code produced by a compiler is exactly the same as that of the source file. Compiling the source code is considered use of the compiler, and the output is not a work derived from the compiler. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
Steve Langasek <[EMAIL PROTECTED]> writes: > If your understanding of the license exception requirements were > correct, it would be a very easy loophole for people to exploit, using > GPL-compatible library layers to "sanitize" the licenses of library > dependencies. > > But in fact, the GPL's definition of source code is: > > The source code for a work means the preferred form of the work for > making modifications to it. For an executable work, complete source > code means all the source code for all modules it contains, plus any > associated interface definition files, plus the scripts used to > control compilation and installation of the executable. However, as a > special exception, the source code 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. > > For GPL applications linked against curl, "all modules it contains" > includes both libcurl and libssl. When using dynamic linking that is not necessarily the case. Most dynamic linkers use lazy loading of libraries, such that the openssl libraries would not actually be mapped in to the process address space until one of its functions is called. If, as per assumption, the application does not use any ssl related features of curl, the openssl libraries would never be touched, except for a possible scan of its symbol table. The openssl libraries could be replaced by another library containing dummy entries for all the required symbols and the curl using application would still function correctly. How the presence or absence of a particular library at runtime could possibly change the derivedness of a some program from said library is beyond my comprehension. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
Steve Langasek <[EMAIL PROTECTED]> writes: > On Thu, Aug 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote: >> Steve Langasek <[EMAIL PROTECTED]> writes: > >> > If your understanding of the license exception requirements were >> > correct, it would be a very easy loophole for people to exploit, using >> > GPL-compatible library layers to "sanitize" the licenses of library >> > dependencies. > >> > But in fact, the GPL's definition of source code is: > >> > The source code for a work means the preferred form of the work for >> > making modifications to it. For an executable work, complete source >> > code means all the source code for all modules it contains, plus any >> > associated interface definition files, plus the scripts used to >> > control compilation and installation of the executable. However, as a >> > special exception, the source code 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. > >> > For GPL applications linked against curl, "all modules it contains" >> > includes both libcurl and libssl. > >> When using dynamic linking that is not necessarily the case. Most >> dynamic linkers use lazy loading of libraries, such that the openssl >> libraries would not actually be mapped in to the process address space >> until one of its functions is called. If, as per assumption, the >> application does not use any ssl related features of curl, the openssl >> libraries would never be touched, except for a possible scan of its >> symbol table. The openssl libraries could be replaced by another >> library containing dummy entries for all the required symbols and the >> curl using application would still function correctly. How the >> presence or absence of a particular library at runtime could possibly >> change the derivedness of a some program from said library is beyond >> my comprehension. > > I didn't say anything about derived works. Neither does the GPL when > talking about source code. > > The GPL also doesn't define source code to include "all modules it > uses", it defines it to include "all modules it contains". Could you please explain to me how something linked against libcurl contains openssl? -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
David Schleef <[EMAIL PROTECTED]> writes: > On Thu, Aug 19, 2004 at 08:59:44PM +0200, Måns Rullgård wrote: >> > I didn't say anything about derived works. Neither does the GPL when >> > talking about source code. >> > >> > The GPL also doesn't define source code to include "all modules it >> > uses", it defines it to include "all modules it contains". >> >> Could you please explain to me how something linked against libcurl >> contains openssl? > > For one thing, it's absolutely not possible to run the binary in > such a way that openssl is not part of the process image. Since when is Debian distributing linked process images? -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL-licensed packages with depend-chain to OpenSSL
David Schleef <[EMAIL PROTECTED]> writes: > On Thu, Aug 19, 2004 at 11:09:11AM +0200, Måns Rullgård wrote: >> When using dynamic linking that is not necessarily the case. Most >> dynamic linkers use lazy loading of libraries, such that the openssl >> libraries would not actually be mapped in to the process address space >> until one of its functions is called. > > This is not how an ELF runtime linker works. Run ldd on a binary -- > this lists all the shared object files that are mapped into the > address space of the process before main() is called. Sorry, I was a little too quick there. The file is mapped, but is not read from disk until the code is required. The mapping is also shared with other applications using the library. Are all these applications derived from each other? > Symbol references are not necessarily resolved at that time, unless > you define LD_BIND_NOW or are using prelinking. There's really no > method of doing "lazy linking" as you suggest with C, since it would > either fail (such as with global variables in libraries) or be > required to violate the ISO standard, such as taking the address of > a function. There is no requirement that the linker be written in C, or that it follow any standard whatsoever as long as the interface and operation visible to applications is as expected. -- Måns Rullgård [EMAIL PROTECTED]
Re: cdrecord: weird GPL interpretation
Francesco Poli <[EMAIL PROTECTED]> writes: > Hi all, > in cdrtools-2.01a38 I found the following weird GPL interpretation. > I wonder if this is considered acceptable for main (I would say that > this is non-free). I don't know whether cdrecord links with (or is > otherwise a derivative work of) other GPL'd software (whose copyright is > held by other people): in that case I would say that this is even > undistributable... :( > > What do you think about this? > There already is a Debian BTS bug report > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265546) about this > issue (it was filed when it was even worse, it seems...), but it says > it's resoved with version 2.01a38. I wonder if you agree... > > NOTE: I am Cc:ing the the package maintainer (Joerg Jaspert) and the > bug-report filer (Andreas Metzler). > I don't know if they would like to be Mail-Followup:ed... > > Issue description follows: > > -=-=-=-= cdrecord/LICENSE =-=-=-=- > > This software is under GPL but you should read the following > clarifications: > > - You may not modify certain copyright messages in cdrecord.c > > See cdrecord.c for further information. Looks like an invariant section of GFDL infamy. > - You may (with a few exceptions) not modify the location of the > configuration file /etc/default/cdrecord. > > See defaults.c for further information. Looks like lunacy. I don't recall ever reading anything about that in the GPL. > Please note that this is just the way I interpret the GPL and as this > is my software, users should follow my interpretation of the GPL and not > use their own different interpretations. > > -=-=-=-= cdrecord/cdrecord.c (sorry for linewrapping) =-=-=-=- I take it someone on this list followed the recent flame war on lkml. -- Måns Rullgård [EMAIL PROTECTED]
Re: cdrecord: weird GPL interpretation
MJ Ray <[EMAIL PROTECTED]> writes: > On 2004-09-01 23:40:43 +0100 Måns Rullgård <[EMAIL PROTECTED]> wrote: > >> Francesco Poli <[EMAIL PROTECTED]> writes: >>> in cdrtools-2.01a38 I found the following weird GPL interpretation. > [...] >>> - You may not modify certain copyright messages in cdrecord.c See >>> cdrecord.c for further information. >> Looks like an invariant section of GFDL infamy. [...] > > Well, this is like a misapplied bad invariant section, one that > relates to the main subject and may actually be untrue. As far as I > can tell, it's not an interpretation or clarification, but a direct > contradiction of the GPL. The same goes for the restrictions on the > config file default location. I guess that means we don't have a > viable licence :-/ > >> I take it someone on this list followed the recent flame war on >> lkml. > > Heh. Any flame war in particular? Jörg Schilling vs. rest of list. -- Måns Rullgård [EMAIL PROTECTED]
Re: cdrecord: weird GPL interpretation
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Steve McIntyre <[EMAIL PROTECTED]> writes: > >> Joerg's changes are clearly non-free; I've not seen anybody arguing >> otherwise. We basically need to route around him at this point, and >> fork from a previous free version. His ridiculous statement that his >> new statements also apply to older (GPL) versions of cdrtools should >> just be ignored as the puffery that it is IMHO... > > While legally you're right, I think from a point of view of politeness > you're wrong. Go read some postings by JS and you won't feel any need for politeness. -- Måns Rullgård [EMAIL PROTECTED]
Re: cdrecord: weird GPL interpretation
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Måns Rullgård <[EMAIL PROTECTED]> writes: > >> Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: >> >>> Steve McIntyre <[EMAIL PROTECTED]> writes: >>> >>>> Joerg's changes are clearly non-free; I've not seen anybody arguing >>>> otherwise. We basically need to route around him at this point, and >>>> fork from a previous free version. His ridiculous statement that his >>>> new statements also apply to older (GPL) versions of cdrtools should >>>> just be ignored as the puffery that it is IMHO... >>> >>> While legally you're right, I think from a point of view of politeness >>> you're wrong. >> >> Go read some postings by JS and you won't feel any need for >> politeness. > > I've read them. It doesn't seem any worse than the drivel which shows > up here regularly. Joerg tells Alan Cox he doesn't know anything > about Linux systems or security. People here say things about that > ridiculous once a week -- you've seen them too. Add to that an arrogant center-of-the-world attitude (you can't change the kernel now, cdrecord is in code freeze pending release and similar statements). > On the other hand, I find this message interesting: > > http://lkml.org/lkml/2004/8/19/111 > > In particular, he seems to be relying on German "Authors' Rights", and > claims to be in discussion with Debian people. That's nearly a month > ago. More specifically, he claims to be in discussion with Debian how to stop SuSE from doing what they have every right to do. I know nothing about German law, so I can't comment on that bit. -- Måns Rullgård [EMAIL PROTECTED]
Re: cdrecord: weird GPL interpretation
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Raul Miller <[EMAIL PROTECTED]> writes: > >> I do agree that we should avoid upgrading to versions he's provided which >> are accompanied by statements about copyright which conflict with the GPL. >> >> But I don't see any valid reason for pulling prior versions out of main. > > I see this as a similar circumstance to Pine. UW had very clearly > given a free license, then switched to a loopy interpretation where we > didn't have a license to distribute modified versions. So it got > pulled from main. They changed their license for future versions -- > sure, they called it a clarification, but it was a pretty big change. > But Debian doesn't distribute that old pine, because -- even when the > copyright holder has gone insane -- it's polite to accede to their > wishes. > > The same action is appropriate here. There's a slight difference, if I am not mistaken. UW did not change the license, and then claim that the new license would apply to copies of old versions of the software received under the old license. What they did was to clarify their interpretation of the license, which although highly unusual was not self-contradicting. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL and command-line libraries
"Wesley W. Terpstra" <[EMAIL PROTECTED]> writes:
> Good evening!
>
> I'm developing an error-correcting code library which works on a lot of data
> at once. Since the API is quite simple and the cost of process creation
> relatively insignificant, I would like to provide a command-line API.
>
> I feel this has several engineering advantages:
> 1) it's easier to debug and understand if you can interact with it
> 2) bugs in the library don't crash programs using it
> 3) multithreading can be used in the library and not the application
> ... and other more problem-specific benefits.
>
> To the point: I want this library to be released under the GPL, BUT ...
> Would the GPL still protect it?
>
> If someone writes a program that does: popen('my-api');
> does the GPL require that program to also be GPL?
> From the short answer I got on IRC it seemed the answer was: No!
That's correct. It's even in the GPL FAQ.
> What I am concerned about is the following scenario:
>
> Mr. John Wontshare writes a streaming multicast client.
> To deal with packet loss, he uses my error-correcting library.
> Without my library, Mr. Wontshare's client can't work at all.
> Mr. Wontshare's client represents only a small investment of effort and
> without having had access to my library, he could have never written it.
> He then distributes his client along with my library to end-users.
>
> These users don't get Mr. Wontshare's code, even though he uses my library.
> Even worse, he refuses to port his client to MacOS X for business reasons.
> (intentionally giving an unfair competitive advantage to another platform)
>
> To me anyways, this sounds like exactly the situation the GPL is supposed to
> protect against. Is this _not_ a derivative work?
Unfortunately for you, no, it's not a derivative work.
> If that's really the case, is it possible that a GPLv3 might address this?
Only if GPL3 is incorporated into the copyright laws worldwide.
Doesn't seem likely to me.
> There are several things I've considered to prevent this scenario:
>
> 1. Write in all documentation, help, etc: "popen my app = derivative work"
>... and hope that this is enough to give me a victory in a lawsuit or at
>least scare Mr. Wontshare away from even trying this.
Maybe it scares someone, but it can't be enforced by law.
> 2. Patenting the new algorithm my library uses and putting in a clause which
>covers this corner-case and making it otherwise free.
Software patents don't exist in large parts of the world.
> 3. Crafting a special (GPL-incompatible) licence which does what I want.
Legally impossible.
> 4. Writing to debian-legal and asking for advice.
You got my 2 cents.
> I've heard all sorts of arguements in IRC that drawing the line in a good
> way is very hard. I believe that. However, what I want to know is, if this
> went to court, would things like the intention and degree of dependency be
> considered in determining if the client was a derivative work or not?
>
> What can I do to prevent the above scenario from happening?
Don't release your code at all.
--
Måns Rullgård
[EMAIL PROTECTED]
Re: GPL and command-line libraries
Josselin Mouette <[EMAIL PROTECTED]> writes: > Le mardi 02 novembre 2004 à 21:53 +0100, Wesley W. Terpstra a écrit : >> Mr. John Wontshare writes a streaming multicast client. >> To deal with packet loss, he uses my error-correcting library. >> Without my library, Mr. Wontshare's client can't work at all. >> Mr. Wontshare's client represents only a small investment of effort and >> without having had access to my library, he could have never written it. >> He then distributes his client along with my library to end-users. > > If Mr Wontshare's client doesn't work without your software, this is > what I call a derivative work. Whether it is linked to it using ELF or > not is irrelevant. Mr. Wontshare's program *uses* the GPL program, but isn't derived from it. See http://www.gnu.org/licenses/gpl-faq.html#MereAggregation. Further, consider what would happen if someone else created an application with an interface compatible with the OP's program. Would Mr. Wontshare's program then become a derivative this program as well? A program compatible with the OP's could even be written before Mr. Wontshare writes his. Which one is it then derived from? The only consistent answer is that it is not derived at all. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL and command-line libraries
"Wesley W. Terpstra" <[EMAIL PROTECTED]> writes: > On Tue, Nov 02, 2004 at 11:12:11PM +0100, Måns Rullgård wrote: >> > If Mr Wontshare's client doesn't work without your software, this is >> > what I call a derivative work. Whether it is linked to it using ELF or >> > not is irrelevant. >> >> Mr. Wontshare's program *uses* the GPL program, but isn't derived from >> it. See http://www.gnu.org/licenses/gpl-faq.html#MereAggregation. > > To quote that answer: > > 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). > > My question was essentially, does the scenario I outlined constitute > combining two parts into one. I believe the answer should be yes. > However, IANAL and I thought FSF lawyes frequent debian-legal (?) > might be able to tell me what a judge would likely think. To find out what a judge might rule, you might as well flip a coin. That's what the courts do anyway, if one of the sides doesn't have much more money than the other. In that case, the side with the money wins. >> Further, consider what would happen if someone else created an >> application with an interface compatible with the OP's program. Would >> Mr. Wontshare's program then become a derivative this program as well? >> A program compatible with the OP's could even be written before Mr. >> Wontshare writes his. Which one is it then derived from? The only >> consistent answer is that it is not derived at all. > > Or else, his is a derivative work of whichever one he makes use of. > If he ships with one of them, his intention seems to be clear. > > I don't see how that is logically inconsistent. It's all about causality. Consider two scenarios, both involving three programs, A, B and C. Scenario 1: 1. A is written. 2. B written, and makes use of A. You argue that B is a derivative work of A. 3. C is written, and is compatible with A. B is clearly not a derivative work of C, since it existed before C. Scenario 2: 1. A is written. 2. C is written, and is compatible with A. C is not a derivative work of A. If it were, most of the GNU programs would be illegal, since they would be derivative works of non-free compatible programs. 3. B is written, and makes use of the interface shared between A and C. In the second scenario, if B is a derivative work of A, it must also be a derivative work of C, since A and C are equivalent. This conflicts with scenario 1, where B cannot possibly be a derivative work of C. In both cases, we have in the end an identical set of programs, and the derivedness relations between them must also be equal. The only solution is that B is not derived from either A or C. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL and command-line libraries
Jonathan ILIAS <[EMAIL PROTECTED]> writes: > Måns Rullgård wrote: >> It's all about causality. Consider two scenarios, both involving >> three programs, A, B and C. >> Scenario 1: >> 1. A is written. >> 2. B written, and makes use of A. You argue that B is a derivative >> work of A. >> 3. C is written, and is compatible with A. B is clearly not a >> derivative work of C, since it existed before C. >> Scenario 2: >> 1. A is written. >> 2. C is written, and is compatible with A. C is not a derivative >> work of A. If it were, most of the GNU programs would be >> illegal, since they would be derivative works of non-free >> compatible programs. >> 3. B is written, and makes use of the interface shared between A and >> C. >> In the second scenario, if B is a derivative work of A, it must also >> be a derivative work of C, since A and C are equivalent. This >> conflicts with scenario 1, where B cannot possibly be a derivative >> work of C. In both cases, we have in the end an identical set of >> programs, and the derivedness relations between them must also be >> equal. The only solution is that B is not derived from either A or C. > > AFAIK, as B uses A, B depends on A. At runtime, B cannot depend on A > and C at the same time. So if B is distributed to be run with A that > is GPL, B must be distributed under GPL terms. At runtime, B depends on something that can be provided by A or C, it does not care which. Just like "make" depends on /bin/sh, not asking whether your sh is Bash, Solaris sh, or some other sh. They are all equivalent, and "make" isn't derived from either of them. > I don't know if in this case B is legally a derivative work of A but > the dependency seems to be enough to "spread" A's GPL license to B. Licenses do not spread across interfaces. If they did, virtually every computer program would be illegal. If you are indeed right, I will immediately install BSD or Solaris on my machines, even though many of the GNU tools are better. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL and command-line libraries
Lewis Jardine <[EMAIL PROTECTED]> writes: > Anthony DeRobertis wrote: >> Nathanael Nerode wrote: >>> (The FSF's statements that linking with a library creates a >>> derviative work of the library confuse people; it may help to >>> remember that this only applies to the *binary image* created by >>> the linkage, which contains elements of the library, not to the >>> source code of the program using the library.) >> A derivative work requires creative input. Neither a compiler nor a >> linker can provide that. There is no creative input in typing >> "make", so the binary can't be a derivative work if the inputs were >> not. >> > What is the correct term for a work that combines two other works, > created without creative input? An anthology, or a compilation, I think. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL and command-line libraries
Anthony DeRobertis <[EMAIL PROTECTED]> writes: > Måns Rullgård wrote: > >> Lewis Jardine <[EMAIL PROTECTED]> writes: > > >>>What is the correct term for a work that combines two other works, >>>created without creative input? >> An anthology, or a compilation, I think. >> > > From Title 17, Sec 101: > A ''collective work'' is a work, such as a periodical > issue, anthology, or encyclopedia, in which a number of > contributions, constituting separate and independent > works in themselves, are assembled into a collective whole. > > A ''compilation'' is a work formed by the collection > and assembling of preexisting materials or of data > that are selected, coordinated, or arranged in such a > way that the resulting work as a whole constitutes an > original work of authorship. The term ''compilation'' > includes collective works. > > I don't think those are the appropriate terms; it would appear that a > compilation (including collective works) need to be original works of > authorship. That requires creative input. Was the question concerning the term for a work consisting of other works, each in itself the product of creative work (and thus copyrightable), combined into a single work without any additional creative work, or was the question for combination of parts which are not by themselves copyrightable, combined without creative effort, or a combination of non-creative parts in a creative fashion? Producing a compilation may or may not involve creative work. For instance, in the production of a literary anthology, there may be significant amounts of work in the selection of parts to include, as well as their order. In this case, the compilation might be protected by copyright law. On the other end, a collection consisting of all works published during some specific time interval, is not the result of creative work. > If it isn't creative, it isn't a work under copyright law. See, e.g., > Fesit v. Rural Telephone Service, holdings (a) and > (b). > http://caselaw.lp.findlaw.com/scripts/getcase.pl?navby=case&court=US&vol=499&invol=340 This case is about a telephone directory. Quite obviously, each individual entry cannot be considered a creative work (it is an arbitrary number assigned to a name), and simply collecting all of them is not considered to add any creative element. > AFAICT, the output of the compiler is treated under copyright law the > same way the source code would be; I supect the best term we have for > this situation is "mere aggregation" of two seperate works. IOW, 'ld' > in this case is performing the same function 'tar' normally would. The compiler outputs a mechanical transformation of its input. If the input was covered by copyright, then the output will be as well, otherwise it will not. Mechanically transforming something does not add any creative value, and hence does not alter the copyright status of whatever is being transformed. Mechanically combining two works into one, as might be done by the linker, does not either add any creative element. -- Måns Rullgård [EMAIL PROTECTED]
Re: GPL and command-line libraries
Ken Arromdee <[EMAIL PROTECTED]> writes: > On Fri, 3 Dec 2004, Raul Miller wrote: >> If I ship some product in three parts, such that the combination of those >> three parts is consistently assembled and used, then I'm distributing >> that product. > > Says who? > > Shipping parts can be different from shipping a combination if for > some reason you are given different rights to ship parts and ship > combinations. It's just that outside free licenses that never > happens. It's perfectly legal to sell all the ingredients for making a bomb, but selling ready-made bombs is not. -- Måns Rullgård [EMAIL PROTECTED]
Re: LCC and blobs
Josh Triplett <[EMAIL PROTECTED]> writes: >> But what if loading the firmware is not required? > >> That if the device was >> "warm-booted" in another OS? (I know there are technical limitations >> here) Would the driver-firmware relation still be a "depends"? > > No, then the driver Depends: firmware | other-os . We don't ship > either, so the driver still needs to go to contrib. :) And presumably > other-os depends (though not in the Debian package sense) on the > firmware as well, so even if that other OS was Free and we shipped it, > we'd be back to needing the firmware. What if every unit of this hardware included a CD with the required firmware? Then anyone in owning the hardware would also have the firmware, without Debian needing to touch it. For those not owning the hardware, the driver is obviously useless anyway. > To me, that seems much like arguing that because an emulator (such as > one for a console system) provides a GUI, and because it can run and > display that GUI without needing a ROM, the emulator should go to main. > I don't believe that is "a significant amount of functionality". Do > you? Feel free to try to convince people. I'm convinced enough. Some time ago, I was playing around with an emulator for Texas Instruments calculators. It obviously required a ROM image to be useful, and the only legal way of obtaining one was dumping it from your own calculator (an easy task). I still found this emulator useful, since I happen to have one of the calculators. Sure, the emulator is useless for anyone who doesn't own a calculator, but a lot of software is useless for a whole lot of people for all sorts of reasons. Is software only "free" if it is useful for *everybody*? Debian includes hundreds of programs that require a fast network connection to be useful. Lots of programs make specific use of various types of hardware (mice, printers, monitors, GPS receivers, etc.) and are quite useless without these. By your reasoning, the only software allowed in main would be programs that could be used on any machine that will run Debian at all. The only things I can think of that all machines have are a CPU and a few megabytes of RAM. Everything else is more or less optional. Maybe we should also consider that some software is only useful to a small set of people, such as those working in some specific field. If use of a program requires some knowledge of, say, signal processing, does that make it non-free? Education is far from free, and is certainly not distributed by Debian. Yes, I'm deliberately being a little extreme here, but I see no fundamental difference between requiring the user to possess some data and requiring the user to possess a physical object. -- Måns Rullgård [EMAIL PROTECTED]
Re: LCC and blobs
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > It doesn't matter if the manufacturer includes the CD. If I buy the > card on eBay, the original owner may not have a license to > redistribute the firmware to me. That's a purely hypothetical situation. Show me a case where someone has been convicted for selling used hardware, and including the driver CD. >> Yes, I'm deliberately being a little extreme here, but I see no >> fundamental difference between requiring the user to possess some data >> and requiring the user to possess a physical object. > > One is software, which Debian could ship, and the other is hardware, > which Debian cannot ship. Software has no inherent limitation on its > duplication and distribution -- copying bits and shipping them about > is essentially free. Duplicating and distributing objects is hard > enough to be the basis of our economy. > > Free software, free data, are inherently different and useful concepts > without needing to free all hardware. As I said, lots of software requires any potential user to have some knowledge about something (I previously mentioned signal processing as an example). To my knowledge, Debian does not distribute any free books on signal processing, even though it could, if such literature existed. Does this prevent signal processing toolkits from going into main? I see gnucap (GNU Circuit Analysis package) is in main. This is useless for anyone without some knowledge of electronic circuits, and Debian does not include any books on that subject, so the gnucap package depends on non-free "data". Does this mean that gnucap must be moved to "contrib"? -- Måns Rullgård [EMAIL PROTECTED]
Re: IRAF component relicensed
Raul Miller <[EMAIL PROTECTED]> writes: > On Sun, Dec 19, 2004 at 03:45:40PM -0500, Justin Pryzby wrote: >> This is probably hotly debated, but how do math-algorthm copyrights >> work? > > Articles about mathematics, and specific expressions of algorithms, > are copyrightable, but the concepts aren't. > > In the U.S. 17 USC 102 states: > >In no case does copyright protection for an original work of authorship >extend to any idea, procedure, process, system, method of operation, >concept, principle, or discovery, regardless of the form in which it >is described, explained, illustrated, or embodied in such work. > > In international law, article 2 of the Berne convention states: > >It shall, however, be a matter for legislation in the countries of the >Union to prescribe that works in general or any specified categories >of works shall not be protected unless they have been fixed in some >material form. > > Which I think meant that the rules could vary from country to country. > However, WIPO has since come out and stated (in article 2 of the treaty): > >Copyright protection extends to expressions and not to ideas, >procedures, methods of operation or mathematical concepts as such. > > Is that clear enough? And this is probably the reason we have thousands of (probably invalid) software patents instead. -- Måns Rullgård [EMAIL PROTECTED]
Re: LCC and blobs
[EMAIL PROTECTED] (Marco d'Itri) writes: > On Dec 20, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > >> [EMAIL PROTECTED] (Marco d'Itri) writes: >> >> differently depending on the presence of additional software -- the >> >> kernel, for example, or the firmware. >> > I'm not doing this either. >> Great. Then the driver operates differently depending on the presence >> of additional software -- it needs a Linux kernel and the firmware. > But then drivers also "depend" on "additional softwares" stored in > flash EEPROMs in devices. > >> Without either of those, it does not operate. This is a dependency. > But then ICQ clients "depend" on non-free ICQ servers... And every program depends on a computer, most of which is probably constructed using a design language like VHDL, which is not far from software. NON-FREE -- Måns Rullgård [EMAIL PROTECTED]
Re: Is the xdebug's non-free license necessary?
Derick Rethans <[EMAIL PROTECTED]> writes: > On Mon, 20 Dec 2004, Josh Triplett wrote: > >> >>This is much broader. For example, I cannot write a derivative called >> >>"Brian's Xdebug" or "Xdebug manual" or even "A third-party manual for >> >>Xdebug". >> > >> > The manual is no problem, that's not a derived product. >> >> It could very well be a derivative; a manual might want to copy some of >> the code for illustrative purposes, or copy various comments. > > IMO just copying a tiny bit of code or copying various comments does not > make something a derivate. I mean, com'on, other people can come up with > those same comments or tiny bits of code. This seems to me to be no different from citing a paragraph from a book, which is perfectly legal under normal copyright law. If a code fragment is used in another program, matters might be different, though. -- Måns Rullgård [EMAIL PROTECTED]
Re: Is the xdebug's non-free license necessary?
Matthew Palmer <[EMAIL PROTECTED]> writes: > On Tue, Dec 21, 2004 at 11:10:11AM +0100, M?ns Rullg?rd wrote: >> Derick Rethans <[EMAIL PROTECTED]> writes: >> > On Mon, 20 Dec 2004, Josh Triplett wrote: >> > >> >> >>This is much broader. For example, I cannot write a derivative called >> >> >>"Brian's Xdebug" or "Xdebug manual" or even "A third-party manual for >> >> >>Xdebug". >> >> > >> >> > The manual is no problem, that's not a derived product. >> >> >> >> It could very well be a derivative; a manual might want to copy some of >> >> the code for illustrative purposes, or copy various comments. >> > >> > IMO just copying a tiny bit of code or copying various comments does not >> > make something a derivate. I mean, com'on, other people can come up with >> > those same comments or tiny bits of code. >> >> This seems to me to be no different from citing a paragraph from a >> book, which is perfectly legal under normal copyright law. > > There is no such thing as "normal copyright law". Not all jurisdictions out > there have any concept of what is known commonly as "fair use", which is the > only thing I can think of that would allow you to quote a paragraph from a > copyrighted book without the copyright holder's permission. You're right. >> If a code fragment is used in another program, matters might be >> different, though. > > Why? Quoting from a book is often done to illustrate something, or otherwise give an example. I can't see how a code fragment could be considered an example of something, if it is actually executed as part of a program. -- Måns Rullgård [EMAIL PROTECTED]
Re: LCC and blobs
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Anthony DeRobertis <[EMAIL PROTECTED]> writes: > >> Brian Thomas Sniffen wrote: >>> That's not software. That's firmware, at best -- you can look at it >>> as software, but then you don't get to distribute any drivers. It is >>> also internally consistent to think of chips as hardware and >>> distribute drivers appropriately. It is never consistent to think of >>> files on disk as anything but software. >> >> Hmmm, I have a CF card. Upon it are files, and in every meaningful way >> it is a disk. Therefor, that data is software. >> >> Yet, CF is actually chips --- often the same chips as used to hold >> firmware distributed with hardware. Thus, it's all hardware. > > Sure. It's on a medium for software exchange, thus it's software. If > it were an integral component of a device, it'd be hardware. If it is glued to the socket, does it become hardware? > I've never been confused when looking at such things; the closest > case I've found to confusing is the MP3 player, which has its OS on > disk. I'm inclined to say that it's software to the MP3 player, an > architecture which Debian does not support. It's hardware, a drive, > to the (Intel?) Debian-supported PC to which it's connected. Why is this different from the SCSI controller board, whose CPU (and related components) is also an architecture not supported by Debian? Does it matter whether it connects to the PC by the PCI bus directly, or over USB? -- Måns Rullgård [EMAIL PROTECTED]
Re: LCC and blobs
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: >> Can a company release an encrypted CD, so that it's as difficult to >> modify the firmware on CD as it is in a chip, and then have it >> count as part of the hardware? > > No, that's not hardware. That's an encrypted CD. That, and the DRM > approach below, are just various forms of non-free software. The > difference with a chip on a card is not that it's difficult to modify, > but that it's not treatable as software! I can't open it in Emacs, so > it isn't software. You can pull the chip from the socket, copy the contents to disk, and open it with any editor you like. The chip can also be rewritten. Where is the fundamental difference from a device where the firmware is written with the chip in its socket? -- Måns Rullgård [EMAIL PROTECTED]
Re: LCC and blobs
Michael Poole <[EMAIL PROTECTED]> writes: > A BIOS is normally stored in binary form as executable or > interpretable code plus associated data. Most people would call > executable code in binary form "software;" Debian uses a broader > definition than that. The real question is why you think that > executable binary data is not software. A firmware image is not software to the system on which Debian runs. What it is to another system (e.g. some PCI card) is irrelevant. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Combining X+Y in the way that you have described is anything but > mechanical: it is a task which typically takes a skilled programmer a > great amount of time and thought. Different programmers might do it > in different ways. I'm not referring here to the work done by ld, but > to the process of building a new program which has libfoo as a > component. > > Additionally, the program ultimately delivered to the user isn't X > with some minor bits of Y. It contains big chunks of Y -- one per > function used, at least -- directly copied. Just being in a different > memory space isn't enough to change the relationship between the > creative parts of the works. The program vim encompasses a copy of > libc. Wrong. A dynamically linked program in ELF format (the most common on Linux systems) contains a list of undefined symbols, and a list of sonames to search for those symbols. I have a hard time seeing how this would make a program derived from the library. If multiple independent implementations of the library exist, which would the program be derived from? The program vim contains a list of function names, all of which are found in the ISO C standard, or in one of POSIX, SuS etc. It also mentions a soname similar to libc.so.6. Please explain how that can form a copy of libc. In the case of Java, the binding is even looser. A class might contain references to other classes which the JVM is free to look for anywhere it pleases. AFAIK, Eclipse uses only the standard Java API as published by Sun, and will run equally well with any implementation of said interface. This whole discussion is something between ridiculous and hilarious, definitely not useful. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Lewis Jardine <[EMAIL PROTECTED]> writes: > >> Brian Thomas Sniffen wrote: >> >>> Combining X+Y in the way that you have described is anything but >>> mechanical: it is a task which typically takes a skilled programmer a >>> great amount of time and thought. Different programmers might do it >>> in different ways. I'm not referring here to the work done by ld, but >>> to the process of building a new program which has libfoo as a >>> component. >>> Additionally, the program ultimately delivered to the user isn't X >>> with some minor bits of Y. It contains big chunks of Y -- one per >>> function used, at least -- directly copied. Just being in a different >>> memory space isn't enough to change the relationship between the >>> creative parts of the works. The program vim encompasses a copy of >>> libc. >>> -Brian >>> >> What about the case where there's a common ABI, such as Java written >> against Sun's standard API, then compiled into Java Bytecode? >> >> In this case, writing against Y is creative, but when the end-user >> runs the program, is Java's run-time-linking creative or mechanical? > > What Java's doing is mechanical. But what Debian *instructed* it to > do, by shipping Y and the Java run-time together such that when you > ask for Y to be installed, you get Y and the JVM... that's clearly > creative. > >> Does this change when the program could also be linked with A, W, or >> Z, all of which implement the same ABI? > > No. But it does matter which one Debian ships it with. > >> Does this change if there's no way to tell which of A, W, Y or Z X was >> originally written against? > > The author's intent matters. If he writes against X, and Debian ships > with Z instead, then that is an artistic choice on the Project's > part. So if the author's intent isn't obvious, but it *could* be in > the set of legitimate intents, I don't see a problem. > >> Does this change if the program is aggregated with W and Z, but not Y? > > You've now lost me in letters, and I don't understand this question. > But the rest of these caused me to clarify my thinking on the matter, > and to realize that there's always a person in the system who's > imagining a combined work on an end-user system and taking action to > put it there. This might be the original author, Debian or some other > distributor, or the end-user. If it's anyone but the end-user, then > that combined work is being distributed. So you are basically saying that aiding or hinting the end-user to create these would-be derivative works is enough to be violating the license? Then how can things like thepiratebay.org be legal? It is also legal to sell all the ingredients for a bomb, along with instructions needed to build one. However, building and using the bomb is most likely illegal. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Thu, Jan 13, 2005 at 07:08:23PM +0100, M?ns Rullg?rd wrote: >> So you are basically saying that aiding or hinting the end-user to >> create these would-be derivative works is enough to be violating the >> license? > > That's overstated. It's enough to have to argue the point in court and > be unsure of the result, which is bad enough that we can't really go > there. > >> Then how can things like thepiratebay.org be legal? > > They aren't with any degree of certainty. It's certain enough that Microsoft have failed to shut them down. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Thu, Jan 13, 2005 at 04:11:22PM +0100, M?ns Rullg?rd wrote: >> Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: >> >> > Combining X+Y in the way that you have described is anything but >> > mechanical: it is a task which typically takes a skilled programmer a >> > great amount of time and thought. Different programmers might do it >> > in different ways. I'm not referring here to the work done by ld, but >> > to the process of building a new program which has libfoo as a >> > component. >> > >> > Additionally, the program ultimately delivered to the user isn't X >> > with some minor bits of Y. It contains big chunks of Y -- one per >> > function used, at least -- directly copied. Just being in a different >> > memory space isn't enough to change the relationship between the >> > creative parts of the works. The program vim encompasses a copy of >> > libc. >> >> Wrong. A dynamically linked program in ELF format (the most common on >> Linux systems) contains a list of undefined symbols, and a list of >> sonames to search for those symbols. I have a hard time seeing how >> this would make a program derived from the library. If multiple >> independent implementations of the library exist, which would the >> program be derived from? > > You've got the causality backwards here. The program is linked to the > libraries because it is a derivative of the libraries. Not the other > way around. > > Derivation is something that happens when you *write* the program. Not > when you build it. How many times does it have to be stated that *using* an API does not form a derivative work of *any* implementation of the API? Any other interpretation invariably leads to contradictions. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 19:02 +0100, Dalibor Topic wrote: >> Brian Thomas Sniffen wrote: >> > Måns Rullgård <[EMAIL PROTECTED]> writes: >> >> [large discussion of C snipped out] >> >> >>In the case of Java, the binding is even looser. A class might >> >>contain references to other classes which the JVM is free to look for >> >>anywhere it pleases. AFAIK, Eclipse uses only the standard Java API >> >>as published by Sun, and will run equally well with any implementation >> >>of said interface. >> > >> > >> > Great -- which implementation does Debian ship it with? That's all >> > that really matters. >> >> I disagree that it's all that matters. It also matters whether the >> implementation that Debian ships actually puts any restrictions on the >> license on its data, or whether it doesn't. Kaffe, being an interpreter, >> does not, afaict: >> >> "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."[1] >> >> As the GPL of the interpreter does not place any restrictions on the >> data, the incompatibility of intepreter's GPL and data's CPL does not >> matter, as the data never becomes limited by the GPL and the license >> conflict never happens. > > To cite Linus: > > "You are a weasel, and you are trying to make the world look the way you > want it to, rather than the way it _is_." > > If you at least went on and read next paragraph of the FAQ from which > you took the above. > > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > > "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." I fail to see the relevance of this paragraph to the discussion at hand. The alleged incompatibility was between the interpreter (JVM) and the program being interpreted. Does Eclipse make explicit use of libraries licensed under the GPL? > Plese stop claiming the black is white. Thanks. If you want it black, paint it black. Rewrite the GPL. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 19:55 +0100, Måns Rullgård wrote: >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> > If you at least went on and read next paragraph of the FAQ from which >> > you took the above. >> > >> > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL >> > >> > "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." >> >> I fail to see the relevance of this paragraph to the discussion at >> hand. The alleged incompatibility was between the interpreter (JVM) >> and the program being interpreted. Does Eclipse make explicit use of >> libraries licensed under the GPL? > > It surely does explicitely call java.lang.Object.wait() quite often java.lang.Object is part of the standard Java API published by Sun (http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html). > (as any multithreaded java program), which in turn calls the JVM, Quite so. > which is purely GPLed. Incorrect. There exists a GPL JVM for sure, but there also exist other JVM implementations (e.g. Sun's) equally capable of running Eclipse. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Thu, Jan 13, 2005 at 07:58:53PM +0100, M?ns Rullg?rd wrote: >> >> Then how can things like thepiratebay.org be legal? >> > >> > They aren't with any degree of certainty. >> >> It's certain enough that Microsoft have failed to shut them down. > > They haven't tried. All Microsoft have done to them so far is send > them some nastygrams in the mail. And for some reason you believe Microsoft would be content with that, if they believed they had any real chance to stop them? -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 20:15 +0100, Måns Rullgård wrote: >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> >> > On Thu, 2005-13-01 at 19:55 +0100, Måns Rullgård wrote: >> >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> >> I fail to see the relevance of this paragraph to the discussion at >> >> hand. The alleged incompatibility was between the interpreter (JVM) >> >> and the program being interpreted. Does Eclipse make explicit use of >> >> libraries licensed under the GPL? >> > >> > It surely does explicitely call java.lang.Object.wait() quite often >> >> java.lang.Object is part of the standard Java API published by Sun >> (http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html). >> >> > (as any multithreaded java program), which in turn calls the JVM, >> >> Quite so. >> >> > which is purely GPLed. >> >> Incorrect. There exists a GPL JVM for sure, but there also exist >> other JVM implementations (e.g. Sun's) equally capable of running >> Eclipse. > > Please don't get that theorhetical. What we have here is an explicit > usage, Eclipse does not explicitly use *anything* from *any* JVM/class library. Saying java.lang.Object doesn't say anything about which implementation shall be used. > not pure "possibilities", if there exist another implementations > then use it and do not infridge on the GPL. The Eclipse authors do not tell you which JVM to use. > Now, in our case, Eclipse is linked agains a libraries that ARE GPLed. No, it is being interpreted by an interpreter that is covered by the GPL. Even the FSF admits that this does not create a derived work. > We are compiling GPL-incompatible code against purely GPLed headers. Who is compiling what code? Since when does Java have headers? > Please see Linus's email I cited in my other emails for more info. > > Would it have been compiled against a differently licensed library, > this particular problem would be solved. Wouldn't it? It is compiled against an interface, not an implementation. Which particular implementation was used while compiling is irrelevant. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 20:58 +0100, Måns Rullgård wrote: >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> > Now, in our case, Eclipse is linked agains a libraries that ARE GPLed. >> >> No, it is being interpreted by an interpreter that is covered by the >> GPL. Even the FSF admits that this does not create a derived work. > > You really should reread FSF FAQ: > > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > > "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." > > Do you understand that an interpreter for Java IS such an interpreter > that provides "bindings" to other facilities? The paragraph above concerns JNI interfaces to libraries *separate* from the interpreter. For instance, one could imagine a JNI binding to GNU readline. The use of such bindings is independent of the JVM being used (bindings might not exist for all JVM implementations, but that's irrelevant). The existence of a binding facility does not make a program using them derived from the interpreter. In FSF logic, it is derived from the bound libraries, no more, no less. > Do you understand that a program being interpreted is effectively > linked to these facilities it uses thru these bindings? Yes. Which bindings does Eclipse use? > Do you understand that in case we're discussing these facilities are > released under the GPL? We are discussing the case where the interpreter is released under the GPL, nothing has been said about third-party library bindings. > Do you understand that in case we're discussing even the java library > itself is under GPL? (or at least parts of it, which is about the same) Doesn't matter. There exist other implementations, and a program can't possibly be derived from more than one. Don't you see the inconsistency? >> > We are compiling GPL-incompatible code against purely GPLed headers. >> >> Who is compiling what code? Since when does Java have headers? > > Either you're not capable of abstracting notion of headers as they're > used in C, or not willing to do so. What do you think, in Java, > provides you with the informations that you're given thru headers in C? > >> > Please see Linus's email I cited in my other emails for more info. >> > >> > Would it have been compiled against a differently licensed library, >> > this particular problem would be solved. Wouldn't it? >> >> It is compiled against an interface, not an implementation. Which >> particular implementation was used while compiling is irrelevant. > > Ok, so please compile Eclipse agains an *interface* which is not its > implementation (covered by GPL, in our case). Sure, if you use ie. > some stubs covered by IPC-compatible license, I won't say a word. If the implementations are fully compatible, the compiled bytecode should be bit-identical no matter which one was used. > But in our case you're using an implementation that also at the same > time defines the interface (this if functional equivalent of header > files). You cannot simply take a GPL implementation, compile against it > (never mind whether it's C, Java, Python or whatever), and they claim > you just didn't create a derivative work of the implementation you used. That's precisely what I am claiming, and several court cases support my claim. > Please look at FSF FAQ once again, please try to understand what the Reading the same FUD over and over again isn't going to alter the logic of the universe. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Måns Rullgård <[EMAIL PROTECTED]> writes: > >> The Eclipse authors do not tell you which JVM to use. > > But Debian does, when it says: > Depends: j2re1.4 | j2re1.3 | java2-runtime > > So the eclipse-platform distributed by Debian *does* call on a > particular JVM. And it isn't kaffe, it's Sun's. Then why on earth does the license of Kaffe have any relevance whatsoever to Eclipse? > We do document the technical fact that you can programatically > substitute kaffe for any java-runtime. So? How does this make Eclipse a derivative of Kaffe? >> It is compiled against an interface, not an implementation. Which >> particular implementation was used while compiling is irrelevant. > > Can you support this assertion? The program, including its libraries, > which the developer intends to put on end-user systems appears quite > relevant to me. If I write a program in Java (it has happened), I intend for the end-user to run it under any JVM of his choice. I don't care which one chooses. The only reason I can see for suggesting a specific implementation is for support issues, e.g. "we only provide support for running our product under JVM implementation X". -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: >> It is not hard: Some distribution of Eclipse is only encumbered by the >> GPL if it requires a GPLed work to correctly operate. You may have >> some odd version of Eclipse, but the standard releases have no such >> requirement. > > While most of what you said seemed perfectly reasonable, this does > not. > > Some distribution of Eclipse is encumbered by the GPL if it, that > distribution, includes a copy of a GPL'd work (and it is not mere > aggregation, which this certainly isn't). So shipping Eclipse+Kaffe > is not OK. Shipping Eclipse+otherJVM is fine. Your definition of "include" appears to be a little broader than the one most of us use. > I do not think anyone will disagree with this. Can we now confine > this argument to whether a program distributed as a > package with Depends: jre | java-runtime contains a copy of a package > with Provides: java-runtime? > > I'm inclined to say no, that that is not the intended operating state, > merely an incidental of technically compatible packages -- and so even > if Eclipse had a Depends: some-non-kaffe-jvm | java-runtime and Kaffe > a Provides: java-runtime, there would be no conflict with the GPL here. You're starting to make sense. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > On Thu, 2005-13-01 at 21:56 +0100, Måns Rullgård wrote: >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> >> > On Thu, 2005-13-01 at 20:58 +0100, Måns Rullgård wrote: >> >> "Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: >> >> > Now, in our case, Eclipse is linked agains a libraries that ARE GPLed. >> >> >> >> No, it is being interpreted by an interpreter that is covered by the >> >> GPL. Even the FSF admits that this does not create a derived work. >> > >> > You really should reread FSF FAQ: >> > >> > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL >> > >> > "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." >> > >> > Do you understand that an interpreter for Java IS such an interpreter >> > that provides "bindings" to other facilities? >> >> The paragraph above concerns JNI interfaces to libraries *separate* >> from the interpreter. For instance, one could imagine a JNI binding >> to GNU readline. The use of such bindings is independent of the JVM >> being used (bindings might not exist for all JVM implementations, but >> that's irrelevant). The existence of a binding facility does not make >> a program using them derived from the interpreter. In FSF logic, it >> is derived from the bound libraries, no more, no less. > > It shows you have no idea how a JVM is organized. The "interpreter" > part on which you're hanging so strongly is only part of a JVM. The > part that actually gets to interpret the bytecode. But there's also > a lot of functionality (think about it as a VM-specific library) that > is being used from within java library, and via JNI bindings calls > library functions of a JVM. > > Yes. A JVM migh be seen as an interpter + a library of native calls > used by the java library. And in case we're discussing this native > library is GPLed. The license of the library does not matter. Eclipse is written to work with any implementation of the standard Java API. >> > Do you understand that a program being interpreted is effectively >> > linked to these facilities it uses thru these bindings? >> >> Yes. Which bindings does Eclipse use? > > I told you. Plenty. And if we're making Eclipse Build-depend on > a GPLed version of these, then we're explicitely forcing these bindings > to be GPLed. Guess what, Eclipse does not have a Build-depends on any GPLd JVM. It has a Build-depends on j2sdk1.3 | j2sdk1.4, which are virtual packages. Guess what else, Kaffe doesn't provide either of these. Surprised? I'm amused. >> >> > Please see Linus's email I cited in my other emails for more info. >> >> > >> >> > Would it have been compiled against a differently licensed library, >> >> > this particular problem would be solved. Wouldn't it? >> >> >> >> It is compiled against an interface, not an implementation. Which >> >> particular implementation was used while compiling is irrelevant. >> > >> > Ok, so please compile Eclipse agains an *interface* which is not its >> > implementation (covered by GPL, in our case). Sure, if you use ie. >> > some stubs covered by IPC-compatible license, I won't say a word. >> >> If the implementations are fully compatible, the compiled bytecode >> should be bit-identical no matter which one was used. > > Does it matter? What however IS different is the fact which actual > implementation you use as the interface against which you're compiling, > and also with which implementation of library an app will be us
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
"Grzegorz B. Prokopski" <[EMAIL PROTECTED]> writes: > Putting it differently: if that was allowed, then why do we need glibc > to be LGPLed, and not GPLed? After all the C language and its basic > libraries are also standarized to great extent. I can see no real reason. > But having glibc purely GPL just doesn't sound good, does it? It sounds like it would make for a lot of arguing with FSF, nothing else. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > "Michael K. Edwards" <[EMAIL PROTECTED]> writes: > >> [no longer relevant to debian-java, I think] >> >> On Thu, 13 Jan 2005 15:28:57 -0500, Brian Thomas Sniffen >> <[EMAIL PROTECTED]> wrote: >> [snip] >>> You are ignoring the >>> creative act performed by the programmer who arranged calls to >>> functions within libc. That was creative effort on his part which >>> critically involves a copy of libc. >> >> As is the creation of a critical essay on libc. But that's not a >> derivative work either. > > But an annotated edition of libc is. A program seems far more similar > to an annotated edition than to a critical essay -- since it includes > a copy of the library, after all, and pointers into it. Now you stopped making sense. A program includes only references to a library, not the library itself. A distribution, e.g. Debian, might include both the program and the library. I don't see a problem with distributing a collection of programs, where some of them can be combined in ways that violate some license, as long as all of them still have legitimate uses. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Dalibor Topic <[EMAIL PROTECTED]> writes: > >> 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 >> says, the GPLd interpreter can't impose restrictions on its >> input. They even get compiled in statically on Debian for debian's >> kaffe package. > > Very nicely said. This is exactly why it's legal to make and > distribute Eclipse and other free Java programs in the first place. > > On the other hand, it's also exactly why it's problematic for Debian > to distribute an Eclipse which incorporates a copy of the GPL'd Kaffe. Please start using a dictionary with the same definition of "include", "incorporate" and similar words as everybody else's dictionaries use. -- Måns Rullgård [EMAIL PROTECTED]
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: > Dalibor Topic <[EMAIL PROTECTED]> writes: > >>> When I instruct my computer running the Debian OS to load and run >>> eclipse, the code from some JVM package and the code from the Eclipse >>> package and from dozens of others are loaded into memory. The process >>> on my computer is mechanical, so we should look back and see who has >>> designed and created this particular combination. In this case, it >>> was Debian, who took the top level Eclipse component and selected >>> a particular JVM and particular support libraries to include. >> >> That's the 'running is illegal/GPL puts restrictions on use' fallacy. :) > > I'm not talking about running; I'm talking about making a copy of > Eclipse and a copy of Kaffe and putting them both on an end-user's > system such that when I type "eclipse" I get a program made out of > both. So what? Eclipse is still only a Java program being interpreted by Kaffe, which is perfectly within the limits set by the GPL. -- Måns Rullgård [EMAIL PROTECTED]
Re: May be non-copyrighted documment included in main?
MJ Ray <[EMAIL PROTECTED]> writes: > Petr Gajdusek <[EMAIL PROTECTED]> wrote: >> The only notice in the documment says: >> "This publication is not copyrighted. One can copy it and use any part >> of it with mentioning the source. Publishers ask only for information >> about it." >> >> Is this sufficient to include publication in main section? > > It may depend where it's from: copyright is automatic in > many countries. > > As such, the permission granted to copy it and use any part with > attribution is needed and might be sufficient, but it looks like > it deliberately discriminates against publishers. I don't think > it follows DFSG 1 or 6. It says something about publishers, but exactly what it's supposed to mean is beyond me. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-DEV] PHP License
Ian Eure <[EMAIL PROTECTED]> writes: >> 6. Redistributions of any form whatsoever must retain the following >> acknowledgment: "This product includes PHP, freely available from >> <http://www.php.net/>". >> >> Ouch. This means that I can't distribute a PEAR module released under >> the PHP License without bundling in PHP itself. This makes it impossible >> to distribute PEAR modules by themselves (i.e. not bundled with the PHP >> language) in a deb or an rpm. :-( >> > I feel that your interpretation of those clauses is overbroad and > incorrect. The clause does not state that the product must bundle > PHP, but that it must affix a notice to the effect that it includes > it. But without including PHP, it won't be, well, included, making the statement false. Using false statements as part of a license doesn't seem like a very good idea to me. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] PHP License
Sean Kellogg <[EMAIL PROTECTED]> writes: > On Wednesday 24 August 2005 01:46 pm, Catatonic Porpoise wrote: >> Sean Kellogg wrote: >> >I'm pretty sure it is a PHP-derivative. It relies on all sorts of built >> > in PHP functions to create the finished work. Perhaps... PERHAPS... >> > the code you download for phpbb, on its own, MIGHT be a separate and >> > distinct work, but it's not "phpbb" until it's merged with PHP functions >> > to create the finished, derived work. >> >> I see a little problem with this line of reasoning. It would seem to >> imply that if I post a C program I wrote on my website, in source code >> form, that program is subject to the license of every libc anyone might >> ever compile it with. > > I would think the code you post is just code. You're free to post > your own code as much as you like. However, if I download that code > and use it in conjunction with glibc, then yes, I must abide by the > license chosen by the authors of glibc. But it does raise an > interesting question... [...] > But if we assume the developers of phpBB actually downloaded PHP, > they agreed to not make derivative software with certain titles. > Going back to the C example you raised... the developer of the C > program must abide by the terms of the libc he or she chose to > develop with. I build my code on a variety of systems, including Linux/glibc, *BSD, Solaris, AIX, MacOSX, etc. Does this mean that my programs are derivatives of all these C libraries/compilers? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PEAR-QA] PHP License
Sean Kellogg <[EMAIL PROTECTED]> writes: > On Wednesday 24 August 2005 02:17 pm, Måns Rullgård wrote: >> Sean Kellogg <[EMAIL PROTECTED]> writes: >> > On Wednesday 24 August 2005 01:46 pm, Catatonic Porpoise wrote: >> >> Sean Kellogg wrote: >> >> >I'm pretty sure it is a PHP-derivative. It relies on all sorts of >> >> > built in PHP functions to create the finished work. Perhaps... >> >> > PERHAPS... the code you download for phpbb, on its own, MIGHT be a >> >> > separate and distinct work, but it's not "phpbb" until it's merged >> >> > with PHP functions to create the finished, derived work. >> >> >> >> I see a little problem with this line of reasoning. It would seem to >> >> imply that if I post a C program I wrote on my website, in source code >> >> form, that program is subject to the license of every libc anyone might >> >> ever compile it with. >> > >> > I would think the code you post is just code. You're free to post >> > your own code as much as you like. However, if I download that code >> > and use it in conjunction with glibc, then yes, I must abide by the >> > license chosen by the authors of glibc. But it does raise an >> > interesting question... >> >> [...] >> >> > But if we assume the developers of phpBB actually downloaded PHP, >> > they agreed to not make derivative software with certain titles. >> > Going back to the C example you raised... the developer of the C >> > program must abide by the terms of the libc he or she chose to >> > develop with. >> >> I build my code on a variety of systems, including Linux/glibc, *BSD, >> Solaris, AIX, MacOSX, etc. Does this mean that my programs are >> derivatives of all these C libraries/compilers? > > Yeah, I believe so. That's absurd. In theory, I could write the code without access to any of the libraries, only using the POSIX spec for reference. The result could be compiled and run on any POSIX compliant system (and there are some). Now in practice, I'll occasionally make a mistake, so I need to test the code to make sure it works. If this makes my program a derivative of all these C libraries, I'm in real trouble, since I have no license to create such derivatives of most of them. > This is why glibc is under the LGPL. No, the reason for that is that the FSF insists that using the GPL would disallow non-GPL programs linking with it at all, and for whatever reason they don't want that situation. > It's really easy to create derived works under U.S. Law. > > As a side note, there is some really interesting unexplored areas of > law relating to derivative works and things like dynamic vs. static > linked libraries. There is some case law, but I think it leaves a > lot unanswered. Indeed. > For the purposes of this discussion, I'm supporting the popular > contention that using a dynamically linked library creates a > derivative work (although, I have my doubts). The same logic applies here. If the program can work with either of several different libraries, it is not a derivative of any. If it were, we'd have the absurd situation of programs being derivatives of libraries written after the program. Clearly, this is not possible. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL+OpenSSL issue -- good suggestion?
Pascal Giard <[EMAIL PROTECTED]> writes: > I maintain the mail-notification package and face a GPL+OpenSSL issue. > I've tried to reach an arrangement with the upstream author but failed. > > Find the bug entry here: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286672 > > Recently, a user posted a suggestion, i'd like to know if it's a > valid solution. If not, is there anything else i can do? This is getting absurd. The usual argument here is that Debian should follow the wishes of the upstream author, even if the legal foundations are shaky. Why not in this case? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
Sean Kellogg <[EMAIL PROTECTED]> writes: >> The thing is that the kernel is indeed much like a library, but not >> like a static one. The kernel is a lot like a shared library in >> that it exists in memory, and has functions that can be called. It >> is different mainly in that it stays in memory, and on some >> architectures has special capabilities not available to regular >> shared libraries. >> >> Note that it is not different by being a critical part of the >> operating system, as other libraries, especially things like the c >> library, or even the runtime linking library (ld.so) > > I've written about this very issue in law school. It seems to me > there are two ways to view the issue. One is that the GPL is a > Contract (*shudder*) and thus the parties are free to restrict what > is done with code they distribute. Consider it a contract that says > "you can have this code, but only if you free the code you combine > it with... otherwise you can't have the code" That is a perfectly > fine contract, mutual promises and all. > > However, many say that the GPL is not a contract and must be > considered a pure license and the sole product of copyright law. If > so, then the GPL can only exercise power over (s)106 rights (US > copyright law). Any item outside of those rights cannot be > controlled by the license. The GPL tries to do this by claiming a > derived work or out-and-out copying. I think you very much hit it > on the head by asking whether it is either... and based on my > understanding of what is and is not a derivative work, what > constitutes copying, and applicable caselaw, I don't think it is. > > But then again, I think the GPL is a contract... so I don't see it > as much of a problem. Even if the GPL is a contract, it doesn't matter. Read section 0: 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Note particularly the phrase "derivative work under copyright law". Whatever terms the parties of the contract agree to, they apply only to the program itself and the aforementioned derivatives, specifically not other programs that merely use the code covered by the contract. The contradictory rephrasing following the colon doesn't pose any problems either, as a program dynamically linked to a library doesn't contain the library, or any parts of it. All it does is makes reference to it, and does so in a very non-specific way. The section continues: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. The phrase "running the Program" is not directly applicable to a library, so we have to assume that for libraries, this translates into using the library, i.e. causing its code to be run, typically by running a program that uses the library. This act being unrestricted per the quoted paragraph, it follows that any program can link with a GPL library, no matter what license that program has. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
Sean Kellogg <[EMAIL PROTECTED]> writes: > On Thursday 08 September 2005 11:38 am, Andrew Suffield wrote: >> There's an awful lot of lawyers and law professors who think that the >> GPL works. Go start by arguing with them. > > Based on my readings of law review articles and the common legal arguments > surrounding the GPL, the reason it works is because the GPL is a contract. > The linking clause is a contractual term that you must agree to in order to > receive a copyright license. Pretty standard forbearance. Which linking clause? The one in the FAQ? That's not in any way part of the license/contract. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
[EMAIL PROTECTED] (Claus Färber) writes: > Andrew Suffield <[EMAIL PROTECTED]> schrieb/wrote: >> You are the one who is supposedly attempting to offer an argument >> here. Not me. I'm just telling you why yours is broken. > > You are actually creating straw mans which are broken. The original > argument isn't. > > The argument, simplified, basically goes like this: > > 1. Program A is licensed under the GPL. => Debian can distribute A. >Library M is licensed under the GPL. => Debian can distribute M. >Program B is a derivative of A, which dynamically links against M. >=> Debian can distribute B. > > 2. Library O is licensed under the a BSD-like license, which contains >an advertisting clause. => Debian can still distribute O. >Program C is a derivative of A, which dynamically links against O. >=> Debian can't distribute C. > > 3. Library M is fully compatible to O. So programs B and C are actually >identical. >=> Debian can and can't distribute B/C at the same time. >=> This can't be right. > > So one of the assumptions made above is wrong. The only assumption that > is not obviously right is: "Debian can't distribute C". > > Well, you can replace "Debian can't distribute C" by "Debian can't > distribute C unless M is available". But this is very strange as it > would mean that the advent of M changes the copyright status of C, which > is actually derieved from A and O. This is the argument that has been rehashed here countless times. Each time, the reply has been something like "you're wrong", with no explanations whatsoever. I can only take this to mean that they are out of real arguments, but refuse to admit it, just like the FSF themselves. I'm giving up this discussion for now, until people perhaps decide to start using logic and reason, rather than philosophy and religion to reach their conclusions. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL, yet again. (The kernel is a lot like a shared library)
Andrew Suffield <[EMAIL PROTECTED]> writes: > On Fri, Sep 09, 2005 at 09:54:04AM -0300, Humberto Massa Guimar?es wrote: >> > On Thu, Sep 08, 2005 at 04:22:18PM -0300, Humberto Massa >> > Guimar?es wrote: >> > > > If you're going to make an argument at odds with established >> > > > understanding and industry practice then you'll have to >> > come up with >> > > > more than that. >> > > > >> > > > There's an awful lot of lawyers and law professors who >> > think that the >> > > > GPL works. Go start by arguing with them. >> > > >> > > I can't argue with someone who offers ABSOLUTELY NO ARGUMENT. >> > >> > You are the one who is supposedly attempting to offer an argument >> > here. Not me. I'm just telling you why yours is broken. That doesn't >> >> No, you are not "telling me why my argument is broken". If you are >> trying, you're not being very clear. Why is my argument broken exactly? > > By trivially continuing it to the next obvious point, it concludes > that the GPL doesn't work. Therefore it's broken somewhere. Figuring > out where is left as an exercise for the students. I really don't care > about the details. Ah, but this is based on the assumption that the GPL actually does work. The argument was intended to show that it doesn't, and apparently succeeds at this. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MySQL only useable for GPL clients?
Martin Koegler <[EMAIL PROTECTED]> writes: > The newer MySQL client libraries are GPL (with the FLOSS exception), > older versions were LGPL. > > At http://dev.mysql.com/doc/internals/en/licensing-notice.html > MySQL has put a descrption of their network protocol, where they > force programs using this protocol to be GPL: > >>The MySQL Protocol is proprietary. >> >>The MySQL Protocol is part of the MySQL Database Management System. >>As such, it falls under the provisions of the GNU Public License (GPL). >>A copy of the GNU Public License is available on MySQL's web site, and >>in the product download. >> >>Because this is a GPL protocol, any product which uses it to connect >>to a MySQL server, or to emulate a MySQL server, or to interpose >>between any client and server which uses the protocol, or for any >>similar purpose, is also bound by the GPL. Therefore if you use this >>description to write a program, you must release your program as >>GPL. Contact MySQL AB if you need clarification of these terms or if >>you need to ask about alternative arrangements. What are those people smoking? Writing a program that implements a protocol does not in any way I've ever heard of create anything derived from the protocol specification. An MPEG decoder is not a derivative of the MPEG specification (patents issues are unrelated), and this is no different in principle. Remember that it is perfectly legal to reverse engineer a protocol, and then proceed to write your own programs using it. Surely, there can't be more restrictions when the specification is publicly available. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MySQL only useable for GPL clients?
Alexander Terekhov <[EMAIL PROTECTED]> writes: > On 10/11/05, Martin Koegler <[EMAIL PROTECTED]> wrote: > [...] >> At http://dev.mysql.com/doc/internals/en/licensing-notice.html > > Under the laws of the GNU Republic (MySQL district), all works are "derived" > (in metaphysical sense) from some other preexisting GPL'd work(s) and hence Not just from preexisting works, they can be derived from works to be written later too. Some of the regulars here have repeatedly asserted the equivalent of this. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logo rip-off
Henning Makholm <[EMAIL PROTECTED]> writes: > Scripsit Amaya <[EMAIL PROTECTED]> > >> /me wonders... >> Isn't the Debian swirl logo just a very basic Adobe Illustrator >> template? > > The stroke is, but the particular way it swirls is not. Looks like a pretty standard spiral to me. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logo rip-off
Henning Makholm <[EMAIL PROTECTED]> writes: > Scripsit Måns Rullgård <[EMAIL PROTECTED]> >> Henning Makholm <[EMAIL PROTECTED]> writes: >>> Scripsit Amaya <[EMAIL PROTECTED]> > >>>> Isn't the Debian swirl logo just a very basic Adobe Illustrator >>>> template? > >>> The stroke is, but the particular way it swirls is not. > >> Looks like a pretty standard spiral to me. > > I didn't know there were standards for spirals. Which standard in > particular are you referring to? In this case, most likely one supplied with Adobe Illustrator. The logo is just that texture wrapped along a simple spiral. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logo rip-off
Steve Langasek <[EMAIL PROTECTED]> writes: > On Thu, Oct 13, 2005 at 09:37:08PM +0100, Måns Rullgård wrote: >> Henning Makholm <[EMAIL PROTECTED]> writes: > >> > Scripsit Måns Rullgård <[EMAIL PROTECTED]> >> >> Henning Makholm <[EMAIL PROTECTED]> writes: >> >>> Scripsit Amaya <[EMAIL PROTECTED]> > >> >>>> Isn't the Debian swirl logo just a very basic Adobe Illustrator >> >>>> template? > >> >>> The stroke is, but the particular way it swirls is not. > >> >> Looks like a pretty standard spiral to me. > >> > I didn't know there were standards for spirals. Which standard in >> > particular are you referring to? > >> In this case, most likely one supplied with Adobe Illustrator. The >> logo is just that texture wrapped along a simple spiral. > > Could you please tell us where in the Adobe Illustrator interface to find > the simple spiral template in question? I don't have Adobe Illustrator. However, other graphics programs I've used have had such spiral functions. I'd certainly expect a program as expensive and with such ambitions as Adobe Illustrator to have it. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logo rip-off
Henning Makholm <[EMAIL PROTECTED]> writes: >> I'd certainly expect a program as expensive and with such ambitions >> as Adobe Illustrator to have it. > > On the contrary - a specific spiral template sounds like an extremely > arcane and particular feature for someone to embed in a program. Most programs of that type have tools to draw rectangles, (regular) polygons, circles, ellipses, and spirals. Those are all basic geometrical shapes. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Logo rip-off
Henning Makholm <[EMAIL PROTECTED]> writes: > Scripsit Måns Rullgård <[EMAIL PROTECTED]> >> Henning Makholm <[EMAIL PROTECTED]> writes: > >>>> I'd certainly expect a program as expensive and with such ambitions >>>> as Adobe Illustrator to have it. > >>> On the contrary - a specific spiral template sounds like an extremely >>> arcane and particular feature for someone to embed in a program. > >> Most programs of that type have tools to draw rectangles, (regular) >> polygons, circles, ellipses, and spirals. Those are all basic >> geometrical shapes. > > I'm beginning to think that you are being deliberately obtuse. > > There are millions of *possible* spiral shapes that one could > draw. Elektrostore chose the *exact same* spiral shape as the Debian > swirl, and positioned the stock brush at the *exact same* point on the > spiral. *That* is not just a default template. How did you measure the shape? How do you know that both logos were not created using default settings? -- Måns Rullgård [EMAIL PROTECTED]
Re: Clarification regarding PHP License and DFSG status
Florian Weimer <[EMAIL PROTECTED]> writes: > * MJ Ray: > >> Do you think that this licence does not require a developer >> of a modified package (other than PHP) to lie by saying >> "This product includes PHP software"? > > Perhaps the PHP folks subscribe to the view that PHP scripts are > derivative works of PHP. Then it wouldn't be lying, would it? They still don't *include* PHP. There's a huge difference between require and include. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Clarification regarding PHP License and DFSG status
Florian Weimer <[EMAIL PROTECTED]> writes: > * Matthew Palmer: > >> On Wed, Nov 23, 2005 at 03:08:24PM +0100, Florian Weimer wrote: >>> * MJ Ray: >>> >>> > Do you think that this licence does not require a developer >>> > of a modified package (other than PHP) to lie by saying >>> > "This product includes PHP software"? >>> >>> Perhaps the PHP folks subscribe to the view that PHP scripts are >>> derivative works of PHP. >> >> Ye ghods, I'd hope not. That would be similar to believing that this >> message is a derivative of the English Grammar manual I read in school. > > Or that all non-trivial Emacs Lisp code must be licensed under the > GPL. This position is not *that* unusual... Not being unusual doesn't make it sensible or correct. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Clarification regarding PHP License and DFSG status
Glenn Maynard <[EMAIL PROTECTED]> writes: > On Fri, Nov 25, 2005 at 07:23:24PM +0000, Måns Rullgård wrote: >> >>> > Do you think that this licence does not require a developer >> >>> > of a modified package (other than PHP) to lie by saying >> >>> > "This product includes PHP software"? >> >>> >> >>> Perhaps the PHP folks subscribe to the view that PHP scripts are >> >>> derivative works of PHP. >> >> >> >> Ye ghods, I'd hope not. That would be similar to believing that this >> >> message is a derivative of the English Grammar manual I read in school. >> > >> > Or that all non-trivial Emacs Lisp code must be licensed under the >> > GPL. This position is not *that* unusual... >> >> Not being unusual doesn't make it sensible or correct. > > Just to take a guess at where this strange claim might have originated: Statements like this one would seem to have something to do with it: http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > The FSF (from what I understand) claims that binaries linked against > GPL libraries are derivative works of the library, because the > resulting binary has pieces of the GPL software in it. This isn't > obviously true with C libraries, which has led to a lot of debate > around the topic, but the claim isn't entirely unreasonable. > > They do not claim (again, AFAIK) that the *source* of the program > using it is a derivative work of the library it uses. > > "PHP scripts are derivative works of PHP" sounds like someone > misinterpreted the FSF's claims, and ended up believing that the > source of a program is a derivative work of its libraries. (That, > unlike the FSF's claims, seems to make very little reasonable > sense.) For compiled languages they do not make this claim. For interpreted languages they appear to be claiming exactly this. The grounds for making such a distinction, or how to make it, are beyond me. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Clarification regarding PHP License and DFSG status
Glenn Maynard <[EMAIL PROTECTED]> writes: > On Fri, Nov 25, 2005 at 09:22:24PM +0000, Måns Rullgård wrote: >> Statements like this one would seem to have something to do with it: >> http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > > Odd statements, indeed. It's curious that the FSF would take > positions that seem to seek to expand the power of copyright, and > it's not the first time I've had this impression. They will gladly make any claim, however preposterous, as long as it suits their agenda. Their agenda, if anyone missed it, is to make everyone use the GPL for various political/philosophical reasons. When people cannot be persuaded to use it, the FSF will tell them lies, in order to make them believe that they have no other choice. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Clarification regarding PHP License and DFSG status
Arnoud Engelfriet <[EMAIL PROTECTED]> writes: > The FSF makes very similar claims without additional context > in their GPL FAQ: > >Q: If a library is released under the GPL (not the LGPL), does >that mean that any program which uses it has to be under the GPL? > >A: Yes, because the program as it is actually run includes the >library. >http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL That doesn't fit any meaning of include that I'm aware of. The program and the library are sitting next to each other in the same address space. That doesn't make one of the include the other. Suppose a library allocates some shared memory that is accessed by all processes using that library (many examples exist). Does that make all programs using this library "include" each other, since they partially share address space? >Q: You have a GPL'ed program that I'd like to link with my code to >build a proprietary program. Does the fact that I link with your >program mean I have to GPL my program? > >A: Yes. >http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL I guess you all know what I think the GPL FAQ is a load of. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Potential debian logo license violation
Andrew Donnellan <[EMAIL PROTECTED]> writes: > The outer ring of the spiral seems a fair bit wider than the Debian > logo. It seems to be just a textured spiral to me. I played around with the Greek site's logo, trying to match it against the Debian logo. This is the result: http://inprovide.com/~mru/junk/debian.png This took a fair amount of rotating and stretching, and it's still not very close. My guess is that someone happened to draw a vaguely similar spiral. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Potential debian logo license violation
Giannis Beredimas <[EMAIL PROTECTED]> writes: > Hi Måns, > > Måns Rullgård wrote: > >>I played around with the Greek site's logo, trying to match it >>against the Debian logo. This is the result: >>http://inprovide.com/~mru/junk/debian.png >> >>This took a fair amount of rotating and stretching, and it's still >>not very close. My guess is that someone happened to draw a vaguely >>similar spiral. >> >> > > I decided to toy around with the logo myself. However, since the > http://infosoc.gr site has a pseudo 3D-rotated version of the logo I > decided to use a "flat version" I didn't know such a version existed, much less where to look for it. > (http://ru6.cti.gr/broadband/images/logo-ktp.gif). From the mentioned > gif: > - I extracted the logo > - Rotated 90 degrees anti-clockwise > - Replaced the background with a white-one and made the spiral red > > The result is available at > http://mperedim.serverhive.com/box/logo-comparison.jpg. Bottom left is > the original debian logo, bottom right is the extracted infosoc > logo. Afterwards I resized the bottom-right logo (keeping its original > aspect ration) and superimposed it over and under the debian logo. > > Personally I am seeing more than a vague similarity, but (as I said in > original mail) maybe it 's just me. There are similarities in the shape that has been rolled up to form the spiral. The spiral itself differs, though. The Greek spiral has about 2.5 revolutions, while the Debial logo has barely 2. Maybe they used the same Adobe Illustrator brush that was used to create the Debian logo, and applied it to a spiral with different parameters. If you create a logo by using stock items from a widely used graphics design program, you can only expect to find others using similar graphics. -- Måns Rullgård [EMAIL PROTECTED]
Re: Potential debian logo license violation
Andrew Donnellan <[EMAIL PROTECTED]> writes: > On 11/28/05, Måns Rullgård <[EMAIL PROTECTED]> wrote: >> Giannis Beredimas <[EMAIL PROTECTED]> writes: >> > >> >> There are similarities in the shape that has been rolled up to form >> the spiral. The spiral itself differs, though. The Greek spiral has >> about 2.5 revolutions, while the Debial logo has barely 2. Maybe they >> used the same Adobe Illustrator brush that was used to create the >> Debian logo, and applied it to a spiral with different parameters. > > Seems to be. So the Debian logo was made with Adobe(r) > Illustrator(tm)? Proprietary software! There was a thread on that topic some time ago. Someone posted a screenshot that was quite convincing. Of course, there are those who refuse to believe it. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moglen's "all good faith"
Alexander Terekhov <[EMAIL PROTECTED]> writes: > Hey legals, enjoy Moglen speaking on one-way street, linking, etc. > > http://news.com.com/Defender+of+the+GPL/2008-1082_3-6028495.html > > Now, > > > One specific area where the linking question arises is in the Linux kernel, > where proprietary video drivers loaded are loaded as modules. Another one > might be the use of a network driver that relies on proprietary firmware that > is loaded from an operating system. (Such firmware, sometimes called > "blobs," are strings of hexadecimal digits loaded from the operating > system kernel into the hardware device to enable it to run.) > > Moglen: In all good faith, I can't tell you. If the kernel were pure GPL in > its license terms, the answer...would be: You couldn't link proprietary > video drivers into it whether dynamically or statically, and you couldn't > link drivers which were proprietary in their license terms. > > > I just wonder under what "impure" GPL license terms do you think Moglen > thinks the Linux kernel is developed currently (note that the context is > kernel drivers which has nothing to do with Linus' not-really-an-exception > for user space). > > Any thoughts? Perhaps this: Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. Besides, I'm free to insert whatever modules I want in my kernel, so long as I don't distribute /proc/kcore. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moglen's "all good faith"
Alexander Terekhov <[EMAIL PROTECTED]> writes: > On 1/20/06, Måns Rullgård <[EMAIL PROTECTED]> wrote: > [...] >> > Moglen: In all good faith, I can't tell you. If the kernel were >> > pure GPL in its license terms, the answer...would be: You >> > couldn't link proprietary video drivers into it whether >> > dynamically or statically, and you couldn't link drivers which >> > were proprietary in their license terms. >> > >> > >> > I just wonder under what "impure" GPL license terms do you think Moglen >> > thinks the Linux kernel is developed currently (note that the context is >> > kernel drivers which has nothing to do with Linus' not-really-an-exception >> > for user space). >> > >> > Any thoughts? >> >> Perhaps this: >> >> Also note that the only valid version of the GPL as far as the kernel >> is concerned is _this_ particular version of the license (ie v2, not >> v2.2 or v3.x or whatever), unless explicitly otherwise stated. > > And how does that make it "impure" GPL? Permission to relicense > under revised later versions is not part of the GPL license terms. Are we talking about what makes sense, or about what Mr Moglen says? -- Måns Rullgård [EMAIL PROTECTED]
Re: Moglen on kernel firmware blobs
Marco d'Itri <[EMAIL PROTECTED]> writes: > http://news.zdnet.com/2100-9595_22-6028746-2.html?tag=st.next > > Moglen: > > I would distinguish the blobs from the proprietary drivers in the > kernel. If the kernel's terms were unambiguously GPL, which they are > apparently not, (proprietary drivers) would be forbidden. The > blobs--though they are ethically objectionable to the Free Software > Foundation, which believes that users ought to know what's running--are > different because they are separate works when executed running in > separate computers. From the point of view of the GPL work called the > Linux kernel, they're just data. Exactly what I've always been saying. Call them non-free if you will, but don't get it mixed up with the GPL. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bitstream font license
olive <[EMAIL PROTECTED]> writes: > The lisence for the bitsream (package ttf-bitstream-* in main) font > state among other: > > [...] > The Font Software may be sold as part of a larger software package but > no copy of one or more of the Font Software typefaces may be sold by > itself. > [...] > (see the full license at > http://packages.debian.org/changelogs/pool/main/t/ttf-bitstream-vera/ttf-bitstream-vera_1.10-3/ttf-bitstream-vera.copyright > ) > > Does the fact that the fonts cannot be sold separatly is compatible > with the DFSG? In spirit, no. However, it is easy to work around that restriction. Simply sell the fonts as part of the Hello World package. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A new practical problem with invariant sections?
Nathanael Nerode <[EMAIL PROTECTED]> writes: > Anthony DeRobertis wrote: >> Nathanael Nerode wrote: >> >> >>>Oh, it's possible, the section just ends up as unreadable garbage. >>>Nothing in the GFDL requires that the invariant sections be >>>readable. >> >> >> Well, actually, its not because devices easily barf on things that >> aren't ASCII. >> >> And, further, the GFDL says I must preserve invariant sections >> "unaltered in their text", not "unaltered in their octects"; I seriously >> doubt that'd count... > Mmm, I guess you're right. But then transliterating to ASCII must be acceptable. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: x264 for Debian
Arc Riley <[EMAIL PROTECTED]> writes: > On Thu, Mar 02, 2006 at 01:26:56PM -0800, David Liontooth wrote: >> >> Are there objections to including the new H.264 encoder in Debian? >> For details, see bug 354667 (request for packaging). >> >> Debian maintainer Christian Marillat currently maintains an unofficial >> package, and we would like your advice on whether this GPL'd codec meets >> the DFSG. > > Theres a difference between the code and the codec. > > The codec has dozens of different corporations holding patents over > it, who will try to extract royalties for it in countries where > those patents are upheld (ie, USA), and giving it "this is free > because it's GPL" hurts truely patent-clear codecs such as > VP3.2/Theora from being recognised as such. VP3/Theora is all but free of patents. On2 has granted unlimited free use of the patents they hold relevant to VP3. There are almost certainly other patents that could be construed to cover VP3 as well. It is a good gesture nonetheless. That said, VP3/Theora can hardly compare with H.264 in terms of coding efficiency. There really is no viable alternative in some situations. Microsoft's WMV9/VC1 comes close but I'm sure it has every bit as non-free licensing terms. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: x264 for Debian
Arc Riley <[EMAIL PROTECTED]> writes: > On Thu, Mar 02, 2006 at 10:45:12PM +, M?ns Rullg?rd wrote: >> > >> > The codec has dozens of different corporations holding patents over >> > it, who will try to extract royalties for it in countries where >> > those patents are upheld (ie, USA), and giving it "this is free >> > because it's GPL" hurts truely patent-clear codecs such as >> > VP3.2/Theora from being recognised as such. >> >> VP3/Theora is all but free of patents. On2 has granted unlimited free >> use of the patents they hold relevant to VP3. There are almost >> certainly other patents that could be construed to cover VP3 as well. >> It is a good gesture nonetheless. > > I didn't say patent-free, I said patent-clear. On2 has put a > license on it which allows it to be used for any purpose and > disclaims any right to restrict it's use or charge royalties. This > is the patent version of the BSD license. Sure, On2 has allowed free use of *its* patents relating to VP3. That doesn't mean that some obscure company will pop up out of nowhere with a bunch of patents they claim *also* apply to VP3, and that On2 has been infringing all along. Something like that happened with JPEG not too long ago. > The dozens of corporations holding patents over H.264/MPEG-4 have > not made such a release, and are activly seeking royalties. We > don't even know yet what those royalties will be since those > corporations are still fighting amoung each other over how to divy > up the bounty from the combined patent portfolio. Regardless of the > result, it is not patent-clear, will not be patent-clear, and will > suffer worse bashlash as the free MP3 encoders did. The patent situation is unfortunate. Nevertheless, the H.264 codec is being adopted by broadcasters throughout the world. For good or bad, the codec is here to stay for a while. > The GPL specifically forbids redistribution when the liberties > granted by the GPL are limited or restricted by patents/etc. To > distribute this software on any US-based server is, thus, in > violation of the GPL. I won't argue about that. >> That said, VP3/Theora can hardly compare with H.264 in terms of coding >> efficiency. There really is no viable alternative in some situations. >> Microsoft's WMV9/VC1 comes close but I'm sure it has every bit as >> non-free licensing terms. > > This argument has nothing to do with the freeness of it, or it's > compliance to the DFSG, but instead seems to be arguing that it's > patent status should be ignored because it's superiority over free > codecs makes it OK to ignore the ethical concerns over it. I'm not saying the patent issue should be ignored. It just strikes me as silly to even start comparing Theora with H.264. If you need HD content encoded at 4Mbps, H.264 is the only codec that is capable. Likewise, SD content at 500kbps is impossible with other codecs. It doesn't matter how free something is when it is useless for the required application. I'm not saying that Theora is useless per se. It is adequate for some applications. They are just not the ones where H.264 would normally be considered. This is all off-topic for debian-legal, so I won't pursue the argument further (unless someone says something really silly). -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: x264 for Debian
Mike Hommey <[EMAIL PROTECTED]> writes: > On Thu, Mar 02, 2006 at 08:39:32PM -0500, Arc Riley <[EMAIL PROTECTED]> wrote: >> > I'm not saying the patent issue should be ignored. It just strikes me >> > as silly to even start comparing Theora with H.264. >> >> Certain graphic artists would say the same of GIMP vs Photoshop, or compare >> their favorite music application with the numerous GNU/Linux offerings, or >> even 3d Studio Max/Bryce/Poser/etc vs Blender. >> >> There are free alternatives. They may or may not be considered >> acceptable for specific applications, but this doesn't change that >> proprietary software is proprietary and is, thus, not DFSG-free. > > For the sake of correctness, please stop linking H264 with > "prioprietary". The fact is the software is *free* as in speech. It > being patent encumbered doesn't make it proprietary. It still is > free as in speech in those countries that don't have such patents. The spec is also available free of charge. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Eduard Bloch <[EMAIL PROTECTED]> writes: > Hello debian-legal experts ;-), > > I need a bit support to clarify the issue with cdrtools' build system. > > Summary: a while ago, Joerg Schilling (upstream) replaced the copyright > headers in the files of his build system inside of the cdrtools package > with references to a CDDL license context. D-L v. JS, now that's a flame war I'd like to see ;-) Flaming aside, this is a non-issue. The source for cdrecord contains invariant sections (those obnoxious "warnings" about using device names), so it's certainly not DFSG-free. Just use dvdrtools instead. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 possible issues.
Steve Langasek <[EMAIL PROTECTED]> writes: > On Sat, Mar 18, 2006 at 09:15:40PM +, John Watson wrote: >> On controlling music, I personally see no issues with this. With >> out DRM, music or other media type content could not be legally >> made available over the Internet. > > This is false. Without DRM, certain greedy and immoral content > providers will be *unwilling* to provide music over the Internet; > but I am aware of no copyright laws in any jurisdiction that > *mandate* the use of DRM. Well, since the content providers appear bent on using DRM, I'd rather have them use an open source DRM than some Sony-style rootkit. The majority of the content will always be non-free anyhow (and I don't have a problem with that), so an unobtrusive, portable DRM scheme isn't inherently bad in my view. DRM becomes nasty when it is closed and difficult (or even illegal) to use on your operating system of choice. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Don Armstrong <[EMAIL PROTECTED]> writes: > On Sat, 18 Mar 2006, Eduard Bloch wrote: >> Summary: a while ago, Joerg Schilling (upstream) replaced the >> copyright headers in the files of his build system inside of the >> cdrtools package with references to a CDDL license context. >> >> In #350739, the reporter claims that we and JS are violating the GPL >> because not all files required to create the executable work are >> available under the GPL license. > > It's not that they have to be available, it's just that they have to > be compatible. [Moreover, JS violation of the GPL isn't interesting > because he's presumably the copyright holder, and can therefore do > whatever he wants with his work.] Even if JS can do whatever he wants, Debian can't lawfully distribute a work with inconsistent license terms. >> CDDL is considered GPL-incompatible for linking with GPLed code. > > Not just linking; it's the creation of a derivative work of a GPLed > work. Frankly, I don't see how you can argue that cdrecord is not a > derivative work of the GPLed part of cdrecord and the build system. I disagree. The final executable is no more a derivative of the build system than it is of the compiler. After all, no parts of the makefiles end up inside the executable. >> We have the option of splitting the source package into code (GPLed) >> and meta-code (CDDL). Would that be suitable for main? > > I don't see how this would get around the GPL incompatibility issues, > as the build system is only useful for cdrecord. Not that I'd go so far as to call it useful, but JS does use the same makefile templates for other software. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Don Armstrong <[EMAIL PROTECTED]> writes: > On Sun, 19 Mar 2006, Måns Rullgård wrote: >> Don Armstrong <[EMAIL PROTECTED]> writes: >> > Not just linking; it's the creation of a derivative work of a >> > GPLed work. Frankly, I don't see how you can argue that cdrecord >> > is not a derivative work of the GPLed part of cdrecord and the >> > build system. >> >> I disagree. The final executable is no more a derivative of the >> build system than it is of the compiler. After all, no parts of the >> makefiles end up inside the executable. > > The makefiles direct the assembly of the executable, just like the > source code directs the operation of the compiler. [And indeed, some > question as to whether some part of the executable is a dirived work > of the compiler exists as well; luckily there are exceptions in the > licences of gcc to deal with this case.] > > There are multiple different ways that the compiler and assembler can > be directed by the makefile; quite a large number of them will produce > an operational executable. Given only the source files, writing a makefile that will produce a working executable is fairly simple. I see makefiles as more of a convenience than a necessity to build a program. You might as well argue that every program in Debian is a derivative of apt and the package descriptions, since the former uses rules in the latter to decide what to install. Again, I say this is just a convenience that saves users the time to find out and install the dependencies manually. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Sam Morris <[EMAIL PROTECTED]> writes:
> Måns Rullgård wrote:
>> Flaming aside, this is a non-issue. The source for cdrecord contains
>> invariant sections (those obnoxious "warnings" about using device
>> names), so it's certainly not DFSG-free. Just use dvdrtools instead.
>
> Oh? How is it in main then?
A package being in main doesn't automatically mean that it should be
there. Packages have been removed from main in the past.
These are the bits I'm referring to, from cdrecorc.c (sorry for the
long lines, but that's how it's written):
---BEGIN QUOTE---
/*
* Begin restricted code for quality assurance.
*
* Warning: you are not allowed to modify or to remove the
* Copyright and version printing code below!
* See also GPL § 2 subclause c)
*
* If you modify cdrecord you need to include additional version
* printing code that:
*
* - Clearly states that the current version is an
* inofficial (modified) version and thus may have bugs
* that are not present in the original.
*
* - Print your support e-mail address and tell people that
* you will do complete support for this version of
* cdrecord.
*
* Or clearly state that there is absolutely no support
* for the modified version you did create.
*
* - Tell the users not to ask the original author for
* help.
*
* This limitation definitely also applies when you use any other
* cdrecord release together with libscg-0.6 or later, or when you
* use any amount of code from cdrecord-1.11a17 or later.
* In fact, it applies to any version of cdrecord, see also
* GPL Preamble, subsection 6.
*
* I am sorry for the inconvenience but I am forced to do this because
* some people create inofficial branches. These branches create
* problems but the initiators do not give support and thus cause the
* development of the official cdrecord versions to slow down because
* I am loaded with unneeded work.
*
* Please note that this is a memorandum on how I interpret the GPL.
* If you use/modify/redistribute cdrecord, you need to accept it
* this way.
*
*
* The above statement is void if there has been neither a new version
* of cdrecord nor a new version of star from the original author
* within more then a year.
*/
/*
* Ugly, but Linux incude files violate POSIX and #define printf
* so we cannot include the #ifdef inside the printf() arg list.
*/
# define PRODVD_TITLE""
#ifdef CLONE_WRITE
# define CLONE_TITLE "-Clone"
#else
# define CLONE_TITLE ""
#endif
if ((flags & F_MSINFO) == 0 || lverbose || flags & F_VERSION) {
printf("Cdrecord%s%s %s (%s-%s-%s) Copyright (C) 1995-2004 Jörg
Schilling\n",
PRODVD_TITLE,
CLONE_TITLE,
cdr_version,
HOST_CPU,
HOST_VENDOR, HOST_OS);
#if defined(SOURCE_MODIFIED) || !defined(IS_SCHILY_XCONFIG)
#define INSERT_YOUR_EMAIL_ADDRESS_HERE
#define NO_SUPPORT 0
printf("NOTE: this version of cdrecord is an inofficial
(modified) release of cdrecord\n");
printf(" and thus may have bugs that are not present in
the original version.\n");
#if NO_SUPPORT
printf(" The author of the modifications decided not to
provide a support e-mail\n");
printf(" address so there is absolutely no support for
this version.\n");
#else
printf(" Please send bug reports and support requests to
<%s>.\n", INSERT_YOUR_EMAIL_ADDRESS_HERE);
#endif
printf(" The original author should not be bothered with
problems of this version.\n");
printf("\n");
#endif
#if !defined(IS_SCHILY_XCONFIG)
printf("\nWarning: This version of cdrecord has not been
configured via the standard\n");
printf("autoconfiguration method of the Schily makefile system.
There is a high risk\n");
printf("that the code is not configured correctly and for this
reason will not behave\n");
printf("as expected.\n&q
Re: cdrtools - GPL code with CDDL build system
"Andrew Donnellan" <[EMAIL PROTECTED]> writes: > Why is he quoting the GPL *preamble*? Preambles aren't supposed to > have legal effect, are they? I guess JS is as thoroughly confused about legal matters as he is about device naming. > (Interesting looking at the case of the preamble question in > Australia's 1999 constitutional referendum - the 'no' case says that > the preamble could have had legal effect.) Could you elaborate on this, or provide some pointers? -- Måns Rullgård [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Don Armstrong <[EMAIL PROTECTED]> writes: > On Sun, 19 Mar 2006, Måns Rullgård wrote: >> Given only the source files, writing a makefile that will produce a >> working executable is fairly simple. I see makefiles as more of a >> convenience than a necessity to build a program. > > You could extend this argument to any segment of sourcecode in the > program. Not at all. Every piece of source code gets compiled into some machine code (except parts that get optimized out), and so is part of the work, both before and after compilation. Exactly how the source code is transformed into machine code is irrelevant. You might use compiler A, I might use compiler B, and someone else might prefer to do it all by hand. In each case, the executable is a transformed version of the source code. In neither case does any part of a makefile (or equivalent) get included in the output. A work can't be derived from another work without including some piece of it (ignoring for the moment reuse of literary characters without any verbatim copying of text taking place). In many cases a program could be compiled with a command like find . -name '*.c' | xargs gcc If the program is large, gcc will probably run out of memory, but that makes no difference in principle. The makefile describes how the work can be done in smaller steps, nothing else. Is a printed book a derivative work of the manual for the printing press? > Since the output that you get from the compiler is dependent > on the way in which the compiler was called, just like the way in > which the source code was written determines the object code you get > out, this argument isn't terribly persuasive. The output depends on which compiler is used, and on which options were given to that compiler. This still does not change the fact that the output is a mechanical transformation of the input, and is not a derivative of anything of which the source was not already. You can certainly not be arguing that the source code is derived from the makefiles. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools - GPL code with CDDL build system
Don Armstrong <[EMAIL PROTECTED]> writes: > On Sun, 19 Mar 2006, Måns Rullgård wrote: >> A work can't be derived from another work without including some >> piece of it > > This is actually not the case; including output of a work (or > generated by a work) in another work can make that work a derivative > work of the first work. That could only possibly make the executable a derivative of the compiler. The makefile doesn't output anything in its own right. It does cause make to print a few lines to the console when it is run, but those messages are not included in the executable. Lot's of (mainly single-file) programs don't come with a makefile at all, only a README file telling you to compile the C file and naming the libraries it needs. Is the compiled program a derivative of this README file? >> Is a printed book a derivative work of the manual for the printing >> press? > > This is the wrong analogy. The right analogy is: Is a printed book a > derivative work of the typeface used in the printing press? I guess next you'll be saying that the compiled program is a derivative of the font the author used when he wrote the makefile. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
