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.
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
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
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)
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
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
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
, 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
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
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)
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
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
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
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
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
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
Next page: Security>>