Understanding the Three Most Common Open Source Licensesdocshare01.docshare.tips/files/13810/138102055.pdf · Understanding the Three Most Common Open Source Licenses February 2012

Helping Enterprises Use Open Source Software

Understanding the Three Most Common Open Source LicensesBy Jilayne LovejoyCorporate Counsel, OpenLogic

In This Guide:• BriefIntroductiontoOpenSourceSoftware• OverviewofCommonOpenSourceLicenses• LicenseInterpretationGuidelines• TipsforOpenSourceLicenseCompliance• ResourcestoHelpYouGetStarted

UnderstandingtheThreeMostCommonOpenSourceLicenses February2012

Helping Enterprises Use Open Source Software

About OpenLogic’s Open Source License Compliance Solutions

OpenLogicoffersavarietyofproductsandservicesthathelpenterprisesunderstandwhatopensourcetheyuseandwhattodotocomplywithopensourcelicenses:

• ApplicationAuditservice• ApplicationCertificationservice•M&AOpenSourceAuditservice• OpenSourceFulfillmentCenterservice

Learnmoreatwww.openlogic.com/products/scanning-compliance.com

• OSSDiscoverybinaryscanner• OSSDeepDiscoverysourcecodescanner• OpenLogicExchange(OLEX)LicenseComplianceModule

CONTENTS GNUGeneralPublicLicensev2. . . . . . 6 Background . . . . . . . . . . . . . 6 LicenseDetails. . . . . . . . . . . . 6 HowtoComply . . . . . . . . . . . . 6 StickingPointsandPracticalTips. . . . 7 Summary . . . . . . . . . . . . . . 8 GNULesserGeneralPublicLicensev2.1. . 8 Background . . . . . . . . . . . . . 8 LicenseDetails. . . . . . . . . . . . 8 HowtoComply . . . . . . . . . . . . 8 Summary . . . . . . . . . . . . . . 9 Conclusion . . . . . . . . . . . . . . . . 9 ReferencesandResources . . . . . . . . .10 ApacheSoftwareLicensev2. . . . . . .10 GNUGeneralPublicLicensev2. . . . . .10 GNULesserGeneralPublicLicensev2.1. .10

WhatisOpenSourceSoftware?. . . . . . . 1 ADevelopmentModel. . . . . . . . . . 1 ALicensingConstruct . . . . . . . . . . 1 PermissiveorCopyleft. . . . . . . . . . 2 What’sInaName?. . . . . . . . . . . 2 InterpretingOpenSourceLicenses . . . . . 3 WhyIsItSoHard? . . . . . . . . . . . 3 Jacobsen v. Katzer . . . . . . . . . . . 3 InterpretationGuidelines. . . . . . . . . 4 TheThreeMostCommonOpenSourceLicenses . 4 ApacheSoftwareLicense2.0 . . . . . . 5 Background . . . . . . . . . . . . . 5 LicenseDetails. . . . . . . . . . . . 5 HowtoComply . . . . . . . . . . . . 5 StickingPointsandPracticalTips. . . . 5 Summary . . . . . . . . . . . . . . 6

The information provided in this white paper is for informational purposes only and does not constitute legal advice.


Page 1 Helping Enterprises Use Open Source Software

What is Open Source Software?Before you can understand any given open source software license, you must first understand open source software. Development model, social movement, legal construct, selfish motivation coupled with altruistic sharing, alternative licensing model – open source software can be said to be all of these things. Spawned by an ideology of freedom and perpetuated by licensing that is open rather than closed, the framework within which open source software exists is integral to its understanding.

A Development ModelIn his famous essay and book of the same name, “The Cathedral and the Bazaar,” Eric Raymond described the open source development model by contrasting it to the typical proprietary development model. His metaphor is instructive. Whereby the typical, proprietary approach of software development consists of confidential engineering by a limited number of people with long intervals between releases, “the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches . . . out of which a coherent and stable system could seemingly emerge only by a succession of miracles.”1 What Linux chief architect and project coordinator, Linus Torvalds2, grasped was that treating users as co-developers resulted in many people looking at the code. Those people inevitably had different uses and different priorities in terms of functionality, the result of which meant that bugs would be found and fixed more quickly. What could be called selfish motivation – to fix that which matters most to you – is harnessed in a collective and cumulative way. In contrast, a closed, or cathedral-building model of development requires extensive internal testing to discover weaknesses. In this way, open source engineering employs the sociological theory of collective intelligence.3 Of course, the only way to leverage community-based contributions to a software project is to make available the source code, or human-editable version of the code – precisely the thing which people seek to protect in the typical closed-production model.

