Find Command Cheat Sheet » Free from Linux Training Academy » Download Now!
Welcome Guest | Sign In
LinuxInsider.com

Open Source Software: Your Company's Legal Risks

By Michael P. Bennett and Katherine K. Ivers
Sep 4, 2008 4:00 AM PT

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.

Open Source Software: Your Company's Legal Risks

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).


How important is a candidate's knowledge of technology in winning your vote?
Extremely -- technology is at the center of most of the world's big problems and solutions.
Very -- a candidate who doesn't understand technology can't relate to young people.
Somewhat -- a general understanding is sufficient.
Not very -- choosing good advisers is more important than direct knowledge.
Not at all -- technology is often a distraction from more important issues.