Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
Note: I am replying only to -legal for now, someone with more
firm knowledge than either me or Mr. Edwards should post a
proper rebuttal to -devel so Mr. Edwards' arguments will not
look undisputed to the broad masses of Debian Developers.
On Thu, May 05, 2005 at 07:26:00AM -0700, Michael K. Edwards wrote:
> 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.
>
Well, I have certainly seen no signs that the view expressed in
the GPL FAQ does not have consensus on the debian-legal list.
It may be that Mr. Edwards has valid arguments undermining the
GPL under US law (but see below), but that is an entirely
different thing than the consensus of the debian-legal mailing
list.
> 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.
>
Note that this I am initially only addressing the arguments and
references given by Mr. Edwards, I am not adding additional
legal references myself. However I encourage anyone trying to
answer the questions I raise to provide such concrete references
supporting their answers to any questions of law raised by the
arguments of Mr. Edwards, myself or others.
> > 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).
>
The way I have always understood these cases is that copyright
does not restrict use of an API in its role as 'methods of
operation' when someone does not actually copy the work that
defines the API (such as a concrete header file), but copy only
the 'method of operation' itself (In Borland-Lotus, Borland was
sued for creating a plug-replaceable reimplementation of an API,
like lesstif compared to motif).
> 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.
>
At what point in this analysis does the copy of (parts of) any
one component included in the linked binary cease to be a "copy
or derivative work" of the original component? And at what
point does activities related to the combined bundle (creative
or not) cease to be restricted by the copyrights and license
terms of the individual components?
> 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.
>
I still don't see how this prevents at least portions of a
collection (with or without an applicable collection copyright)
from being a copyrightable derived work or copyright protected
copy of an included component. Book example: A bundle of
Hamlet+Cliff's notes is not excused from complying with any
copyright or licensing restrictions on Cliff's Notes, otherwise
any warez site out there would be legal because it is a
collection of unrelated works with different copyright holders.
> 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?
>
But is a linked program "loosely bound" relative to the library
it is linked against? (Even if the program and library appear
inside a much larger loosely bound collection. Think a magazine
appearing within a large loosely bound collection of "all US
magazines published in June 2004").
> 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.
>
This tactic (I think) is based on a two way attack.
1. Ask defendant if he accepts the terms of the GPL. If he says
no he has no license, proceed to preliminary injunction for
copying without a license.
2. Claim that defendant violated the contract (to be prosecuted
separately), then invoke GPL4 (automatic termination), then
state that there has not been any license in place since the day
of the first violation, then proceed to preliminary injunction.
(SCO vs. IBM may become a major precedent here, as SCO started
the affair by invoking such a clause and demand).
> 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.
>
Look at that "These requirements apply..." paragraph again, it
only disclaims its reach when those "works not based on the
program" are distributed on their own.
This leaves two potential loopholes for linkers: does the term
"a whole which is a work based on the Program" also cover "a
whole which is partially a work based on the Program"? If it
does then that paragraph still covers a whole in which a part is
the Program or a Derivative work of the Program. If it does not
and a linked program is not a "work based on the Program" in a
legal sense, then that "These requirements" paragraph does
indeed disclaim any force and effect against linked programs.
The other potential loophole is if the "mere aggregation"
paragraph further down in clause 2 is interpreted to cover an
aggregation of the Program and an independent work linked to the
Program (or derivative works of either). I believe the "mere" in
"mere aggregation" reasonably excludes that interpretation.
The doctrine of "interpretation of contract terms against the
drafter", becomes rather "interesting" for the GPL in the
following scenarios:
What happens if the contract was drafted by a third party (FSF),
where the contracting parties are a non-FSF copyright holder and
a non-FSF licensee?
What happens in the (not uncommon these days) case where the
licensor is a non-FSF copyright holder, but the licensee is the
FSF itself? Does the doctrine imply that the GPL would have a
different meaning in that scenario (example: copyright holder is
Linus, user is RMS)?
In the case where the copyright holder is not associated with
either the FSF or Debian, but the licensee is an organization
(Debian) that partially grew out of the FSF, does the doctrine
imply that Debian is restricted by the ambiguities of the GPL in
such cases, thus granting Debian less permissions than other
licensees?
> >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.
And that is precisely where many people disagree. GPL is
commonly interpreted (by laymen et least) to contractually
restrict that very activity using the phrase "whole which is a
work based on the program", the word "mere" in "mere
aggregation", and just as importantly the second-to-last
paragraph of GPL clause 3.
I don't recall seeing anything that settles the interpretation
of those phrases one way or the other, and Mr. Edwards has not
given any arguments on those two points in this particular mail.
>
> 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 .)
>
This analysis depends on the conclusions disputed above.
> 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.
>
So the "district judge" (a US term not directly applicable to
Sweden) declared that the GPL was apparently enforceable, but
not enough for a pre-trial injunction at that early stage of
that trial. That same district judge then ruled on another
matter, and the issue of the GPL was not brought up again in
that case.
> 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.
>
Lost? Any citations for that? So far Mr. Edwards has only
stated that in the MySQL-Progress case, there was no preliminary
injunction, not that this lack of injunction was due to anything
other than being "not urgent" combined with a Scandinavian
tendency not to grant preliminary injunctions lightly.
> > 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:
>
It is certainly a poor rule to determine "derivative work in and
of itself". A complete verbatim or slightly modified copy of
the original can certainly function without the original.
It may or may not be a good rule of thumb to determine if two
works are so closely related as to preclude combined
distribution of both from being "mere aggregation", though I
don't consider it a good rule for that either.
> ] 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.
>
Nor does it free them. It simply does not consider the issue.
> 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.
>
It is thus important to notice that most of the places where the
GPL might have been used for license lock-in on a grand scale
carefully abstain from doing that: gcc, flex, bison and the GPL
parts of libc grant linking exceptions. perl grants execution
and linking exceptions. The Linux kernel grants API and running
program exceptions in the form of Linus notes in the kernel
COPYING file. There are probably more examples.
> 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.
>
I have not seen the FSF or a debian-legal consensus claiming
that copyleft is a good for vendor lock-in or trademark
enforcement. I see nothing in Mr. Edwards' argument rebutting
the claim that copyleft can restrict the use of a program
through its documented interface by another program if both are
distributed together.
> 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.
>
Does this imply that Mr. Edwards is not willing to listen to
arguments?
> Cheers,
> - Michael
>
Cheers
- Jakob
Disclaimers: IANAL, TINLA, IANADD, plus the one in my sig
--
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.
Reply to: