On 7/27/05, Jeff Licquia <[EMAIL PROTECTED]> wrote: > On Wed, 2005-07-27 at 10:05 -0300, Humberto Massa Guimarães wrote: > > First of all, Debian GNU/Linux is *NOT* a derivative work of > > OpenSSL, GStreamer, nor any of its plugins. A derivative work has a > > definition in the statute (in the US case, 17USC). > > Hmm. I suppose this is part and parcel of the move in the USA to > copyright "compilations" or "databases"? I suppose I had never thought > of it that way.
No, the "derivative work" category (which had a parallel, but no special name or significance, in prior copyright statutes) was created in the 1976 Copyright Act, essentially for the sake of the exceptions to license termination in Sections 203 and 304. It has no special significance under law other than in cases involving these sections, and using it in the text of a license is eccentric at best. Prior US statute and jurisprudence treated translations, adaptations, and so forth as just a subset of works that were both copyrightable as originals and infringing on the older work in the absence of license. "Compilations" and "databases" have no relation to derivative works in statute or in history. For a history of the rules about copyright in "compilations" whose component parts are uncopyrightable facts were established, see the discussion in Feist v. Rural Telephone ( http://www.law.cornell.edu/copyright/cases/499_US_340.htm ); note that "compilations" were copyrightable under both the 1909 and 1976 Acts, and that decisions like Harper & Row (1985) and Feist (1991) _narrowed_ the judicial interpretation about what made them copyrightable, discarding "sweat of the brow" and focusing on what originality they may contain. I'm not aware of any contemporary "move to copyright" such things, i. e., to restore the "sweat of the brow" doctrine; there is some effort to harmonize the treatment of compilations among Berne Convention nations and to codify the Feist standard of "thin" protection for factual compilations. In short, the GPL drafters could also have attempted to encumber _collective_ works containing a GPL work, which would affect Debian CDs (works of authorship by virtue of the creative expression in the selection and arrangement of their components), but the actual language of the GPL doesn't, when appropriate standards of contract construction are applied. The GPL probably couldn't legally block the _use_ of a GPL component from components under different licenses no matter how it was written, given precedents such as Lotus v. Borland and Lexmark v. Static Control. The copyright monopoly is granted on creative expression, not on function, and is not meant to be leveraged to block competitive interoperability. The League for Programming Freedom's amicus brief in Lotus v. Borland at http://web.archive.org/web/lpf.ai.mit.edu/Copyright/lpf-sc-amicus.html is moderately eloquent on the topic. Maybe you can find a way for Eben Moglen's own words not to damn his position on GPL "violation" through linking, but I can't. > > Yes. There is no derivative work status on the program that uses a > > library. I and M.K.Edwards, in the last 3 months or so, have brought > > a lot of arguments and case law to this extent to d-l, and my own > > and humble conclusion is that: especially in the case of dynamic > > linking (and more so in the case of dlopen()ing), the distribution > > by debian of both a program A and a linking-to-A B.so is subject > > only to the *separate* compliance to the terms of both A and B.so, > > independently of any terms applied only to derivative works of A or > > of B.so. > > Mr. Edwards, elsewhere, refers to the GFingerPoken thread, which I had > followed. There may be other threads I did not follow, and I will look > for them. The message to which I pointed you has a link back into the main fray (threads with titles like "Urgently need GPL compatible libsnmp5-dev replacement", "GPL and linking", and "What makes software copyrightable anyway?"). I've put together a 50-some page monograph that contains 'most everything I know about the subject (and about the process of construing the GPL, apart from the warranty disclaimer, about which I've learned more since); copies available for private circulation upon request. > I confess to not seeing how the manner of linking makes a difference > from a copyright point of view. Static linking creates a derived work, > in that the resulting binary contains the library, much as how a motion > picture film contains its soundtrack. To me, splitting the soundtrack > off a movie, and creating a machine to recombine them afterwards, does > not cease to make the movie an infringement on the soundtrack's > copyright, which is equivalent to the dynamic linking process. Is such > a scheme really effective from a legal standpoint in avoiding copyright > liability? The manner of linking doesn't make a difference in principle, and the statically linked case is no more a derived work than the dynamically linked case. Dynamic linking makes it abundantly clear that neither the source code nor the binary form of the program contains any more of the original's creative expression than is dictated by interoperability requirements, and may add an additional defense under 17 USC 117, but the only effect is to make it less likely that a district judge will rule incorrectly (IMHO, IANAL, TINLA). The reason that your analogy is incorrect is that the soundtrack is an essential part of the creative expression in the film. The relationship between program and library is not one of creative expression, it is one of engineering use. Net-SNMP, for instance, employs the OpenSSL programming interface in order to incorporate not the expressive content of OpenSSL but its functionality. That's not the relationship between a film and its soundtrack, it's the relationship between a film and the sprockets in the projector. > > I do not have enough time right now to answer properly (ie, with the > > links to the discussions, examples, and caselaw that I, amongst > > others, presented here on d-l), but I trust that you can find them > > if you are interested. > > > > As I said two paragraphs above, I consider that I presented all my > > arguments in this direction, and (to me, at least) I consider my > > point proven. > > That's great. Other people with legal expertese (the FSF legal team, > for example) have done the same, and have come to entirely different > conclusions. Others with legal expertese commented, as I recall, on the > KDE/Qt controversy back in the day, too, and I don't recall seeing any > argument against it that wasn't based on emotion or wishful thinking > ("the KDE and Qt people are good people, they wouldn't sue anyone"). The FSF legal team are very much interested parties, and are on record as stating that the GPL is more useful as a tool for subverting the dominant paradigm of copyright than as an actual legal document. They have never, to my knowledge, cited any legal precedent more recent than the 1710 Statute of Anne (whose content they misrepresent) in support of the contentions in the FSF FAQ. I am no lawyer, but I will cheerfully walk you through the statutory, historical, and judicial support for my perspective in mind-numbing detail. Judge for yourself. > I am not a lawyer, and thus am forced to accept arguments from authority > (and regurgitate them when necessary, as was the case in this thread). > It seems clear in my interaction with you that my understanding of the > copyright process is hopelessly inadequate for evaluating these > arguments; there always seems to be some exception to the general rule > that people can throw at any position people can take. You are not forced to accept arguments from authority. There's a primary literature (appellate court decisions) that you can check for yourself (through FindLaw, for instance). You can verify that an argument's citations to the primary literature are honest and accurate representations of the thrust of the case. You can easily find similar cases that aren't cited in the argument, and see if they lead to similar conclusions, and verify which cases are frequently cited in later opinions. None of this takes a law degree, only some research skills and a passing familiarity with the legal lingo. > And, it seems to me, that in the authority face-off, you lose. I've > never heard of you outside this forum. Mr. Edwards has already admitted > to a lack of formal legal training. The GPL, on the other hand, has a > law professor and a team of lawyers behind it, as do other groups > promoting free software and open source, and their efforts at enforcing > their view of the world have been quite successful to date. Are you > seriously telling me that these people don't know what they're talking > about regarding the law, and that you do? On what basis can you make > such an extraordinary claim? On the basis of hundreds of citations to the actual law of the land. Outside the rather insular free-software community, and the journalists for whom it makes good copy, few people believe that the FSF has the law straight. There are a few lawyers who maintain diplomatic relations with the FSF for their own purposes, which is fine; but there really needn't be much of a relationship between the persuasiveness of GPL-related propaganda and its foundation in law. Note that, on the only occasion that it has yet been tested in court (Progress Software v. MySQL), the GPL was evaluated according to garden-variety contract law standards, the "derivative work" question was postponed to a trial stage that never happened, and the "GPL terminates automatically on violation" arguments raised by Eben Moglen dismissed out of hand. > Now, the standard answer when confronted with such a quandary is "go > hire your own lawyer". Which is a great idea, if you have hundreds of > dollars to throw away. If I wanted to throw money at legal crap, I > would have stayed in the Windows world. > > So, you will forgive me, I hope, for continued skepticism. You may be > right, and the entire free software community may be wrong, about the > way things work. But I'm betting not. Not by any means the entire free software community; read what, for instance, Linus Torvalds has to say on the topic. Bet as you like. :-) Cheers, - Michael (IANAL, TINLA)
