Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
Note, I admit that there is a lot of repetition in my arguments,
reflecting to some degree repetitions in that to which I
respond. I have tried to limit this by stating my arguments
once or twice and referring to those from other places in the
text.
On Fri, May 06, 2005 at 02:00:54AM -0700, Michael K. Edwards wrote:
> Thank you for a reasoned response, Jakob. Oh, and by the way -- just
> because I am arguing against the legal validity of the FSF FAQ's
> claims that linking to a GPL-incompatible work violates the GPL,
> doesn't mean I think Debian maintainers or debian-legal should take up
> shrugging at GPL incompatibility. In the long run I think it's a lot
> more important to be able to refactor and merge separately authored
> code bases than it is to be able to build and link them as binaries.
> I think it's tragic that attempts to club software companies with a
> fictitious ueber-GPL have contributed to the fencing off of the
> software commons.
>
> On 5/5/05, Jakob Bohm <jbj@image.dk> wrote:
> [snip]
> > Michael K. Edwards wrote:
> > > 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.
>
> Certainly several regular contributors do not buy the "GPL is not a
> contract" bit. Others have disagreed with the notion that mechanical
> combinations create derivative works. I'll let other dissenters from
> the rest of the "consensus", if any, pipe up for themselves.
OK, there may be more dissenters than I had previously noticed.
I was ticked off by the way your original message to -devel
*could* leave people not following -legal with the impression
that there was the opposite consensus, which could result in a
lot of misguided future activity which could be unlawful if you
turn out to be wrong in your conclusions.
>
> [snip]
> > > 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).
>
> They didn't hinge on anything as trivial as a header file boundary,
> nor did the classic Atari, Sega, Sony, Nintendo, etc. cases. They add
> up to, "You may copy directly any bits that you really have to in
> order to interoperate." You may not copy an entire implementation
> with creative content if you could reasonably write your own workalike
> (Atari v. Nintendo); but attempts to parlay the copyright monopoly
> into an interoperation veto (Lexmark) can justify verbatim copying of
> expressive content. You may reverse engineer (Sega v. Accolade) in
> order to avoid onerous contract terms for access to trade secret
> material, but you don't need to reverse engineer published
> (non-trade-secret) materials that you have obtained by legitimate
> means.
>
> The Supreme Court transcript in Lotus v. Borland is enlightening
> because it is clear that both API continuity (not just menu layouts,
> but portability of existing user macros) and historical bounds on the
> meaning of "method of operation" came into play. As for "copying the
> work that defines the API", if you (for instance) write an application
> that compiles against header files containing the published interface
> to GNU readline, your application winds up pretty much containing the
> bits that it has to in order to interoperate. Trying to booby-trap
> header files with string literals in order to create grounds for a
> copyright infringement claim is unlikely to be viewed any more
> sympathetically than Lexmark's stupid checksum tricks.
Do you have any references allowing copying of any non-trivial
amounts of copyrighted material *not* needed to use an API on
these grounds? Each of the references you have provided so far
only permitted necessary bits (as far as you quoted those
references).
>
> [snip]
> > > 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?
>
> Of course you have to have license to make copies. You also need
> explicit license to make derivative works, even if you have the right
> to copy and use (see S.O.S., Inc. v. Payday, Inc., 886 F.2d 1081, 1087
> (9th Cir. 1989)). The GPL authorizes the making and distribution of
> copies and of derivative works, subject to the constraint that the
> source code for the distributed work be made available. My point is
> that that constraint ends where the boundary of the "work based on the
> Program" does, which is at the boundary of the derivative work, not
> the enclosing collection. That's how I believe a court would construe
> the text of the GPL.
>
But I do not see anything in the GPL granting those licenses
*unconditionally*, and you have yet to give a clear argument why
the reach of the *conditions* for copying or creating derivative
works stops at the edge of the copy or derivative work.
> And in any case a software licensor can't prevail on a copyright
> infringement claim, in the presence of a valid and not otherwise
> materially breached license, without showing copying of material that
> is both protected expression and not covered by the license. See
> APPLE COMPUTER, INC. v. MICROSOFT CORP., 35 F.3d 1435 (9th Cir. 1994),
> especially Section II. We come back to the argument that published
> APIs are simply not protectable expression.
>
One obviously needs to claim material breach if the defendant
claims to have a license. I am certainly not claiming that
published or unpublished APIs constitute protectable expression
(though I am not admitting the opposite either), and I do not
see the logic of the GPL FAQ doing so either.
More specifically, the theory in the GPL FAQ does not depend on
the use or non-use of header files or other API definitions by
the linking work. The theory is about the inclusion of parts of
the library itself (the GPL-ed implementation code) in the
resulting linked binary.
> > > 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.
>
> Again, you're missing my point; of course the copies and/or derivative
> works require license. But no additional license is required to
> bundle them in ordinary commercial ways as long as they remain
> separately identifiable. There's a bit of an untested boundary line
> involved in the electronic analogy to anthology vs. box-o-books; but
> industry practice (which courts do notice) is to roll installers for
> X, Y, and Z onto the same CD-ROM, so you don't need a "mere
> aggregation" clause to justify that.
>
> In fact, computer makers jumble together fragments of software
> components licensed from dozens of vendors on a pre-installed system
> without anyone caring whether they can veto related or competing
> products on the same install. The exceptions are rather notorious
> (IE, Java, generally Somebody v. Microsoft), and those cases have
> hinged on anti-competition and cross-development license disagreements
> rather than "hey, you created an anthology without specific license".
>
The "mere aggregation" clause (if it is not a no-op) explicitly
excludes this scenario from being limited by the GPL. One can
thus debate the reach and meaning of the rest of the GPL without
appealing to the effect of those scenarios on the reasonability
or legality of an interpretation.
For static linking, it is much more like "a commented edition of
a book". For dynamic linking, the relationship is more
debatable, but some (not necessarily me) could claim that this
is at least as close as very tight bundling with a book of
comments to the individual chapters of the first book, but
without the (US specific) defense of fair use for criticism.
> > > 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").
>
> As I said, there isn't a 100% firm precedent that I can find, but
> courts tend to ignore technical quiddities and focus on issues of
> preserving the public benefit of encouraging competitive
> interoperation on one side vs. the suffering due to possibly unfair
> (plagiaristic) means of competition on the other. There's no legal
> reason to care whether three shared libraries are shipped on separate
> hard disks and combined in memory at run-time (or interconnected via
> Clay Pigeon Protocol) vs. statically linked into the same blob o' ELF
> bits -- unless there are specific contract terms dictating one or the
> other as a condition of license, with violation agreed to be grounds
> for termination. That's a really strict standard; see Sun v.
> Microsoft for discussion of "condition of license" vs. "contractual
> covenant".
>
Interestingly, this is the (sometimes controversial) claim of
the GPL FAQ with respect to dynamic linking! Except that the
GPL FAQ theory is that the legal insignificance of the technical
details implies that dynamic linking should be as restricted as
static linking, not that static linking should be as
unrestricted as dynamic linking.
[ Note, I have not tried to look up the transcript of that
really long and outdrawn case. I don't have a shorthand tool
for locating individual US court transcripts based solely on the
names on the participants, and I certainly have no easy way of
finding the right page within such a transcript based on so
loose a reference. ]
> [snip]
> > 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.
>
> Naturally.
>
> > 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).
>
> That's not how it works, at least under common law. The accuser would
> have to show grounds for termination -- in the absence of "termination
> at will" language (in most jurisdictions), evidence of uncured
> material breach and of harm not reparable by damages -- and the
> accused can rebut with other constructions of ambiguities of the
> contract, evidence of remedy of breach, arguments from balance of
> harms, lack of evidence supporting a claim of irreparable harm if a
> preliminary injunction is not granted, and all the usual barriers to
> grant of preliminary injunction under a contract law standard. The
> only "shortcut" is not termination of a valid license but proof that
> the scope of the license was exceeded -- and that is still subject to
> construction of the license contract against the offeror.
>
Of cause. I didn't say that getting a preliminary injunction
would be easy. I said that the *tactic* would be to *try* to
convince the judge that the GPL copyright holder would be likely
to prevail on the contract issues and asking the judge for a
preliminary injunction based on that likelihood. This would of
cause involve arguing the issues you mention. I did not state
that the tactic would ever be successful.
> > > 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.
>
> That paragraph draws two scenarios: "separate works ... when you
> distribute them as separate works", which the GPL doesn't attempt to
> touch; and those works when they are "part of a whole which is a work
> based on the Program" -- i. e., a whole which is itself a derivative
> work. Perhaps there's an ambiguity about whether there is a third,
> undiscussed, scenario in which a "whole which is a work based on the
> Program" is collected together with things that are separate works but
> are not "distributed as" separate works -- but that ambiguity is
> definitely to be construed against the offeror.
I argue no such third scenario. I argue that the paragraph
might not disclaim all attempts to reach outside the limits of a
"work based on the Program", this hinges on whether "a whole
which is a work based on the Program" covers a different scope
than "a work based on the Program".
>
> As I read it, this paragraph is there to reassure people that if they
> add their special sauce to a GPL program and then pass it along under
> the rubric of a single whole, they can still use their special sauce
> in their own closed source product. As I understand the history, RMS
> was spurred to add this clause (and perhaps to write the GPL itself)
> when a closed-source vendor tried to demand exclusive rights to any
> special sauce he might add as a condition of source access. Such a
> demand would be pretty much at the outer limits of enforceability
> anyway.
While this clause does provide such reassurance, comparison with
other licenses written at approximately the same time (like the
commercial licenses for Borlands development tools) indicates to
me that this may also be written to ensure that the clause does
not try to reach so far as to be thrown out of court wholesale.
Kind of like the way in which some warranty disclaimers make
explicit that they are not trying to disclaim that which cannot
be legally disclaimed.
>
> With or without this paragraph, there's a line beyond which it's none
> of the licensor's business what else is rolled into the same
> transaction. In the case of a product distributed under the same
> terms to all comers, that line is generally drawn at the outside of
> that product's shrink-wrap, even if there are six more layers of
> shrink-wrap around products of progressively larger scope. There is
> plenty of precedent for sub-components with different license terms
> within a tarball, so an upstream's innermost "shrink-wrap" may be as
> small as a single file (or smaller if a chunk of text remains an
> identifiably separate work of authorship embedded for a valid
> engineering reason, such as a firmware blob in a driver maintained
> with the vendor's cooperation in the main kernel tree).
>
The question is partially where that line is, partially how far
out the GPL is actually trying to reach. Your argument seems to
be (at least partially) that if the GPL cannot reach out to the
whole universe, it reaches nowhere at all.
> Look at it this way. There's an MP3 player with a big CompactFlash in
> it sold at very low margin, with the expectation of making it up on
> their cut of the bundled music download service's revenues. A
> retailer sticks it in a baggie with a Torx wrench and an dismantling
> instruction sheet, and it sells like hotcakes for the CF salvage
> value. The MP3 player vendor might have some legal means of
> retaliation, but it's unlikely to be a claim that the retailer didn't
> have license to anthologize the MP3 player's doco with the dismantling
> instructions. Nor is it contributory infringement if the instruction
> sheet says "look at Figure 3 in the player's Quick Install Guide to
> find the pressure points on your particular model".
>
How would this be if the MP3 player came with a sale condition
that the MP3 player not be resold in dismantled form? Could
this bundling then be construed as an unlawful attempt to
circumvent the sale condition? And again remember that the GPL
FAQ viewpoint is not (primarily) about the copyright on the API
definition / MP3 player's doco, but about the copyright on the
API implementation / big CF chip.
> > 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 phrase "work based on the Program" is defined in Section 0 as
> "either the Program or any derivative work under copyright law", and
> then that legal definition is incorrectly paraphrased. Under the
> legal definition, I think it is clear that only creative adaptation
> creates a derivative work, and linking X against Y doesn't qualify (as
> long as X is not derived from Y in a creative sense).
But does "a whole which is a work based on the Program" mean the
same as "a work based on the Program" (call this "YES"), or does
it also cover a whole (copyrightable as a whole or not) which
includes within itself a copyrightable portion which is truly "a
work based on the Program" (such as, by example, the Program
itself)?
And does "a work based on the Program" indeed have the limited
meaning debated elsewhere in this message?
As I wrote, if the answers to these two questions are YES, YES,
then the GPL looses its reach, and several of its permissions
(including the "mere aggregation" paragraph) become no-ops
granting permissions already granted. But if either of these
two questions are answered with a NO, then this paragraph is
disclaiming the GPL's reach in fewer cases and the other
paragraphs are no longer no-ops.
>
> > 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.
>
> "Mere aggregation" has no legal meaning as far as I can tell, and this
> whole paragraph is a no-op. I believe it was written to reassure
> people about putting GNU and UNIX on the same tape.
Actually the GPL goes out of its way to (try to) ban that
specific action.
The paragraph is an effective no-op, if the paragraph before it
already permits the same thing. Assuming for the sake of
argument that this is not the case, then the next question
becomes what actions it does permit.
If "mere aggregation" has no specific meaning prescribed by law,
it needs to be interpreted. One interpretation would be to take
it as purely English text in which case it could mean to
aggregate in the general sense of the word without doing
anything else. Another interpretation would be to take it as an
unclear subset of the actions considered aggregation by
copyright law (both statute and case law). A third
interpretation would be to ignore the word "mere" as line noise
and treat it as meaning exactly the same as "aggregation" means
under copyright law.
The first interpretation is kind of soft, but could be construed
as covering such things as the Debian CD, pre-installed hard
drive contents etc. The second and third interpretations could
both imply that a too trivial aggregate / anthology work would
not be excepted, unless the totality of copyright law also uses
the word "aggregation" to refer to non-copyrightable instances
of the same actions as those which in other instances would
result in the creation of a copyrightable aggregate work. The
third interpretation could imply that a linked program would be
excepted because it is an aggregate, while the second
interpretation could avoid that implication because it is more
then "mere" aggregation.
>
> > 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?
>
> Sorry, I misspoke; contracts are construed against the offeror, not
> against the drafter, when there's a distinction. The offeror had the
> option of proposing language as explicit as he or she chose, so
> ambiguities are as a matter of law construed against his or her
> interests. That is the case even if the offeror chose a boilerplate
> license drafted by someone else.
>
AH, that is a big difference indeed. But what happens if the
person offering the contract text is not the person offering the
goods or services being contracted? Like if someone hands out a
form contract offer that people need to sign to be considered
for an audition, or if the licensee has directly or indirectly
asked the licensor to use the GPL.
> > 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)?
>
> Courts (in the US anyway) are obligated to reach the demonstrated
> intent of the parties to a contract. Written contract terms are
> evidence of the parties' intent, and govern in the absence of strong
> evidence to the contrary; by statute, some contract terms (such as
> copyright assignment) cannot be found to exist without a written
> agreement. The FSF FAQ is probably strong evidence of what RMS thinks
> he's being bound to when he copies or modifies Linux, but Linus is
> probably under no obligation to accept that interpretation no matter
> how widely it's published.
>
> Linus may, on the other hand, be bound to the GPL interpretation that
> he has published with regard to Linux licensees -- but they aren't
> bound to accept his interpretation either. (See below for a link to
> his statement to that effect; I think he's right that estoppel is the
> legal mechanism limiting his room to claim differently in court.)
> When there is no "meeting of the minds", as in any shrink-wrap
> license, there is little other than the license text that can be read
> as evidence of what the licensee can't deny that he or she was
> agreeing to.
>
> > 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?
>
> As a legal matter? Not in the absence of a binding memorandum of
> understanding, or similarly strong evidence of acceptance of
> additional terms or interpretive matter (oral or in writing) by
> someone with the legal authority to bind Debian. In other words, not
> a chance; no one has that legal authority with regard to
> Debian-the-movement; at worst perhaps SPI could be enjoined from
> permitting the use of its assets in a way contrary to a binding
> understanding with the FSF. (Remember, IANAL, etc., and I haven't
> spent a lot of time reviewing the history or thinking about ways to
> "get at" Debian legally.)
>
This question hinged on the word Drafter in your original mail.
Note as an aside that I think there may have been an actual
written "memorandum of understanding" between SPI and FSF back
when FSF was actually funding the project during its early
history, although I have no reason to believe it actually
discussed the issue at hand.
> > > >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.
>
> Did you miss this:
> But the GPL appeals to the legal definition of "derivative
> work" in order to define a "work based on the Program" ...
> and this:
> In this construction ... the "mere aggregation" clause is
> a no-op.
> (on the grounds that earlier language limits the GPL's scope to the
> bounds of a derivative work anyway.)
>
My words quoted above (and, I think yours in the paragraph I
quoted before them) are mostly a summary of that written earlier
in this text. Even if "a work based on the Program" is to be
limited to not include linked programs, the specific phrases in
GPL clause 2 refer to the slightly different concepts of "a
whole which is ..." and "mere aggregation", which might be
interpreted to limit the permissions given by the paragraphs
using those words to less than the permissions that would have
been granted without those additional words.
> As for the second-to-last paragraph of GPL clause 3, I would
> paraphrase it as "the source code, the whole source code, and nothing
> but the source code" -- and quite right, too. The complete source
> code for "an executable work" is indeed defined in this paragraph to
> include that of all of its (non-operating-system) modules. But clause
> 3 starts with: "You may copy and distribute the Program (or a work
> based on it, under Section 2) in object code or executable form ..."
> So once again, the clause is referring to a work based on the Program,
> which is limited to the scope of the term "derivative work".
But if GPL clause 2 does not grant as much permission as you
think it does, one must look for a clause permitting the
distribution of a linked work. This would be either 1, 2, 3 or
a combination of those. Combinations not involving clause 2
would permit only verbatim copying of the GPL work (and most
forms of static linking are not verbatim). Combinations
involving clause 2 would require complying with clause 2 as a
condition for distributing the binary form of the portions of
the GPL work included in the linked program. At which point we
are back to considering the reach of clause 2 itself.
>
> So why my concession that the case for license is a little weaker for
> static linking? Simply because a court might rule that the paraphrase
> is close enough that "a work containing the Program or a portion of
> it" reaches to the next layer of shrink-wrap, which might be an ELF
> binary or even a Debian package. But frankly I think that anyone who
> believes that "a work based on the Program", as defined in the GPL,
> spans interface boundaries between separately engineered, maintained,
> and packaged software components with no common authorship is
> confused. Or to be generous, arrived at that opinion before looking
> closely at the GPL text and at some implementation of copyright law as
> interpreted in recent courts of competent jurisdiction. Hey, no great
> shame in that; I used to be confused that way, too.
>
There are 3 issues here:
Does "a work based on the Program" cover separately engineered
programs inspired by or designed for use with "the Program" (I
hope not)?
Does "a work based on the Program" include works (copyrightable
or not) that include within them a copyrightable copy or
derivative of "the Program", to the extent that the GPL has not
explicitly exempted those larger bundles as "mere aggregation"
(whatever that means)?
Does the GPL impose conditions on the combination of "a work
based on the Program" with something not "a work based on the
Program" in some limited circumstances?
> [snip]
> > > 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.
>
> That's not what the judge declared. Here's the relevant opinion text:
>
> <court-opinion>
> With respect to the General Public License ("GPL"), MySQL has not
> demonstrated a substantial likelihood of success on the merits or
> irreparable harm. Affidavits submitted by the parties' experts raise a
> factual dispute concerning whether the Gemini program is a derivative
> or an independent and separate work under GPL P 2. After hearing,
> MySQL seems to have the better argument here, but the matter is one of
> fair dispute. Moreover, I am not persuaded based on this record that
> the release of the Gemini source code in July 2001 didn't cure the
> breach.
>
> In any event, even if MySQL has shown a likelihood of success on these
> points, it has not demonstrated that it will suffer any irreparable
> harm during the pendency of the suit, particularly in light of the
> sworn statement that all source code for Gemini has been disclosed and
> the stipulation, given by [NuSphere parent] Progress during the
> hearing, that the end use license for commercial users will be
> withdrawn. Finally, because the product line using MySQL is a
> significant portion of NuSphere's business, Progress has demonstrated
> that the balance of harms tips in its favor regarding the use of the
> MySQL program under the GPL.
> </court-opinion>
[ I had not seen this more specific text before, it contains
details not previously cited in this discussion, interesting
reading indeed ]
>
> There is no hint in the opinion of any reason for doubt that the GPL
> was an enforceable contract; but there is equally no reason to think
> that Progress Software's conduct would have justified any further
> remedy under the GPL. The FSF general counsel's assertion in his
> affidavit that Progress Software's license had been "automatically
> terminated" was ignored without comment. The judge did not rule on
> the "derivative work" question of fact because it didn't matter to the
> immediate proceedings. A routine walk through the contract law (not
> copyright law) criteria for a preliminary injunction showed that
> MySQL's claim had no hope of meeting the appropriate legal standard
> irrespective of the factual dispute.
>
> Let me say that again: the FSF's case had zero traction with the
> judge on points of law. The judge didn't so much as seriously
> consider recognizing grounds for "automatic" contract termination and
> applying copyright law standards of infringement and remedy. Not just
> because MySQL had obtained a preliminary injunction on trademark
> grounds, either; that injunction only covered use of the MySQL(TM)
> mark. Progress was explicitly permitted to "state that its product
> operates with the MySQL program" and to go on selling it and servicing
> customers. (In fairness, they had already released source code by
> then and agreed to comply with MySQL's other demands; apparently only
> the FSF was pushing for validation of copyleft legal theory, which
> they sure didn't get.)
>
> I do have to say that the specific facts of the MySQL case, which
> involved a statically linked mysqld with no indication that Progress
> Software's Gemini component was or could be provided as a separate
> work, are about as prejudicial to the defendant's position as they
> could be without actual proof of cut-and-paste MySQL source code
> inside Gemini. If the FSF couldn't get a preliminary injunction on
> this one, I can't see how they would ever win a dynamic linking case
> involving long-term stable APIs.
>
Not much here that differs from what I wrote (and you quoted)
above: The judge deferred ruling on the derivation issue to a
later trial, but actually leaned towards derivation. The
preliminary injunction was denied because the judge was not 100%
certain that derivation would win in the end, and because a
balance of harms consideration indicated that such a drastic
measure should await further proceedings. Those later
proceedings never happened because of an out-of-court
settlement.
So the injunction tactic failed, the GPL was declared enforcible
in general, and the more specific issue of derivation and
linking was deferred to a trial that never happened.
> (The district judge runs the US federal version of a court of fact, as
> opposed to an appeals court or "court of law". In principle, courts
> of law review not the evidentiary support for the court of fact's
> rulings but the correctness of their legal reasoning in light of
> statute and precedent. IANAL and am not the person to ask for a full
> explanation of the degree to which a given precedent is binding, but
> for what it's worth no commentator seems to have felt there was any
> legal defect in the judge's reasoning.)
>
> [snip]
> > 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.
>
> See above. Oh, and it was Massachusetts (US) federal district court,
> not Sweden.
>
Oh, I always thought it was a Swedish court, due to the
Swedish-like sound of so many of the names involved, I stand
corrected on that.
> [snip]
> > > 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.
>
> If gcc, flex, and bison had purported to create GPL-encumbered output,
> few people outside the FSF would ever have cared to use them. Few
> people had any interest in glibc before the LGPL was drafted to give
> it some viability beyond the pure-GNU-system enthusiasts. (Bluster is
> a nuisance even if you don't believe it's enforceable.) Perl's
> Artistic License came first, and Larry added the GPL so people could
> write XSUB glue to (L)GPL libraries without doing legal research, and
> nobody ever seriously argued that Perl programs had to be GPLed.
>
You missed my point here: The 30.000 feet view you described as
well as cases that cite fairness in competition in various ways
are based on legal theories applying only to a small subset of
the cases where the derivation theory in the GPL FAQ might be
applied or rejected. In actual practice, the various holders of
important GPL copyrights have directly avoided such a clash
between fair competition and GPL FAQ derivation theory.
This makes sense: case law tends to be influenced by the
concrete facts of whichever concrete case gets to set the
precedent. If the first case to fully test the GPL derivation
theory is one where the purported violator was merely using an
unavoidable system interface covered by the GPL, then a court
would tend to rule in favor of fair competition and against a
license interpretation creating a monopoly. If the first case
is one where the purported violator was actively trying to
circumvent the GPL by putting avoidable code received under GPL
in a shared library in a way that makes no sense otherwise, the
court would be more likely to rule in favor of GPL FAQ theory.
So it is prudent for those with an interest in the enforcibility
of the GPL FAQ theory to carefully choose their battleground and
make way in places where they are more likely to loose.
MySQL was actually a risky case to try: MySQL AB is pushing a
far-reaching variant of the GPL FAQ theory way beyond what is
commonly accepted. It could easily have resulted in a much
worse precedent for the GPL side because of that.
> As for Linus and Linux, it appears that his opinion about the legal
> meaning of the GPL is not too far from mine (though not quite
> identical; see thread at http://lkml.org/lkml/2003/12/4/239 , for
> instance) and that he's done the sensible thing and estopped himself
> from pursuing a class of silly copyright infringement claims. Which
> is what the FSF should do, and then we can all get on with making
> software that sucks less.
>
The FSF should do that if it is in its interest or makes no
legal difference.
It is in Linus interest to assure the world that running on top
of a Linux kernel does not subject your code to the terms of the
GPL, and to do so in a manner seen as legally binding by those
who might otherwise refuse to use his big creation.
The FSF has a different interest in many cases, especially for
its various GPL-ed libraries and it is thus in the interest of
the FSF to stick to its GPL interpretation if at all possible,
and grant explicit additional permissions in the cases where its
software would otherwise not be used, or where the circumstances
could otherwise inspire the creation of case law to the
contrary.
> > > 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.
>
> Do I have to spell out the "vendor/license lock-in" analogy? And
> c'mon, this paragraph is an aside, and I've rebutted that copyleft
> claim pretty verbosely already. You probably could write a
> distributor agreement that says "you can only carry GPL stuff"; as
> long as you don't have Microsoft's market power, you wouldn't be
> shooting anyone's foot but your own. But the GPL's text -- aka
> copyleft -- doesn't actually say that, not even in the milder "you can
> only bundle related-in-an-engineering-sense things with me if they're
> also GPL" sense. Engineering relationships are not copyright
> relationships.
>
I understood the analogy. I think it is a strawman because the
parts of the GPL world that might actually be used in a manner
creating a monopoly like total license lock-in have carefully
avoided this course of action. With MySQL as one of the most
notable exceptions.
> > > 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?
>
> On the contrary; in the right mood, I'll listen as much as I talk;
> well almost. :) But this stuff is not as hard as it is made out to
> be, the primary literature (I'm thinking mostly of appeals court
> opinions) is quite readable and freely available (probably true in .dk
> too), and this area of law is now well trodden in a way it wasn't
> twenty years ago. Arguments from the 1710 Statute of Anne and the
> meanings that "derivative work" might have in a parallel universe
> where it's not a legal term just aren't that interesting. (That's not
> directed at Jakob, of course.)
>
Disclaimers: IANAL, TINLA, IANADD, plus the one in my sig
Jakob
P.S. The disclaimer in my sig has not been cleared through a
lawyer. Its primary design criteria was the 4 line limit of
Usenet sigs.
--
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: