On 9/12/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> wrote: > > > 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;
Ok. This leaves open the question of how thin that protection would be (which in turn depends on the specific work(s) in question). But it does eliminate some scenarios. > 2. please assume we are talking (unless otherwise noted) about > dynamic linking; and Dynamic linking of what, with what, in what fashion? > 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). So basically, any bits which are in the executable which would not be there if all .h files were removed are not eligible for copyright protection? That's tantamount to saying that the binary isn't copyrightable. Alternatively, you're trying to make some kind of statement about the mechanisms of the compilation process and the information density of .h files, but that kind of reasoning seems to beg the question of what's derived from what. > > 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. So, perhaps you're saying that all .h files in the cases you're interested in are trivial? > > > 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? Processes are not fixed in a material form. If they are, they cease to be processes and are instead something else (perhaps a symbolic description of some process). > 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. I don't know what you're talking about here. > > [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. I think I know what you're talking about here. Basically: stuff can be copyrighted if it's something which has concrete existence, which a person put creative effort into making. For example, a person could write something with a pen, and that could be copyrighted. Now, you could look at what a pen does -- it mechanically transfers ink onto paper, and if you focussed just on that, you wouldn't have anything copyrightable. Further, you could take this work and you could run it through a photocopier -- so running it through a photocopier does not in and of itself make a work copyrightable. But, still, the output of the photocopier might have copyright protection because of something which happened earlier -- before the photocopier was used. This same rule must apply works which use dynamic linking. The dynamic linking doesn't mean that the work is protected by copyright. It doesn't say who has the copyrights. It might be an interesting thing to discuss, but dynamic linking isn't a process which makes a work a copyrighted work or a derivative work or not a copyrighted work or not a derivative work. Dynamic linking does have something to do with the copyright status of a work, because it has something to do with the existence of the work -- and only works that exist get copyright protection. Similarly, the binding on a book has something to do with the copyright protection on that book. The binding serves to show that the book is a work as a whole. But bindings on books don't really say whether or not a work is copyrighted, derived or much of anything else. That's what kind of thing we're talking about when we talk about the transformation involved in dynamic linking. > > 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? And the answer to that question has to do with the creative work which went into those programs, starting with program X. Lacking any more specific information, I'd be inclined to answer: probably, but not necessarily. > > 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. I believe both of those two are in the public domain, but I could be wrong. I don't have time to look this up at the moment, so you should assume I'm wrong. -- Raul
