We have the answers from FSF Licensing Engineer Brett Smith to the questions you posed regarding the GPLv3. Of course, if you have more questions after reading his answers, fire away.
So, I'll turn this page over now to Brett Smith:
Before I start with the questions, I'd like to take a quick moment to
thank PJ for helping to organize this, and the many people who submitted
their thoughts. The FSF Compliance
Lab deals with the GNU licenses in many different ways—we
investigate violations, help people come into compliance, and educate users
and developers about their terms. Hearing your thoughts on GPLv3 has
helped me understand what needs to be done as we finalize the license.
If you'd like to learn more about the Compliance Lab, please stop by our
web site. A team of volunteers actually
help me answer questions like this all the time; if you think you'd be
interested in pitching in, don't hesitate to drop us a line. You can also support
our work by joining the FSF.
A lot of your comments seemed to be suggestions for the draft itself,
rather than questions per se. I do appreciate those, and while I would
have loved to provide some sort of response to each of them, I'm afraid I
simply don't have the time. Please do submit those to our comments page—we do read and
consider everything there, and the feedback will help inform the last call
draft we publish next.
I've roughly organized the questions by topic: they start out discussing
the drafting process, move on to the more significant changes in draft 3
such as lockdown and patent terms, and then more specific, nitty-gritty
questions. I've also done some slight editing to the questions to help
clarify them in the new context; I strove not to lose any substance, and
I've provided links to the original comments so you can double-check me on
that. I hope my answers are as helpful to you as your comments were to
- Is it really necessary to reference any specific (and therefore fragile)
- Are we really incapable of bluntly stating our intent from basic
near-universal principles alone? (Examples are "copyright" and patents".)
- Is the concept of "free software" not basic enough to be expressed in a
legally binding way without these references?
- Are we willing to initiate an arms-race with lawyers and lobbyists paid
to subvert our work?
- How long do you hope GPLv3 will be able to protect our software
unmodified? 15 years (like GPL2)? 15 months?
- Does the FSF think we could "win"? (I use "win" in the sense that
software would be "effectively free" as long as the authors kept applying
the license patches from the FSF, say, every Tuesday.)
Free software is dirt-simple to express in a license. Here you go:
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so.
I just took the main paragraph of the Expat license and trimmed it
slightly. This is a complete free software license: it gives the recipient
all the four freedoms. I wouldn't want to use it as a developer, but as a
user there's absolutely no problem with it. It even sounds like legalese.
That's 61 words. By contrast, just the legal terms of GPLv2—not
counting the preamble and appendix—weigh in at 2021 words. That's
more than 30 times bigger! Why is the GPL so much longer? Can't we make
Writing a free software license is easy. Writing a good free software
license, that does a good job of addressing the needs of both users and
developers, is hard. And writing a copyleft is where the rubber hits the
road. Copyleft is where we have to consider the environment that software
exists in today, how users' freedoms are threatened, and how best to counter
those threats. When you write a copyleft, you don't get the high-minded
language of freedom; you get compromising text like "a written offer, valid
for at least three years, to give any third party, for a charge no more
than your cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code."
That's so complicated! What if someone tries to give you punch cards?
Those are machine-readable if your machine was bought in the fifties. And
how do we know what their cost of physically performing distribution is?
What if they lie? And what's this business about "any third party?" Plus,
why does it say three years? Shouldn't we be able to get source after four
Despite all these questions—all questions that people have
legitimately asked at one time or another—this language has served us
well in GPLv2 for over fifteen years now. I still explain it to lawyers
and engineers inside companies big and small, and they all usually provide
written offers that are reasonable for users.
I won't deny that GPLv3 is more complex than GPLv2. That's because we
live in a more complex world now, where people interact with software in
lots of ways besides sitting down in front of a box that runs their code,
and some developers want to have all the advantages of freedom with none of
the obligations. You can use simple language if all the participants have
shared understanding. Unfortunately, not everybody groks freedom yet.
I understand why some people are averse to referring to specific laws in
GPLv3, but I have yet to hear an alternative that's actually better. We
want to say: "Judge, the law creates a special class of software that has
special rights, and we want you to know that this software is not in that
class and has no special rights." We could describe that class in plain
English, but then the judge may not make the connection. He might think
our definition is different somehow. Calling out the law directly
eliminates that risk.
And avoiding that risk is important, because we do want GPLv3 to last. I
don't think it's going to make it quite as long as GPLv2; probably
somewhere between five and ten years instead. Of course, we'll update the
license whenever the integrity of the GPL is threatened, but this sort of
timeframe is the goal we're working towards.
When I first started coming into the free software movement, the
complaint du jour was journaled filesystems. Free software will never have
a journaled filesystem, they said; it's too boring, nobody working on their
own time wants to make that sort of thing. These days, I have to
double-check and make sure that I don't use a journaled filesystem
when I format a USB drive. In between then and now, they also said that
we'd never develop an office suite, or a "real" relational database, or
enterprise software. Every day, the list of things you can't do with free
software shrinks, and each time that happens, more people start using
GNU/Linux. As time goes on, more of the world runs on free software. We
have to stand our ground and be smart moving forward, but if we're
successful in that, I think success for the movement will follow.
The object of revising GPLv2 was ostensibly to improve and clarify it. With
respect, this latest draft of GPLv3 is hardly clear; to the contrary,
there's a lot more ambiguity. For instance:
I've heard Eben Moglen speak on several occasions, and he's acknowledged
that he's intentionally included ambiguous terms in the license.
We did include nebulous language in previous drafts so as to generate
discussion and figure out where certain lines should be drawn. That
process should be finished at this point, however, and there shouldn't be
any more language that's intentionally difficult to understand. If you
have suggestions for how we can help clarify the specific points you
brought up, I would encourage you to submit them to our comment page, if
you haven't already.
1. Should this comment period lead to serious work for the v3 team, is the
self-imposed deadline flexible? The implied point of view is that real
improvements will benefit thousands for years, while hitting the date might be
more of a pointy-haired-boss thing...
Right now I have no reason to believe that we'll be delayed. The
process has gone very smoothly so far. Except for compatibility with the
Apache Software License, I haven't yet heard of any issues that might
require much of our time. But we do agree that getting this right is more
important than getting it on time—we already extended our deadline
once, after all, to address the new threat presented by the
Microsoft-Novell patent deal.
2. Our justice system has been based on accepting that a few
false negatives (crooks) will go free to protect citizens from government
false positives (good guys going to jail).
Should the authors of GPLv3 reconsider the balance between the goal of
worldwide acceptance of the GPL versus dealing with specific risks, if
dealing with the risk either complicates the GPL and creates legal
interpretation risks or complicates the GPL and makes developer-readability
risks and barriers to use?
This balance is something we keep in mind as we revise the license. We are
trying to keep the complexity as low as we can. For instance, when we
changed the anti-tivoization terms in the latest draft from something in
the definition of source code to a condition in section 6, one of our
motivations was to make it easier to understand. We've received some
feedback telling us we made the right judgment in that, which I was glad to
see. The change actually added more text, but I think it's simpler
From our perspective right now, GPLv3 addresses very real and serious
threats. We recognize the high cost of doing this, but we think the costs
of inaction are even greater. People have already envisioned a world where
all hardware is locked down, and are trying to figure out how to force it
on an unwilling public. Microsoft is already trying to force every free
software user to pay them royalties. These are not abstract issues.
Other organizations are fighting to take away your freedom.
What considerations have been given by the FSF regarding international and
I ask because things like the sections on patents, and references to
things like the "Magnuson-Moss Warranty Act" (whatever that is) seem very
Could the addition of these sections—although tightening the GPLv3
in the U.S.—actually weaken it (as unenforceable) in the place most
of us reside—i.e., "abroad"?
We are doing everything we can to make the license work uniformly in as
many jurisdictions as possible. This is why we have defined new terms such
as "propagate" and "convey," instead of using U.S.-centric language like
"distribute." In the latest draft, we also replaced a reference to the
DMCA with one to the corresponding WIPO treaty.
I don't see anything in the patent section that would be particular to
the U.S.; if you do, please let us know. As for the reference to the
Magnuson-Moss Warranty Act, we recognize that it has some costs outside the
U.S. We think it would still be enforceable because the text makes very
clear that this reference is not supposed to supplant any local laws; we're
only incorporating a definition into the license. Even then, we're still
considering this balance, which is why the reference is in brackets. We
only propose it because it has exactly the kind of interpretation we would
like the GPL itself to have.
This is a topic that nobody has picked up on yet, but it is quite explicit
in the FSF drafts: GPLv3 is incompatible with the Apache Software Foundation
Now, GPL2 has been incompatible with ASF2 because the Apache license
said "sue for patent infringement and your rights to this app go away".
GPLv3 has a similar clause, and everyone—including the Apache people
working with the FSF—thought all would be well. But come the next
draft, no, the FSF came up with some other argument against the Apache
license that they did not even bring up with the Apache folk.
Now, this may seem minor, but in the Java world it is not. Sun's JVM
uses Apache code for XML support, so Sun cannot release the JDK under the
GPL—as promised—until the two are compatible.
What game is the FSF trying to play here?
The indemnification provision of the Apache Software License was brought
up as a potential compatibility problem in discussion committee. Once it
came to our attention, our thinking evolved the way we described in the
rationale document. At first we couldn't determine the exact scope of the
requirements, and so assumed it was no problem. We then came around to the
idea that, despite that, we should still act as though there were some
requirement there, which would make the two licenses incompatible.
This wasn't a proposition we were really eager to consider. In fact,
saying we were reluctant would be putting it mildly. Both interpretations
of the language are reasonable. However, the community places a lot of
trust in the FSF's judgment on licensing matters like this, and we must
honor that trust by considering these issues from all possible
angles—even the ones we don't like.
We wanted to be forthright about our concerns in the rationale document;
I think that's a better policy than trying to sweep the problem under the
rug. But you're absolutely right that we should've discussed this issue
with the ASF before releasing the last draft, and you have my apologies for
that. I hope we can make it up to you. In the weeks between then and now,
the FSF and ASF have had the discussion we should've had back then, with a
goal towards finding a solution that will provide compatibility between the
two licenses again. I can't promise anything yet, but I'm optimistic that
we're going to find that solution.
The Apache Software License is a good license. We still want
compatibility between the GPL and ASL, and continue to work towards that.
We keep getting tripped up on the legal nitty-gritty, but we're going to
get through it.
Why is the GPL being forked to deal with a loophole? If it's worth
closing the loophole for ASP, why not include the fix in the main GPL? Why
is this one named and the other potential combination licenses are not? So
what happens when I link to BSD code, or public domain code, or ...?
Not everybody agrees that this issue constitutes a loophole. And when I
say that, it's not just big business on the other side of that debate;
there were developers here on Groklaw disagreeing about this issue. There
are reasonable arguments on both sides, and the GPL is not the place to
In the previous drafts of GPLv3, we tried writing a provision that would
provide for compatibility with any license that required
network-interactive applications to provide their source in particular
ways. But nobody was really satisfied with it. Large companies said the
risk of having that requirement present would cause them to avoid using or
endorsing software under GPLv3. At the same time, developers who are
interested in tackling this issue felt the provisions were too
technically-oriented and allowed certain kinds of requirements that
would've been too burdensome.
The new provision allows us to provide for compatibility with a license
that addresses this issue, while taking all this criticism into account.
It doesn't seem like a major loss, either; the only free software licenses
we may have lost compatibility with (compared to the previous draft) are
the Affero GPL v1, and the Honest Public License. Both of those are
GPL-based, and I think their users will be very interested in moving to
AGPLv2. We're certainly looking forward to hearing their feedback once we
publish the first draft of that.
You'll still be able to link to code under other GPL-compatible licenses
just as you do with GPLv2. Section 7 in the current draft helps make this
Is it OK to distribute a program in which some components are
GPLv2-licensed and some components are GPLv3-licensed?
That depends on some more details. I've prepared a matrix that lays out a
lot of the common options, and posted it to the GPLv3 FAQ.
Note that this only covers cases when you're combining code into a
single program through usual methods, such as actually copying the code
from one project into another, or using a library.
Given the nature of [free software] projects, and the large number of
contributors to most of them, how can any large project move from GPLv2 to
If the project is released under GPLv2 or any later version—as
most projects are—upgrading to GPLv3 should be a relatively
straightforward process for any team that wants to do so. They effectively
gave themselves permission to upgrade, after all. Beyond that, I can't
really talk much in general about how projects should migrate to
GPLv3—because every project is run differently and will be willing to
take different steps to reach this goal, the process will be different as
It definitely should be possible, however. There are lots of good
reasons to upgrade to GPLv3, and we'll be happy to do what we can to help
projects that are interested in making the switch. Licenses aren't
designed to be permanent, so it's important to have some kind of structure
to make upgrades easy. The FSF has collected copyright assignments to do
this for GNU programs, and the SFLC has been helping developers establish
other ways to achieve this goal. Unfortunately for hackers, this is the
kind of thing that requires some legal advice, but hopefully the release of
GPLv3 will provide a good opportunity for lots of projects to hammer this
Why do you feel the need to draw lines between different locations of
If a buisness doesn't want control of their hardware, they should rent that
hardware. And I seriously doubt that any business really wants
manufacturers to have control over their hardware. Manufacturers who are
worried about modifications to their software causing them liabilities
should put it bluntly (at point of sale) that they are not responsible if
the thing they sell is modified in any way.
We don't want to draw a line based on whether you rent or own the device
that houses the software, because if we do, every device manufacturer will
find a way to "rent" their device as a way to get around the GPL's
requirements. We've already seen some distributors try to make this very
argument with GPLv2, particularly in the ISP business where it's common to
lease modems to customers—even though rental qualifies as
distribution in pretty much every jurisdiction.
Moreover, the companies that have the sort of "managed IT" that we're
trying to allow—where they don't have the keys to modify the software
and actively don't want them—are already renting that hardware.
Nonetheless, they were still concerned that it would not be possible to use
GPLv3 software in these programs.
I've been trying to learn more about what would and what wouldn't be
considered a consumer product. One thing I found said it's a case-by-case
issue. Are there any bright-line rules to categorize a tangible
product into a household as opposed to say maybe a industrial, or
professional product? Do you have a list of electronic products that you
consider to be consumer products? Do you have a list of electronic products
you don't consider to be consumer products? Do you have a list of
border-line products? For this list of border-line products could you
provide a couple walk-through case-studies showing what method you would
use to make a determination of its categorization?
Corbet from LWN has said
What it comes down to, though, is that gadgets
intended to be sold to businesses will be exempt from the "installation
instructions" requirements. This seems strange; it may well be businesses
which would have the most use for the ability to change the code running in
devices they purchase. ... This exemption could prove to be a big
loophole. ... The exemption for devices which are not "user products" looks
similar; with this language, the FSF may well be setting us up for a flood
of "business use" gadgets which happen to available at the local big-box
Does your user product definition protect individuals against this type of
gamesmanship? Does it protect people whose hobbies approach professional
We took the definition of Consumer Product from the Magnuson-Moss Warranty
Act, and we have proposed that the license refer to its interpretation,
precisely because it has been very resistant to exactly the kind of
gamesmanship you describe. If you'll excuse some oversimplification, when
courts have been asked to determine whether or not something is a Consumer
Product under the Magnuson-Moss Warranty Act, they have generally asked one
question: do people buy it for their personal use? If so, then yes, it's a
Like I said, that's oversimplifying the issue, but it is accurate in that
those courts have not considered how the product is named, marketed,
priced, or otherwise described by its manufacturer. The main thing that
matters is who generally buys it, and for what purpose.
Any device you can buy at an electronics store should qualify as a Consumer
Product. This includes the overwhelming majority of desktop and laptop
computers, portable media players, all kinds of mobile phones, DVRs, plenty
of digital cameras, wireless routers, and other dedicated hardware.
Devices that probably don't count are the kind of very-high-end computing
equipment you would expect: Blade servers, huge rackmount Gigabit Ethernet
switches, that sort of thing.
The line between these two extremes is blurry. I don't know exactly where
we're going to settle on a cut-off point. None of these devices should be
locked down; we say that in the preamble of the draft. But the people
distributing these devices aren't locking them down just to take away
users' freedom, and right now there's no reason to believe that's going to
change—quite the opposite, actually. Meanwhile, the devices where
this is a problem are all very safely tucked under the Consumer Products
umbrella. So even if the definition of Consumer Product isn't perfect, we
think it's still a good compromise to help us achieve our goals.
The obvious hole to me [in section 6] is that there are no
limits given on what a conveyor can require the user to do in following the
installation procedure. A TiVo-like distributor could specify a procedure
in its Installation Information whereby all binaries to be installed on the
device have to be sent to it to be digitally signed by their private key
before they will run. Their procedure could work perfectly well, and
providing it does I don't see how this requirement would break the terms of
the GPLv3 at all, although it seems to be breaking its spirit.
If I have to send my binaries to them for signing, they'd also be entitled
to get my source changes since I'm now propagating a copy of code that is
licensed under the GPLv3. Could they require me to sign over any additional
rights to my modifications as part of that installation procedure?
When we wrote this language, we didn't intend for "procedures" to include
all kinds of interaction between the person conveying the software and the
recipient. All we had in mind were relatively straightforward technical
instructions—press this button, upload that file, and so on. This is
something we've gotten a lot of feedback on and we'll consider clarifying
it to better reflect what we had in mind.
Would re-wording the "Installation Information" section to apply to
all users (i.e., removing the "User Product" definition) be a additional
permission, or an additional restriction?
That would be an additional restriction. Think of it this way: suppose you
add some sort of terms to the GPL. If a licensee didn't realize those
terms existed, and just followed the plain GPL, would they also be in
compliance with your additional terms? If so, then it's an additional
permission; otherwise, it's an additional restriction.
So, in your particular case, if someone distributed your software in
something that wasn't a User Product, and just followed the terms of GPLv3,
they'd run afoul of your additional terms. So it's a restriction.
So I can add any additional permissions, but anything restrictive can only
be something from the list?
And if I recive something which claims to be licenced under the GPL, the
GPL itself removes the restrictions which shouldn't have been allowed to have
been placed there in the first place?
If I understand the phones/medical devices situation correctly, it's
possible to avoid making such devices unmodifiable by putting the
unmodifiable code in ROM rather than using tivoization to ensure that it's
unmodified. But wouldn't making code unmodifiable this way have all the
same disadvantages to the user of making it unmodifiable by tivoization?
What does the user gain by having things unmodifiable in one way rather
than in another?
You're absolutely right that, from a user's perspective, having software
in ROM is no better than having locked down software. However,
manufacturers don't put software in ROM solely to restrict people's
freedom. There are often technical reasons for this decision. It might,
for example, be simpler or cheaper.
When we think about this issue, we're primarily concerned with hardware
that looks a lot like a general purpose computer. Despite the continued
march of progress, your microwave is not going to be a useful GNU/Linux box
for the foreseeable future, and that doesn't really bother us. Even if the
manufacturer does burn some GPLed software to its ROM, what could you
really do if you had some ability to modify that? Maybe I could build a
better user interface, and that would definitely be nice. But a locked
down microwave isn't nearly as threatening to society as a locked down
And your DVR, for all intents and purposes, is a general-purpose
computer. It's capable of all sorts of interesting work, and you should be
able to put it to use as you see fit. We don't really see firmware for
those devices going into ROM; it doesn't make technical or economic
Even in portable devices where using ROM could make sense, like smart
phones and media players, the trend has been moving away from that for some
time already and that's only going to continue. Given all this, I think
the lines we've drawn work well: really limited hardware isn't
unnecessarily included, and everything else is.
Company A makes a consumer product (vacuum cleaner, personal video
recorder, coffeepot, whatever) that uses GPLv3 software. They do not sell
directly to the consumer, but rather to distributors. With each shipment,
they include Corresponding Source and Installation Instructions, to stay in
Distributor B takes possession of thousands of products from A, and puts
the box with the Corresponding Source and Installation Instructions in a
cabinet somewhere, and proceeds to sell the products without including
those things. Net result: the consumer gets an appliance with
GPLv3-covered software, without source code or installation
instructions. (To add to the problem, if I as a consumer copy the software
as it exists in the device to give to a friend to analyze, I'm in
After all, A has done what is required of it. B is not in the business of
doing anything it needs a license for, but is rather just reselling things
provided by A. If I have legitimate copies of a book, or song, I can sell
those as I wish with regard to copyright. I just can't make any more copies
without some sort of license. Therefore, B need not accept the GPLv3 to
operate, and is not bound by its restrictions. B is free to distribute
source and instructions (and A cannot forbid it in an agreement), but it
may well not be in B's interest, as B may think it will add to support
costs and possible complaints.
It's not clear that "B is not in the business of doing anything it needs
a license for." It would at least be reasonable to argue that B is
conveying the software just the same as company A is, and so is bound to
the same terms. Certainly, if you're opening the box to remove those
materials, you should be aware of what's on the device, and the fact that a
license came with it. In the United States, the first sale doctrine which
is most likely provide B with an out is especially murky when it comes to
Even if they do have no license obligations, however, this scenario does
feel a little implausible. Company B would need to have some reason to
want to undermine the GPL—enough of one that they're willing to stick
their neck out on this case. Most resellers simply don't have a dog in the
fight either way. And if B was a subsidiary or had some other relationship
to A, it could very well be possible to convince a court to see these as
the orchestrated actions of the single parent company.
[Company X] produces two hardware devices with identical processor and
peripherals, each of which stores its code in flash. Both of them take in
new firmware images from the user, but one of them additionally takes a
signature which only [Company X] can create, and only installs the image if
the signature verifes. Neither device, as constructed, uses anybody else's
[Company X] writes some lousy firmware for these that doesn't do anything
useful, but doesn't use anybody else's code. All this firmware does is let
people fetch firmware images (and signatures), and provide them to the
hardware for upgrade.
[Company X] releases enough documentation that people get Linux working on
the unlocked hardware. Other people turn this into a great
system. Everybody able to get the unlocked hardware (which is not everybody
who might want it) is happy, and can customize it to do what they want.
[Company X] downloads some images and the corresponding sources from other
people and finds images that don't do anything [Company X] wants to
prevent. [Company X] doesn't accept the GPL, because, since they do not
intend to modify, copy, or distribute the covered work, they don't have
to. [Company X] releases signatures for the firmware images they like. It
points customers at these signatures and at their author's sites (since it
can't legally distribute the images itself).
(This situation is even more likely if the locked and unlocked hardware are
by different companies, and the locked hardware is expensive, while the
unlocked hardware is provided to end users free with some service.)
Now, the only people who are bound by the terms of the GPL are the people
writing firmware images, and they're releasing everything they have. Also,
their firmware is designed for unlocked hardware, which is what they're
developing on, and what they probably expect users to have. [Company X]
doesn't need a license to hyperlink to firmware images other people
publish, and Freedom 0 means they can read the source, test it, and produce
signatures. [Company X] owns the hardware designs, including the signature
checking device, outright.
So I don't see how any possible GPL which follows Freedom 0 is going to
affect what is probably the laziest strategy for getting locked hardware
running specific versions of GPL software. It seems to me like anything
that could be prohibited by the license is actually less objectionable than
the behavior that doesn't involve the license at all.
I hope you don't mind that I changed the name of the company in your
example. This is a hypothetical situation with a pretty nasty player at
the center of it, and I don't want to suggest that anyone's quite this
mean. I get a lot of compliance by being nice to companies, after all.
I think it would be possible to bring a contributory infringement case
against the company in this situation. From what you've written, it's
pretty clear that they mean to convey the software—they produced
signatures for it, after all—and they're just using hyperlinking to
try to work around the license's requirements. That's not fooling anybody;
certainly not a judge.
But I'll go ahead and pretend for a moment that nobody wants to try to
bring that case for some reason. The thing is, I don't think that product
is going to sell. If the product doesn't even pretend to do
anything out of the box, and the first thing you have to do is download
some firmware and a signature from a web site—well, that sounds an
awful lot like a computer without an operating system, and retailers
haven't exactly been clamoring to offer that product to their customers.
So I think Company X is going to have to write some real firmware, on their
own. It won't be very good, and it drives up their development costs, but
it at least has to look nice enough that people want to pick it up off the
shelf. And then some hackers will buy it because they know they can
install free software on it, too.
When that happens, I'll have to consider starting my own company, Company
Y, because the business opportunity in this situation is just too good to
pass up. Company Y is going to build a box that looks a lot like Company
X's, except it's not going to have signature checks on the firmware.
Instead of developing my own firmware, the box will ship with some of the
firmware that other people have already written. I'll go ahead and tell
people how to build and install their own firmware, too, because what's it
matter to me? My costs are lower, so I can sell the hardware for less than
Company X's product and still make more profit on each device. On top of
that, I'm going to sell more of them, because my device has more features
out of the box, and Company Y will have a reputation of being friendly to
the free software community. I even have a cool Web 2.0-style slogan
that'll drive the point home: Y for You. And so through the superiority of
my product and my slick marketing campaign, freedom wins.
Right now, under GPLv2, I can take a piece of software, modify it, and then
charge ten billion dollars before I give anyone my modifications. That's
horrible from an abstract freedom perspective; my software's not really
free because nobody's going to pay that much. And that's exactly why we
don't worry about it: because nobody will pay that much, nobody will charge
that much, so there's no real threat to freedom. Because the GPL doesn't
really place any limits on commercial distribution of the software, the
market tends to correct towards freedom. This effect is so strong that
even the distributors who were doing everything right, who were putting
together a good package of free software with nice printed manuals and all
that, never really spent too much effort trying to charge for their work.
They decided they'd rather sell support contracts.
I think this sort of thing is another situation where there's an abstract
threat that's going to have a hard time materializing. If you're trying to
convey GPLed software without leaving your fingerprints on it, either
you're going to get too close to the copyright line, or someone else is
going to pick up the software and run with it.
Let's say that I create medical device, and I want to use some GPL v3
licensed code as part of it. Let's also say that this medical device has
the potential to kill someone if something goes wrong. Needless to say, I
don't want just anyone putting software on the device, but I want to be
able to issue code patches to be applied to existing devices.
I'll want to follow the terms of the license, but allowing some arbitrary
person to install new software on the device just isn't an option. Is there
a way to make this work within the terms of GPL v3?
Someone working in the medical industry recently mailed me with this same
question, except the software was under LGPLv2.1 instead of GPLv3. After I
explained the requirements of the license to her, I asked her a question of
my own: if her company was very careful to disclaim responsibility for
modifications to the device, and someone did it anyway and caused a
problem, what would happen? She answered without hesitation: "Oh, it'd
FDA regulations on medical devices are very strict, mostly for good reason.
Right now, letting users modify the software on their devices is forbidden.
That's something we want to change, but it would be premature to address
this directly in the license; we need to campaign for some regulatory
I don't see how this wording in any way affects a covenant provided by a
third party to users. It clearly refers to a license but I am sure I read
somewhere that the way they got around GPL2 was by avoiding a license and
creating a "covenant to customers" instead. I don't see how this is
addressed in any way here.
Using a covenant is not really the way the Microsoft-Novell deal tries to
step around GPLv2. The license says that if you have any
conditions imposed on you that prevent you from fulfilling the terms of the
license, you cannot distribute the software at all. This is true whether
the conditions come from a patent license, a covenant not to sue, or
We still have you covered, though. See the second paragraph of section
11, which says:
For purposes of the following three paragraphs, a "patent license" means
a patent license, a covenant not to bring suit for patent infringement,
or any other express agreement or commitment, however denominated, not
to enforce a patent.
Why would you have a phrase like "with a third party that is in the
business of distributing software" in paragraph five of Section 11?
If I'm MS, wouldn't I just license a few critical patents to a patent troll
and let them do the the dirty work?
... and Anonymous wrote:
I've heard it eluded to that Microsoft already has in place patent
agreements with businesses over the use of Linux and other opensource
software already. How do you protect against that? If you're in business
and a company like Microsoft approaches you and says your use of that
software infringes our IP. Pay us and as a stipulation, keep it a
secret. How do you respond to that or as a community, protect against that?
The reason the Microsoft-Novell patent deal is so nefarious is because it
puts pressure on all free software users to pay a fee to Microsoft. That
only works because a few things are true about the company. First, it has
a large patent portfolio, and other companies are concerned that a typical
GNU/Linux installation may infringe those patents. Second, Microsoft sees
free software as a competitor, and so we know it's going to do everything
it can to make life hard for free software users. If one of those weren't
true, the same pressure wouldn't materialize.
A standard-issue troll doesn't create this effect because it doesn't see
free software as a competitor. In fact, it doesn't have any competitors at
all; it's just a leech. They'll threaten anybody who has enough money to
be a worthwhile target that they think they can win against, and once they
have their money they'll go away until they get another patent to use.
They would never sue me personally because it doesn't gain them anything.
In fact, other companies distributing free software have already made
patent deals with trolls similar to the Microsoft-Novell agreement. We
don't want to penalize them for this; it doesn't hurt the community, and
it's sometimes the most economical way to deal with the problem. That's
why this limitation is there.
GPLv3 is going to provide free software developers with more protection
against patent aggression than any other license. It's one of the best
reasons to adopt the license. But it's not going to solve all of our
problems with patents; it never could. If Microsoft decided to wage
full-scale war and start suing all free software users for patent
infringement, consequences be damned, no license could stop them. The only
way to solve that problem once and for all is to abolish software patents.
In the meantime, the whole community needs to cooperate to make Microsoft's
war more expensive. The new terms in GPLv3 are part of that. Patent pools
like OIN are another part. We have been making progress on this, though I
do wish it were a little sooner coming.
It isn't quite obvious to me that Microsoft has "propagate[d] by procuring
conveyance of" Linux in the Microsoft/Novell deal. My understanding of the
deal is that Novell distributes Linux and Microsoft agrees not to assert
its patents against Novell's customers. How exactly does this constitute an
act by Microsoft of procuring conveyance?
The deal between Microsoft and Novell also includes some marketing
cooperation. Microsoft provides coupons for SUSE to companies, who then go
to Novell to redeem the coupons and get their copy of the software. Those
coupons procure the conveyance of lots of free software.
Our lawyers have seen the terms of the deal under
NDA—unfortunately, they're still secret—but they're confident
that Microsoft is already conveying GPLed software under this agreement.
The coupons are the most direct proof; there is some other evidence to
support that idea as well.
I parse section 11 paragraph 3 as: IF ( rely-on-patent-license AND
source-not-available ) THEN...
But the source is required to be available (by section 6). What
is the difference between this and the section 6 requirement (other than
"free of charge")?
Paragraph three of section 11 is concerned with whether or not the
source is publicly available to everyone. Section 6 only requires
distributors to provide source to their recipients.
As to option (1), how does having the source help with patents?
When someone is relying on a patent license in order to convey a GPLed
work, it creates a number of problems. For starters, the people who get
the software may be afraid to convey it to other people. In that scenario,
everybody would effectively pay a royalty to the licensee, and there won't
be any competition pressuring them to bring the price down, either. When
the source is publicly available, it's harder for them to set up that toll
What can the user do with the source they download? Depending on what
patents are involved, and how the software is written, it might be possible
to modify the software so that it no longer infringes them. For instance,
if the software is a video playback program using licensed codecs, you
could modify it to use Ogg Theora instead, and still benefit from interface
code and other generic features that were in the original program.
Depending on your jurisdiction, you may also have some protection from
patent infringement claims, depending on exactly who you got the software
from and how they're related to the licensee. It seems likely that you
have at least some sort of implied license to exercise your rights under
the GPL. There's still some legal risk here, but not as much as there has
been in the past. As always, each user will have to decide for themselves
how much risk they can handle.
As long as noncommercial developers can get the code, we think patent
licensees will have a hard time breaking the development and distribution
cycles for free software. This option, along with public availability
requirement earlier in the paragraph, keeps the code flowing.
As to options (2) and (3), if you don't hold the patent yourself, then how
can you disclaim or extend the patent license, for yourself or for others?
I'm not sure I understand what would prevent you from disclaiming your own
license. All we require in option 2 is that you make it clear that you are
not relying on your patent license when you distribute the software. If
the patent holder wants to sue someone for patent infringement, they'll be
pressured to go after the distributor who disclaimed the license first.
Other users can see how that case develops to inform their own decisions
about how much risk is involved when they use the software.
Option 3 acknowledges that you must "arrange... to extend the patent
license." In other words, we realize that you can't do this unilaterally;
you'll have to discuss it with the licensor.
Question number one: if GPLv3 is incompatible with
non-problematic patent agreements, could this be misused to make it harder
for corporations to join the community? Imagine corporation A does not
distribute Free Software today. Some unfriendly organisations may trick
corporation A (after the date limit) into patent cross-license agreements
that are incompatible with the GPLv3. Then corporation A is unable to
change its mind at a later time and distribute Free Software. This could be
the basis of an attempt to limit the community growth.
Yes, this is a very real concern. That's why we've attempted to draft
those particular terms as narrowly as possible.
Question number two: What if someone structured his organisations into
separate parts where the owners of the patents that sign cross-licensing
deals is a different legal entity than the parts of the organisations that
depend of GPLv3 software? For example, you could have a holding where there
is a patent troll outfit and a software development outfit and all software
patents on the development outfit products are transfered to the troll
outfit before they are licensed to third parties. The software development
can use GPLv3 software a lot, but the troll outfit never uses any. This is
an example among other possible scenarios.
I ask because I think you have to be a GPLv3 licensee for this section
11 to be applicable to you. If the patent licensing outfit is a seperate
legal entity, it will not hold a GPLv3 license and will not be bound by its
terms. In this case couldn't the patent arm get to sign cute patent
agreements with third parties?
We are considering adding terms to the license so if an organization
distributes GPLed software, its patent obligations would be extended to
organizations it controls as well. That would help address this case
That said, this seems like a remote possibility; I have to question what
the overlord organization gets out of this arrangement. Very few companies
have such incentive to try to undermine the GPL, and even if they went
through this sort of kabuki dance I think it would be self-thwarting, as I
Question number three: If it is OK to let Novell/Microsoft get away with
paragraph 5 before the cutoff date because paragraph 4 is good enough, why
isn't it OK to also let them get away after the cutoff deal? I ask because
depending on the answer to first two questions paragraph 5 may hurt Free
Software friends more than it hinders those getting cute with the GPL.
Novell did a lot of damage to the community's patent defenses when it made
its deal with Microsoft. We need to discourage other distributors from
making similar arrangements, and paragraph 5 serves that purpose much more
effectively than any other part of the license.
While we were drafting this language, we worked extensively with the
friends of free software you're talking about, and we continue to do so, to
ensure that this language will not cause undue problems for them. These
conversations have been productive and it's quite possible that we'll make
a couple of adjustments based on what we hear.
Could I ask for a clarification? It seems to me on reading the relevant
bits of the GPLv3 that the GPLv3 patent provisions only cover GPLv3
code. Is this right?
With one caveat, that's correct. We could've written them more broadly,
but that would've been asking too much of the large patent holders who
distribute free software.
I guess that could lead you to the question: why don't Microsoft and Novell
make a patent agreement which explicitly excludes all GPLv3-covered
software from its scope? That leads us to the caveat: paragraph 5 of
section 11 kicks in if the patent license or covenant not to sue covers a
product or compilation of software that includes some portions under GPLv3.
So, if you create a distribution that includes any software under GPLv3,
you can't arrange to provide discriminatory patent protection for that
distribution, even if you try to carve the GPLv3ed parts from the deal.
Section 0 paragraph 6 excludes private modification from the
definition of "propagate". This seems to create an anomaly: making a
verbatim copy is propagation, but if I make a trivial change to the
work (say, copy all but one byte), then I have a modification, and it
escapes from the definition of "propagate".
I've grep'd the text of the license, and I can't find any place where
this would make a difference, but I'm curious why it was done.
Under copyright law, you need to have permission if you want to modify a
work, even privately. So, if people are going to release their work under
the GNU GPL, the license has to provide permission to do that. However,
we're not particularly interested in placing restrictions on private
modification, so we carve that out of the definition of propagate, and make
it clear that you have permission to do this in section 2.
Of course, if you give a copy of the modified work to someone else,
that's something else entirely, and falls under the definition of convey.
That's the main goal of these new terms: to draw a clear line between the
acts that we've historically considered distribution—the kind that
provide other people with a copy of the work—and those that don't.
So, we want to define propagation to include any activities that involve
making a copy. Then we define conveying as the subset of those acts that
involve giving the copy to another party. Excluding private modification
from the definition of propagate should help make that line even
What does "occasionally" mean, there [in section 6(c)]?
We don't have any secret, precise legal meaning in mind. It means the same
thing it does in everyday English. Yes, different people will have
slightly different ideas about what exactly counts as occasional. That's
okay by us; we're comfortable with any of the possibilities a judge is
likely to accept.
Removing automatic termination from the GPL seems to be a
serious error given the breadth of people who contribute to GPL licensed
software (many of whom don't have the resources to identify and notify
violators) and the difficulty of determining if a proprietary package
contains GPL code in violation of the copyright.
What then is the rationale for removing automatic termination, and why
should we wish to license code under the GPLv3 if it fails to include an
automatic termination clause?
Dealing with license violations is a major part of my job. When I
determine that someone's violating the license on some piece of software
where the FSF holds the copyright, like GCC or coreutils, I send them a
letter. It tells them everything they need to know up front. I explain
what the license requires, and how they failed to meet those obligations.
I inform them that they've lost their rights to continue distributing the
software, and we'll restore those rights if they work with us and take
appropriate steps to cure the violation.
This hasn't happened to me personally yet, but occasionally a violator
will think to ask: what about our rights for all the other software we were
distributing? How do we get those back?
That's a very tough question to answer. We do have an answer for it,
but it's not exactly satisfying to some of these companies. Everyone
involved, including me, could breathe a lot easier if there were a clear
way to get all your rights back, and the new termination clause provides
As long as enforcers of the GPL are primarily concerned with bringing about
compliance, I don't think the new provisions will undermine their work.
While the violation is ongoing, a copyright holder can always put the
violator on notice, and once that happens they have all the time in the
world to pursue the matter however they want. And if the violator already
brought themselves into compliance, then we've reached our goal.
wrote, in reference to "Any attempt otherwise to propagate or modify it
is void" in section 8:
What does that mean? Can you give an example of a situation
where the outcome would be different if this sentence were omitted from the
No, this sentence doesn't actually change anything. It's only meant to
remind you of what copyright law already says: you're not allowed to change
or share the work unless the copyright holder or the law itself gives you
permission to do so.
Shouldn't distribution in any country be limited by patent laws in that
country? What happens if Congress passes laws to limit exports to Iran of
patented technology which is available under an unrestricted royalty free
license acceptable to GPLv3? Can Microsoft or someone else use this clause
in GPLv3 to block the use of programs in the US on the basis that it doesn't
comply with the GPLv3 requirement that it must be distributable to everyone
including individuals in Iran? Of course distributing in Iran won't be a
problem because US law doesn't run in Iran, but what is worrying is whether
it may be used to block use of the GPLv3 program in the US.
This is a good question. In fact, it might not be as hypothetical as you
think. After all, there's a piece of free software you're not allowed to
develop or distribute in the United States already; it's called DeCSS.
A license can't give you permission to break the law. As long as the
law doesn't expressly prohibit you from fulfilling your obligations under
the GPL, we don't think it can be used as an argument under section 12 to
cease conveying the program. So, in your example, I can convey a copy of
GPLed software to someone in the U.S., and also pass along the source and a
copy of the license, and I've done everything I'm required to do. I'm not
the one who insists that my recipient not convey the software to Iran; the
government does. I shouldn't be held responsible for that.
It's also unlikely that Microsoft would be able to even try this sort of
action. If anyone were going to do it, it would be the copyright
I myself have a couple projects that I release under the GPL. Something
that I would like to add as a limitation to my license is to have it
automatically expire when a new version of the GPL is released, with the
option that the person may then relicense it under the new version of the
I was thinking that this could be an allowed limitation in section 7. It
would be completely voluntary on the part of the developer, so I can't see
that it would be a hard sell either.
Just thinking of this possibility with respect to the Novell deal makes
for a lovely fantasy. It allows me as a developer to not have to worry
about a future loophole, because if something comes up strong enough to
warrant a license change, my software is retroactively covered. The day
after GPL v4 is released, whomever is misusing an unforeseen loophole in
GPL v3 is cut off.
In these days where software is often "patched" to retroactively fix a
bug, wouldn't it be nice if a license could be too?
I appreciate your enthusiasm for GPLv3, and definitely understand your
concerns. However, adding a feature like you describe isn't really
feasible. One big reason is that it's not clear to us how to have it work
effectively. How do users find out about new versions of the GNU GPL?
What if they don't have Internet access? What if the web is superseded by
another system? And so on.
Another reason is that this sort of language in general has the
potential to grant rights to users initially, and then take them away at a
later date. While there are specific circumstances where this seems like a
good idea, we must make a principled stand against this. A license that
can be changed from under you is a license that can take away your freedom.
While the GNU GPL would never do that—it will always be a free
software copyleft license—we must not encourage other license authors
to adopt such language.
A highly politicized area where copyright like restrictions and patents are
indeed harming people is the field of Plant Breeder's Rights which give a
plant breeder a copyright like monopoly on plant varieties. It has been no
exception that farmers and plant breeders in the developing world have
developed new pest and stress resistant varieties of important crop plants,
only to find them being hijacked by a commercial breeder who starts
enforcing Plant Breeder's Rights against the original breeders. Patents on
genetically modified plants are a dime a dozen. Many large companies also
produce Tivo like restrictions on seed. For instance, by manipulating the
plants to be sterile when raised from their seeds.
While reading the rationale document, I was wondering whether the GPL could
be used to cover new plant varieties? And whether it would need
I'm afraid I can't answer your questions authoritatively; unfortunately, I
don't know enough about this particular issue. In the latest draft, we did
introduce some small changes so the license works more effectively with
laws similar to copyright, such as semiconductor masks. I imagine that
might help. The idea of copylefting plants certainly sounds intriguing,
but it's a little out of our field—we are the Free Software Foundation,
Also, what are we going to do about the FUD that Microsoft will put up over
the MS-Novell deal? I think it's already clear that they paint the GPL as
"anti-business" but here, they'll probably try to sell it as a risk that
the GPL can be amended to punish you if you use it. Never mind that that's
largely ridiculous, only applies to new code, and would only ever happen if
you were trying to do something to extort free software users, I don't
doubt that they're already preparing a media blitz over it.
Is any PR machinery in place, yet, to handle this?
In the past few weeks, we've gotten a good sample of the tactics
Microsoft is going to use against GPLv3. The so-called Association for
Competitive Technology has been on the warpath. GPLv3 is an unenforceable
contract, they say. You can't negotiate it. It's going to send us back to
the bad old days of technology when different pieces of software couldn't
talk to each other. Apparently, their plan is to say anything they can
think of that sounds scary, and then see what sticks.
Nothing good ever came of underestimating Microsoft's power, but I think
this is a pretty good sign for us. I don't think they're fooling anybody
who honestly has an open mind about this subject. And once you see other
big companies releasing software under GPLv3, I think that'll do a lot to
dispel the FUD right there.
Of course, we are keeping an eye on what they say, and we do have ways
to react if things get nasty. We've put too much work into the substance
of this license to let it be defeated by marketing. Like I said at the
beginning of this, we do need to be smart in how we move forward. Drafting
the license has been the focus of much of our efforts lately. A lot of
talking and listening and careful consideration has gone into the language
we have today, and I think it represents a great step forward for software
freedom. Given that almost all the harsh criticism has come from
Microsoft, I'm hopeful that you all—the community—agree.
And with that, I think I've addressed all the concerns that were raised.
Thanks again for all your feedback—GPLv3 is a better license because
of your support.