<nettime> O'Reilly: Linux and Patent Risks

["nettime's avid law student" <nettime@bbs.thing.net>]

Linux and Patent Risks
by chromatic
08/06/2004
http://www.linuxdevcenter.com/lpt/a/5073

Conventional wisdom among free software and open source developers has
long warned that software patents could corrupt and disrupt good software
projects. The GPL mentions such a risk, for example. While only a few
patents have actually stopped the development of some software (Unisys'
GIF patent, the patented LZW algorithm, and Fraunhofer's MP3 patent), the
risks involved in developing software in a patent-haunted world remained
unclear.

Though many developers prefer to ignore patents, the current laws (at
least in the U.S.) provide minimal legal defense for unwitting
infringements. Worse yet, though a project may have pedigreed and
documented prior art that could easily convince a court to overturn a
patent, the cost of such an action is out of reach for most developers --
and many companies.

A recent report commissioned by Open Source Risk Management (OSRM)
examined the Linux kernel for patent violations that patent holders could
cite in lawsuits against distributors. Unsurprisingly, the report found
283 patents that might come into play.

Reactions to the report varied greatly. This was apparently the first
broad study of its type, the first such study to clarify the risks that
software patents pose to open development. Many longtime developers always
suspected that this was the case. Other people took offense, as if the
report suggested a flaw in the development of the kernel; suggested
reasons not to use Linux or free software in general; or provided fear,
uncertainty, and doubt in an attempt to sell OSRM's legal insurance.

Dan Ravicher is the patent attorney who conducted the study. By day,
Ravicher is the executive director of the non-profit Public Patent
Foundation, working to reform the patent system. He also represents the
Free Software Foundation on a pro-bono basis.

I recently spoke to Ravicher in an attempt to clarify the aims of the
study and the conclusions he reached from it.


Considering Risk

The best way to analyze the study and its conclusions is to consider the
idea of risk as a business would. Ravicher suggested that the purpose of
the study was to answer several questions:

    * Are there pieces of code in the Linux kernel that may potentially
	violate patents?
    * Of the potentially violated patents, have the courts upheld any of them?
    * Who holds these patents?
    * Are the risks associated with these patents greater, less, or the same
	as with similar proprietary software projects?
    * How can users, developers, distributors, and companies ameliorate these
	risks?

OSRM's position is that it's better to have specific answers to these
questions. It's easier to have plans in place when you know the problems
you might face and the likelihood of those problems. Before announcing the
results of the study, Ravicher shared them with several entities in the
free software development community, including Bruce Perens, Linus
Torvalds' legal counsel, OSDL, Red Hat, IBM, and Hewlett Packard. They had
mostly similar, favorable reactions. Findings

The most important finding is that Linux infringes on zero patents that
have survived reviews in court. The 283 patents that the kernel could
infringe have all gone unchallenged so far. There is a chance that a court
could find the patents invalid -- so the conclusion that there are 283
ways in which patent holders could bring suit against kernel developers,
users, and distributors is flawed.

Further, Ravicher discovered that open-source-friendly companies
(including IBM and HP) hold about 100 of those patents. Again, the
likelihood that such a company would bring suit against someone using or
distributing Linux is small, especially since those companies often
distribute Linux themselves.  (Legally, a company probably could, but it
goes against the spirit of open source.)

Less-friendly companies, such as Microsoft, do hold several of the 283
patents. Though courts may find these patents invalid, even reaching the
point of judgment is expensive and time-consuming. It could cause a lot of
trouble.


Mitigating Risks

How much trouble this could cause depends on several factors.
Pragmatically, individual users, developers, and small businesses have
relatively little risk -- it's expensive to initiate patent infringement
proceedings. Suing someone with few assets (compared to a large company
with a large portfolio of offensive patents) is likely a bad investment.

A court judgment in this case could be as simple as an injunction against
a particular developer, leaving other developers reasonably free to
continue developing and distributing the software. The damages would be
minimal, as an open source developer often distributes comparatively few
copies of the software (preferring mirrors and other download sites) for
little or no charge.

Large companies, such as the aforementioned IBM, also present un-tempting
targets, with armies of lawyers and filing cabinets full of patents to use
defensively. It's likely that two behemoths would settle with a
cross-licensing agreement.

Medium-sized companies without several patent attorneys on staff or a
portfolio of similarly-broad patents have the most risk. This is the space
where OSRM seeks to make its business -- building a valuable service
around free and open source software, not by selling licenses or keeping
code secret.

As Ravicher explained, the cost of proprietary software includes some
amount of patent insurance. The vendor of the software takes on the risk
of defending its users against patent claims made by other parties. Open
source and free software demand no such licensing fees, giving users the
option of ignoring the problem or, now, purchasing patent insurance from
OSRM or a similar group.

Ravicher also carefully pointed out that this study helped OSRM consider
their business model. Contrary to the perception that they want such suits
to come about, that would actually be bad for business. OSRM is betting on
two things. First, that there will be few suits claiming patent
infringement.  Second, that providing insurance against these suits will
be valuable to enough businesses to cover OSRM's costs. Toward a Better
Patent Policy

There are other objections to the study, namely that OSRM has not released
details of the patents and that someone should challenge these patents and
reform the system overall.

To the first objection, Ravicher notes that the current system of awarding
damages in a patent infringement case is unusual. Notably, it relies on
the amount of knowledge the infringing party had about the patent. If the
court finds you guilty of willful infringement, where you knew about the
existence of the patent at the time of your infringement, you may be
liable for triple damages and the attorney fees of the other party.

Unwillful infringement leaves you liable for only damages with no
multiplier.  This is the real trap, since if you search for potential
infringements and find one, you open yourself to charges of willful
infringement. In this case, ignorance is still bad, but it's much better
than the alternative.

If OSRM were to release the exact patents, this would turn the kernel
developers (and distributors) into willful infringers, increasing their
risks. This is not a goal. Many attorneys recommend against looking for
patents you infringe for this reason.

Of course, it's better that the software not infringe at all. To this end,
Ravicher said that OSRM plans to help developers work around troublesome
sections to help to redesign out infringements or to prove that the kernel
doesn't actually infringe upon specific patents. This may prove tricky,
with both sides walking a thin wire of deniable willfulness, but it's
doable.

As for the notion that someone should challenge the patents altogether,
remember that the cost and trouble of challenging a patent is excessive.  
Chasing down a couple of hundred patents right now, when none of the
patent holders have used them offensively against the kernel, is asking
for trouble and, again, increasing risk.

OSRM could publish the details of patents that the patent holders agreed,
in a legally binding form, never to assert against Linux. In effect, IBM
could write a formal legal license for open source software to use
patented methods in perpetuity, mitigating the risk that IBM (or anyone
who asserted a right to that specific patent) would bring suit against
users, developers, and distributors.

This seems to be the best outcome, but only time will tell if
open-source-friendly companies will lay down legal weapons in this way.
Conclusions

The biggest question is how the Linux kernel compares to other pieces of
software, especially proprietary ones. Ravicher concluded that it is no
worse off than proprietary software, repeating that the difference between
the two (in this sense) is that the price of a proprietary license
nominally provides some indemnification against unwillful infringement on
the part of the user.

For developers, the best approach seems to be to continue developing. The
current legal framework over software patents really discourages even
trying to find possible infringements. Until and unless the system stops
rewarding ignorance, there may be little developers can do except support
other groups who can help work around patents without opening themselves
up to increased legal liability.

For businesses, the risks are nearly the same, unless you present a
tempting, tasty target to a malicious patent holder. Unfortunately, those
sharks have started to swim lately.

Ideally, non-profit groups such as the EFF and Ravicher's own Public
Patent Foundation will succeed in their quest to reform software patents.
Until that happens, though, knowing the risks involved can only help
people make better choices.

chromatic is the technical editor of the O'Reilly Network.

#  distributed via <nettime>: no commercial use without permission
#  <nettime> is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@bbs.thing.net and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: nettime@bbs.thing.net