Patents in an open source world

Does the dramatic increase in the number of software patents portend a
catastrophe for open source software?

Some argue that the threat of patents is vastly overstated. They point out
that, while there are from time to time serious assertions of software
patents, patent litigation is in practice very rare. This reflects both the
high cost of such litigation and the difficulty of winning.

It is true that obtaining a patent is much easier than having to prove its
validity in court. A patent is awarded by civil servant patent examiners in
a government office based on limited information, whereas litigation
involves skilled software experts and patent attorneys who leave no stones
unturned to find prior art or other legal arguments for invalidity. The
presumption of validity evidenced by a plaque from the Patent Office can be
overcome by clear and convincing evidence that the patent is invalid.
Companies recognize that they should assert patent infringement only of
patents whose validity is clear.

Ultimately, though, there will be valid software patents (at least in the
United States). We should presume that at least some valid software patents
have been granted covering the technology now included in open source
software.

Measuring the risk of patents just by remembering the benign past ignores
the simple fact that assertions of infringement of a few valid patents
directed toward such important open source products as Linux, Apache, the
Mozilla browser or Open Office could seriously damage our businesses.

A successful patent assertion can force us to pay royalties we can’t afford
or require us to cease making, using or selling an infringing product. The
risks, while small, must be assessed and addressed.

Quality or quantity

Can the open source community create its own patents?

The people commonly referred to as the “open source community” – in this
instance meaning the hackers and developers who write much open source
software — can never generate the number of patents obtained by the big
patent powerhouse companies. Filing patent applications simply takes too
much time and costs too much money.

Another problem is that good patents aren’t typically recognized to be
valuable until many years after the invention. Investing time and money to
secure patents is itself a high-risk venture requiring the kind of capital
not available in garages and home offices.

Big companies apply a different strategy. They invest heavily to obtain many
patents in many areas, betting that at least a few of them will prove to be
valuable in the future. This is not to say that big companies scatter
inventive buckshot at random. They invent in areas of technology that are
important to their business strategies. And then they hope that some of
their inventions will become important and valuable enough to pay back their
investments in many other worthless patents and inventions.

Quantity leads to occasional quality, and to potentially huge profits from
legal monopolies or royalties.

Scanning for asteroids

Which patents will affect us?

Someday a huge asteroid will hit the Earth – it has happened more than a few
times before in the history of our planet. Now that technology has made the
search for near-Earth asteroids a reasonable activity, our astronomers are
conducting methodical and often automated searches of the sky. Whether we
can then avoid what we discover is a secondary problem that is the subject
of frightening science fiction.

The search for patents infringed by open source software has many of the
same characteristics. We’re convinced we may someday be hit by patent
infringement lawsuits. Therefore we conduct searches, although in our case
the technology for searching patent portfolios is still mostly a manual
procedure. And then, when we find an infringed patent, what shall we do to
avoid or compensate for it?

Just as asteroids are more likely to arise in the asteroid belt, so patents
are more likely to arise in the companies that directly compete against our
open source software. Knowing where to look dramatically helps narrow the
search. That is why we search the patent portfolios of operating system
software companies for patents that might cover Linux; it is the most likely
place to find such patents.

Unlike the semi-automated scans of source code that can detect certain types
of copyright infringement, there is no computerized scanner for patent
infringement. There are only two ways to find such patents:

1. Wait for one to hit us

.

2. Conduct a laborious and expensive manual search through the
   thousands of patents issued to our likely adversaries.

Which option we pursue depends on our assessment of the risk compared to the
cost of a search. The second alternative, in which we search for
infringement, is laborious and expensive. Doing it right requires careful
analysis by technical and legal experts who carefully compare the functions
performed by software (not its code!) to the written claims of each patent.
The arcane but precise language of patents and intellectual property law
makes this a job for the highly skilled.

Most open source projects, and even most commercial software companies,
simply cannot afford to conduct rigorous patent searches. But the high cost
of conducting a rigorous search doesn’t excuse the failure to conduct any
search at all. Companies have an obligation to their customers, and perhaps
even a duty under the law, to act with reasonable diligence. The standards
for reasonable diligence depend intricately on assessments of value and
risk. The bar is probably higher for a fundamentally important software
product like Linux that is an essential component of modern computing than
it would be for a simpler open source project with limited users. Our
publicly-traded commercial partners who contribute to and redistribute open
source software may have legal obligations to undertake patent searches in
order to identify and publicly disclose material business risks relating to
patents.

The cost of intellectual property protection rises as the value of the
intellectual property itself goes up.

Avoidance

Can we avoid patented technology altogether?

Some engineers wishfully assert that there is prior art for every software
patent (if only we could find it), and that we can design around any
software patent (given enough time and engineering resources). This is not
always true in the real world. There are occasionally original ideas that
result in fundamental patents that simply cannot be designed around given
reasonable time and money.

But in that “real world,” those engineers are often enough right to justify
our looking for prior art or designing around a software patent. Finding
prior art or designing around a patent can completely resolve assertions of
patent infringement. We should put our engineers and software experts to
work as soon as we know or reasonably suspect that we’ve got prior art to
find or a patent to design around.

Do we take this path after we receive a cease-and-desist letter, or before?
One advantage to a methodical patent search early in the product development
and distribution cycle is that it gives us time to prepare for patent
assertions and resolve them one way or another. We can change our software
before our customers become enamored of a patented feature, or we can find
prior art to invalidate a patent through patent reexamination procedures
much less costly than patent litigation. If we wait until patent
infringement lawsuits are filed, we may not have time to respond
appropriately.

