Leading items

GPLv3: a first look

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, which 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:

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:

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 code":

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.

Software patents

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:

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 document:

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 added:

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 holders.

Additional terms

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 optional restriction:

Beyond that, version 3, like its predecessors, explicitly disallows the imposition of additional restrictions.

Other changes

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 .NET API patent, mono, and GNOME

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:

"...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.

This message 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:

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 decision.

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 resolved.

[The author wishes to disclose that he holds stock in Red Hat, Inc.]

Comments (30 posted)

The return of software patents in Europe?

Last July, when the European Parliament killed the software patent directive, few people thought that it would remain dead forever. The sorts of 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:

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>>