Raul, 90% of your questions (below) are rethoric. Assume every work eligible for copyright protection, for the sake of the argument, and for $DEITY's sake. AND we're talking ONLY about dynamic linking. AND, to boot, that those bits that end up in a compiled work by way of being in a .h file (for instance) are not eligible for copyright protection.
All the assumptions above create a simplified model, that we can refine later -- if we can come to any conclusion at all. ** Raul Miller :: > On 09 Sep 2005 17:52:00 +0200, Claus Färber <[EMAIL PROTECTED]> > wrote: > > 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. > > (Question: is B a derivative of M? For that matter is A a > derivative of M? Is B a derivative of M? Is A a derivative of M? -- those are the million-dollar questions. I don't think so, because there is no intellectually-novel transformation of M that produces A or B. The GPL text would think it is -- at least for its own "a work based on the Program" definition of a derivative work IFF we were talking about static linking, which we're not. AT LEAST NOT INTRINSECALLY (sorry for the caps, but this is important -- there *is* the possibility of A or B being derivative works of M, but for this to be determined the criteria of abstraction, filtration, comparison would have to be fullfilled -- for the sake of our simplification, we assume NOT: like a program that uses SHA1() and MD5() is NOT a derivative work of OpenSSL and a program that uses printf() is NOT a derivative work of glibc) > Is A+M a work eligible for copyright protection? Is B+M a work > eligible for copyright protection?) > > > 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. > > (Question: is C a derivative of O? Is C+O a work eligible See above. > for copyright protection?) > > > 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. > > (M can be fully compatible with O without B being identical to C. > And I've some other questions about the nature of B and C -- see > above.) Imagine that B and C are actually the same program, and you'll see the argument. > > > So one of the assumptions made above is wrong. The only > > assumption that is not obviously right is: "Debian can't > > distribute C". > > I can see other things which rather obviously could be wrong. But > there's too few details here to really say for sure. Hope I enlightened you. > > > 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. > > One of the issues here is that in the typical case the advertising > clause isn't enforced, nor is it enforceable. So, in the typical > case, it isn't a restriction on redistribution, and can't be a > problem with the GPL. Not relevant. Suppose advertising clause enforceable and actively enforced. > > Further, in the cases where it could be an issue, it's likely a > trademark issue rather than a copyright issue, so it's still not a > restriction on redistribution. > > Unless... well, we probably could cook up a hypothetical case > where this advertising clause is a copyright problem. But your > above presentation has enough problems even without this kind of > hypothesis. Please, back to the subject, so we can construct a coherent thinking framework... > > Put differently, what you're probably arguing is that there are > programs (and libraries) which don't have much creativity in them, > and so aren't eligible for more than an absolute minimum of > protection. But this kind of argument is rather specific to those > kinds of programs and those kinds of libraries. > No! Is glibc below your line of "don't have much creativity"? or OpenSSL? It's not below my line. The problem /in/ /casu/ is: can a GPLd program that dynamic links with a GPL-imcompatible-licensed library be distributed at all? Especially if there is another, fully compatible, GPLd, library that is distributed in the same set as the program and the library? > You might even argue that most programs (or libraries, or exported > elements of libraries, or code bases, or whatever) are lacking in > creativity, but this argument can never apply to all > programs/libraries. I never said any of this, nor did Claus. -- HTH, Massa