A Licensing ConstructSo, what is an open source license? It is helpful to start by thinking about the typical intellectual property (IP) license or, to continue with Raymond’s metaphor – by asking what kind of access is usually granted to a cathedral. Anyone who has visited the Notre Dame or the Sistine Chapel would quickly answer that question with one word: restricted. U.S. copyright law vests certain rights in the author of a work upon its creation.4 These rights belong to the author by default, restricting use of the work by others and include the right to reproduce, distribute, publicly display, and prepare derivative works.5 A license allows an author to grant some of those rights to licensees and place conditions upon the grant of such rights while retaining ownership in the work. A typical software license allows a licensee to use the software and make a copy for back-up purposes, while restricting the number of users; prohibits reverse engineering and the creation of derivative works; may place restrictions on fields of use or the types of other software or hardware with which the licensed software can be used; and provides some kind of warranty as to functionality or performance.

Open source licenses are the redheaded step-children of IP licensing. Although similar to a typical IP license in terms of requiring compliance with the conditions imposed, open source licenses go against the grain by granting back a broad range of rights. As with a bazaar, open source licenses grant access to anyone at any time and offer the software “as is.” Nevertheless, pin-pointing a definition for “open source license” is a somewhat slippery task. Two oft-cited definitions come from two prominent open source organizations: the Open Source Initiative and the Free Software Foundation.

The Open Source Initiative (OSI) is a non-profit organization whose goal is to educate and advocate for the benefits of open source software.6 The OSI is specifically known for its open source definition and its approval process for licenses based on that definition. The ten-point definition requires a license to: allow free redistribution; provide the source code; allow modifications or the creation of derivative works (with some permissible restrictions around this); and pass the rights under

1. http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/578/4992. http://en.wikipedia.org/wiki/Linus_Torvalds3. See http://en.wikipedia.org/wiki/Collective_intelligence4. While there are many similarities of copyright law across jurisdictions, for purposes of this article the focus is based on United States law.5. 17 U.S.C § 106.6. http://www.opensource.org/



the license directly to each licensee. The license must not tie the software to a specific product or restrict what other software, what technology, or what fields of use it may be used with.7

The Free Software Foundation (FSF) is a non-profit organization that advocates for computer user freedom via free and open source software and publishes and maintains the GNU public licenses (i.e. GNU General Public License; GNU Lesser General Public License; the GNU Affero General Public License; and the GNU Free Document License).8 The FSF uses the term “free software” explaining that “free” is a matter of liberty not cost, or anecdotally, “free as in free speech, not as in free beer.”9 The FSF defines free software in terms of four freedoms: the freedom to run the program for any purpose; the freedom to study and change the program (which requires access to the human-readable format or source code); the freedom to redistribute copies; and the freedom to distribute copies of your modified version.

You can see that these two definitions express many of the same concepts yet in different ways. However, these definitions don’t distinguish some of the practical differences among open source licenses; namely those licenses that are considered “permissive” versus those that are considered “copyleft.”

Permissive or CopyleftOpen source licenses tend to be broadly categorized in one of two ways: permissive or copyleft. Permissive licenses are those that offer a broad grant of rights with few simple conditions for compliance. The license requirements in a permissive license are minimal, usually focused on retaining attribution notices and including a copy of the license with the work.

“Copyleft” is a play on the word “copyright” and refers to using copyright law and licensing, which is usually restrictive, to guarantee freedom. Licenses that require the licensee to provide access to the source code and to license any modified version or derivative work under the same license are referred to as copyleft. These requirements meet the goal of perpetuating the freedom of access to the source code and any subsequent modifications. The latter condition - applying the same license to any derivative work - is also referred to as hereditary, self-perpetuating, or in the pejorative, viral, or contaminating.

With these categories in mind, along with the OSI and FSF definitions and the practical reality of common license terms, open source licenses can be defined by the following attributes:

1. (permissive, copyleft) The license grants a wide range of rights – including the right to copy, distribute, modify, create derivative works, and redistribute the modified version or derivative work.

2 (permissive, copyleft) The license disclaims all warranties. The author assumes zero liability and the software is available “as is.” Although this is mentioned by neither the OSI nor the FSF definition, it is ubiquitous to open source licenses. This makes sense; if you are creating and contributing to a project and offering the code to others for no cost, you do not want to be liable for any implied warranties.

3. (copyleft) The licensee must provide access to the source code, especially if the licensee has made modifications or is distributing the code in binary format.

