GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
On 5/4/05, Andrew Suffield <asuffield@debian.org> 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
Reply to: