Last update: Tuesday, March 19, 2002 2:15 PM
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 SPCopyright © 1999-2003, Justin Simoni.