The latest technology buzz, after the Internet, telecom, and mobile, is cloud computing. Hype or not, in various names and forms, cloud computing providers - platforms and applications alike - are counting on more than $40 billion in revenue in 2011 alone, growing to more than $241 billion in 2020, according to a recent report on "Sizing the Cloud" by Forrester Research.

Open Source Software in the Clouds
Most software applications today incorporate some open source software directly or indirectly (dynamically linked). Developer's resourcefulness, code reuse, and efficiencies of development make open source an attractive option for all technology organizations. Cloud applications are no exception and many applications deployed in clouds are either entirely open source (think OpenStack or OpenERP Server), or have a significant amount of open source in them. According to the "Future of Open Source Survey" released by Northbridge Venture Partners, there are now more than 470 open source projects targeting cloud computing.

The use of open source software in a cloud application is governed by certain obligations, usually contained in the associated open source license. Managing compliance with software licenses is like any other quality management process. A good quality assurance process makes sure that the deficiencies are discovered and corrected before a product is released to the market.

Once the market discovers a quality problem, correcting it could be costly. Until now, open source software license management has been more rigorously applied to products that were distributed in volume, such as desktop applications, networking devices, entertainment products or mobile devices. Ownership and licensing issues abound in the mass products domain - think Sony vs. LG, Apple vs. the world, Microsoft vs. Google, SFLC vs. Cisco/Linksys, SFLC vs. Samsung/Verizon, etc.

Cloud computing technology and platforms don't introduce new risks on their own, rather cloud-based software applications do. What separates a software application deployed in a cloud from other applications is that generally these applications are not distributed. They are perceived to be less visible from market scrutiny, and also don't fall under many of the obligations associated with copyleft licenses.

Open Source Licenses
The variety of licenses currently governing the use of open source software is extensive, with approximately 80 recognized by the Open Source Initiative (OSI). In reality, less than two dozen are exploited. Almost all open source licenses can be widely categorized into several varieties.

• Public Domain licenses are basically free-for-all licenses you can do anything with (except sue the author).
• Permissive licenses, such as MIT, BSD and Apache licenses are most common, as they can be modified and used in any open source or proprietary application as long as the attributions (copyright comments and the names of original authors/organizations) are not deleted.
• Copyleft licenses have more or less protective (also referred to as restrictive) terms associated with them.
• Weak copyleft licenses, including Eclipse Public License (EPL) and Mozilla Public License (MPL), allow modification and mixing of the open source code with proprietary code, as long as you make the non-modified open source code available somewhere on line and point to it in the documentation. LGPL (Lesser GPL) licenses are strongest in this category as they require modified code to be released in the source form (unless the application only links to the open source LGPL code and does not statically include it in the application).
• Strong copyleft licenses, such as GPL version 2 and version 3, impact software that is distributed. Almost all of these licenses require software (using all or part of a copyleft open source software) be released under copyleft obligations (hence the term viral used for these licenses). Any proprietary code that is a modified version of the GPL code must also be made available in source form. GPLv3 specifically disallows use in its entirety or modified form in any DRM applications.

Alfero GPL and Cloud Applications
The Alfero version of the GPL (AGPL) license, issued by the Free Software Foundation in late 2007, goes one step further, extending the GPLv3 rules to applications that are not distributed. These include software developed mainly for in-house applications and software deployed in web services or cloud applications. Specifically, if the software deployed in a cloud application contains, in its entirety or modified form, any AGPL-licensed software, the source code for the entire running application must be made available to the community.

AGPL obligations, in summary, are the following:

• Freedom of use - no license fee to use, modify, redistribute.
• Copyleft - reciprocal usage and disclosure/permission requirements.
• Source Code Provision requirement - source code must be provided with any distribution (propagation) of code (original and modified).
• Modifications are allowed, but all modified files must have their source code freely available for use and modification by others.
• Combination with other code is NOT permitted unless the other code is compatible or can be converted to GPL terms [copyleft].
• Anti-Circumvention Protection - no code covered by GPLv3 may be included in or constrained by any anti-circumvention mechanism (technical or legal).
• Software Patent License Grant - a software patent that is based in any part on GPLv3 code and distribute the product, you are deemed to grant a license to use, modify and redistribute that patent to all downstream users of the product.
• "Tivo-ization" clause - if your product (that uses or is based around GPLv3 code) is bound by other licensing terms that are restrictive or otherwise incompatible with GPLv3, you may not convey (distribute) the product.

Certain versions of popular web applications such as SugerCRM, Launchpad and PHP-Fusion are licensed under AGPL.

Last Word...
Just like traditional software, it's important to know what is in your code as early as possible before it goes to market. As with all quality management processes, discovering your license obligations early in the development process reduces the cost and time spent fixing problems right before the product is released. Many cloud applications are not distributed, and therefore don't fall under obligations associated with many copyleft licenses, except the recent ones such as AGPL. To gain a clear understanding of third-party components and their license obligations a process must be put in place where external content is identified, tracked and managed. This can be done within a structured open source adoption process, either manually, or increasingly deploying automated tools.

• Which Open Source Software License Should I Use?