4. (copyleft) The license requires that any derivative work be kept under the same license.

The permissive and copyleft categories may suggest the over-arching goal of the licensor. If the goal is mass adoption of the code, including allowing the code to be used by corporations or combined and incorporated into proprietary software, then a permissive license would more easily facilitate this. If the goal is perpetuating access to the source code and ensuring that any modifications are available to others, then a copyleft license would be more appropriate. Of course, this is not a hard and fast rule. There are highly-valued open source projects under copyleft licenses that have enjoyed mass adoption, Linux being the most visible example.

What’s In a Name?Another distinction of open source licenses compared to typical proprietary software licenses has to do with the name. Open source licenses are often named after the project or institution that authored the license. For example, the GNU, Apache, and Mozilla licenses are named after the projects or foundations that authored the licenses. The BSD, which stands for Berkley Software Distribution, and MIT licenses are named after their

7. http://www.opensource.org/docs/osd8. http://www.fsf.org/about/9. http://www.gnu.org/philosophy/free-sw.html



respective universities. Where an entity authors a license, it may then issue updated versions of the license over time. For example, the Mozilla Foundation recently released Mozilla Public License version 2.0 after a lengthy review and comment period.10 By doing so, the Mozilla Foundation was able to address some ambiguities in and make overall improvements to the previous version. Despite project or institution specific names, these licenses are usually written so anyone can use them. In other words, the Apache Software License can be used by companies and individuals to license their own software, not just software by the Apache Foundation.

Interpreting Open Source LicensesWhy Is It So Hard?Understanding and interpreting open source licenses is not always an easy task. Open source licenses are essentially unilateral; if you use the software, you agree to the terms of the license. There is no protracted negotiation process during which to ruminate and refine terms as is often the case for custom-developed software. Open source licenses may not track on statutory language or use accepted license wording.11 Alternative language or definitions may be used instead of legal terms of art. The shorter licenses can be vague and the longer licenses may use technical jargon that is difficult for attorneys to understand. All of this can cause ambiguity when it comes time to interpret the license for compliance.

Adding to the difficulty in understanding and interpreting open source licenses is the fact that the more troublesome compliance terms have yet to be litigated, most notably the derivative works question in regards to the GNU General Public License. However, that does not mean there is no guidance. Organizations that have authored or maintain an open source license often provide a frequently-asked-questions resource to proselytize their interpretation. Whether a court would agree with their interpretation may be debatable, but so long as

there is no judicial opinion it is wise to pay attention to these resources. For the more common and established licenses, seasoned open source attorneys can also rely on community-accepted practices for compliance.

Jacobsen v. KatzerThere is one appellate decision involving an open source license. Among other issues, Jacobsen v. Katzer involved some code written by Jacobsen, which he released under the Artistic License.12 Katzer used the code in its product and failed to comply with the license, by not including copyright notices, attribution, and notice of modification in its distribution. This breach of license caused Jacobsen to bring an action for copyright infringement.13

Katzer argued that the Artistic License was merely a contract not a license.14 This is important because of the available remedies under contract law versus copyright law. Under contract law, the non-breaching party may recover actual damages with the goal of putting the non-breaching party where she/he would have been but for the breach. However, this may not be so helpful when the software was obtained at no monetary cost. In addition to actual damages, copyright law also allows for lost profits to be recovered in the form of “any profits of the infringer that are attributable to the infringement and are not taken into account in computing the actual damages.”15 Alternatively, statutory damages are available in the amount of $750 to $30,000 USD per infringed work or up to $150,000 USD if the infringement was willful.16 In addition, injunctive relief, impoundment, and destruction of the infringing items are possible remedies.17

The court held that the Artistic License was indeed a license, not a contract, and thus copyright remedies were available.18 The court reasoned that the “choice to exact consideration in the form of compliance with the open source requirements of disclosure and explanation of changes, rather than as a dollar-denominated fee, is entitled to no less legal recognition.”19

10. http://mpl.mozilla.org/announcements/11. For an example for those not offended easily, see: http://sam.zoy.org/wtfpl/8. http://www.fsf.org/about/12. 535 F.3d 1373 (2008).13. Id. at 1375-76.14. Id. at 1380.15. 17 U.S.C. § 504(b).16. 17 U.S.C. § 504(c).17. 17 U.S.C. §§ 502, 503.18. Jacobsen, 535 F.3d at 1382.19. Id.



