What you should know if you are deploying open source in the cloud.
Since the emergence of strong cloud service providers like Amazon Web Services, Google and Rackspace, software development and deployment is increasingly taking place in the cloud. According to Gartner, cloud computing is expected to grow at a rate of 19% this year. Big industry players including Netflix and eBay already have turned to the cloud for significant proportions of their operations and offerings. And in the next few years, we are likely to see more and more innovative startups like Coupa completely suspended in the cloud, relegating on-premise computing to a vestige of a bygone era.
While enterprises are shifting from legacy solutions toward the cloud, open-source software is gaining significant traction for similar reasons. Gartner projects that 99% of Global 2000 companies will incorporate open source into their operations by 2016. Adopters of both cloud and open-source solutions are drawn toward the increased potential for collaboration and lower total cost of ownership.
The proliferation of open-source cloud projects (think OpenStack, CloudStack, Eucalyptus) and increasing use of open-source software within the cloud suggests a need for enterprises to understand how the cloud environment impacts open-source license compliance. Before the emergence of the cloud, restrictive open-source licenses maintained software freedom through the regulation of distribution. However, because software is provided as a service in the cloud, licensing obligations that are linked to the act of distribution no longer apply. This has led to the development of newer cloud-driven restrictive open-source licenses, such as the AGPL. The game-changing effect of the cloud on traditional open-source compliance mechanisms and the subsequent development of remedial open-source licenses calls for organizations to audit and update their intellectual property policies to minimize the risk of infringement.
The emergence of cloud computing and its impact on open-source compliance has reignited the historical battle between proprietary and open-source software, and reinforced traditional divisions within the Open Source community. The genesis of the proprietary vs. open-source debate dates back to the unbundling of IBM in the mid-1970s, after which it was no longer possible for users to access and modify code. Although user freedoms were removed through the process of unbundling, programmers continued to find ways to access, modify and share code, famously prompting Bill Gates to write his “Open Letter to Hobbyists” after Microsoft's Basic was leaked.
During the late 1970s and early 1980s, the Open Source movement emerged in two distinct factions, the first of which was headed by Richard Stallman, a former programmer at the MIT Artificial Intelligence Lab. Stallman's belief that the ability to access, modify and redistribute code is a fundamental freedom led to his development of the GNU project, which was licensed under the GPL—a restrictive license specifically designed to ensure that GNU code could not be rendered proprietary when incorporated in derivative works.
Around the same time, the BSD UNIX system was being developed by the Computer Science Research Group at Berkeley. In the late 1990s, the BSD UNIX became available under the BSD license. While Stallman's GPL was designed as a restrictive copyleft license aimed at preventing the underlying code from becoming proprietary, the BSD was drafted as a permissive license that would enable users to embed the underlying code into proprietary offerings.
Licenses that cover open-source code carry unique terms that have implications on code use, modification and distribution. As previously mentioned, there are two broad categories of open-source licenses—the permissive and restrictive types. Permissive licenses, such as the MIT and BSD licenses, provide minimal obligations on code use, modification and distribution, enabling developers to incorporate open-source code into proprietary software, which they then could protect by adding additional license terms.
In contrast, restrictive open-source licenses, such as the GPL, do not allow users of covered code to release derivative works under different license terms. In addition, these restrictive licenses require users that distribute modified programs to make their source code available to downstream users, in order to maintain the copyleft community's goal of achieving software freedom. This concept of software freedom refers to the right of all downstream users to access, run, modify and redistribute software containing the covered code. This feature of restrictive licenses renders it impossible to incorporate open-source code into proprietary offerings. There is no way to avoid these stringent rules, and the failure to comply with such obligations can lead to severe consequences, including being forced to come into compliance by releasing the asset's source code or paying damages for intellectual property infringement.
In the pre-cloud environment, software vendors made their products available to end users through software distribution. Because there was no other means of making software available to users, it was impossible for vendors to escape the distribution clauses in restrictive open-source licenses. However, this has changed with the introduction of cloud computing.
Restrictive open-source licenses, such as the GPL, operate to maintain software freedom only to the extent that the underlying open-source code is part of a distribution. For example, the GPLv3 states that:
You have certain responsibilities if you distribute copies of the software: responsibilities to respect the freedom of others. If you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code.
Before the emergence of the cloud, this license term ensured that any time software incorporating covered code was deployed to third parties, that distribution would be governed by the GPL terms such that the distributor would be forced to make its code available to users. However, the proliferation of cloud-based SaaS solutions threatened to destabilize the GPL model by creating an environment in which for the first time software was made available to users without being distributed.
In instances where software containing GPL code is made available through network services, the distribution clause is bypassed and the provider does not have to release its source code. Remember the free software reciprocity trigger: “If you distribute copies of such a program...you must pass on to the recipients the same freedoms that you received.” However, because software is not distributed in the cloud—it's simply made available to users as a service—providers do not have to pay these freedoms forward. Rather, they can access the benefits of using free software without being forced to provide those same benefits to their users. This loophole enables SaaS enterprises to embed GPL-covered code into proprietary cloud offerings. Effectively what this means is that, within this distribution-free model, the GPL assumes the attributes of a permissive license (think MIT, BSD).
For anyone who thought that the cloud rendered the proprietary and open-source debate moot, think again—the battle is far from over, it simply relocated to another frontier. Before long, the copyleft faction of the Open Source movement regrouped and responded to the threat that the cloud-based SaaS model posed to its goal of maintaining software freedom. The weapon of choice that the movement developed and deployed to respond to the unique challenges imposed by the emerging cloud-based SaaS environment was the Affero GPLv3 (AGPLv3), which covers popular applications such as PHP-Fusion, Launchpad and SugarCRM.
Unlike the GPL, which relies on the act of distribution to trigger the free software reciprocity clause, the AGPLv3 includes the following term that was articulated specifically for situations in which software is used on a network but is not technically distributed. This clause states that:
If you modify the program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the corresponding source of your version by providing access to the corresponding source from a network server at no charge, through some standard or customary means of facilitating copying of software.
This license term applies the distribution-based reciprocity clause to cloud-based software offerings in which users run programs from remote servers.
The AGPL was drafted as a solution to the problem that the public cloud created. Its preamble states that whereas the GPL “permits making a modified version and letting the public access it on a server without ever releasing its source code to the public...the AGPL is designed specifically to ensure that, in such cases, the modified source code becomes available to the community.” But what happens if an organization uses AGPL code internally? The remote network interaction clause states that:
If you modify the program, your modified version must prominently offer all users interacting with it remotely through a computer network an opportunity to receive the corresponding source of your version...through some standard customary means of facilitating copying of software.
It appears that the same principle applies in both the public and private cloud contexts—any users have the right to access the modified code and to create their own versions. In the private cloud scenario, these freedoms would extend to any employees, contractors and other parties using the server.
The failure to comply with open-source license obligations can lead to severe consequences, including being forced to come into compliance by releasing the modified code and paying damages. Non-compliant organizations are exposed to risk as courts in various jurisdictions including the United States, Germany and France have consistently ruled that open-source licenses are enforceable, leading to a proliferation of open-source litigation and settlements.
One of the earlier infringement suits that solidified the enforceability of open-source software resulted from the acquisition of Linksys by Cisco in 2003. Shortly after the acquisition, Cisco was sued for infringement relating to the use of GPL-covered code in its router firmware. It turned out that the infringing chipset was provided to Linksys by Broadcom, which in turn outsourced the development to a third party. As a part of the settlement that was reached between the parties, Cisco was forced to make the infringing code available on its Web site, appoint an open-source compliance officer and make a monetary contribution to the Free Software Foundation.
BusyBox also launched a string of successful infringement suits against companies that incorporated its code and leveraged the resulting assets in violation of the GPL. The first of these involved the use of BusyBox code in embedded systems provided by Monsoon Multimedia, Inc. BusyBox alleged that Monsoon utilized BusyBox code without making its modified code available to downstream users pursuant to the GPL. The parties settled for an undisclosed amount, and Monsoon agreed to publish its code and appoint an open-source compliance officer. A similar settlement was reached between BusyBox and Verizon Communications. More recently, BusyBox filed a suit against 14 electronics suppliers, including Samsung and Best Buy, alleging that the defendants distributed devices containing BusyBox code without making their modified code available to users. While some of these defendants opted to settle, in the case of Westinghouse, a District Court in New York found in favor of the plaintiff. In that case, the Court determined that Westinghouse willfully infringed BusyBox's copyright in the code, and consequently the damages were tripled.
The proliferation of open-source infringement suits and resulting settlements have solidified the enforceability of open-source software. Because of the immense financial and reputational damage that is associated with intellectual property infringement suits, it is crucial for organizations to ensure compliance with open-source license obligations. Although the cloud environment poses new uncertainties for organizations relying on open-source software, there are various tools that can be engaged to minimize the risk of non-compliance.
Given the new obligations imposed by the AGPLv3, it is critical for cloud-based SaaS providers to take inventory of the open-source code embedded in their product offerings and to ensure that their intellectual property policies are in line with the obligations imposed by the various open-source licenses covering the code being used. A variety of tools are available that can assist SaaS enterprises to ensure open-source compliance in the cloud. For example, enterprises can scan their software with tools that are specifically designed to detect open-source code and provide a list of the license obligations that accompany each component. In addition, a structured Open Source Software Adoption Process (OSSAP) can be used to define acceptable intellectual property license policies for the organization, audit the current software portfolio and incoming code, and ensure compliance through all of the software development and procurement stages.
Open-source license management solutions now are accessible to companies in the cloud. Because these solutions are hosted in the cloud environment, they eliminate the need for enterprises to install or update code-scanning software. Instead, companies can sign up with a service provider and are given access to software that scans their code, identifies open source and provides a breakdown of the associated license obligations. Such open-source license management services are invaluable to SaaS enterprises, particularly given the uncertainties associated with open source in the cloud. In addition to ensuring that organizations understand and are able to meet their open-source license obligations, these management solutions position enterprises to respond efficiently and effectively to any instances of non-compliance that are detected. For example, by understanding which components of the software are used in a non-compliant fashion, SaaS enterprises are positioned to replace the infringing code with code that offers similar functionality or to adapt their policies to ensure adherence to obligations.
The emerging cloud-based SaaS model offers immense opportunities but also raises new risks for organizations in relation to intellectual property infringement. Various open-source license management solutions are available to assist enterprises in making a safe transition into the cloud. For enterprises planning on navigating the cloud environment—and for those that have already made the migration—it is important to take an inventory of the code incorporated in the software being offered and to determine if open-source licensing obligations are being met. Keep in mind that the intellectual property policies that were developed for the traditional software distribution model will need to be assessed and updated to meet the distinct obligations associated with the cloud environment.