User: Password:
Subscribe / Log in / New account

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:

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

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

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.

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:

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

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

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

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.

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

January 18, 2006

This article was contributed by Mitch Skinner

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, etc.

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

"Business considerations that prevented certain Mono components from being 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 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:

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

Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds