On Aug. 13, 2008, the Court of Appeals for the Federal Circuit (CAFC) issued a decision in the much-watched case Jacobsen v. Katzer, No. 2008-1001 (Fed. Cir. Aug. 13, 2008), which turned on whether violating an open source licensing agreement should be considered copyright infringement.
It is important for companies to be aware of the implications of this decision and to respond accordingly; this applies to all companies that use open source software — even those who think they don’t. The temptation to incorporate open source software into a company’s products is great, because open source software is readily available via download and is free of charge.
Developers on tight budgets and time lines often see open source as a quick fix, and it is — but there’s a catch. Though free of charge, open source software is not free of terms and conditions, and virtually all open source software is subject to a license agreement. The decision in Jacobsen strengthens the ability of open source programmers to enforce these license agreements, and should cause companies who use or distribute open source in their own software to carefully review their policies.
Jacobsen v. Katzer
There has been a debate related to whether a violation of an open source license should be treated merely as a breach of contract, or whether it should be treated as copyright infringement as well. The difference is significant. In Jacobsen, the CAFC weighed in on this debate.
Robert Jacobsen, the plaintiff and a model train hobbyist, holds a copyright to software code that he makes available to the public free of charge under an open source license, the Artistic License. The defendants, Matthew Katzer and Kamind Associates, develop commercial software products for the model train industry and hobbyists. Jacobsen brought an action for copyright infringement and moved for a preliminary injunction against the defendants, accusing them of copying certain portions of his software code and incorporating it into their own commercially available software products without abiding by the terms of the Artistic License.
The District Court for the Northern District of California denied Jacobsen’s motion for a preliminary injunction, reasoning that the scope of a nonexclusive license is intentionally broad and amounts to a covenant not to sue. The court further reasoned that the provision that the user must insert a prominent notice of attribution did not limit the scope of the license, and that violation of that term resulted in breach of contract but did not constitute copyright infringement. Therefore, injunctive relief was not available. Jacobsen appealed to the CAFC.
The CAFC vacated and remanded the District Court’s decision. It found that violations of open source licenses can constitute copyright infringement, because the language in the licenses imposes “conditions” of use, such as the notice and other requirements, not merely covenants that are governed by contract law. Violation of a condition of a license constitutes copyright infringement, whereas violation of a covenant is merely a breach of contract.
Implications of the Decision
The implications of the Jacobsen decision are significant for several reasons. First, if violations of open source licenses are treated as copyright violation, it is much more likely that courts will grant injunctive relief. One of the ways to establish the need for an injunction is by establishing the potential for irreparable harm. Irreparable harm is presumed in cases of copyright infringement. This presumption does not apply to claims of breach of contract. The granting of injunctive relief is significant, because it can force a company to stop using or distributing its software products and, therefore, significantly impact overall business functions.
Second, the available damages are far more significant for copyright infringement than for breach of contract. Copyright infringement damages include statutory damages of up to US$150,000, attorneys’ fees and disgorgement of profits. Conversely, damages for a breach-of-contract claim are normally limited to monetary damages. Furthermore, the calculation of damages resulting from a breach-of-contract claim involving open source licensing agreements is challenging, because there is no monetary consideration for obtaining the software code.
Third, although the license examined in Jacobsen was the Artistic License, not the more widely used General Public License (GPL), the analysis and decision can be applied to the GPL, as it contains similar requirements labeled as “conditions.”
Following this ruling, it is much more likely that open source developers will aggressively assert their rights and seek injunctive relief. Therefore, companies should proactively develop policies and procedures regarding the use of open source software, as the financial and legal risks associated with the improper use of open source software have been made clear by the Jacobsen case.
Practical Steps for Responding
The Jacobsen decision should prompt companies using open source to institute policies regarding its use — and to thoughtfully assess the benefits of each type and location of use, and which open source license is applicable. There are over seventy open source licenses, each imposing different terms and conditions. Not all of them may be appropriate for use by a particular company. In addition, the Jacobsen decision should prompt companies that do not think they are using open source to confirm that is in fact the case. The likelihood of developers using open source is high, as it is easily accessible, and developers recognize the benefits that open source can have on development time and costs. However, many companies are unaware that their developers are using open source or the extent to which it is being used.
Below are some practical steps a company can take to avoid the risks associated with the use of open source software.
- Adopting an Open Source Use Policy
Adopting an open source software use policy is the starting point for addressing the risks associated with the use of open source software. The policy should track all use of open source software and set forth the circumstances under which use of open source software is allowed, and the particular open sources licenses that are acceptable, paying particular attention to any software that is distributed.
- Implement Employee Education and Training
In addition, although employees (especially software developers) might be aware of the existence of open source, they may not be aware of the risks and obligations, or the variations in open source licenses. Therefore, employee education is imperative. Employees who understand the risks, obligations and benefits will be more likely to support and follow the company policy. Educated employees will be better able to recognize when using open source would benefit the company or when the risks would be too great. Companies may wish to appoint a specific person or group to which questions regarding open source software use can be directed. In addition, it may be appropriate to task specific employees from the business and the software development teams to work together to address issues surrounding the use of open source.
- Conduct Audits
Along with the adoption of an open source use policy, it is important for a company to perform an initial audit of its software so that it has a complete understanding of where and how it is using open source. The likelihood of developers using open source is high, as it is easily accessible and the price — no cost — is right. Many companies, however, might be unaware that their developers are using open source or the extent to which it is being used. In addition to the initial audit, there must be regular audits to ensure compliance with the policy and any applicable open source licenses. The policy itself should also be audited on a regular basis to ensure it remains appropriate for changing company objectives, and that it is effectively balancing the benefits of the use of open source with business and legal risks.
- Implement Record Keeping and Code Management
A record-keeping system should be put into place to ensure full documentation of open source use. In addition, a software version-control tracking system should be put into place to ensure copies and versions of the open source code used by the company are tracked, and to track how the code is used, i.e. whether it is used internally or in software that is distributed.
- Consider Internal Restructuring
Along with auditing the software, company may wish to consider segregating the IT and software development departments. The company may wish to consider isolating open source development environments from traditional development environments. Because open source licenses are often triggered when open source is included in software that is distributed, the standard for internal use of open source by the IT department may be lower than the standard for incorporating open source in software intended for distribution. Separating the IT and development departments will help prevent the inadvertent inclusion of open source into proprietary software intended for distribution.
- Monitor Commercial Software
Commercial software licensed by a company from a third party may contain open source. Therefore, it is important to monitor the procurement of commercial software and to ensure that commercial software providers include representations, warranties, and indemnifications in their license agreements stating that the software supplied does not contain any open source, or that the open source included in the licensed software is clearly identified.
- Obtain Insurance Coverage
An additional option for minimizing the risks associated with open source is the purchase of insurance. For instance, Open Source Risk Management (“OSRM”) offers insurance policies to companies using open source who fear that they may be sued. OSRM covers up to $10 million for direct loss suffered by the insured following a finding of noncompliance with specific license agreements.
The decision of the Court of Appeals for the Federal Circuit in Jacobsen is significant, and there is no question that it creates additional risks for companies using open source software. It is also likely that the open source community will be more aggressive in its efforts to enforce these licenses as a result of this decision. However, companies can lower the risks associated with the use of open source by carefully considering their open source use policies, becoming more vigilant regarding the implementation of these policies, and providing employees with education and training.
Michael P. Bennett is a partner in the intellectual property department of Wildman Harrold (Chicago) and counsels clients regarding the legal issues inherent in existing and emerging technology. Katherine K. Ivers is an associate in the Intellectual Property department at Wildman Harrold (Chicago).
Loading ...
It does not apply to companies/developers that use open source software.
It applies to companies/developers who obtain/add/modify open source software and re-distribute/sell without contributing the code added/modified back to the community or asking permission from the copyright holder.
so how many companies re-distribute/sell? not even 2% of companies who use open source software.
Proprietary Software?
You can not even look at it…so forget about it.
cmartinez: you labeled your post as FUD (fear, uncertainty, doubt). I think that misses the point. The Jacobsen court was the first appellate court in the US to rule on substantive issues related to an open source license. That by itself makes the decision important and worthy of discussion. And it was the Court of Appeal for the Federal Circuit, one of the most influential courts for intellectual property issues. All the more reason to take note of the decision.
The situation you are describing is hardly unique to companies that might use and re-distribute open source software. This should already be normal business practice for just about every company in existense.
You can pretty much sum up your article by saying:
"If you want to re-distribute any copyrighted material you must follow the license of the copyright holder."
For some reason many people think open source software is somehow odd or different when you are talking about copyrights. its probably more accurate to think of closed source software as the oddity when thinking about copyrighted material.
For centuries all copyrighted material has been ‘open source’, although that term was not used. There was almost no difference between the copyrighted material and its delivered form. Stories, Newspaper articles, movies, music and pictures are all forms of copyrighted materials. When you read a book by Stephen King, you actually get your hands on a copy of his ‘source code’. You don’t just get to read the synopsis on the back cover. You get the entire story.
If you try to re-distribute Mr. King’s copyrighted work without the permission of the copyright holder, you will be in violation of copyright law.
The same holds true for music, movies and all other copyrighted works.
This is actually the purpose of the copyright. To protect the ownership of materials that are distributed publicly. There is the public domain, the copyrighted domain, and the secret domain.
Secret? Yes, as in trade secrets. Another way of protecting the ownership of material is to never publish the ‘source’. A great example for trade secrets is the formula for Coca-Cola or the Colonel’s 11 secret Herbs and spices. There are also algorithms used in business that are maintained as trade secrets, like Google’s search algorithms.
Historically trade secrets were not copyrighted because they were not published and disseminated. It was up to the secret holder to keep the secret. AT&T inadvertently placed almost all of ancient Unix code in the public domain by failing to keep it secret and distributing it widely without copyright notice (pre- Berne convention).
Open source is like most copyrighted material that the corporate world is familiar with. Corporations know that they cannot use a Celene Dion song in an add campaign without the permission of the copyright holder. It does not matter if the CEO can hear the song in public every time they board an elevator, or that any musician familiar with the art could transcribe the notes for the song.
It is copyrighted material and they need the copyright holder’s permission.
Those of us old enough remember when closed source software was in a kind of legal limbo. At one time you actually had to publish things with a copyright notice in order for things to be copyrighted. This changed with the ratification of the Berne convention in the mid 1970’s. If we still operated under the old rules, Microsoft would have to publish their source code in order to get it copyrighted.
But now we actually have the weird situation where material that is never disseminated to the public in human readable format is still entitled to the same copyright protections as the more familiar copyrighted materials like books, music, poetry and open source software.
If a company fails to honor the license granted by the copyright holder in their use of that copyright holder’s works, they are going to have to call in the lawyers. The fact that the material is ‘open source’ like a novel, or a poem is incidental.