At first blush, open source compliance may seem like a daunting task. But with a little research, review, and education, you will discover that compliance is not as difficult as first thought.
First, let’s look at the term compliance itself. Merriam-Webster online defines compliance as “conformity in fulfilling official requirements.” The concept is not difficult to grasp; if you use open source software, to be in compliance means fulfilling the license requirements. And, when you think about it, that makes perfect sense. Open source developers do not develop software to make money, so what do they want? They want users to comply with their license. Maybe they want attribution, or they are interested in protecting the source code so others can use it and benefit from ongoing contributions. Maybe they are simply interested in protecting themselves from litigious users. Whatever their motivation, developers who take the time to license their work expect users to comply in exchange for their efforts.
How do you comply? Here is a simple outline to start on the road to compliance:
1. Know what you have
There are actually two parts to this: 1) know what open source software (OSS) you are using in your application; and 2) know what license the OSS is distributed under. The easy way to do this is to track OSS as you download it and begin to use it in your application. This proactive approach allows you to record the license as you obtain the software, which is easier than trying to find it later.
The common approach is to go back through your code and create a list, or a bill of materials, of the OSS and accompanying licenses. You can perform a manual review, but this will probably miss some OSS. For the best results, use an open source scanner to catch all the pertinent software. While building the list, you may need to refer to the website of origin for the OSS and find the license information.
2. Read the licenses
The good news/bad news is that many open source licenses were not written by lawyers. So, in quite a few instances, the licenses are not written in legalese. This can make understanding the licenses easier. On the other hand, when non-lawyers author licenses, there tends to be more ambiguity, which can make compliance requirements less clear.
3. Build a checklist
As you build your checklist also consider timing: when to comply. For example, a license condition may require document of modifications to the original source. In this case, comply when making modifications. Many obligations only need to be met under certain usage conditions.
Most compliance steps are not difficult to complete. Common compliance obligations include: not removing notices and copyrights, acknowledging warranty disclaimers, giving attribution where attribution is due, not claiming authorship of the OSS, documenting your modifications, and including the original license, author, and project information as much as possible.
Use your checklist to document the steps you take to comply with each license. You may write something as simple as “I read and understood this license restriction, and did not violate it.” For more complex compliance requirements, you may need to document how you combine your code with open source as proof that your specific usage does not trigger/fail that requirement. This is particularly important if the requirement requires you to release your source code when it is combined with open source to create a derivative work.
This list provides the first steps in developing your own open source compliance program for your company. If you need help, please feel free to contact OpenLogic. We specialize in helping organizations build open source governance and compliance programs, as well as providing open source scanning and auditing. We would love to assist you.