This decision is an important and logical starting point for open source license jurisprudence. It firmly establishes and validates open source licenses as intellectual property licenses, eliminating a defense to non-compliance by technicality. Although the case involved one specific open source license (that is not commonly used today), the opinion reads to apply to all open source licenses, generally discussing the economic and innovative benefits of the collaborative development model.20

Interpretation GuidelinesOpen source licenses are no different than any other intellectual property license; that is, there are conditions or requirements that need to be met and restrictions that need to be minded. However, because the terms of an open source license were not bilaterally negotiated, determining intent and interpretation in order to comply with the license can be less clear than an arms-length custom licensing scenario. A helpful starting point is to break down the requirements into an if/then statement. For example, if you distribute the code - the triggering event or use of the code - then you must provide a copy of the license - the requirement or obligation. Some triggering events may demand further analysis. Does the license define “distribution” based on copyright case law or is the definition broader? Does the definition of distribution or conveyance include access to the software via a web-based platform? Is it possible that how you use the software will change over time, thus changing what requirements or obligations are triggered?

When it comes to complying with a requirement, sometimes the devil is in the details; for example, how must you provide the copy of the license? Is it enough to retain the license in the header of some of the source files or do you need to have some kind of license notice in every file? Where does the license go if you are distributing the work in binary form? Some licenses may have specific guidance on how a condition must be met and some are vague, requiring you to decide what seems reasonable.

Once you have sorted out what you need to do to comply with the open source licenses, then you need to consider if there are any conflicts among the terms. Sometimes there can be conflicting obligations causing two licenses to be incompatible. Typically this occurs when there’s a derivative work involved. For example, if you have created a derivative work by combining

two projects, each under a different license that requires you to release a derivative work under the same license, it would be impossible to comply with both licenses. If you have an end-user license agreement for your product, there may be a conflict between the terms of your license and the open source licenses for code included in your product.

At the end of the day, when it comes to complying with open source licenses, there is often no definitive answer. Because there is no established jurisdiction on the interpretation of specific open source license compliance terms, you may simply have to make a determination based upon your interpretation of the license. How you make that call may hinge on the risk profile of your company as well as how your product is engineered and therefore involve discussions among your business and development teams.

The Three Most Common Open Source LicensesThe three most common licenses discussed in this paper were identified based on 2011 research from OpenLogic Exchange (OLEX), OpenLogic’s database of over 330,000 open source software packages. Of course, there are different ways to determine what is “most common.” When looking at the percentage of projects using various licenses, the most common licenses (regardless of version) were the GNU General Public License (GPL) at almost 70%, the Apache Software License (Apache) at 7.6%, and the GNU Lesser General Public License (LGPL) at 6.7%.21 However, when looking at licenses for the projects actually downloaded from OLEX, the top three were the same but in a different order, with Apache coming out on top, followed by LGPL and then GPL. Similarly, when we looked at aggregated data from our scanning solution, OSS Deep Discovery22, Apache came out as the most frequently found license in code scanned by our customers. This may indicate that while many projects choose GPL, the projects most often being used are under Apache. This could be the result of the preference of developer versus preference of end users in terms of the goals of the license. Popularity of the actual projects under each license may also be a factor. Regardless of how we looked at the numbers though, Apache, GPL, and LGPL were the most prevalent open source licenses.

20. Jacobsen, 535 F.3d at 1378-79.21. http://www.openlogic.com/news/press/05.16.11.php22. http://www.openlogic.com/products/scanners.php



For each license, we will look at its background, what the license grants you, how to comply, and some tips and sticking points. Citations to the section of the license are included in parentheses. Additional references and resources for each license are included at the end of this document.

Apache Software License 2.0Background

The Apache Software License 2.0 (Apache 2.0) license was released in 2004 and is OSI approved. This is the third iteration of the license. Version 1.0 was much like the original four-clause BSD License. Version 1.1 added a clause requiring acknowledgement and a naming restriction clause and, like the BSD License, removed the advertising clause to avoid compatibility issues. Apache 2.0 took a departure from the brief, simplistic style of version 1.0 and 1.1 by adding a definition section and an explicit patent grant, causing the license to be much longer. Removing the “vanity” clauses – the acknowledgment and naming restriction clauses that included specific names in version 1.1 – reduced potential license proliferation and made it easier for anyone to use the license for their own code. Apache 2.0 is used for all Apache Software Foundation projects, including the Apache HTTP server23 as well as the majority of the code used in the Android mobile operating system.24

License Details

Almost all open source licenses provide a direct grant from the licensor to each licensee. This is often implicit, but Apache 2.0 has explicit text to this end. The definition of “contributor” means each person who has ever contributed to the work as well as the original licensor. Each contributor grants the rights to reproduce, prepare derivative works, publicly display, publicly perform, and distribute work in source or object form (Section 2). This grant of rights tracks unambiguously with U.S. copyright law.

The license also includes an explicit patent license to all patent claims that a contributor has that might be infringed by contribution or combination of contributions with a work licensed under Apache 2.0 (Section 3). The frequently asked questions for the license on the Apache Software Foundation website clarifies that this only applies to patent claims that you own or have the right to license and that read on your contribution or

the combination at the time of your contribution.

Finally, like all open source licenses, there are no warranties – a work licensed under Apache 2.0 is provided “as is” and disclaims all liability (Sections 7 and 8).

How to Comply

Below is a summary of the key requirements that must be met to comply with Apache 2.0 and the restrictions and terminations clauses.

1. You must provide a copy of the license (Section 4.1).

2. You must retain all notices (Sections 4.3 and 4.4).

3. You must give notice of modified files (Section 4.2).

4. You must apply the license to modifications if the modifications are submitted as a contribution to the Apache Software Foundation (this does not apply otherwise) (Section 5).

5. You must agree to indemnify contributors if you offer additional support, etc. (e.g., your own warranties). (Section 9).

6. You may not use the Apache trademarks or trade names without prior permission, except as necessary in notices (Section 6).

7. The license terminates if patent litigation commences that alleges the licensed work infringes on the licensee’s patent – this is referred to as a patent retaliation clause (Section 3).

Sticking Points and Practical Tips

Below are a couple of aspects of Apache 2.0 that warrant a closer look:

4. “Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: . . . 2. You must cause any modified files to carry prominent notices stating that You changed the files . . .”

This seems straightforward – if you modify the code, you must say you modified it. But what is considered “prominent” notice? It’s quite possible that what one person considers “prominent”

23. http://httpd.apache.org/24. http://source.android.com/source/licenses.html



might be different than someone else. One strategy is to look how notice of modification is required for other open source licenses used in your product and then implement “notice of modification” in a way that will comply with all the open source licenses in use that have such a requirement.

It should also be noted that if you are distributing the modified code, there is no requirement to submit the modifications back to the Apache Software Foundation. The original code will still be under the Apache license, but you may distribute your modified version under a different license so long as you comply with the Apache license as well. In other words, the Apache 2.0 is considered to be a permissive license, not a copyleft license.

Another issue to be aware of with the Apache 2.0 license is its lack of compatibility with the GNU General Public License version 2 (GPL v2). The FSF considers the clauses that terminate the license if a patent infringement suit is initiated and the indemnification clause as “further restrictions” in violation of Section 6 of GPL v2.25 The Apache Software Foundation does not consider the two licenses incompatible, reasoning that section 7 of GPL v2 is similar enough to the Apache 2.0 patent termination clause that it makes them the same restriction.26 Version 3 of the GPL remedied the controversy by allowing certain additional clauses, including a patent retaliation clause. However, the Apache Software Foundation considers GPL v3 and Apache 2.0 “one-way” compatible due to the licensing philosophy regarding linking; that is, under GPL v3, merely linking to a work is considered a derivative work.27 The issue has never been completely resolved. Therefore, this is something to keep in mind if dealing with both licenses in one project or piece of software.

Summary

If you’re considering what license to use, Apache 2.0 is a good choice if your goal is mass adoption of your project or code, including the use or inclusion in proprietary or closed code, and you are not concerned about accessing modified version of the source code. In terms of compliance, proper attribution is key: do not strip out headers; retain a copy of the license and notices; and track and record your modifications.

GNU General Public License v2 (GPL v2)Background

The GPL v2 was released in 1991 and is OSI approved. This is the second iteration of the license. There is a third version, released in 2007, but widespread adoption of version 3 has yet to take hold and much software remains under GPL v2. Notable projects licensed under GPL v2 include BusyBox, the project that is the subject of most, if not all, of the lawsuits filed by the Software Freedom Conservancy.28 Linux is also licensed under GPL v2.

License Details

The GPL v2 grants licensees the right to copy, distribute, and modify a work. Any deviation from these expressly granted rights automatically terminates the license (Section 4). The GPL v2 also enables users to charge a fee or offer a warranty for the work (Section 1). Like all open source licenses, the work is provided “as is” and the licensor disclaims all warranties (Sections 11 and12). GPL v2 allows a licensee redistributing the code to choose any version of the GPL unless otherwise stated (Section 9). You may use the license on any work, but cannot modify the text of the license in any way. This is to discourage license proliferation.

How to Comply

Below is a summary of the key requirements that must be met to comply with GPL v2 and the restrictions and termination clauses.

1. You must provide a copy of the license (Section 1, 2, and 3).

2. You must retain copyright, attribution and disclaimer notices (Section 1, 2, and 3).

3. You must give notice of modified files (Section 2 and 3).

4. You must provide the source code (Section 3).

5. The license applies to all derivative works (this makes it a copyleft license) (Section 2).

6. You must not place any restrictions on the grant of rights (Section 6).

7. The license terminates automatically if the terms are violated (Section 4).

25. http://www.gnu.org/licenses/license-list.html#apache2 26. http://www.apache.org/licenses/GPL-compatibility.html27. Id.28. http://www.busybox.net/



Of course, the million-dollar question when it comes to GPL v2 is: what is a derivative work? The license states that any derivative work must also be licensed under GPL v2 (or another version of GPL), however it never clearly states what is considered a derivative work. Merely asking if you’ve modified the work or created a derivative work is probably not a thorough enough inquiry. This is a muddy area of U.S. copyright law as it is based on fact-specific, case-by-case analysis. Further complicating matters, the GPL v2 begins by defining the term “work based on the program” as a derivative work under copyright law, but then goes on to mention this term in four more places in the license with inconsistent references and implications to its meaning that result in seemingly broader interpretation than under U.S. copyright law.

Because there is no judicial opinion on the derivative work question, we look to the community and authors of GPL v2. Information posted on the FSF’s frequently-asked-questions page consider these scenarios a derivative work: (1) static or dynamic linking; (2) plug-ins that make function calls and share data structures (except operating system libraries); (3) modules included in same executable file; and (4) modules designed to run linked together in a shared address space. Conversely, Unix-style output chaining, sockets, remote procedure calls, and independent execution such as command line arguments would not be considered a derivative work according to the FSF.30 Due to the lack of clarity here, Linus Torvalds has included his interpretation and intent on the derivative work question in regards to Linux, which is licensed under GPL v2.31 His view is that user-space programs are not considered a derivative work of the kernel; to hold otherwise would mean that any program that ran on Linux would have to be also licensed under GPL v2.

Of course, as technology evolves, more situations arise over time that change the way code fits together, making the derivative works question ever-challenging. The guidance here is to consider the intimacy of the integration between the GPL’ed code and the other code. It is also helpful to think in terms of the spirit of the license: perpetuating the freedoms you got with the software. You must provide enough code or information to enable subsequent licensees to take the code and your modifications and also be able to modify it.

Sticking Points and Practical Tips

The notice of modification requirement in GPL v2 is very similar to the language in Apache 2.0; however, it states that in addition to “prominent notice” you must also provide the date of any changes. One way to ensure compliance with this requirement is to create a policy for tracking modified files that will work for all applicable licenses – providing extra information such as dates of changes for a license that doesn’t require dates is not going to violate the license.

The requirement that you must provide the source code has been a hot topic in the open source license compliance world. This requirement has been the subject of every suit filed by the Software Freedom Law Center and many other non-compliance actions.29 There are two ways to comply in a commercial distribution situation; a third option exists but only applies to non-commercial distribution (Section 3(c)). The first option is to simply include a copy of the source code with your distribution (Section 3(a)). This is the easiest and safest way to comply; once you have provided the source code, you have complied and no further action is needed. However, depending on how you distribute your product or the product storage limitations, this may not always be practical. If you are distributing an executable via a download, you may offer “equivalent access” to a copy of the source code even if both the executable and source code are not downloaded at the same time, i.e., via separate servers (section 3). The second option is to provide a written offer for the source code, which must be valid for at least three years (Section 3(b)). This option can be problematic due to the time frame; can you be sure that the address you provided will still be valid and someone will respond in three years?

Regardless of which option you choose, you must ensure that you provide the complete corresponding source code. Pay attention to how this is defined in the license, which includes associated interface definition files, scripts, and any modules contained in the executable (Section 3). A practical compliance tip here is to always keep a copy of any source code used in your product along with the necessary build files, scripts and documentation. This is also good development practice, as sometimes it is hard to find the exact version later when you need to fix a bug in a legacy product.

