GPL, "license upgrades", and the obligation to offer source code
[dropped debian-devel; didn't notice previously that this fork was
still spamming them]
On 5/9/05, Glenn Maynard <glenn@zewt.org> wrote:
> On Mon, May 09, 2005 at 06:25:46PM -0700, Michael K. Edwards wrote:
> > I used to think it extroardinarily unlikely that this formula, with
> > regard to as-yet-unwritten offers of contract, would have legal force
> > in any jurisdiction. The prevalence of similar terms in shrink-wrap
> > software licenses nowadays -- which I abhor, and blame directly on
> > RMS, Eben Moglen, and the FSF -- has eroded that confidence to some
> > degree. If it were ever to come up in a court case in which I
> > personally was involved, I envision disputing its validity to the last
> > breath. (I reserve the right to do otherwise, of course.)
>
> I'm confused. Why would an optional upgrade clause ("party X may offer
> alternate terms for this software, which you can accept at your option")
> like the GPL's be used in a shrink-wrap license?
Gentle reader, if you're gonna read this at all, go get a big cup of
coffee and your fine-print-complex-grammar glasses. I wax prolix at
the best of times and this batch of quasi-legal grits is extra coarse
grind. I am SO not a lawyer it is not even funny. All persons,
living or dead, are purely coincidental and not to be construed. <--
That mangled quote was deliberate but all others are accidental, and
so is any other error of fact or implication below. Ready?
Consider the terms of the end-user license discussed in Micro Star v.
FormGen, in which the EULA for the bundled Duke Nukem scenario editing
utility stated that works created with it "must be offered [to others]
solely for free". The Ninth Circuit upheld FormGen's right to enjoin
Micro Star from distributing such scenarios commercially, since they
amounted to derivative works of the Duke Nukem character and
storyline. (For those reading along at home, that opinion is at
http://laws.findlaw.com/9th/9656426.html .) That's a square deal;
scenario authors knew what terms applied when they posted their works.
Now let "DNPL" be the GPL, except with FormGen as the license steward.
Suppose a stripped-down "Duke Nukem 2-D" and its scenario editor were
offered under DNPL v2 "or any later version", and the scenario editor
lacked the real-world license's "solely for free" clause above. In
this situation, you can only distribute your k00l scenarios by
offering them under DNPL terms, since the only construction under
which their creation would be permitted would be as derivative works
of DN2D (not DN3D). But your friends who have purchased DN3D can use
them with either game engine, so it's all good.
Then suppose that FormGen publishes DNPL v3 containing a clause to the
effect of "copyright holders on derivative works of any version of
Duke Nukem grant FormGen an exclusive license to publish their works
commercially". FormGen can then gather up all of the extant Duke
Nukem scenarios, "upgrade" their license to DNPL v3, and exploit them
commercially as DN3D scenarios. Oh, and just for good measure, they
can write in a clause that lets them (and only them) publish DNPL
works without accompanying source, and then break scenario format
compatibility in a bug-fix release of DN3D, so that only the
commercialized scenarios work with the fixed DN3D. They could even
accomplish the same effect without any FormGen-specific language, just
by _relaxing_ the rules so that _anyone_ can publish them commercially
without source; they're the only ones with the tools to make
new-format binary scenarios!
This narrative (entirely hypothetical; FormGen has never tried to pull
something like this, as far as I know, nor do I have any reason to
expect it of them) would be even worse with typical click-wrap
licenses that say that the licensor can change the rules with no
notice and no option to stay at the old license version. It is my
impression that the typical shared-source license goes further, with
no option to remove the "or any later version" clause on your own
works. I believe that the FSF's exhortation to "give us room to
bug-fix the license" has had a major influence in legitimizing this
sort of language in the eyes of software developers. Just because the
FSF themselves haven't (yet) pulled a license bait-and-switch (unless
you feel that way about the GFDL), that doesn't absolve them from
responsibility for opening that gateway to hell and perfuming it with
righteousness (or lefteousness, as the case may be).
Does this make it clear why no court should enforce on you any
covenant to accept contract terms that you were unable to review at
the time your acceptance was solicited, no matter how vociferously you
agreed to that covenant at the time?
> I also don't understand why you're so opposed to it. Why should I not be
> able to say "you can distribute under these conditions; in addition, John
> may offer you a new license in the future, terms which you may accept or
> ignore"?
That's not the right question. The right question is, why should you
delegate to John the authority to grant me (or himself) the right to
accept new license terms, on your behalf, under which I and he may
exploit your copyright material? And -- given the power to destroy
much of the practical value of your and my rights under the existing
license, as in the above scenario -- why also extend him the means of
giving you and me a Hobson's choice of accepting these changed terms
or not? We can download the bug-fixed version (via click-through) and
perhaps be estopped from disputing the new terms in court; if we
don't, we risk losing access (as the frozen pre-license-upgrade
version we're holding ages out of compatibility with critical updates
to the rest of our system) to our own work and each other's. Is John
paying you and me for that privilege?
In case you think this is just about video games and hypothetical
licenses: how would you like it if, when a GPL "upgrade" comes out
that you'd just as soon avoid, the GCC license changes to say that, by
using it to compile GPL works, you agree to permit anyone who holds
copyright license from you under GPL v2 to accept the "bug fixes" in
v3 with respect to those works? Would you like to be forced to fork
GCC on the spot -- especially if that license change immediately
precedes major bug fixes? I'm not saying that the FSF will or would
pull such a stunt, I'm asking you: if you don't draw the line at
having the licenses for your own published works changed on you, where
do you draw it?
Maybe you think that GCC is the last program that the FSF is likely to
play games with? Read Wind River's "Open Source Initiatives" press
release at http://ir.windriver.com/phoenix.zhtml?c=91814&p=irol-newsArticle&ID=682743&highlight=
and enjoy the quote from Mark Mitchell. It's nice to have the FSF
Release Manager for GCC running your toolchain program. Yes, that's
the Wind River whose chairman and co-founder wrote and published this
lovely piece of anti-GPL, anti-Linux FUD entitled "Linux In Embedded
Systems: Where Are The Benefits?" (sic):
http://cnscenter.future.co.kr/resource/security/application/wp_linux2.pdf
. He was, at the time, running a business utterly dependent on the
GNU toolchain, apparently with active help from the FSF. Oh, they're
reformed now ( http://itmanagement.earthweb.com/entdev/article.php/3114681
) -- but it makes you think.
Now if you were Linus, would you trust the FSF to rewrite the license
on your work? Before you answer, remember that GCC is the only
compiler which doesn't choke on the Linux kernel (last time I
checked). Mind you, I am casting no stones at Mark Mitchell or
CodeSourcery; they're in the perfectly legitimate business of
providing software development services around the GNU toolchain, and
as far as I know they have no influence on FSF license policy
whatsoever. (See
http://www.obscorp.com/obsportal/modules/news/article.php?storyid=155
for more quotes from Mark about the impact of commercialization on GCC
development.)
But at what point do you wake up and smell the potential for conflict
of interest, and notice that the FSF's "GPL is GPL and closed-source
is closed-source and never the twain shall meet (at run-time)"
position is very convenient for the people who pay the bills? Almost
as convenient as "we can't protest Red Hat's trademark policy,
subscription agreement, and ISV support lock-ins because they aren't
about copyright." I am not out to impugn the intentions of the FSF,
RMS, Eben Moglen, or their pet hamsters here. I am pointing out some
reasons close to home why, now that I think about it, authority to set
future licensing conditions with respect to my work is the last thing
that I personally would delegate out -- especially to someone with
IMHO bizarre ideas about what is legally possible -- absent good and
sufficient compensation.
That's all I have to say about "license version upgrade" clauses at
the moment. But while we're on the topic of things the GPL attempts
to do that aren't legally possible, let's talk about binary
distributions. Forget what happens when your customers can't
reproduce your build environment, which the GPL makes no real attempt
to address. Is the preamble at least right when it says that "you
must make sure that they, too, receive or can get the source code"?
Let's dispose of one canard up front. It is very clear from the
discussion in Quality King (cited below) that the phrase "lawfully
made under this title" [17 USC] does not distinguish between copies
made _personally_by_ the copyright holder and copies made
_under_license_from_ the copyright holder. Otherwise 17 USC 109(a)
would be completely toothless, since when it comes to a book or a
product label it's the printer who does the copying; and a statute,
unlike a contract, must as a matter of law be construed if possible to
give force to all of its provisions.
Now here's that "copyright and parallel imports" case I didn't have
handy earlier: Quality King v. L'anza Research (
http://laws.findlaw.com/us/000/96-1470.html ). Looks to me like
Supreme Court precedent for the contention that, thanks to the "first
sale" doctrine, the GPL can't put subsidiary conditions (such as the
offer-of-source requirement) on your resale or other redistribution of
a "particular copy ... lawfully made under this title" [17 USC]. So
the constraints placed on who can choose option 3c (pass upstream's
offer of source along to the recipient) are bogus, and anyone can
safely pass unaltered Debian binary packages around. "First sale"
allows them to rely on Debian (technically, the Debian maintainer or
buildd operator; but a reasonable construction of agency shifts the
duty to the Project) to satisfy the offer of source code.
So how did I manage that leap of logic? Suppose I'm the one to do the
dirty -- create a derivative work -- by compiling source to binary. I
say that's doing the dirty because arguably it's a non-trivial
transformation (unlike run-time linking, there are a lot of creative
choices involved in constructing a particular build environment), and
a fortiori if I've altered the source. So I'm stipulating that I've
created a "work based on the Program" using my license under the GPL
and no other.
I can't offer people the binary alone, claiming "first sale" doctrine
to avoid obligations under the GPL, because nobody sold or gave me
that binary; I created it under GPL authority from all of the
copyright holders involved. But I can satisfy GPL 3a, "accompanying
it with ... source code", by offering that source code for download --
only for the duration that that particular binary is offered. That's
the industry's reading of the last paragraph of GPL 3; practically
nobody (hi, Ukai-san! lonely angel!) pretends to satisfy 3b with
regard to every binary they stuck on a web site three years ago, and
that's been true for over a decade.
But once I toss that binary through the ether to Joe Blow, that is a
first sale, whether or not he chooses to grab the source at the same
time; and he can pass it to you, commercially or otherwise, without
any particular authorization from me. That's true even if I stick
source and binary in the same tarball, and he only passes along the
binary; see the references to Gamma Audio as cited in Columbia
Pictures v. Krypton VII.B for that reasoning, and anyone who needs
help getting from TV series to tarballs can get it if they ask nicely.
It's still true if he burns a whole stack of binaries to a nice
pretty DVD-ROM and sells it to you that way, as he is merely
"presenting them in, what some consumers deem to be, a more attractive
display" (see Allison v. Vintage Sports, cited in the postscript
below; punctuation sic).
But wait -- he made copies, and that takes a copyright license, so the
GPL burden is on him, right? Well, not if he has downloaded it once
from me for every time he passes it to someone and has done his
bookkeeping in between, even if he keeps it in "inventory" and doesn't
pass it on until years later. Since I'm talking mostly about whether
the "noncommercial distribution" and "in accord with Subsection b"
parts of the parenthetical constraint on 3c are enforceable, let's
assume for the moment that Joe plays this "binary inventory" game (see
postscript). So even if he stipulates freely that his distribution is
commercial in nature, that I opted 3a instead of 3b, and that he has
accepted the GPL with respect to that work, he hasn't done anything
that requires GPL license in the course of passing my binaries to you.
Nor is there any evidence that he has accepted an independent
contractual covenant _not_ to exercise statutory first sale rights of
transfer with respect to binary blobs he got directly from me.
So you want source with your binaries? Better get it at the same
time, and doubly so if you aren't getting the binary from the entity
under whose banner it was compiled; and if you can't get it from Joe
and I don't offer it any more, your only recourse is to drop that
binary like a hot potato. That's what "no warranty" means -- neither
Joe nor I warrant that you can come back to me tomorrow and get the
source code for the binary you got from Joe today. As long as, at any
given time, I offer from my website the source code for the binaries
that are on my website at the time, I'm in compliance with GPL 3a; and
Joe can claim "first sale" protection for offering unaltered binaries
by themselves. (Did I mention that I am not a lawyer and this is not
legal advice?)
There's a legal tool for exercising control over how distributors
monkey with your packaging, and for obliging them to do more for the
sake of your reputation than observe statutory anti-defamation
provisions (including, in some jurisdictions, "droits d'auteur").
It's called a "trademark". It comes with a few rather inconvenient
strings. You've got to exercise quality control over the things it's
stamped on, you've got to notice when people misuse it and do
something about it, you've got to establish your right to it
separately in each market unless it's globally notorious -- and those
things cost money. Trying to dress up a copyright license as a poor
man's trademark doesn't actually get you very far.
Cheers,
- Michael
OK, if you read this far, you must want to know how Joe Blow optimizes
away his binary inventory. We're back to the fact that the GPL is an
offer of contract, not some magical creature of copyright law. Joe
does indeed have to claim authorization under the GPL to create
additional copies. But that does not give me, as hypothetical
plaintiff, a fast path to preliminary injunction. In the words of Sun
v. Microsoft ( http://caselaw.lp.findlaw.com/data2/circs/9th/9915046.html
), "before [the copyright holder] can gain the benefits of copyright
enforcement, it must definitively establish that the rights it claims
were violated are copyright, not contractual, rights". The scope of
copyright law ends when the copies have been made; see the doctrine of
first sale again (example at Bourne v. Walt Disney at
http://caselaw.lp.findlaw.com/data2/circs/2nd/947793.html , sections
1c-d) for why Somebody With Standing v. Joe Blow therefore becomes a
pure contract law dispute.
Now I'm giving binaries away to all comers from my Web site. Joe
_could_ have forced me to do the replication of binaries under my own
GPL rights, but _didn't_. How does that harm me? Suppose Joe had
downloaded from me "retail" and played "binary inventory". That would
have cost him some download bandwidth -- during his quiet time, so
probably zero incremental cost -- some hard disk space, and a little
programming effort. But it would have cost me upload bandwidth --
probably metered, and possibly during my peak demand. So I actually
win more on cost of distribution by his skipping the binary inventory
technicality than he does. (Remember: any cost of distributing
sources that I bear when his customers come to me for sources that I
still offer, he would have shifted onto me with the "binary inventory"
scheme anyway.)
So prima facie I have suffered negative economic harm by his avoidance
of "binary inventory". And since both of us have disclaimed all
warranty whatsoever, and I have met my GPL obligations by offering the
source for the duration that I offered the binary, Joe has not placed
me at any legal risk. Maybe the guy who got it from Joe has a
statutory cause against him because there's a copy of the GPL attached
to that binary and that's false advertising or something, but in what
way does that harm me? Under contract law, it's pretty hard to obtain
a remedy when I can't show any harm.
If Joe thinks it's good for his reputation (or good risk management)
to be able to satisfy requests for source on demand, that's his
problem, not mine. And if I build and distribute a binary, offering
it for unlimited download (with no distinction between wholesalers and
retailers), and have some reason to want Joe's customers to be able to
get the source long after I myself have stopped distributing that
binary, that's my problem, not Joe's. Unless he does the dirty and
modifies or rebuilds it; in which case the torch does indeed pass to
him. But then I'm not in the end-user software business, I'm in the
software maintenance and services business (which is where the GPL
shines, as a way to settle the issue of vendor lock-in with respect to
expertise in grazing the commons), and Joe only loves me for my source
code.
So how do I deal with people who curse me as just another brittleware
vendor from whom a precise source code version can't be had when it's
really needed (when they need a point fix for something broken on a
production system running _my_ six-month-old nightly build, which the
last sysadmin plucked off of WarezRUs for no recorded reason)?
Happily, the actual historical legal system comes to the rescue,
giving me an escape from the Brave New Copyleft World. I can attach
trademarks and require Joe to execute a trademark license in order to
"buy wholesale" (i. e., make copies with my trademarks on them); then
I would have both the right and the obligation to exercise quality
control over the form in which my products arrive in customers' hands.
Whoops -- if I got some fragment of my product under the GPL from
someone else, the GPL won't let me make a distinction between
wholesale and retail on a "people who copy" / "people who don't copy"
basis. I need a totally parallel system of "goods", inextricable from
the (binary) software itself, whose distribution I can police without
tripping the GPL's "everyone's a publisher" alarms. Suddenly Red
Hat's trademark policy, and the endless "if you don't get patched
binaries direct from us under subscription, kiss your ISV
certifications goodbye" bluster, starts to look to me like something
other than greedhead GPL circumvention.
(Even so, my friends still tell me that maintaining RHEL boxen feels
like being the pit crew for a Formula One team composed of Soviet
tractors; I wouldn't know. ;-)
Did I mention that the doctrine of first sale applies to all
intellectual property claims, and hence the "Joe can play binary
inventory" part of the analysis is unchanged if you add patents and
trademarks and your very own name and likeness? See Allison v.
Vintage Sports (
http://caselaw.lp.findlaw.com/data2/circs/11th/966809man.html ).
Patent's a little different because the license can be conveyed
independently of the binary instance -- but that's a topic for another
time.
IANAL, TINLA, YMMV, HTH, HAND.
Reply to: