Lawyers and Licenses in Open Source-based Development: How to Protect Your Software & Your Sanity
1 like553 views
The document discusses the importance of understanding and adhering to open source licensing terms to avoid legal and financial penalties when using open source software components. It categorizes common license types and emphasizes the challenges organizations face when selecting appropriate licenses and managing compliance, particularly in Java development. The report also highlights Sonatype's Nexus Lifecycle, a tool designed to streamline the management of open source components and automate policy enforcement to enhance development efficiency.
Lawyers and Licenses in Open Source-based Development: How to Protect Your Software & Your Sanity
- 1. WHITEPAPER Lawyers & Licenses in Open Source-based Development: how to protect your software & your sanity
- 2. Page 2 Lawyers & Licenses in Open Source-Based Development: How to Protect Your Software & Your Sanity overview You can build better software faster with Open Source Software (OSS) components, but you must ensure that your organization meets component-licensing terms. Violating the terms of an open source license is copyright or intellectual property infringement and can lead to legal and financial penalties. What is open source licensing? Source-code authors own their work and it is protected by copy- right. Open source licensing protects the intellectual property rights of the original creators and determines the way in which it may be used and distributed by others. Common open source license types There are hundreds of open source licenses, each with distinct rules and regulations regarding the licensing of OSS components. The most common types of open source licenses are: • “Liberal”licenses, such as Apache, MIT or BSD, allow you to copy, modify and distribute derivative works with limited conditions. These typically include attribution to the original authors and a copyright notice. These licenses most often are found on lower-level projects. • “Weak Copyleft”licenses, such as Mozilla, Eclipse and the GNU Lesser General Public License (LGPL), allow you to copy, modify and distribute larger works that include open source components, but require you to make source code and documentation available for any modifications to the initial component itself. These licenses tend to be used in libraries or platforms. • “Copyleft”licenses, like the GNU General Public License (GPL), require you to license applications under the same Copyleft license even if they just include a single component licensed in this way (see Figure 1). This includes the require- ment that the application’s source code be made available Figure 1: “Copyleft” licenses require you to license applications under the same Copyleft license even if they just include a single component licensed in this way. This type of license is generally incompatible with commercial software.
- 3. Page 3 Lawyers & Licenses in Open Source-Based Development: How to Protect Your Software & Your Sanity when it is distributed outside of your organization. In some cases, such as the Afferro General Public License (AGPL), the right to obtain source code is extended to any network user of the licensed work. This type of license is generally incom- patible with commercial software. Choosing the right license type for a new application and ad- hering to all open source license obligations throughout the software development lifecycle can be tricky. Several common license types are incompatible and cannot be combined into a new application (see Figure 2). You’ll need the right tools and information to select appropriately licensed components—and ensure that you are complying with license terms. Java open source dependencies Java component-based development introduces unique licens- ing issues: • It is often difficult to determine a component’s licensing terms. Project owners may omit licensing information or submit incorrect information when publishing their project to distribution sites such as the (Maven) Central Repository. • You must consider the license of every component, including all dependencies. If even a single Copyleft licensed compo- nent, no matter how many levels deep, is included in your ap- plication, then the entire application must be licensed under that Copyleft license (see Figure 3). Figure 3: You must consider the license of every component, including all dependencies. If even a single Copyleft licensed component, no matter how many levels deep, is included in your application, then the entire application must be licensed under that Copyleft license. Figure 2: You can’t combine components with incompatible licenses into an application. Lv3 Y
- 4. Page 4 Lawyers & Licenses in Open Source-Based Development: How to Protect Your Software & Your Sanity Cut through the complexity Evaluating the legal obligations of open source components can be difficult and time-consuming. Nexus Lifecycle (formerly Sonatype Component Lifecycle Management) can help. Nexus Lifecycle delivers actionable licensing, security and quality infor- mation about open source components utilized throughout your organization. By integrating with your existing tools and processes it gives you the licensing information and management you need, when and where you need it: • Enable developers to choose appropriately licensed compo- nents during design and development with information in their IDE. • Identify and manage component licensing during the build phase to address issues quickly and avoid costly rework. • Analyze your existing applications to identify problematic licenses, including all dependencies. • Gain visibility into which licenses are being downloaded by your organization from the Central Repository. Using automated policies to guide license decisions As we have explained, understanding and choosing appropriate open source licenses is essential to software development. The challenge most organizations face is how to address this issue without slowing down the development process - either during development or later when an application scan or analysis uncov- ers numerous potential license violations requiring tedious re- search and remediation. Most organizations view open source policies as an essential method for avoiding copyright risk. Yet manual policy approvals and workflows slow the development process and developers often find workarounds. Another approach involves policy automation combined with built-in component intelligence. The developer has instant visibil- ity into the license for a component and associated risk of using it based on the organization’s established policy. Furthermore, when an inappropriate license is used, an email alert is triggered and sent to various stakeholders. Choosing the right license type for a new application and adhering to all open source license obligations throughout the software development lifecycle can be tricky.
- 5. Page 5 Lawyers & Licenses in Open Source-Based Development: How to Protect Your Software & Your Sanity Figure 4: Nexus Lifecycle includes standard policies for not only license risk (shown), but also security and architecture—all out-of-the box and ready to implement or customize. a lawyer’s perspective By Heather Meeker Many companies have come to realize that managing the use of open source without automation diverts business, technical and legal resources, which is part of the true cost of free software. The last decade has seen an evolution of automated tools to help identify, track, and manage the use of open source software. The best tools can help manage use of software in an integrated way, not focusing on open source or proprietary software to the exclusion of the other. One such approach is Software Supply Chain Management, the process of providing develop- ers with collaborative tools, intelligence, and control at every phase of the application lifecycle that addresses the management of licensing risk for component-based development. Sonatype has a solution, Nexus Lifecycle, that provides a set of software management tools designed to help organizations incorporate supply chain practices easily into their development processes. For instance, such tools enable organizations to select appropriate licensed components during design and development; identify and manage component licensing during the build phase to address issues quickly and avoid costly rework; and scan existing applications to identify licenses and dependencies, so you can assess these against corporate policy. Heather Meeker Source: TechCrunch, “Open Source Software: Compliance Basics and Best Practice,” by Heather Meeker, a leading authority on open-source software licensing. Ms. Meeker is currently employed at O’Melveny & Meyers, LLP.
- 6. Page 6 Sonatype Inc. • 8161 Maple Lawn Drive, Suite 250 • Fulton, MD 20759 • 1.877.866.2836 • www.sonatype.com 2015. Sonatype Inc. All Rights Reserved. Sonatype helps organizations build better software, even faster. Like a traditional supply chain, software applications are built by assembling open source and third party components streaming in from a wide variety of public and internal sources. While re-use is far faster than custom code, the flow of components into and through an organization remains complex and inefficient. Sonatype’s Nexus platform applies proven supply chain principles to increase speed, efficiency and quality by optimizing the component supply chain. Sonatype has been on the forefront of creating tools to to improve developer efficiency and quality since the inception of the Central Repository and Apache Maven in 2001, and the company continues to serve as the steward of the Central Repository serving 17.2 Billion component download requests in 2014 alone. Sonatype is privately held with investments from New Enterprise Associates (NEA), Accel Partners, Bay Partners, Hummer Winblad Venture Partners and Morgenthaler Ventures. Visit: www.sonatype.com Remediating risks early in development When combining automated policies with component intelligence in the IDE, developers are easily able to identify which components violate policies and which versions are preferred instead. Figure 5: By integrating component intelligence directly into the most popular developer tools, choosing a safe component takes no longer than choosing a risky one. In this example of an Eclipse interface, developers can easily identify component risk and choose a better option. For more information about Sonatype, visit www.sonatype.com