Open Source Compliance Basics and Best Practices
Published: November 21, 2012 10:30
As open source components lower costs, improve quality and speed software development processes, they’ve quickly become the building blocks of the modern software supply chain. In fact, open source components make up about 80 percent of today’s typical applications . But the development shift from custom-written applications to applications assembled using existing open source components has introduced new challenges and risks. If you’re starting a business or launching a project that leverages open source, you need to understand the basics of open source licensing, which control how you can use the intellectual property in open source software (OSS). Understanding OSS licensing and compliance is essential to position your business or project for success.
Enforcement and Risks
Open sources licenses are real – and in recent years, they are being enforced more and more often. If you use open source code but don’t follow the license requirements, you can face:
- Copyright Infringement Damages (Including Statutory Damages)
- Injunction (Orders Halting Use or Distribution of Code)
- Reduction in Value of Patent Portfolios
- Bad PR
- Engineer Relations Problems
- Corporate Exit or Investment Failure
Basic License Conditions
Users of OSS must follow the licensing conditions for each piece of OSS they are using, including fragments or sub-components. Therefore, software development organizations, individual developers, and organizations using OSS within internal computing environments, or distributing products that include OSS components, must be able to identify all of the licenses that apply to the OSS -- and adhere to their licensing conditions.
This can be perplexing, as there are hundreds of different open source licenses, each with its own, sometimes unique, conditions. However, there are essentially just two major categories of OSS licenses:
- Copyleft (also called “viral,” or “reciprocal”) licenses require that anyone who exercises the license adhere to certain conditions, particularly when distributing larger works that include copyleft OSS components.
- “Weak Copyleft” licenses, such as LGPL, Mozilla Public License and Eclipse Public License, require you to make source code and documentation available for any modifications to the OSS. These licenses are often used for libraries and platforms, because they allow you to use the OSS in a proprietary application, as long as the library remains under the OSS license.
- “Strong Copyleft” licenses, most notably the GNU General Public License (GPL), go further, and only allow you to use the OSS in GPL programs. Strong copyleft licenses are therefore usually not consistent with proprietary software development.
- Permissive (also called “non-viral” or “academic”) licenses allow you to copy, modify, and distribute derivative works with minimal conditions, such as attribution to the original authors and a delivery of the copyright notice. Apache, MIT, and BSD are examples.
You are responsible for identifying and complying with the license for the OSS components, including sub-components that may be bundled within a software package.
What OSS Licenses Have in Common
All OSS licenses have a few things in common. First, OSS licenses don’t discriminate among users or uses -- none are limited to non-commercial use or use in a limited field. Second, they grant all the rights of copyright. In the U.S. the rights of copyright are to copy, to distribute, to prepare derivative works and to publicly perform and display. If you are the recipient of OSS, you can practice all of these rights in the code, subject only to the OSS license conditions.
All open source licenses also completely disclaim warranties and liabilities. This basically means, “Buyer Beware -- What you see is what you get.” The licensor has no obligation for the quality of the code, so you need to vigilantly monitor the quality of the code you’re using. Also, no warranties mean no promise that the software is not infringing of third party IP rights.
In addition, all OSS licenses contain notice requirements. They range from a simple copyright notice to reproducing the entire license that governs the software. Notice requirements can make complying with open source licenses quite challenging when you’re ready to distribute your code.
Best Practices for Compliance
To reduce the legal risks that can arise from the use of open source, organizations and developers must:
- Maintain a sensible open source strategy as part of your business model. A professional attitude and established OSS process will make your company look good to investors, acquirers and customers.
- Keep a record of the licensing terms that apply to the OSS you’re using, as you use it. Don’t rely on the ability to backtrack to find those terms, because they can change or become difficult to locate.
- Abide by all OSS licensing conditions to avoid being sued for damages or injunctive relief – as well as being embarrassed by bad PR.
- Correctly identify all OSS components, subcomponents, and dependencies to ensure that you know what conditions apply to you, and which will apply to your customers.
- If you change OSS, document the changes. This may be necessary to comply with license conditions, and is also good engineering practice.
- Consider seeking professional legal guidance and leveraging available tools to avoid potential licensing conflicts and compatibility issues for derivative and new products.
Open source compliance is really about doing the best you can. Open source licensing can be complex and confusing, particularly if you are accustomed to living in the world of proprietary licensing. So, when it comes to evaluating the legal conditions for use of OSS components, don’t hesitate to ask for help. Look to legal experts to help you understand how to combine OSS under different licenses and properly prepare for a product launch or acquisition/exit transactions.
Today, development is brisk in the area of automated tools to manage software development. Many companies have come to realize that managing the use of open source without automation diverts too many resources away from business, technical and legal tasks. The best tools help manage use of software in an integrated way, not focusing on OSS or proprietary software to the exclusion of the other.
One such approach is sometimes referred to as Component Lifecycle Management (CLM). CLM is the process of providing developers with collaborative tools, intelligence and control at every phase of the application lifecycle that address the management of licensing risk for component-based development. One of the latest CLM products is Insight from Sonatype, which is one of the latest generation of software management tools designed to help organizations incorporate CLM practices easily into their development processes, for instance:
- Selecting appropriate licensed components during design and development.
- Identifying and managing component licensing during the build phase to address issues quickly and avoid costly rework.
- Scanning existing applications to identify licenses and dependencies, so you can assess these against corporate policy.