Internet Society Vietnam Website

topbar left of language choice Tiếng Việt English version topbar right of language choice
Separation line header and body. Click to skip navigation frame

 Link to ISOC Vietnam homepage ISOC Vietnam news site Infomation about ISOC International and  ISOC Vietnam Information and materials from our work groups This is the archive with all our documents Join ISOC Vietnam!

Translate this page with BabelFish

Last update:
Tuesday, March 19, 2002 2:15 PM

Contact webmaster

separation arrow end

Patents in an open source world

Subject: [bytesforall_readers] Patents in an open source world
Date: Tue, 27 Jul 2004 10:08:05 +0000
From: Sunil Abraham <sunil@mahiti.org>
Reply-To: bytesforall_readers@yahoogroups.com

Patents in an open source world
Monday July 26, 2004 (12:53 PM GMT)
By: Lawrence Rosen
http://trends.newsforge.com/article.pl?sid=04/07/22/201217&tid=147&tid=110&tid=132

Open source appears challenged by patents but that fear is often
exaggerated. Lawrence Rosen, technology attorney and author of "Open
Source Licensing: Software Freedom and Intellectual Property Law"
(Prentice Hall, 2004), offers a calming view of the patent situation. He
describes reasonable steps we can take to prevent patents from
interfering with software freedom.

The "Chicken Little" syndrome

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.
Thanks,

ಸುನೀಲ್
--
Sunil Abraham, sunil@mahiti.org http://www.mahiti.org
314/1, 7th Cross, Domlur Bangalore - 560 071 Karnataka, INDIA
Ph/Fax: +91 80 51150580. Mobile: +91 80 36701931

Currently on sabbatical with APDIP/UNDP
Manager - International Open Source Network
Wisma UN, Block C Komplex Pejabat Damansara.
Jalan Dungun, Damansara Heights. 50490 Kuala Lumpur.
P. O. Box 12544, 50782, Kuala Lumpur, Malaysia
Tel: (60) 3-2091-5167, Fax: (60) 3-2095-2087
sunil@apdip.net http://www.iosn.net http://www.apdip.net


<< Call for submissions: Gender Equity and Free and Open Source Software

| Archive Index |

IOSN Releases: User Guide to Using the Linux Desktop >>


To facilitate co-ordination regarding the introduction of OSS SW in Vietnam

Subscribe to OSS:

Subscribe | Unsubscribe

Powered by Mojo Mail 2.7.2 SP
Copyright © 1999-2003, Justin Simoni.