29. See Software Freedom Law Center, http://www.softwarefreedom.org/services/; and gpl-violations, http://gpl-violations.org/about.html#whois30. http://www.gnu.org/licenses/gpl-faq.html#MereAggregation31. http://kerneltrap.org/node/1735



GNU Lesser General Public License v2.1 (LGPL v2.1)Background

The LGPL v2.1 was released in 1999 and is OSI approved. Like the GPL v2, this is the second iteration and more oft-used version, although a third version was released in 2007. Generally speaking, LGPL is considered a more relaxed version of the GPL. As originally conceived, the “L” in LGPL represented “Library” as the license was designed to be used for libraries. (In the industry, the LGPL is fondly referred to as the Lesser GPL due to the more relaxed nature of the license.) The rationale was to permit the use of the library in proprietary programs, because if the library was released under GPL then any program linked to that library would also need to be released under GPL. By relaxing the obligations triggered when linking the library to other code, libraries licensed under the LGPL v2.1 can enjoy greater mass adoption.

License Details

The LGPL v2.1 grants essentially the same rights and includes the same termination clause as does GPL v2. The main difference lies in how and under what circumstances the hereditary provision is implemented. In other words, the difference really comes down to compliance.

How to Comply

Complying with the LGPL v2.1 involves many of the same requirements as GPL v2 with some exceptions and differences – underlined and discussed further below. Essentially, if you distribute unmodified source or object code or a modified version, similar provisions as the GPL v2 apply.

1. You must provide a copy of the license (Section 1, 2, 4, and 6).

2. You must retain copyright, attribution, and disclaimer notices (Section 1, 2, 4, 6, and 7).

3. You must give notice of modified files; the modified version must still be a library (Section 2).

4. You must provide the source code, if you are distributing object code (Section 4 and 6).

5. The license applies to all derivative works (with an option to

Section 6 of the GPL v2 states that you “may not impose any further restrictions on the recipients’ exercise of the rights granted herein.” Like the definition of a derivative work, the license authors take an expansive view of what may be considered a further restriction. This restriction can come up in two scenarios. If you create a derivative work by combining some GPL’ed code and some other code under another license (open source or otherwise), the sum of that work would need to be licensed under GPL, while the terms of the other license may also still apply to that code. If that license has terms that could be considered a further restriction, the licenses are incompatible and the code cannot be combined. Another scenario is if your product contains GPL v2 code and you release your product under an end user license agreement (EULA) that has terms considered to be a further restriction. A recent public example of this scenario involved an iPhone app that included GPL v2 code and was available via iTunes.32 Because the iTunes store terms include restrictions on the number of users and number of copies a recipient may make, the FSF considered this a further restriction.33 To remedy this scenario, remove any such restrictions from your EULA or make sure your EULA contains a carve-out or exception for conflicting terms with any open source license stating that in such case, the terms of the open source license apply as to that part of the code. In Apple’s case (or any other such app store) you can simply come into compliance by ceasing distribution of the code, although that may not be the best outcome.

Summary

In sum, license your work under GPL v2 (or any of the GPL licenses) if your goal is to perpetuate the freedoms of open source software and if you want access to modified versions of the source code or if you don’t want people to be able to modify your code and release it under a proprietary or otherwise closed license. For compliance, pay special attention to tracking your modifications and providing proper access to the source code – whether you modify the code or not. If you are combining the GPL’ed code with other open source software or your own code, heed how the code interacts and integrates.

32. http://www.wired.co.uk/news/archive/2010-11/01/vlc-could-be-pulled33. http://www.fsf.org/news/2010-05-app-store-compliance



Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)

Section 6 provides several options to comply with the requirement to provide the source code. Similar to the options from GPL v2, you may accompany the executable with the source code or equivalent access or make a written offer for the source code. Additionally, section 6(b) has been interpreted to mean that if you are dynamically linking to the library, you have met the source code access requirement so long as you allow new versions of the library to be linked with the application:

6 . . . Also, you must do one of these things: b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user’s computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.

Finally, the FSF has clarified that in regards to Java applications that link to LGPL v2.1 libraries, the application need not be released under LGPL v2.1, but need only follow the requirements of section 6.34

Summary

If your goal is mass adoption of your library, but you also want to perpetuate the freedoms of open source software and still allow your library to be used, then the LGPL v2.1 is an appropriate license to use. Bear in mind, the LGPL v2.1 is very similar to GPL v2 but is more permissive. For compliance, pay attention to the same issues as with GPL v2 in essence, and make sure you allow modification and recombination of the library.

