LWN.net Weekly Edition for April 20, 2006 [LWN.net]

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

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:

Another affirmative act that may serve as a basis for patent infringement liability is improving on patented technology the alleged infringer is legally entitled to use, yet the improvements are already patented.

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:

A patent grants the right to exclude others from a particular area of claimed technology, but does not confer the right to practice an invention.... If, for example, Patent A claims a method of using a particular algorithm with a particular type of processor, and someone legally entitled to use Patent A tries to improve the scalability of the algorithm so that it can be used with a second processor, it is possible that a second patent, Patent B, already claims this improvement. The result is that someone legally entitled to use the Patent A must obtain a license to use the technology claimed in Patent B, and an individual entitled to use the technology claimed in Patent B must obtain a license to use the technology claimed in Patent A.

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:

Guideline 3: Developers should only use the technology in the way described in the pledged patents, staying within the scope of technology claimed. Developers should not assume that patented improvements to the technology claimed in the patents have also been pledged to the Patent Commons. Improvements are, by definition, distinct from the contributed patents and may, in fact, already be patented by someone else who has not made a pledge to the Patent Commons. A search of patents for any improvements (when you know you want to improve upon a pledged patent) is advisable.

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:

In sum, the more an alleged infringer knows about a patent that is claiming the technology of a product that she is making, using or selling, the greater the likelihood that she will be liable for damages for patent infringement.

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

The fact is, technical people are better off not looking at patents. If you don't know what they cover and where they are, you won't be knowingly infringing on them. If somebody sues you, you change the algorithm or you just hire a hit-man to whack the stupid git.

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 game PluginJewels, for use on RockBox and available at http://www.rockbox.org/twiki/bin/view/Main/PluginJewels, is a blatant copyright violation of Bejeweled, the popular match-three game owned by my company, PopCap Games, Inc., of Seattle, Washington, USA. I am writing to you to demand that you remove PluginJewels from www.rockbox.org and all other sites where users may download this game for the Rockbox, no later than April 30, 2006. PopCap Games takes seriously all copyright and trademark violations of our games and, if necessary, we will enforce our rights to the fullest extent of the law.

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:

However, I don't think we'd lose anything by being "soft" and simply modify our jewels somewhat so that they don't look so similar to their versions, just to be nice.

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:

For Nvidia, intellectual property is a secondary issue. 'It's so hard to write a graphics driver that open-sourcing it would not help,' said Andrew Fear, Nvidia's software product manager. In addition, customers aren't asking for open-source drivers, he said.

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.

ATI may claim that they accept the fluidity of the kernel interface "as part of our day-to-day responsibilities in Linux," but I bet that is said through clenched teeth after months trying to get a driver to work across distributions.

Fragmentation didn't work for old-school Unix. Linux solved the structural issue by providing a level of consistency made possible through use of the GPL. It's worth remembering that before attempting to justify an unjustifiable lack of a consistent Linux kernel interface.

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)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

Security: Mozilla troubles; New vulnerabilities in bsdgames, fcheck, firefox/mozilla/thunderbird, and gdm.
Kernel: Virtual time; Thread safety, write(), and POSIX; The future of Linux security modules.
Distributions: Ubuntu to get Edgy; SUSE Linux 10.1 RC1; Aurora Sparc Linux 2.0
Development: Zope CMF Version 2.0.0, new versions of Mailman, Sussen, Ambisonics plugins, Snd-ls, GNOME, GARNOME, PCB, SQL-Ledger, TuxFighter, GIMP, Wine, OpenVistA, OO.o, AbiWord, Urwid.
Press: The end of radio, open-source and rootkits, Micro Center fails Linspire, open source DRM, Prior Art Primer, Oracle and Linux, running Rockbox on an ipod, GNOME 2.14 review, Zimmerman's Zfone, cross-platform virus test.
Announcements: FSMLabs and Advantech partner, EFF on DMCA misuses, Perens on domain parking, Summer of Code 2006, Linux essay contest, Ludum Dare competition, Hui VistA training, CELF report, Recon 2006 speakers, Try KDE launched.

Next page: Security>>