Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
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.
[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.
[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.
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.
> > 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".
> > 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".
[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.
> > 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.
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.
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).
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".
> 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).
> 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.
> 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.
> 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.)
> > >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.)
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".
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.
[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>
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.
(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.
[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.
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.
> > 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.
> > 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
ditto, ditto, ditto, and I think I'll echo the last, too.
> 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.
Cheers,
- Michael
Reply to: