Free and Open Source Software (FOSS) has an important place in today’s software landscape. Most companies recognize the value of FOSS and they have implemented hybrid environments combining proprietary and open source software. Evidence of this trend can be found in Gartner research as reported by Laurie Wurster. The geospatial community is embracing open source at an accelerated pace. This is clear from the growth of OSGeo projects and the interest in events dedicated to geospatial open source, such as OSGIS 2011, recently held in Nottingham, UK, and the forthcoming FOSS4G to be held in Denver, Colorado later this year.
Geospatial organizations feel at home when evaluating software for accurate image registration, performance of Web mapping servers or robustness of spatial operators. However, fear, uncertainty and doubt (FUD) arise when organizations learn about the potential legal risks and liabilities associated with FOSS. I would say that FOSS risks are greater than with commercial software, in particular due to IP risks associated with copyleft licenses. As organizations leverage the opportunities presented by FOSS, it is important to understand and manage legal risks. These risks can be mitigated by a properly managed process. Let’s point out that proprietary software is not devoid of risks, an example being the discovery of unauthorized software licenses by a vendor audit.
In this article, I will examine one important aspect of managing risk while adopting open source software: software licenses. My point of view is from a “layman’s perspective,” which will greatly simplify the issues. Thus it should be regarded as a qualitative view point or a “first approximation” that must be complemented with proper legal advice from competent counsel.
Software licenses are the critical link between suppliers and consumers establishing mutual rights and obligations. As such they are extremely important in defining the “rules of the game” for the software ecosystem. In most cases, proprietary (closed source) software products come with End User Licensing Agreements (EULAs) that formalize fairly common terms of usage: rights to use in a single computer or in a network, transfer restrictions, prohibition to disassemble or “reverse engineer,” indemnifications, limits on liabilities, etc. These licenses generally do not have to address intellectual property issues beyond reverse engineering since the source code is not available. For FOSS there is an entirely different context. Licenses precisely target intellectual property issues related to the source code usage.
Licensing plays a central role in defining the very nature of open source software. The Open Source Initiative (OSI) is the recognized steward of the Open Source Definition (OSD). OSI reviews and approves licenses for consistency with the OSD. As I refer to FOSS licenses in this series of articles I will rely on the OSI official list of licenses to define the scope and provide the frame of reference for this discussion.
As I examine the risks associated with open source licenses, it is important to dissect the obligations associated with various licenses. Such obligations are, of course, directly related to usage. In the first instance, we can classify users (or usage) into two broad categories: (1) those who will not “touch” the source code and (2) those who intend to extend, modify or integrate the open source software with their own code.
In the first case, for users who just run FOSS with no modifications, generally open source licenses impose no special restrictions or obligations. The end user is free to reproduce the software in as many computers as he wishes and execute at will. Many FOSS projects offer pre-built and pre-packaged versions of their software that can be downloaded and installed without retrieving the source code. This is the best option for users who are not interested in development.
FOSS users who extend, modify or integrate the FOSS code are bound to various obligations made explicit in the pertinent open source license. In this respect, we can classify open source licenses as (listed in order of increasing usage restrictions): permissive, weak copyleft represented by the Lesser GNU Public License (LGPL), and strong copyleft represented by the GNU Public License (GPL). Note that more than 60% of FOSS licenses are estimated to be either GPL or LGPL.
So-called permissive licenses generally permit the combination of open source code with proprietary code and impose no obligations beyond a simple acknowledgement of the open source use. The most common permissive licenses are BSD, MIT and Apache. See for example the list of software programs using the GDAL library (MIT license). Copyleft licenses, on the other hand, require that modifications or combined works be licensed under the same terms. In other words, these licenses require that modifications or extensions be free and open as the original work. Copyleft licenses are often referred to as “viral” because the license terms propagate to derived works.
Let’s look in more detail at the obligations associated with the copyleft licenses as exemplified by LGPL and GPL. There is a significant amount of controversy surrounding the interpretation of GPL and LGPL licenses. See, for example, the section “linking and derived works” in the Wikipedia GPL article. The key concept that determines obligations is the concept of “derivative work.” This term has a legal definition that has a long history in copyright law as it applies to various creative works. However, in the case of software, there is legal ambiguity that has not been settled by the courts. If we take a conservative view that any combination through source code or linking constitutes a derivative work, the GPL license clearly establishes that all derived works are to be released under GPL. LGPL, on the other hand, makes a distinction between different kinds of derived works. The LGPL license says that “You may convey a Combined Work under terms of your choice…” as longs as the user can “recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work.” The implication is that if an application uses a statically linked library, the application distribution must deliver the source or object files to allow re-assembling the application. In case of a dynamically linked library, there is no such obligation because the application can be re-assembled without the source or object files.
It should be noted that generally an organization can extend, modify or integrate the FOSS code with no special disclosure obligations as long as the resulting work is used for internal purposes and it is not distributed externally. Quoting from the GNU website (Frequently Asked Questions about the GNU Licenses): “The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.”
Summarizing, for an organization that uses only the open source run time and does not modify or integrate the source code, the legal risks are minimal. The same is true for organizations that use open source privately and do not release modified versions externally. In the case of organizations that distribute modified open source code combined with proprietary code, license obligations need to be examined carefully in order to manage intellectual property risks. In particular, the subtle differences between GPL and LGPL type licenses require careful consideration. Properly managing risk permits organizations to benefit from open source software without compromising their intellectual property. In part two of this series we will examine best practices and tools for effective open source risk management.
Open source licensing: the cloud
Cloud computing is today a hot trend in the IT industry. There are many compelling factors that make the various manifestations of cloud computing attractive to vendors, developers and end users alike. One key model of cloud computing is software as a service or SaaS. If an organization offers SaaS and creates its infrastructure and applications using FOSS, even if it uses GPL (a viral FOSS license) it is under no obligation to disclose any proprietary modifications. The reason for this is that in the SaaS setting, the software does not leave the premises, that is to say there is no distribution of software.
Many consider this a loophole of the GPL license, which goes against the spirit of FOSS. A new variation of the GPL license has been created to address this issue. This is the Affero General Public License or AGPL. AGPL obligates SaaS providers to disclose the source code of any modifications made to the original FOSS program. The AGPL license says that you “…must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work.”