The Free Software Foundation has, at last, made a draft version of version 3 of the
General Public License
available for comments. Your editor, having
read it five minutes ago, is now ready to comment. What follows is a quick
overview of the changes which have been made to the GPL; anybody wanting
more information should certainly read the accompanying rationale document
describes the changes - and their motivations - in detail.
The GPL is an important license. It is the most popular of free software
licenses, and it covers many important components of a Linux system. It is
a codification of the FSF's view of how free software should work, and it
imposes some real obligations on those who redistribute GPL-licensed
software. It is a core piece of our legal source code. So a major
revision of the GPL requires a great deal of thought. In your editor's
opinion, the FSF has put in that thought, and has put forward a revised
license which meets current challenges while remaining true to the spirit
of previous versions.
Digital restrictions management
Many of the changes in GPLv3 have to do with DRM schemes. The license
makes the FSF's position on DRM quite clear, and does its best to ensure
that GPL-licensed code will stay as far away from DRM as possible.
To start, the license makes its intent with regard to DRM clear:
As a free software license, this License intrinsically disfavors
technical attempts to restrict users' freedom to copy, modify, and
share copyrighted works. Each of its provisions shall be
interpreted in light of this specific declaration of the licensor's
intent. Regardless of any other provision of this License, no
permission is given to distribute covered works that illegally
invade users' privacy, nor for modes of distribution that deny
users that run covered works the full exercise of the legal rights
granted by this License.
The purpose here is to help ensure that, in any future court case, all of
the terms of the GPL will be interpreted with an anti-DRM bias.
An interesting clause can be found in section 3:
No covered work constitutes part of an effective technological
protection measure: that is to say, distribution of a covered work
as part of a system to generate or access certain data constitutes
general permission at least for development, distribution and use,
under this License, of other software capable of accessing the same
This provision is clearly targeted at anti-circumvention laws. If it
stands up, it says users can bypass any restrictions encoded in
GPL-licensed software without circumventing "technological protection
measures," since no GPL-licensed program can be part of such a measure.
Another key provision can be found in the revised definition of "source
Complete Corresponding Source Code also includes any encryption or
authorization codes necessary to install and/or execute the source
code of the work, perhaps modified by you, in the recommended or
principal context of use, such that its functioning in all
circumstances is identical to that of the work, except as altered
by your modifications. It also includes any decryption codes
necessary to access or unseal the work's output.
In other words, "trusted computing" mechanisms designed to keep people from
replacing the software on their gadgets cannot be used with GPLv3-licensed
software. This is a large and important change - though its effect will be
somewhat limited for as long as the Linux kernel remains licensed under
version 2 of the GPL.
As expected, the new version of the GPL addresses software patents in a
much more comprehensive manner. One fundamental change is that anybody who
redistributes software covered by the GPLv3 is explicitly granting all
patent licenses needed to use the software. This grant covers "all
versions of the covered work," and would seem to override the "field of
use" restrictions imposed by some patent owners.
Here's an interesting addition in v3:
This License gives unlimited permission to privately modify and run
the Program, provided you do not bring suit for patent infringement
against anyone for making, using or distributing their own works
based on the Program.
It is, of course, a patent retaliation clause. If you launch a patent suit
against somebody using a specific program, you cannot make any further use
of that program. It's a big departure from GPLv2; the previous version of
the license imposed no restrictions on individual use of the software at
all. With GPLv3, the right to use the software - not just to redistribute
it - can go away as a result of filing a patent suit.
There are no other patent retaliation clauses in the GPL itself; the FSF is
not entirely comfortable with this concept in general. From the rationale
Several other free software licenses include significantly broader
patent retaliation provisions. In our view, too little is known
about the consequences of these forms of patent retaliation.
There is, however, a subsection which allows the incorporation of
additional, limited patent retaliation terms. Terms which take away use of
the software for filing a wider range software patent lawsuits can be
They may impose software patent retaliation, which means permission
for use of your added parts terminates or may be terminated, wholly
or partially, under stated conditions, for users closely related to
any party that has filed a software patent lawsuit (i.e., a lawsuit
alleging that some software infringes a patent). The conditions
must limit retaliation to a subset of these two cases: 1. Lawsuits
that lack the justification of retaliating against other software
patent lawsuits that lack such justification. 2. Lawsuits that
target part of this work, or other code that was elsewhere released
together with the parts you added, the whole being under the terms
used here for those parts.
So the GPLv3 does not include full-scale patent retaliation, but there
should be enough there to get the attention of some types of patent
A few other types of additional restrictions are allowed in GPLv3. These
include limits on trademark use or the use of contributors' names for
publicity purposes. The idea here was to try to make the GPL compatible
with a wider range of free software licenses.
The much-discussed "web services loophole" is also addressed by way of an
They may require that the work contain functioning facilities that
allow users to immediately obtain copies of its Complete
Corresponding Source Code.
Beyond that, version 3, like its predecessors, explicitly disallows the
imposition of additional restrictions.
Under version 2, termination of the license was automatic if its terms were
violated. In theory, one who had gone against the GPL would have to go and
explicitly beg forgiveness before being able to distribute the relevant
software again. Back in 2000, Richard Stallman told
the KDE developers that they had to ask forgiveness in this way.
Version 3 changes the terms to put the onus on copyright holders to
terminate a license. Any copyright holder can do so if the terms are
violated, but a violator who mends his ways need not ask forgiveness from
any copyright holder who has not exercised that right.
Version 2 contains a clause saying that, if a program cannot be distributed
in a way which complies with both the GPL and any other restrictions
(patent licenses in particular), it cannot be distributed at all. There
has been some disagreement over just how strong that restriction is. GPLv3
makes it clear that a strong interpretation is expected; this section is
now titled "Liberty or Death for the Program."
The geographical restrictions clause, which allows terms disallowing the
distribution of code in certain countries due to legal problems there, has
been retained in GPLv3. The rationale document states, however, that the
FSF knows of no actual use of that clause, and they suggest it could be
removed during the comment period.
There are many other changes, mostly aimed at clarifying intent and
ensuring that the license is enforceable worldwide. Again, interested
parties are urged to read the license itself and the rationale document for
the full story. They will then be prepared to take part in the comment and
revision process, which is expected to last for about one year. If all
goes well, the FSF hopes to adopt GPLv3 in January, 2007.
Comments (110 posted)
The Mono project pushes a lot of buttons in the free software community.
Patents, Microsoft, language choice, and platform choice all generate lots
of heat individually, and Mono has them all. In spite of all the debate,
there are still some issues that remain unresolved. There are undoubtedly
some people who have been avoiding Mono just because Red Hat was; now that
Fedora has it (while RHEL is still apparently up in the air) it's tough to
know if Mono is safe to use or not.
I'm not a lawyer, but since everyone who has gotten advice from one (or
who is one) is being tight-lipped about it, the rest of us apparently have
to figure things out the best we can. I asked Red Hat Deputy General
Counsel Mark Webbink about the decision to include Mono, and he replied:
I think you can understand that I cannot discuss Red Hat's internal IP
policy. I would point out that the decision to include Mono with Fedora
was made by the Fedora Foundation and its project folks. I feel confident
the determination was made with an understanding of various patent concerns
that have previously been posed to Novell but also with an understanding
that there are protections available to open source developers, vendors,
"...protections available to open source developers, vendors,
etc."--sounds like the patent pools that are intended to create a
mutually-assured-destruction sort of scenario for anyone wanting to sue
open source projects for patent infringement. These pools have
been derided as PR gimmicks, but Webbink's note makes it sound like
some people are willing to actually put some trust in them.
also makes it sound like the Fedora decision-making mechanisms are finally
starting to become separate from Red Hat's. I sent a message to Greg
DeKoenigsberg of the Fedora Foundation, and I got the one-sentence official
line in return:
"Business considerations that prevented certain Mono components from
included in Fedora previously have now been resolved."
Greg also suggested that more information may be forthcoming soon.
One of the really
interesting aspects of the timing is the fact that the main
patent application that has been discussed in the media (the API patent
application) appears close to being automatically abandoned.
The API patent, if it were granted, would be a big blow to the
Mono project. Many patents on various aspects of the implementation could
have been worked around, but the API implementation not only makes up a
significant portion of the Mono codebase (making it a big project to
re-do), but is also what all software written for Mono/.NET uses. If
the API becomes unusable, you can't hide a work-around in the Mono
internals, because the API forms the connection between Mono and the rest
of the world.
In October of last year, the patent office issued a "Non-Final
Rejection" to the patent application, meaning that
Microsoft can try to fix the application. Indeed, if you read the
non-final rejection, there are several suggestions the patent examiner makes
about how to fix problematic issues. However, there is also a big section
of the rejection notice that talks about prior art in the form of two
already-issued patents. Those could be harder to work around.
The rejection notice says that the deadline for reply is three months
from the date of mailing, which was October 21st, 2005. It has now been
almost three months, and Microsoft has not yet replied. According to the
rejection notice, if there's no reply before the deadline, the application
is automatically abandoned.
What does that mean? Well, ask a lawyer, I guess, but it sounds pretty
good for Mono. More importantly, maybe, is what it means for GNOME. In
the spring of 2004, there was a big discussion on whether to
begin using Mono in the GNOME core desktop. For example, see Havoc Pennington's essay on
the topic. Clearly, it would be good to start writing core
functionality in something nicer than C; however, the GNOME developers are
understandably reluctant to open things up too widely and end up with a
large number of different languages in the core desktop. The debate didn't
reach a conclusion, with Novell going one way, Red Hat going another, and
the community left hanging, with little information with which to make a
Since then, several useful GNOME-targeted applications have been written
using Mono. With the confusion regarding whether or not Mono would end up
in all the major distributions, though, those applications have undoubtedly
not gotten as much support and contributors as they could have. There are
also non-Mono alternatives to some of them. While competition between
projects is certainly healthy and a good thing in general, one of the
strengths of free software is the ability to share and cross-pollinate. If
different projects use different languages, libraries, and platforms,
though, that sharing becomes much more difficult. Hopefully, some clarity
on Mono's risks is forthcoming, and then maybe the split can be
[The author wishes to disclose that he holds stock in Red Hat, Inc.]
Comments (30 posted)
Last July, when the European Parliament killed the software patent
directive, few people thought that it would remain dead forever. The sorts
people who push for that sort of expansion of legal monopoly rights tend to
be tenacious; they do not give up easily. Still, the recent headlines
proclaiming the return of the software patent debate were a bit of a
surprise; one would have thought that the pro-patent camp would lie low for
a little bit longer.
In fact, what is on the agenda now is not really a return of the software
patent directive. It is, instead, the longstanding idea of a "community
patent," which would apply across the entire EU. The idea is not entirely
nonsensical; patenting an idea across the EU is currently a lengthy and
expensive affair. People and companies interested in obtaining patents
would really rather go through the process just once; the community patent
would make that possible. The text
of the proposal [PDF] is available for those who are interested.
An attentive reader will note that there
is no mention of software patents in the proposal.
Where the trouble comes in is with this clause here:
The European Patent Office will play a central role in the
administration of Community Patents and will alone be responsible
for examination of applications and the grant of Community Patents.
So, if somebody were to convince the EPO to start granting patents on
algorithms, community software patents would be a reality. The unfortunate
news here is that the EPO has been happily granting software patents for
some time. FFII has put together a list of some
of the worst EPO software patents; included therein are patents on
JPEG, MP3, tabbed dialog boxes, form processing in web servers, some remote
procedure call protocols, electronic shopping carts, and more. Such
patents have no Europe-wide significance now, but, if they were issued as
community patents, the situation would then be different. At that point,
the only hope would be a court battle with the objective of getting
software patents declared invalid. Not a fun process. Besides, it was in
the courts that software patents became enforceable in the U.S.
Before this situation could come about, however, the community patent
proposal would have to be adopted. That has not happened, so far, despite
years of trying. Still, if there is to be a renewed push to establish a
community patent, it would be much better for that patent to come with
clear rules about the patentability of software. The current consultation
period goes through the end of March; there will be a European Commission
hearing on the community patent on June 13, 2006. So there is not a
lot of time to push for changes.
Comments (1 posted)
Page editor: Jonathan Corbet
Next page: Security>>