One of the most dramatic changes in software development practice over the past ten years is the building of "composite" software systems -- a combination of homegrown, open source, and third-party components, which allows teams to rapidly deliver advanced, comprehensive solutions. However, the unmanaged use of open source and third-party components adds risk. It can violate intellectual property rights, create unknown royalty obligations, increase maintenance costs, and introduce unidentified security vulnerabilities.
In this article, I will provide background on the complexities arising from the creation of composite software systems and explain how the latest version of the General Public License, GPLv3, impacts governance in several important areas.
Open source software is a wonderful resource because it allows developers to reuse existing code to fill specific needs rather than write new software from scratch. An additional benefit is that open source components which best meet users' and developers' needs lives on, with the surviving code vetted and improved over time by many people. Gradually, it evolves to become more bug-free, useful, and robust.
Open source code is developed within open source projects. As of this writing there are more than 180,000 separate open source projects (although not all are active), with more spawned daily. By definition, open source code is shared, so open source projects are generally hosted on the Web for public access (although code was originally shared by tape and bulletin boards and is sometimes available from other sources such as books). A broad range of Web sites host open source projects. My company, Black Duck Software, has identified more than 3,000 download sites containing more than 485 million open source files.
Since January 2006, the biggest debate in the open source software licensing arena has surrounded the creation of the GNU General Public License (GPL) v3. GPLv2, published in 1991, is one of the best known and most widely used licenses governing open source code. It applies to the Linux kernel and many other widely used open source projects. Across the globe, GPLv2 has affected thousands of companies and their application development teams who use GPL-governed code as part of their work. The basic tenants of the GPL are that anyone can use, modify, and redistribute code governed by the license, provided that 1) any distribution includes a copy of the license and 2) all the source code for the derivative work is freely available.
How version 3 expands the reach of the GPL
After many months in the making, the GNU General Public License version 3 (GPLv3) was issued by the Free Software Foundation (FSF) on June 29, 2007. GPLv3 has terms that are similar to GPLv2, but expands the reach of the GPL even further into such areas as patent and digital rights management. GPLv3 contains provisions that can affect software development in four key ways, with respect to reciprocity, digital rights management, patents, and license compatibility. Following is a brief summary of those provisions:
Reciprocity (derivative work)
GPLv3, like GPLv2, is a reciprocal license. This means that if an application incorporates code governed by the GPL, or is otherwise a "work based on" the GPL-governed code, and the resulting application is distributed, it must be distributed under the GPL. And the GPL itself stipulates that any distribution must include the resulting source code and a copy of the license. For years, there has been considerable debate about the meaning of "work based on" or "derivative work" in the software context. For example, the Free Software Foundation has taken the position that dynamically linking files creates a derivative work. Thus, in their view of the world, even linking your proprietary code to a GPL-governed .DLL or other shared library should force the release of source code. Clearly, this interpretation should make organizations wary about using GPL-licensed code as part of their development process.
GPLv3 adds more clarity with regard to what constitutes a derivative work. For example, GPLv3 states that if the program is "specifically designed" to work with a GPL-governed library, then the library is considered part of the overall work and the entire application is governed by the GPL. However, if one could swap out the GPL library for another library (i.e., if the application wasn't "specifically designed" to work with the GPL library), then it's not part of the overall work and would not be governed by the license.
Digital rights management (embedded devices)
"Digital Rights Management" (DRM) describes the technical means by which distributors of consumer devices prevent users from deploying modified code on the device. The FSF wanted to address the implications of DRM, at least with respect to GPLv3 code. To do that, GPLv3 includes the following: First, the license prohibits use of GPLv3 as part of DRM. Second, the FSF added provisions to ensure that any user can modify GPLv3 code that is installed on a consumer device and re-load the modified version on the device. In addition to the obligation to provide source code under GPLv3, the license requires that distributors provide all of the installation information needed to reload modified code on the applicable device. Even with some built-in limitations, the DRM provisions of GPLv3 will naturally be of great interest to manufacturers and distributors of consumer devices because of the breadth of obligations they will encounter if they use GPLv3 code.
Patent (redistributed code)
The new license provides guidance related to patent obligations that might apply to developed code. GPLv3 contains a broad expressed patent license. Simply put, this means if a developer modifies GPL code and redistributes it, that developer automatically grants a patent license to all of the patents they have that might apply to the entire application. Any derivative work, then, gets the benefit of the patent license. In that way, the FSF is trying to ensure that users have broad patent rights with respect to any modified GPL-governed code. GPLv3 also contains a "patent defense" provision, which says that, if a user of GPL'd code brings any patent claim based on that code, the user will lose their license to the code under the GPL.
License compatibility (multiple licensing issues)
GPL Version 3 is not meant to supersede Version 2. They will co-exist, so open source projects can choose to publish their code under either version of the license. The vast majority of code available under GPLv2 can be converted by the user to GPLv3 (a practice generally allowed under GPLv2). However, some projects -- most notably the Linux kernel -- are published under a version of the license that does not contain that permission. Those projects do not plan to publish their projects under GPLv3.
Other license compatibility provisions in GPLv3 are equally tricky. The new license affords developers the right to add certain prescribed additional provisions to the license to make their code compatible with other open source licenses. Developers have been asking for this, and now, for example, they can combine code governed by the popular Apache license with code written under GPL as long as they add the required provisions to their version of the GPLv3. Organizations will need to keep track of those additional requirements if they distribute GPLv3 code.
Finally, GPLv3 contains language that lets developers combine GPLv3 code with code covered by the Affero license. The Affero license removes one "loophole" developers see in GPL by requiring developers to publish the source code if the resulting application is Web-based (as in a Web-based search engine, etc.). While this requirement does not exist in the text of GPLv3, developers can combine GPLv3 code and Affero code, and the Affero provisions will apply to the whole work.
For application development teams that practice heterogeneous code assembly and code reuse, the complexities of the GPLv3 license demonstrate the need for code component management and governance. Given these recent changes to the GPL, application developers, managers, and their legal counsel must study the implications and make policy decisions about how best to include GPLv3-based code in their projects.
For further analysis of GPLv3 adoption, see www.BlackDuckSoftware.com/oss.
About Black Duck Software
Black Duck Software provides products and services for accelerating software development through the managed use of open source and third-party code. Black Duck enables companies to shorten time-to-market and reduce development and maintenance costs while mitigating the risks and challenges associated with reuse, including hidden license obligations, security vulnerabilities, and version proliferation. The company is headquartered near Boston and has offices in San Francisco, Amsterdam, and Hong Kong, as well as distribution partners throughout the world. For more information, visit www.blackducksoftware.com.
- Participate in the discussion forum.
- A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
- Global Rational User Group Community