ConclusionIn a world where software is in everything and open source software is becoming more and more pervasive in all things digital, open source licenses and compliance cannot be ignored. Motivated only by risk of lawsuit and relying on second-hand

apply GPL instead) (Section 2 and 3).

a. There is an “exception” (as compared to GPL v2) to what constitutes a derivative work (Section 6).

6. You must provide an uncombined library if combining the library with other libraries (Section 7).

7. You must not place any restrictions on grant of rights (Section 6).

8. The license terminates automatically if the terms are violated (Section 4).

Besides providing notice of any modifications you make, the modified version must also be a software library. Additionally, the modified version must still allow the library to operate under a wide range of programs. Section 2(d) states that you must make a “good faith effort to ensure that . . . [it] performs whatever part of its purpose and remains meaningful.” The library cannot be so tightly tied to a specific program’s data structures that it won’t work; otherwise you have to provide what it needs to make it work.

In regards to the hereditary nature of LGPL v2.1, modifications must be licensed under either the LGPL or GPL, however there is a quasi-exception to this requirement in Section 6. Where the library is combined or linked with a work that uses the library, you may license that work under other terms, provided that those terms “permit modification of the work for the customer’s own use and reverse engineering for debugging such modifications” (Section 6). It’s important to remember that the overall goal is to provide the complete object files so users can re-link after making changes and recompiling it. This theme carries through to the requirement to provide the source code as well, as noted in the highlighted text below:

6 . . . Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable “work that uses the Library”, as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified

34. http://www.gnu.org/licenses/lgpl-java.html



information or what some anonymous person posted on a project forum for your compliance guidance is neither acceptable nor wise. Careful legal analysis coupled with a broader understanding of the “bazaar” in which open source software lives is the only way to ensure reasoned interpretation and sound decision-making.

References and ResourcesApache Software License v2http://www.apache.org/licenses/LICENSE-2.0

Applying the Apache License v2 http://www.apache.org/dev/apply-license.html

ASF Legal frequently asked questionshttp://www.apache.org/legal/resolved.html#category-b

Apache 2.0 and GPL compatibilityhttp://www.apache.org/licenses/GPL-compatibility.html http://www.gnu.org/licenses/license-list.html#apache2

License Profile: Apache Software License, v2.0http://www.ifosslr.org/ifosslr/article/view/42

The Apache License (v2) – An Overviewhttp://www.oss-watch.ac.uk/resources/apache2.xml

GNU General Public License v2http://www.gnu.org/licenses/gpl-2.0.html

Frequently Asked Questions about version 2 of the GNU GPLhttp://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html

OpenLogic is a leading provider of enterprise open source solutions for the cloud and the data center. OpenLogic helps hundreds of leading enterprise across a wide range of industries to safely acquire, support, and control open source software. OpenLogic offers certification, commercial-grade technical support and indemnification for 600 open source packages backed by the OpenLogic Expert Community. OpenLogic also offers CloudSwing, a complete open PaaS solution for enterprises seeking to deploy applications and customized open source stacks in the cloud, and OLEX Enterprise Edition, a SaaS solution for open source scanning and governance.phone:1-888-OPENLOGIConline:www.openlogic.com

© 2012 OpenLogic, Inc.This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/

Frequently Asked Questions about the GNU Licenses http://www.gnu.org/licenses/gpl-faq.html

SFLC: A Practical Guide to GPL Compliance: http://www.softwarefreedom.org/resources/2008/compliance-guide.html

Understanding Derivative Works in Open Source Software: The “Border Dispute” of GPL v2 http://www.openlogic.com/downloads/open-source-derivative-works.php

Software Interactions and the GPLhttp://www.ifosslr.org/ifosslr/article/view/44

GNU GPL 2.0 and 3.0: obligations to include licenses text, and provide source codehttp://www.ifosslr.org/ifosslr/article/view/31

GNU Lesser General Public License v2.1 (LGPL v2.1)http://www.gnu.org/licenses/lgpl-2.1.html

Frequently Asked Questions about the GNU Licenses http://www.gnu.org/licenses/gpl-faq.html

The GNU Lesser General Public License v2.1 – An Overview http://www.oss-watch.ac.uk/resources/lgpl.xml

The LGPL and Javahttp://www.gnu.org/licenses/lgpl-java.html

Why you shouldn’t use the LGPL for your next libraryhttp://www.gnu.org/licenses/why-not-lgpl.html

Documents

Understanding the Three Most Common Open Source Licensesdocshare01.docshare.tips/files/13810/138102055.pdf · Understanding the Three Most Common Open Source Licenses February 2012