Client Counseling for Common OSS License Problems Terry J. Ilardi1 Copyright Counsel International Business Machines Corp. Interpreting and Understanding FOSS Licenses While simple in concept, study of the whole area of free and open source (FOSS) licenses is made vastly more complicated by the fact that so many different agreements fall under the general rubric of “open source.” There are numerous open source licenses, each of which enforce a different set of philosophies and seek achievement of differing goals2. The Open Source Initiative (OSI) manages a comprehensive definition of open source software3 that while useful for enabling general understanding of what FOSS is and is not, is of limited usefulness if you are trying to measure the impact of the use and/or distribution of specific FOSS on your client. Virtually all licenses that are popularly considered to be “open source” adhere to the OSI definitional set but the scope of the definition allows for differences between the licenses that adhere to it. The differences, some subtle, some not so subtle, can and do have enormous ramifications. Whatever open source software is, it is not "Public Domain."4 The software’s author always retains copyright in the work and uses those copyrights to enforce compliance with the nontraditional terms and conditions of a FOSS license. Indeed, one of the leading proponents of open source software, the Free Software Foundation (FSF), describes this approach as “copyleft,” stating “Copyleft5 uses copyright law, but flips it over to serve the opposite of its usual purpose: instead of a means for restricting a program, it becomes a means for keeping the program free.”6 Regardless of the license chosen by the author,7 that license determines the appropriate uses of the work. All licenses permit distribution and modification of the code but in 1 The views expressed in this article are those of the author alone and not of IBM Corporation. 2 The plethora of open source licenses has been decried by many for some time now, but OSI has taken steps to control the proliferation of new licenses and reduce the number of existing licenses. http://opensource.org/proliferation-report (last checked September 6, 2017). 3 The definition may be found at http://opensource.org/docs/osd (last checked September 6, 2017). 4 The 1989 amendments to U.S. Copyright Law (17 U.S.C.) under the Berne Convention Implementation Act (BCIA), have made it difficult to inject any work into the public domain through mere inaction; one will almost always require a written “dedication.” One of the few publicly available documents that can be used to dedicate a work to the public can be found at http://creativecommons.org/choose/zero/. (last checked September 6, 2017). 5 For a further discussion of “Copyleft” see the discussion of the GPLv2 below. 6 http://www.fsf.org/gnu/thegnuproject.html (last checked September 6, 2017). 7 To further complicate matters, OSS software is sometimes licensed under more than one license. For example, the Mozilla browser project had been licensed under a trilicensing scheme, allowing the contributor to select from the GPL, LGPL and Mozilla licenses ( http://www- archive.mozilla.org/MPL/relicensing-faq.html) for its Mozilla browser. (last checked September 6, 2017). - 1 - allowing those activities, each imposes its own, sometimes unique, set of obligations and conditions. As of the date of this writing (September, 2017) the opensource.org site listed 80 unique licenses8 that have been approved and certified by that organization as meeting their definition. There are literally hundreds of other licenses for which such certification has not been sought although most of these are little used. Some open source licenses are single paragraphs that simply authorize copying, modification and distribution of the source code with few other requirements or restrictions.9 Others contain more detailed terms and conditions. For example, some require that the open source license terms apply to other programs that are combined with the open source program, grant patent licenses by distributors or contributors, or require distribution of the source code.10 One requests that the user buy the programmer a beer.11 These licenses are usually found in read.me, licensing.txt or copying.txt files that are downloaded, along with the relevant software, from the Internet or packaged on distribution media, such as a DVD. To the seasoned IP practitioner, FOSS licenses defy many of the traditional notions of value arising from IP ownership. Royalty free licensing of copyrights and patents undercuts the usual value proposition in software and forces the IP creator to gain revenue elsewhere. These differences from traditional licensing schemes coupled with the wide variety of licenses available are principal sources of the continuing challenge that an attorney faces when advising her client on the correct way to launch a product or implement a business strategy dependent on open source software components. Despite what you may have heard, FOSS does not create any new type of intellectual property; the seasoned IP attorney is already equipped with the necessary tools to examine the impact of these licenses. The questions that need to be asked are generally the same–but the answers may be very different. A Sampling of Important FOSS Licenses GPL/LGPL MPL/Apache/ EPL BSD/MIT 8 http://opensource.org/licenses/alphabetical (last checked September 6, 2017). In fact, many of the licenses are no longer being used for new code but govern, principally, older code. 9 See, for example, the BSD, discussed below. 10 See, for example, the GPLv2, discussed below. 11 https://github.com/metashare/META-SHARE/blob/master/NOTICE (last checked September 6, 2017). Among its other simple requirements, the Free Beer License states: “If you use this piece of software frequently, and you think it is worth a couple of euros, you are not allowed to send the author anything else than beer or means that provide facilities to get beer into the author(s) (i.e. openers, glasses).” - 2 - FOSS licenses exist on a spectrum with the “strong copyleft” GPL12 and its brethren that enforce broad sharing, on the left, the Mozilla Public Licenses (MPL), Apache Public License (APL) and the Eclipse Public License (EPL) others that take a moderated approach to the requirement to share code, somewhere in the middle and the Berkeley Software Distribution (BSD) and MIT licenses, which are more or less completely laissez faire in their approach, requiring little or no code sharing, inhabiting the right. While it is well beyond the scope of this paper to analyze all, or even the top ten most widely used licenses, it will be useful to consider several of the most popular licenses to help with your understanding of the conditions they impose upon your client. The GNU General Public Licenses The GNU GPL licenses are undeniably the most important FOSS licenses; about 36% of all open source projects are licensed under the GPL family of licenses.13 Of these, the GPLv2 is the single most important of the GPL licenses and, for that matter, of all FOSS licenses. The GPLv2 One of the most important features of the GPLv2, both to its supporters and its detractors, is what has been described, somewhat pejoratively, as the viral effect. 14 This effect requires that any work that is derived from GPL licensed code must also be licensed under the GPL. This result is far reaching since the definition of derivative work or “based upon” is broadly interpreted by the FSF to include not only works that are modifications of the existing GPL code, but also to include, inter alia, works linked (dynamically or statically) to GPL code, certain software designed to work with and depend upon preexisting GPL code and otherwise new works that include a portion of preexisting GPL code.15 For example, proprietary software that includes any modified or unmodified GPL code may need to be distributed under the GPL if it is a derivative work, 12 For our discussion GPL refers to family of copyleft licenses that include GPLv2, GPLv3, Affero (AGPLv3), LGPLv2 and LGPLv3. There are other strong and weak copyleft licenses in addition to these. See http://www.gnu.org/licenses/license-list.html (last checked September 6, 2017) for more on the various types of licenses. 13In 2008, freshmeat.net, a then important open source repository, showed that more than 64% of the projects it housed were licensed under the GPLv2. http://freshmeat.net/stats/ (last checked February 4, 2008). BlackDuck http://www.blackducksoftware.com/resources/data/top-20-licenses shows that while this number has fallen considerably, GPLv2 is the second most widely used OSS license accounting for t 18% of FOSS projects. But the GPL family of licenses, which includes versions 2 and 3 of both the GPL and LGPL, and the AGPLv3, account for about 32% of FOSS projects. The decrease in market share has come at the hands of permissive licenses such as the MIT (32%), BSD (7%) and Apache 2.0 (14%) licenses which collectively now account for 53% of open source projects (last checked September 6, 2017). 14“The name "viral licenses" refers to the fact that any works derived from a copyleft work must preserve the copyleft permissions when distributed.” Copyleft, Wikipedia, http://en.wikipedia.org/wiki/Copyleft#Is_copyleft_.22viral.22.3F (last checked September 6, 2017). 15 The FSF has argued that the copyright law’s explanation of derivative works is in a sorry state but that the GPL does not go beyond what the law permits. See, for example, Dan Ravicher, Derivative Works: Statutes and Case Law, published by the Free Software Foundation, 2004.