LWN.net Weekly Edition for April 20, 2006

Guides to the patent commons

OSDL has recently released two documents aimed at helping free software developers who wish to make use of software patents which have been made put into a patent commons. They are (both in PDF format):

• Understanding Patent Pledges: Overview of Legal Considerations, and
• A Developer's Guide to Using the Commons.

The Overview document provides a brief introduction to the legal theory behind patent infringement and talks about the various ways in which people can get in trouble for using patented technology. The core bit of advice would appear to be "know what the covered patent provides and do not go beyond it." Thus, for example:

The paper describes just how easy it is to get into trouble, even when using technology which, it seems, is covered by a patent which has been donated to the community:

Software patents, in other words, are dangerous territory, and even having the license to use a particular patented technology does not really mean that using that technology is safe. But we already knew that.

The developer's guide is similar, in that it advocates understanding what is truly covered by a patent and not exceeding that patent's claims. Specifically:

It also suggests being clear on how any patent donation might be terminated in the future. This can only be good advice; a "patent pledge" which can vanish in the future is not worth a whole lot.

For developers, however, the best information to be found in these documents may not be quite what its authors had intended. From the Overview:

Ignorance, sometimes, is bliss. That is why Linus Torvalds discouraged looking at patents back in 2002:

The fact of the matter is that all of the discussion in these documents of "relying on pledged patents" to "innovate safely" is pretty well useless for developers. A patent pledged for use in free software is much like a single mine removed from a minefield. It is a good thing, but it does not make the field much safer to walk across. The existence of the patent commons does not change the nature of the minefield.

Any developer who tries to "innovate safely" by restricting work to algorithms covered by pledged patents - while carefully avoiding improving on those algorithms in any way - will be unable to innovate and will be no safer. The range of algorithms covered by software patents in the U.S. (and elsewhere) is astounding; there is no way to write any sort of non-trivial program without infringing on at least a few of them. The patent commons will not change that situation in any useful way; it is not something upon which developers can rely.

Where pledged patents may be more useful is with organizations like the Open Invention Network (discussed here last week) which can use patents offensively against those who attack the free software community. But the real solution is to fix the legal system and - in parts of the world which do not currently recognize software patents - keep it from becoming broken. As long as the system empowers and encourages patent trolls, there will be patent trolls, and a few "maybe safe if you do not try to improve on them" patents in a patent commons will not discourage them. So, while the new documents can provide some useful insights into the hazards of software patents, no developer should, after having read those documents, feel any safer.

Comments (10 posted)

Rockbox's jewels

LWN readers are familiar with Rockbox; this project (which has developed free firmware for a number of digital audio players) has been mentioned here several times, and was reviewed in detail last January. Since Rockbox operates in the sensitive area of media playback, it is not entirely surprising that the project has managed to attract an unpleasant cease-and-desist note from an outside party. It is surprising, however, that the dispute involves jewels.

In particular, the Rockbox developers have received a notice from a manager at PopCap Games, the makers of "Bejeweled." He came out swinging:

The initial reaction is best described as "befuddled"; the "Jewels" game found in Rockbox contains no code or other materials from PopCap's game, so it is hard to see where the copyright violation might come from. A subsequent message makes things more clear, however; PopCap takes issue with the jewel icons used in Jewels. It is, says PopCap, "obvious that someone on the PluginJewels team ripped the graphics from one of the Astraware-licensed versions of our game".

Bejewelled	Rockbox

The figure on the right shows a subsection of the images (provided by PopCap) meant to back up this claim; Bejeweled appears on the left, Rockbox is on the right. A quick inspection shows some obvious similarities - the Rockbox jewels were clearly meant to resemble those from the original game. But they are just as clearly not identical - the Rockbox jewels have not been "ripped" from an official version of Bejeweled. In fact, they came from Gwled, where they were explicitly developed for use with that game. They are an independent - if imitative - creation.

The message from PopCap makes it clear that the game itself is not a problem; it states that "non-infringing gem art needs to be substituted for the infringing gem art." So not only is Rockbox not threatened, but even the "Jewels" game should be safe. All that is required is to replace the artwork with something seen as being non-infringing. Jewels would be the same game if users were matching penguins, mathematical symbols, or mug shots of SCO executives. But even a change of that magnitude is not required; PopCap only wants "non-infringing gem art."

The Rockbox developers have not, as of this writing, decided how they will respond to this request. None of them seem to think they have actually infringed upon PopCap's copyrights. But, says Daniel Stenberg:

That seems like it could be a reasonable solution to the problem. There appears to be a number of people, however, who oppose making any changes to appease PopCap. Their position is that Rockbox has done nothing wrong, has violated no copyrights, and that to give in to this sort of demand would be an invitation to others who would harass the project with infringement claims. They would rather tell PopCap to simply take a hike.

A smaller group suggests that, since Gwled provided the artwork under the GPL, (1) Gwled has stated that it has the right to distribute that artwork, and (2) PopCap should be sent over to present its claims to the Gwled developers. There would appear to be little support for the idea of simply dumping the problem onto another GPL-licensed project, however.

Rockbox may well be in the right on this issue, and it may well be that, legally, the project is under no obligation to change anything. It may also well be that the project could find itself having to argue that point in court. The free software community faces a wide variety of legal challenges, with others certainly to come in the future. We should pick our battles carefully. The Rockbox developers will have to make their own decision in this case; in so doing, they will want to consider whether the goals of the project are truly served by taking a hard-line stand over a set of little jewel icons.

Comments (10 posted)

Some notes on Linux and free drivers

The good folks at ZDNet have been doing their best to stir up the proprietary driver debate over the last week. Things got started with this article containing a classic quote:

The first part seems better suited to somebody holding a management post at SCO. Free software developers have created a system which scales from tiny embedded systems to supercomputers. Their work powers much of the net. When given the necessary information, free software developers are able to support new hardware more quickly than anybody else.

But, it seems, they are not up to the task of writing a driver for a graphics adapter.

It is true that contemporary graphics cards are complicated devices. They are usually the most powerful processor in the system, and they have all kinds of strange timing and memory management issues. But the idea that the developers who built an entire free system would be stymied by the complexity of a graphics adapter would be insulting if it weren't so comical.

The claim that customers have not been asking for free drivers is more discouraging, as many, many Linux users have been very clear about their wishes for years. Nvidia knows that there is demand for free drivers out there; it simply chooses to ignore that demand.

Perhaps when Nvidia's real customers - large system integrators - start to complain, the message will be heard. To that end, those of us who buy systems need to insist that they come with fully free software. The vendors who sell "Linux-installed" systems with proprietary drivers, ndiswrapper, etc. are not really helping. When those vendors understand that their customers want free systems, they will, in turn, put pressure on their suppliers.

From there, ZDNet columnist John Carroll was shocked to learn that Linux lacks a stable kernel API.

This discussion misses the point entirely. The way to get a driver to work across distributions is to get it into the mainline kernel. Then it will work across distributions - more distributions than any company could ever support - and across architectures as well. When the company abandons the driver in favor of next year's products, it will still work. When a security problem comes up, it will be fixed. And there will be no "fragmentation" problems.

There are a lot of other reasons for insisting on free drivers - see this article from last November for a more thorough discussion. There also is no defensible reason for keeping hardware programming information secret. True competitors will reverse engineer the hardware anyway, and no hardware company makes its money by selling device drivers. Hardware manufacturers in many areas have figured this out, with the result that Linux has outstanding support for their products. Hopefully the remaining holdout vendors will catch on, soon, that there is a large and growing market waiting for them.

Comments (38 posted)