** Raul Miller :: > On 9/9/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> > wrote: > > Raul, 90% of your questions (below) are rethoric. > > Given the context, I haven't a clue what that means. This could > be anywhere from begging the question to a desire to focus on some > useful 10% of my questions.
No, 90% of the questions are "is this eligible for copyright protection?". > > > 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. > > This is even more confusing. "assume every work eligible for > copyright protection...are not eligible for copyright protection"? > In principle, I ought to be able to figure out what you're saying > by looking at the grammar of your sentences, but in this case I > can't. I thought that one was simple: 1. please assume every work mentioned in the argument (unless otherwise noted) eligible for copyright protection; 2. please assume we are talking (unless otherwise noted) about dynamic linking; and 3. please assume that those bits that end up in a compiled work by way of being in .h file or any other similar thing are not eligible for copyright protection (this is an explicit exception to #1 above). > > One of the confusing things is where you say "by way of being in a > .h file (for instance)". As an instance of what? Yes. one nice example are text of non-trivial inlined functions. > > If I start by assuming the conclusion you want to draw is correct, > I can work backwords and fit the pieces together so they make > sense, but that's not the same thing as these pieces being a valid > argument that your conclusion is correct. > > > All the assumptions above create a simplified model, that we can > > refine later -- if we can come to any conclusion at all. > > In other words, let's just start with the conclusion we want to > draw? > > Oh well, on to the questions: > > > ** 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. > > I'm trying to find an interpretation of this sentence that has > some meaning and I'm clueless. > > As a general rule, all derivative works are produced by humans. > > As a general rule, when we talk about transformations we're > talking about processes -- something outside the scope of > copyright law (thought not outside the realm of human activity). Why is it outside the scope of copyright law? The copyright law itself defined a derivation as the result of said processes. 17USC enumerates some processes, and Brazilian Author's Rights acts defines them. > > What I'm not getting is how the presence or absence of some > process which is outside the scope of copyright law has any > bearing on the question of whether one work is a derivative work > of some other work. The processes are not outside the scope of copyright law. > > [For now, I'm skipping sentences which seem to depend on this > "intellectually novel transformation" sentence for their meaning.] Intellectualy novel transformation is the text of the code law that defines "derivative work" in Brasil. I suspect -- but I don't have the time right now to confirm -- that this text (which is already in one of my recent posts) is directly copied from the Geneva convention text. IOW, it's the letter of the law. > > > > 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. > > >From my point of view, the technical features of a system (what > gets linked against what, and what the system does, etc.) are not > the deciding factors. They're just evidence about what the nature > of the creative work under discussion. Evidence, in and of > itself, does not decide the case. Evidence just paints a part of > the picture. I fail to see the correlation of the paragraph above and the argument above it. > > In other words, B and C could actually be the same program where B > is an independent work, where B is a derivative of O, or where B > is a derivative of M or where B is a derivative of both O and M. > Now, obviously, other facts about these cases would have to be > different for each of these possibilities. And there's plenty of > room to argue about exactly where the boundaries between these > cases would be. And, there's potential to argue about what > licenses on these works would mean in each of these different > cases. > > > > 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. > > I don't think I've been enlightened. > > Unless your point was that I should assume the conclusion so that > the argument makes sense. > > > > > 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. > > I'm interested in what you mean by "relevant" here. Do you mean > relevant to Debian's treatment of some software package? If so, > which software package would that be? Yes. The whole argument is: Can Debian distribute program X, dynlinking to libcurl, dynlinking to openssl? Or MUST Debian make its version of program X dynlink to libcurl + gnutls? Even if the latter has worse performance than the first AND openssl is in the distribution anyway? > > > > 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? > > There are elements of glibc which "don't have much creativity", > and thus have only very thin copyright protections. As almost no > programs use glibc as a whole (most programs incorporate only a > small fraction of glibc), this can become relevant in some > examples. Of course, in other cases it's not at all relevant. The relevance here is: do you consider MD5() and SHA1() non-protectable? If you do, your argument leads to: Debian can distribute program X dynlinking to libcurl dynlinking to openssl without any preocupation. > > But, even if glibc is a heavily protected work in the context of > some example, that doesn't mean that the program in that example > would have to be a protected work. > > > 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? > > And the answer depends on the specifics of the programs in > question. Yes, but we should decide on a general (simplified rule) first, and then see if the rule is or not applicable to each case. > > There is no legally valid answer to that question which applies to > all cases. > > > > 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. > > You have not said those particular words. > > You have presented examples whose reasoning I would characterize > this way. > I fail to see how. And you did not explain how, either. My (only) argument is: As a *general* rule, given a program P and a library L, both eligible for copyright protection, unless P has a *creative* reason for being a derivative work of L (*), the sole fact that P dynlinks with L does NOT make P a derivative work of L (**) and, because of all arguments already presented here about the text of the GPL, the fact that one of them (either P or L) is licensed under the GPL does NOT affect the licensing of the other. (*) ie, P is the result of an intellectually-novel transformation on L, or P is the result of any of the processes that 17USC enumerates as making a derivative work of L. (**) Andrew Suffield made the case that this would be true, ie, if my program uses MD5() and SHA1() then it's a derivative work of openssl. -- HTH, Massa
