On 5/4/05, Andrew Suffield <[EMAIL PROTECTED]> wrote: > [This part of the thread belongs on -legal]
Sorry to spam debian-devel -- and with a long message containing long paragraphs too, horrors! -- in replying to this. But that's where this discussion is actually happening now, and I'm afraid I can't agree with Andrew's implication that this issue is settled on debian-legal in favor of the FSF FAQ's interpretation. This isn't about license text, this is about GPL FUD and Debian's maintainers and other contributors, and debian-devel as a whole needs to hear it once in a while. I argue largely in the context of US law because it's been convenient for me to research, but I welcome counter-arguments from other legal systems -- with concrete references. > On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote: > > [Paul TBBle Hampson] > > > This of course assumes the phrase "derived work" is legalese for > > > "code dependancy" or something. I'm sure the GPL actually defines > > > what _they_ mean by it... > The GPL simply defers to copyright law to define "derivative work". Actually, it tries to define "work based on the Program" in terms of "derivative work under copyright law", and then incorrectly paraphrases that definition. Under contract law (in most US jurisdictions at least, IANAL, etc.) the recipient is entitled to have this ambiguity construed against the drafter. More below. > > I might add that > > claiming a program that uses a library's published API is a "derived > > work" is a bit shaky from the get-go. If you actually cut and paste > > code from the library into your program, it's a lot more clear-cut. > > We talk about APIs on forums like -legal to save time, because > everybody (supposedly) knows what we're talking about there. They > aren't directly relevant, it's just that certain aspects of program > design will normally have certain legal implications because that's > how those things are normally implemented. I think Peter has it right, and I'd like to know what grounds there may be to demur. See my recent posts to debian-legal archives for US case law on the matter, which I (IANAL) would summarize as "published APIs are not copyrightable in their role as 'methods of operation' as distinct from their role as creative expression". It's kind of an odd stance for the law to have arrived at -- a difference of usage changes not just whether an act of copying is an infringement but whether the copied material is copyrightable at all. But it makes sense in the context of the prescribed sequence of legal analysis, in which recognizing a protected use "too late" in the sequence leaves the copier open to lawsuits de novo for subsequent acts of copying the same material. The last time I know of that the US Supreme Court looked at the issue -- an appeal from Lotus Development Corporation v. Borland International, Inc.,49 F.3d 807 (1995) -- they deadlocked 4-4 in one justice's absence. The court transcript is fascinating. The latest and greatest analysis at circuit court level appears to be Lexmark v. Static Control (2004). Yes, the US is not the world. Other legal systems are perfectly within their rights to arrive at different conclusions, and the Berne Convention is far from explicit on the matter. But what actual grounds are there for a belief that some particular country's legal system would rule that the arm's-length use of a published API creates a derivative work? Chapter and verse, folks; even if precedents are not law in your legal system, they're a lot more reliable than reasoning outside a courtroom with no judge in sight. > Changing static linking to dynamic, or replacing a linker call with a > dlopen() call, *always* has precisely *zero* effect on whether > something is a derivative work or not. A work is created derivative, > or not, at the time of inception. For source code, this is the time > when the code is written. The way in which it is compiled is > irrelevant. For a binary, this is the time when the binary is built > and linked. A statically linked binary is a derivative work of > everything it links because it contains verbatim copies of those > things. Every binary, static, dynamic, or other, is a derivative of > everything that any part of its source was derived from. I do not think that the binary part of this analysis is correct in any country that implements the Berne Convention. My rebuttal is long enough without the case law references, but you can find them all in the debian-legal archives. Whether statically linked or provided as multiple dynamically linked files, a program composed of separately identifiable independent works of authorship is a "collection" (in some countries' implementation, "compilation") as defined in Article 2 Section 5. Derivative works are defined in Article 2 Section 3 to be "[t]ranslations, adaptations, arrangements of music and other alterations of a literary or artistic work". These exist as categories of copyrightable works for completely separate reasons -- derivative works so that both original author and translator/adapter have economic rights in the derived work (and original author can authorize publication with losing the right to veto adaptations), and collections so that the creative effort that goes into selecting and arranging an anthology can't be ripped off by another publisher. US case law, at least, has consistently regarded binaries as mechanical transformations of the original work for copyright purposes, not derivative works, and courts have rejected arguments that assume the contrary (such as claims that a binary can't be registered for copyright enforcement or that registration doesn't cover source code disassembled from it, or that authorization to make copies of _published_ material doesn't extend to authorization to disassemble for reverse engineering purposes). A mechanical transformation by definition does not create a derivative work, it creates a copy of the original. Cases cited on debian-legal as contradictions of this statement have turned out not to be. Depending on the level of creativity that goes into the "selection and arrangement", a collection may or may not be eligible for copyright protection (over and above the existing copyright holders' rights in the individual works). The combination of Application X, which calls Library Y's API, and Library Y is not copyrightable because it's trivially obvious; so even if you want to read "derivative works" to also include "copyrightable collections", linking (static or dynamic) doesn't infringe copyright in any way that the separate components don't, either on a direct or a contributory basis. Debian as a whole is certainly a copyrightable collection. But with regard to collections at distro level, a distributor can package things arbitrarily once they are published (50% off Hamlet if you also buy the Cliff's Notes, shrink-wrapped together; or even a copyrightable collection, such as Book-of-the-Month Club's 2004 Selections). This is a matter of common sense and actual practice, and there are some indirect precedents from litigation about gray-market parallel imports (I don't have case law handy). I believe that exemption for loosely bound "collections" (as opposed to magazines or critical editions) is likely to cover bundling electronic goods on common media by any publisher with blanket authorization to copy. Has anyone any shred of precedent to the contrary? This language lawyering matters a little bit because the GPL pretends not to be a contract, and hence tries to use a strict copyright law vocabulary to define what is and is not permitted. Silly really, since a contract is the only means of conveying a copyright license under US law or for that matter any other legal system that has come up in discussion on debian-legal. But there's a strategy behind that pretense -- if you can make people believe that an alleged GPL breach can be prosecuted directly under copyright law, then you can wave the "preliminary injunction" club at them and get them to roll over without risking court proceedings. The copyright law standard (under US federal case law) for preliminary injunction is very generous to the copyright holder, in that there is an automatic presumption of irreparable harm irrespective of whether any economic harm to the copyright holder can be demonstrated. And a preliminary injunction usually settles the matter, since it is usually crippling to be enjoined from distribution pending trial. Let's ignore the "non-contract license" pretense, as judges have ignored it without comment in both cases I can find where the GPL has come up. Authorization to publish can be arbitrarily limited by any contract provision enforceable in the relevant venue (e. g., "You may only publish paperback editions no larger that 10x15 cm", and in some jurisdictions "If there is no 'term and termination' clause in this contract, it is revocable at will"). So it is at least conceivable that an offer of contract could gerrymander a grant of license to copy so as to yank it away from wicked linkers. But the GPL appeals to the legal definition of "derivative work" in order to define a "work based on the Program", proceeds to paraphrase that definition incorrectly, and goes out of its way to limit its scope to such works. In this construction, the paragraph in Section 2 that begins with "These requirements apply ..." disclaims any attempt to reach beyond the limits of a "work based on the Program" -- i.e., a verbatim copy or a derivative work -- and the "mere aggregation" clause is a no-op. As a matter of law in the US and other common law systems, this must be construed against the drafter, and the legal definition of "derivative work" used rather than the incorrect paraphrase. >From a larger perspective, though, it doesn't matter much anyway; you don't need a copyright license in order to write code that uses an API to a published work, and I think it is vanishingly unlikely (remember, IANAL) that a court would fault Debian or any similar publisher, on copyright or any other grounds, for combining a GPL component and a GPL-incompatible program that uses it on the same media. Not for direct infringement, not for contributory infringement, not for breach of contract either. It's slightly less unlikely if they are statically linked, just because there's a possible quibble about the construction of "work based on the Program" in the context of a contract law proceeding. Only if they are quite convincingly not separate works of authorship -- as, for instance, a library and the only program extant that uses it may not be, especially if that library is a significant fork at API level from an outside author's work -- is it likely that action on copyright grounds could bar their combination. That's the biggest reason, actually, why I object to the GFDL; documentation as tightly interlocked with GPL program internals as gcc's and emacs's are may well not be a separate work of authorship, so contributors outside the FSF may be legally unable to modify an API and then document it without violating one license or the other (or both). The not-really-separate-works argument is the only _legal_ reason I can imagine why the copyright holders on the GCC Objective C and C++ front ends knuckled under when pursued by the FSF -- although it is of course sheerest folly to court the ill will of the core implementors of the other side of a fluid API. (Distributors of binary Linux kernel modules take note, and read http://lxr.linux.no/source/Documentation/stable_api_nonsense.txt .) The closest that any court I know of has come to ruling differently is the Progress Software v. MySQL case, in which the district judge commented that MySQL "seems to have the better argument" with respect to the way that Progress combined its closed source material with MySQL's GPL code. But in that case the judge applied contract law standards to conclude that no injunction on copyright grounds was warranted even if MySQL's interpretation was correct. MySQL got a preliminary injunction on unrelated trademark grounds, largely because Progress Software was in material breach of a signed trademark agreement of undisputed validity involving large cash payments. Thereafter, they settled out of court, with MySQL and the FSF trumpeting (almost completely without basis) the validity and enforceability of the GPL. Let me say that differently: the GPL is a perfectly valid offer of contract, and has separately been evaluated as "use in commerce" and not release into the public domain by a US appeals court (a valid though not binding precedent anywhere in the US, and likely to be followed at least in any common law system). But its "viral clause" has had its day in (district) court, and lost in every respect that mattered. A defendant claiming license under the GPL is entitled to a full analysis of its conduct under the GPL, using contract law standards of acceptance, breach, remedy of breach, construction against the drafter, and balance of harms, before any attempt to use copyright law to obtain an injunction can succeed. The district judge's provisional leaning towards MySQL on the question of fact surrounding the phrase "derivative work" is irrelevant, since she explicitly declined to draw a conclusion on this question, and if she had it would have been "dicta" (unnecessary to reach the legal conclusion) and would have no value as legal precedent anyway. > A good rule of thumb for whether one piece of source code is a > derivative of another is "Will it function in a reasonable manner > without this other piece?". Thusly a telnet client is not a derivative > of the socksified tcp library you stuff in with LD_PRELOAD, but the > part which sets up ssl connections is a derivative of the ssl library > you use. This is a rule of thumb because it fails in pathological > cases; don't abuse it. > > [There are many other, more complicated cases. Consult -legal for > consideration of specific examples.] Actually, that's a very poor rule of thumb, and I know of no legal proceeding in which it has been followed. The closest that I can come is the logic used in this paragraph from Micro Star v. FormGen, which merits direct quotation: ] Micro Star further argues that the MAP files are not ] derivative works because they do not, in fact, incorporate ] any of D/N-3D's protected expression. In particular, Micro ] Star makes much of the fact that the N/I MAP files reference ] the source art library, but do not actually contain any art ] files themselves. Therefore, it claims, nothing of D/N-3D's ] is reproduced in the MAP files. In making this argument, ] Micro Star misconstrues the protected work. The work that ] Micro Star infringes is the D/N-3D story itself--a beefy ] commando type named Duke who wanders around ] post-Apocalypse Los Angeles, shooting Pig Cops with a ] gun, lobbing hand grenades, searching for medkits and ] steroids, using a jetpack to leap over obstacles, blowing ] up gas tanks, avoiding radioactive slime. A copyright ] owner holds the right to create sequels, see Trust Co. ] Bank v. MGM/UA Entertainment Co., 772 F.2d 740 ] (11th Cir. 1985), and the stories told in the N/I MAP files ] are surely sequels, telling new (though somewhat ] repetitive) tales of Duke's fabulous adventures. A book ] about Duke Nukem would infringe for the same reason, ] even if it contained no pictures. ] Footnote: We note that the N/I MAP files can only be used ] with D/N-3D. If another game could use the MAP files to tell ] the story of a mousy fellow who travels through a beige ] maze, killing vicious saltshakers with paperclips, then the ] MAP files would not incorporate the protected expression ] of D/N-3D because they would not be telling a D/N-3D story. This judge (Alex Kozinski of the 9th Circuit, whose opinions are often amusing) was clearly asking, "Will it function in a reasonable manner without this other piece?" The conclusion is of course diametrically opposite to your examples -- degree of indirection in reference is nothing, plagiarism of creative content is everything. The uniqueness of the implementation used at run-time to make programs or data do something useful is a valid criterion -- but only to the extent that the result is a classical derivative work, i. e., a "sequel" that continues the "story" of the original work. This makes Pac-Man and Tetris clones copyright violations whether or not they use code or bitmaps from the original, but doesn't touch non-trivial applications that happen to make functional use of both OpenSSL and GNU readline, whether or not there is an API-compatible workalike. Lest the discussion should be sidetracked onto "clean room" reimplementations: Note that I am not saying that any of this logic applies to unpublished trade secret source code, for which "clean room" / "Chinese wall" measures are appropriate to ensure that a competing implementation was created using a legitimately reverse engineered functional specification rather than by misappropriating trade secrets. But that has nothing to do with copyright law, or with contract law for that matter; the tort of stealing trade secrets doesn't apply to things that are published (i. e., not secret) and doesn't require that there exist any contractual relationship between accuser and defendant, although such a contract may be evidence of the defendant's access to and probable use of those secrets (hence "clean room" techniques). As long as the above rebuttal is, it's actually the 30,000 foot view. The view from geosynchronous orbit is that copyright is a limited monopoly granted to encourage authors and publishers and give them a reasonable chance of profiting from original creative works in proportion to their popularity and to the difficulty of creating a substitute using means that are considered fair. When a creative work is debased to the level of a mechanism for vendor lock-in (see Lexmark for an extreme case), it's bad public policy to honor that grant of monopoly, and sane courts rule accordingly. There is no reason to suppose that they would (or should) extend special "license lock-in" authority to the FSF. There's an appropriate legal mechanism for vendor lock-in, with higher standards (in principle) of originality, non-obviousness, and reproducibility by anyone once the (more limited) monopoly expires; it's called a patent. And there's another mechanism to discourage false labeling and free-riding on the public's trust in the quality of your work; it's called a trademark, and it comes with a duty of ongoing vigilance. It's unfortunate that the USPTO has been 0wn3d by the Fortune 1000 since about 1980, and that litigating a patent that should never have been granted costs a fortune. But if you're trying to enforce limits not on copying a program but on using it -- including on the distribution terms of other programs created to use it through its documented interface -- then copyright just isn't the right tool. And therefore, as I read it, neither is copyleft. There has been so much silliness written about this topic that no debate among a large circle will ever conclude -- probably not even if every Supreme Court in the world were to rule decisively in the same direction. But if you filter based on whether an analysis is grounded in actual law and cases in some actual jurisdiction, I think it's not hard to understand the enforceable scope of the GPL and similar license contracts. Cheers, - Michael