"Although I am a typical loner in my daily life, my consciousness of belonging to the invisible community of those who strive for truth, beauty, and justice has preserved me from feeling isolated."
The way we develop software is continuously evolving: the everyday processes and practices used to produce software are becoming more efficient, and it is common for a team of developers to change several times over the life of a software project and for the components used to come from a variety of sources. However, the benefits of these changes cannot be fully appreciated unless the correct policies and strategies are used to capture value from innovation. This is where the worlds of technology and Intellectual Property (IP) law collide and where license compliance is fundamental in protecting a company's IP and avoiding legal conflicts.
By understanding how the goals and perceptions of licensing have changed over time, we get a clearer picture of the roots of today's IP conflicts. Open source licensing is not a radically new concept in software development, as can be seen by examining the most commonly used open source license, the General Public License (GPL). In 1989, the Free Software Foundation or FSF released the first GPL which contained a statement of purpose and addressed the major issues of selling, copying, and modifying software. However, it was not written in legal terms and was treated as a social contract rather than the legal document to be debated in courts today. The GPL was adopted as a kind of social framework establishing a general set of rules and expectations for authors, users, and co-developers to observe. Yet the transformation of this particular license from philosophical theory to its present-day legal document is not always acknowledged in the commercial software industry. As a result, the legal risks and responsibilities associated with any open source license are sometimes overlooked.
From an IP perspective, using an open source solution is no riskier than using a proprietary software equivalent. From an end-user perspective, the licensing models are similar. Like proprietary software, commercial support contracts for Open Source Software (OSS) usually incorporate some form of indemnification clause to provide protection, usually financial, against potential third-party lawsuits of IP infringement. But there is sometimes the perception that open source is more vulnerable to IP conflicts because it offers indemnification.
It only complicates the situation that the number of open source licenses is increasing and that the licenses are evolving in their legal complexity. According to analyst group Saugatuck Technology, there are more than one thousand open source licenses, though most of us only hear about the GPL, BSD, and a handful of others.
IP conflicts and legal compliance issues usually arise when developers and managers fail to address open source licenses in a legal context. As evidenced by the percentages assigned to the factors shown in Figure 1, "Licensing Issues and Risks" is not perceived by organizations to be a primary inhibitor.
Figure 1: Inhibitors to Open Source Adoption by Category
Source: Saugatuck Technology Inc., Worldwide Open Source User Survey, August 2007
Risks and Restrictions
One risk is IP infringement resulting from using unauthorized third-party code or from combining incompatible licenses. For example, a software component licensed under GPL cannot be distributed with components licensed under the incompatible Mozilla Public License. Yet, with the wide availability of software components, there are multiple opportunities for infringing code to enter a software project. And, many organizations do not have processes in place to catch and address such occurrences.
The typical open source license is designed to protect the contributor of code as opposed to the licensee. This shifting of risk for IP infringement to the licensee is uncommon in proprietary software development; if a software company sells an unclean product, the end-users are not named in an IP infringement lawsuit. But in the open source world, understanding license obligations and code pedigree is the responsibility of the licensee. And therein lies an important distinction: end users of commercially licensed software are not in anyway liable for the IP integrity of the code, whereas end users of software under an open source license assume the full responsibility for the IP integrity of the code.
Different interpretations of open source licenses have also led to IP conflicts. It is also common for open source licenses to use terms that have no precisely and technically defined and agreed to definition. An example commonly used to emphasis this point are the terms "derivative work" and "collective work" which occur in various licenses such as the GPL. There is also the "linking" debate as to how tightly proprietary software can be coupled with GPL licensed software; as a result, the GPL is often coined as a "viral" license since all derivative works of GPL-licensed software must be released under the GPL.Landmark Cases
In recent years there have been an increasing number of court cases involving open source licenses. As more of these cases make their way through the legal system and judgements are rendered, a better understanding of how open source licenses are interpreted and enforced by the courts is obtained. These cases further establish precedents that establish the validity and enforceability of open source licenses in subsequent cases.
IP conflicts include violations of open source licenses as well as patent and copyright infringements. In 2004, the non-profit GPL violations organization was launched in Germany by Harald Welte in order to enforce the GPL; it claims to have resolved over 100 cases. Two of its four main goals are assisting license holders in legal action against violators and in negotiating settlements with violators out of court. In the United States, the FSF has a similar role, but it only enforces the GPL for software for which it owns the copyrights.
Similar cases occur globally; however, the majority of cases are tried in Germany, partially due to differences between German and US law, such as:
- injunctive enforcement in Germany is easier due to a stricter legal due process; a preliminary injunction can be obtained without giving the defendant the chance to defend itself. The defendant then has thirty days from discovery of an infringement for negotiations. Only within these thirty days can one apply for injunctive relief, or the court will send the case to a regular copyright trial which could last for years
- an author of a component within a larger software product can stop the infringer from distributing the entire program, not just the part they own
- a plaintiff in the US seeking a temporary restraining order (TRO) must post bond to compensate the defendant in case the TRO is wrongly issued; this is not the case in Germany
In April 2005, one of the first injunctions was granted against a major privately-held network security software firm when Fortinet was accused of including GPL software in certain products and using encryption techniques to actively hide the usage. gpl-violations claimed that Fortinet broke the two cardinal rules of the GPL: failure to provide the full source code with the distribution, and failure to provide a copy of the full license text. As a result of the injunction, Fortinet eventually released its source code to the infringing product without charge under the GPL.
Harold Welte explained after the trial, "We are not in any way opposed to the commercial use of Free and Open Source Software and there is no legal risk of using GPL licensed software in commercial products. But vendors have to comply with the license terms, just like they would have to with any other software license agreement."
Another example is Sitecom, a Dutch firm that uses OSS in its wireless access routers. Sitecom was accused of violating the GPL conditions when redistributing their product and the lawsuit was upheld. This was a significant decision confirming that GPL violations are actionable. These cases demonstrate that German courts will support aggressive enforcement of GPL. As a result of these new risks, software should not be developed with disregard to the licensing of its components. Brian Kelly, an IP Partner with Manatt, Phelps & Phillips explained, "Case law interpreting the GPL is both inevitable and useful, because parties are going to end up fighting over ambiguities in the license." These cases have ultimately created greater awareness of consequences and emphasized the seriousness of open source licenses in a legal context for all in the software industry.
An implication from the preceding legal cases is that companies may be held liable for license violations in any country, even if the GPL is not enforced in their home country.
In one of the first open source cases to be debated in the US, courts were asked to evaluate the meaning of a "derivative work". The dispute originated from an agreement which licensed NuSphere to non-exclusively market the GPL-licensed MySQL database product. The claim was that NuSphere distributed the product that linked directly to MySQL's source code without releasing the source code. The key point is that linking to GPL software turns the linked software into a derivative work and all derivative works of GPL software must also be released under the GPL. The judge in this case did not want to create a legal test case and refused to treat it any differently then a trademark dispute. The case was settled out of court, but its arguments raised awareness of the GPL's viral implications: the GPL either bars inclusion of GPL code in proprietary programs or forces derivative works of programs linking to GPL code to be released under the GPL. Indemnification
The case of The SCO Group v. IBM was a landmark event that increased awareness of the importance of indemnification within the GPL community and to customers using OSS.
Corporations that offer proprietary software, like Microsoft, pay a premium for indemnification protection that is bundled into the cost of the license. But this is not always the case for Linux and other OSS. There are essentially three options for customers:
i) assume the risk and work without indemnification,
ii) use the limited indemnification protection offered by Linux vendors, or
iii) purchase outside indemnification from a firm at a premium.
The Open Innovation Network (OIN) is an organization that is garnering support from many companies using open source, such as Google. "Knowing they're protected by the OIN", Google's Chris DiBona argues, "open source developers are more likely to drive the industry forward".
The November 2006 agreement between Microsoft and Novell will also work together to improve interoperability between Microsoft software and its open source and standards-based counterparts. This is essentially about indemnification where Microsoft promises not to pursue IP infringement claims against those open source developers and customers who play by its set of rules. One of these rules dictates that customers obtain their Linux from Microsoft's new partner, Novell. There are signs of improvement as this becomes a driving issue for major standards committees especially in the web services market.
A recent court ruling in the case of Jacobsen v. Katzer has shed light on the key relationships that open source licenses share with patents and trademarks. The suit involves Jacobsen, a scientist and key member of the open source Java Model Railroad Interface project. The plaintiff alleged copyright violations; Jacobsen argued that the defendants violated copyrights by copying and distributing software without including the attribution required by the open source Artistic License. The judge refused to grant an injunction against the copyright infringement. This is the first time a US court has ruled on an injunction request to protect OSS; this decision may or may not create a dangerous precedent for open source licensors looking for injunctions.
The court made two important rulings: i) the Artistic License in question is a contract, and ii) the attribution requirement was a condition of the contract, not a restriction on the scope of the license. By interpreting open source licenses as contracts, the law does not allow for injunctive relief to prevent violators from further infringement. For contract breaches, the remedy is usually monetary damages. However, "assessing damages for use of open source software is difficult because the software is given away free", according to Victoria Hall, attorney for the plaintiff.
These landmark cases in the interpretation and enforceability of open source licenses highlight the importance of compliance and the consequences of failing to meet licensing terms. These cases have also created a business opportunity for companies to develop tools that ensure license compliance and solve customer licensing issues.
The software industry now has a clearer picture of the legal implications of open source licensing. As more cases are tried before courts, useful case law will be created to help interpret future conflicts with more certainty. Many companies are now implementing new or better policies to verify third-party components used in software projects as failing to do so can result in costly litigation and the remediation and re-engineering of non-compliant software. License compliance is not just a concern for lawyers anymore, but a company-wide undertaking that includes IT staff, software developers, project managers, and executives.