.png)
Grab the full download below—perfect for saving or sharing with your team.
How can you successfully navigate open source license compliance? Start with the right tools to identify your dependences and calculate their risks. Our newest blog looks at the basics of open source compliance to get you on your way to finding the management system to get you on the path to compliance
The Basics of Open Source License Compliance
Open source licensing can be very complex and lead to a myriad of compliance issues for customers.
There are several levels of licensing to open source products that can cause non-compliance issues for customers. You may have a product package licensed under a permissive license but not realize that the package dependencies are licensed under a more restrictive license – this is actually very common. If you have a product package like this, you may not realize what the constraints are, or that there are different constraints, and whether your use is compliant or non-compliant.
"Open source compliance is the process by which users, integrators and developers of open source software observe copyright notices and satisfy license obligations for their open source software components" — The Linux Foundation
In its simplest form, a software license is a document that states who can use it and what use is permitted for a piece of software. Open source software (OSS) licenses are licenses that the Open Source Initiative (OSI) has reviewed for respecting the Open Source Definition. There are approximately 80 open source licenses listed by the OSI broken into two categories:
· Permissive, open source: this license type guarantees freedom to use the source code and allows modifications and redistributions, including for a proprietary product (such as MIT or Apache)
· Copyleft licenses (GPLv2 and GPLv3): this type of license guarantees users long-term freedoms but has stipulations limiting its use for proprietary and non-free applications. With a copyleft license, you must share your source code modifications
While there are already a large number of licenses that fall under these two types, sometimes software companies elect to create their own licenses and apply them to their products. If your software package includes one of these, this can seriously complicate your path to compliance and create confusion for your IT engineers. Tracking and complying with the various levels of licenses stipulations can become a very taxing full-time job for your team.
The path to OSS compliance begins by establishing an OSS compliance policy for your organization. The goal is to compile a complete list, or perhaps a visual map, of all the open source components you use and there dependencies. By doing so, you should be able to clearly see any and all conflicts between the licenses. This will also enable you to see if any of your products are unnecessary or better replaced by similar software.
Not only will this audit allow you to map your OSS software, but you may also find ways to save money on your software licenses. You will also be able to audit licenses clauses to see if you meet them and are using your software as your licenses allow.
Regardless of how you are using open source products, it is critical to establish a clear policy and continue to list and map any software as you add or subtract. This will help your organization get one step closer to compliance.
· Protect proprietary IP
· Accelerate the use of open source software
· Comply with open source licensing
· Comply with the third-party software supplier/customer obligations
How you create this list or map of your software licenses is entirely up to your team. You can take either a manual or a semi-automated approach. Each approach has its own benefits, though which approach you take should be determined by your licenses and the path that will support compliance most.
Certainly the most cost-effective approach, manual license management is a popular choice, but there is a definite downside to this approach.
To manually monitor your license, you would create a spreadsheet and fill it out with the components, versions, license types and stipulations, and then compare your data with your policies. This can work well for smaller projects and companies, but when you begin to expand, this can get very complex – especially if you do not have very clear compliance policies in place.
With a manual approach, you will need all of your developers to review and log a software's license before they introduce it to your open source components. By doing so, you can ensure that the licenses that are used are compatible. If this is not done, you might find yourself with license conflicts down the line and either need to pay fees for non-compliance or go back and redevelop your product with aggregable licenses.
Semi-automated approaches integrate tech that helps to file and sort the license types and criteria of your programs. This is helpful as you scale and the number of licenses at play grow. However, while some programs can automate the entire process, no system is flawless. There may be special terms or conditions your automated system won't pick up that a self-audit will uncover. For these reasons, it is critical that you still have a self-audit every so often to ensure you are remaining compliant.
Popular tools for semi-automated approaches are file scanners, code scanners, component identification tools, and continuous integration (CI) scanners. File and code scanner tools work to detect open source components and licenses. Component integration tools are a bit more complex and can help you produce a software bill-of-material or list of all the OSS components comprising your build. This is helpful if you want to sell your product for others to build upon. Finally, CI scanners work with continuous integration or build tools to automatically detect all OSS components every time you run a build. With CI scanners, you can set policies for the system to recognize and respond to.
You can find more information about these tools and other less popular options at the Linus Foundation site.
Whether you opt to manage your licenses manually or semi-automated, Connor can help. Managing your licenses is the only way to manage your compliance and avoid costly audits and fees. To learn more about open source license compliance, contact one of our expert IBM license advisors at softwareadvisoryservices@connor-consulting.com today.