The open source community also has a unique opportunity to create prior art
by publishing its own inventions sooner so that we won’t face patent
infringement lawsuits later. As an important side-effect of open source
software, prior art is documented and date-stamped automatically by services
like SourceForge. And with rigorous audit trails like the OSDL Developer’s
Certificate of Origin, ownership of prior art can be proven. These records
are a fundamental part of our methodical process of searching for, and
subsequently avoiding, software patents.

MAD

Can we defend against patents by preparing to go on the offense?

During the cold war, nuclear catastrophe was averted by a policy of mutually
assured destruction (“MAD”). If any country dared to start a nuclear war,
the theory went, the devastation wreaked upon that country would be many
times worse. Not just the nuclear powers were so protected. Through treaties
and alliances, the allies of the great powers survived under a defensive MAD
shield.

So too, in the field of patents, do large patent portfolios serve the role
of stockpiled nuclear weapons. If a company with a large portfolio is sued,
it will likely own other patents that are essential to the company that
dared to sue. “Sue me,” they say, “and I’ll sue you back even worse for
patent infringement.” In this way, a patent portfolio can be a defense to
litigation, because few will dare sue and risk their own destruction.

Big companies, however, don’t usually treat patents like nuclear weapons
against their major competitors. Instead, they license their patent
portfolios in return for cross-licenses to their competitors’ patent
portfolios. This removes the competitors’ arsenals from use for both
offensive and defensive purposes, leaving the cross-licensed companies free
to operate with a reduced fear of patent litigation.

Because such cross-licenses between big patent owners are usually
closely-held trade secrets, it is not easy for us to know if open source
allies will be able or willing to use their patents to defend open source
software. We simply don’t know if we’re shielded by the MAD patent
portfolios of our best friends.

Withholding the candy

What can we trade in exchange for freedom from patent lawsuits?

Open source projects don’t have patent portfolios for use in cross-licensing
negotiations or for retaliation in the event of patent lawsuits. But we do
have our valuable software.

Many open source licenses now contain a defensive termination provision by
which the license to the software terminates if the licensee sues the
licensor for patent infringement. There are subtle differences among these
termination provisions in the various open source licenses. For example, the
GPL’s section 7 provides that a licensee has no right to distribute the
software if the distributor is subject to patent restrictions that would
contradict the GPL’s conditions. A more straightforward provision in the
OSL/AFL version 2.1 licenses simply terminates the plaintiff’s copyright and
patent licenses to the software if he/she sues the licensor or any other
licensee alleging that the licensed software infringes a patent. The CPL and
MPL, as befits open source licenses by major patent holders, terminate only
patent grants and not copyright grants; such licenses act more like
patent-for-patent cross-licenses than patent defense provisions.

Regardless of the details, the objective of these open source licenses is to
prevent a licensee from enjoying the benefits of the open source software
while simultaneously suing for patent infringement.

Since each open source license contains a subtly different termination
provision, its value as a defense must be individually assessed. For
example, the GPL’s termination provision is not an effective defense unless
the plaintiff is a distributor. And none of these in-the-license defense
provisions, including the GPL, OSL/AFL, CPL or MPL, will help if a plaintiff
isn’t a licensee who makes, uses or sells the open source software.

Companies can also be encouraged to trade their patent rights in exchange
for the huge benefits of cooperative industry standards. The mandatory
patent licensing provisions of standards bodies like W3C help to ensure that
open source software that implements industry standards is shielded from
patent litigation. When companies cooperate to develop royalty-free
standards free of patent encumbrances, open source and proprietary software
can flourish.

Summary

I’ve identified what I believe to be the key components of a comprehensive
strategy to deal with an uncertain patent threat. We need to evaluate the
efficacy of each of them in our environment. There is no single way to
emasculate our enemies’ patent portfolios or to eliminate the inherent risks
of using software in a world that allows software patents.

Here’s a summary of what I recommend:

1. Don’t be too paranoid about the patent problem. It’s a real problem,
   but not a catastrophe. Any patent owner that tries to assert its patents
   against open source software has many hurdles to leap before the royalty
   checks start to arrive.
2. Don’t try to out-invent the big guys. The open source community
   can’t possibly compete in the patent generating business. But we can
   continue to document our own “prior art” to prevent others from patenting
   things they weren’t the first to invent.
3. Conduct a reasonably diligent search for patents we might infringe.
   At least search the portfolios of our major competitors. (This, by the way,
   is also a great way to make sure we’re aware of important technology
   advances by our competitors.) Maintain a commercially reasonable balance
   between doing nothing about patents and being obsessed with reviewing every
   one of them.
4. Design around patented technology wherever possible. The longer our
   lead time the easier this is to do, so do # 3 early in the design and
   development process.
5. Identify allies who can defend us with their patent shields. We have
   important friends whose patent portfolios might be cross-licensed under
   terms that provide additional protection for certain open source products.
6. Withhold our software from those who sue us for patent infringement.
   Choose open source licenses that implement a strong defensive termination
   provision. Support royalty-free patent policies by industry standards
   organizations, and adopt only royalty-free standards.

Lawrence Rosen is founding partner of Rosenlaw &
Einschlag, 3001 King Ranch Road, Ukiah, CA 95482 (www.rosenlaw.com). Mr. Rosen is an attorney
specializing in technology, and the author of “Open Source Licensing:
Software Freedom and Intellectual Property Law” (Prentice Hall, 2004). Mr.
Rosen is a former computer professional who taught programming and managed
several computer departments at Stanford University. He has served as
general counsel and secretary of Open Source Initiative (OSI) and as its
executive director, and has written several major open source licenses. He
advises companies and individuals throughout the world on open source
licensing and related legal issues.

C Copyright 2004 Lawrence Rosen. Licensed under the Academic Free License
version 2.1.