The recent discussions on the proposed version 3 of the GNU General Public
License have been well documented here and elsewhere. This proposal has
clearly exposed some differences of opinion within the development
community, with the anti-DRM provisions being at the core of the debate.
The addition of these provisions has created a fair amount of ill will
against the Free Software Foundation; opposition to them appears to have
created similar feelings in the opposite direction.
In theory, this disagreement should not come about. GPLv2 contains the
9. The Free Software Foundation may publish revised and/or new
versions of the General Public License from time to time. Such
new versions will be similar in spirit to the present version,
but may differ in detail to address new problems or concerns.
If the FSF is adhering to its part of this bargain, then anybody who bought
into the "spirit" of GPLv2 should not have trouble with this revision. So,
clearly, those who oppose the GPLv3 draft - many of whom have released vast
amounts of code under GPLv2 - believe that the revisions are not "similar in
spirit." Some have gone as far as to accuse the FSF of using its power
over the GPL to push its founder's radical agenda onto the code of large
numbers of unwilling developers.
That accusation is probably over the top. The FSF is, with GPLv3,
attempting to respond to a number of problems as it sees them. Software
patents are a clear problem, and the GPLv3 draft tries to mitigate that
problem somewhat. International applicability of the license has not yet
proved to be a problem in practice, but it is clearly something that
reasonable lawyers can worry about. It seems worth fixing the language
before some court somewhere on the planet decides that the GPLv2
incantations only work in the US. And so on.
The FSF also, clearly, sees locked-down systems as a problem. It is
interesting that this has not always been the case; back in 2000, LWN took issue with an interview with
Richard Stallman, where he said:
I'm less concerned with what happens with embedded systems than I
am with real computers. The real reason for this is the moral
issues about software freedom are much more significant for
computers that users see as a computer. And so I'm not really
concerned with what's running inside my microwave oven.
(This interview has disappeared off the original site, but the
Wayback Machine has it).
Most TiVo owners probably see their gadget as being more like a microwave
oven than a computer. It is not that TiVo has come along since then (the
2000 LWN article mentions it); what has changed is the FSF's - or, at least,
Richard Stallman's - position on it.
There are few people who disagree with the idea that locked-down systems
can be a problem. Beyond the fact that such devices will always deny users
the full potential of the hardware, they can spy on us, deny fair use
rights under copyright law, lock us out of our own data, prevent us from
fixing serious problems, and so on. Locked-down systems are designed to
implement the goals of somebody other than the ultimate owner of the
device. Such systems are undesirable at best, and outright evil at their
The disagreement is over how this problem should be addressed. The two
sides, insofar as there are two clear sides, would appear to be these:
- The anti-DRM provisions are a licensing-based response to a legal
and market problem. They prohibit legitimate uses of the technology
(examples could be ensuring that certified software runs on voting
machines or systems - like X-ray machines - which could hurt people if
the wrong software is run) while failing to solve the real problem.
These provisions are trivially circumvented by putting the software in
ROM, do nothing about the DRM being incorporated into all aspects of
computing systems, and would primarily result in Linux being replaced
with proprietary software
in the embedded market. These provisions are a new restriction on how
the software can be used, and, thus, are not "similar in spirit" to
- The new provisions are needed to preserve the user's freedom to
modify, rebuild, and replace the original software on devices that
this user owns. Failure to provide encryption keys when the hardware
requires them is a fundamental failure to live up to the moral
requirements of using free software and, according to some, is
already a violation of GPLv2. DRM is an evil which threatens to take
away many of the freedoms we have worked so hard to assure for
ourselves; it must be fought whenever possible and it certainly should
not be supported by free software. The anti-DRM provisions simply
reaffirm the freedoms we had thought the GPL already guaranteed to us,
and, thus, they are very much "similar in spirit" to GPLv2.
This logjam looks hard to break. Your editor, in his infinite humility,
would like to offer a couple of suggestions, however:
- Reasonable people who believe in free software, and who have put
much of their lives into the creation of that software, can support
either of the two viewpoints above (or other viewpoints
entirely). They are not (necessarily) free software fundamentalist
radicals, corporate stooges, people on power trips, or any of those other
mean and nasty things they have been called in recent times. We can
discuss this issue without doubting each others' motives and without
the need for personal attacks.
- The FSF clearly has some strong feelings about what it wants to
achieve with this license revision, and there are issues it does not
want to back down on. There have also been signs, however, that the
FSF is listening more than it has in the creation of any other
license. This process is not done yet, there is no GPLv3 at this
time. Continued, polite participation in the process would seem to be
Finally, while your editor is standing on this nice soapbox... The
anti-DRM language was very appealing when it first came out. Your editor
does not much appreciate the idea of some vendor locking up his software
and selling it back to him in a non-modifiable and potentially hostile
form. It is a violation of the social contract (if not the legal license)
under which the software was contributed.
But the attempt to address this
problem in GPLv3 carries a high risk of splitting the development community
while doing very little to solve the real problem. Dropping that language
could help to bring the community back together behind the new license,
leaving us united to fight DRM (and numerous other attacks on our freedom)
in more effective ways. The FSF may want to consider whether, in the long
run, its goals would be better served by a license which lacks this
language. Such a license might be closer to the spirit which brought this
community together in the first place.
to post comments)