Creating an Open Source Compliance Checklist

In a recent blog article Using Categorization to Simplify Open Source License Compliance I talked about simplifying open source compliance through license “categorization” where I listed the common categories used in many open source licenses. In this article I’m going to talk about creating an open source compliance checklist based on those categorizations.

In OpenLogic Exchange Enterprise Edition (OLEX), we have analyzed several hundred open source licenses and created a list of high-level obligations for each license. For example, in OLEX the Apache License 2.0 list of obligations looks like this:

• Distribute copy of license
• Give notice of or fulfill other requirements related to modified files
• Obligation to include notice text or files
• Obligation to include copyright or trademark notice
• Obligation to indemnify contributors
• Obligation to apply license to original or derivative works
• Restrictions regarding use of trademark
• Termination of patent license upon filing of patent litigation

If you don’t have the luxury of an OLEX Enterprise Edition subscription, you will want to take a similar approach and summarize the list of obligations in easily digestible “chunks.” This will make it easier for the team to take steps to comply with the various licenses used.

Next you want to examine under what conditions you need to meet certain obligations. For example, the requirement to supply documentation about modifications to open source are only triggered when you modify the code. By creating a set of triggers tied to your list of obligations you can quickly determine if you need to take steps or not.

You can then use these sets of triggers to ask your development team how they are using the open source in your product. Once you have their answers in hand, you can begin to eliminate the obligations you don’t need to meet which in turn helps keep the list manageable.

Some common triggers include: distribution, modification of source and creation of derivative works via linking. So for example, you can confirm that open source found in your source files is indeed distributed with your product or not. It is surprising how many files that contain open source in your source tree actually don’t get distributed with the final product. Or, if your code links to an open source library, how so? Dynamically or statically? The answer to these questions allows you to pick the relevant obligations.

Once you understand your list of high-level obligations by license and when those obligations are triggered you can begin to build your checklist. When we build compliance checklists for our customers we build the list by obligation type and license, then also list the responsible packages. For example if we identify a modification requirement in a license, we list the products that have been modified (down to the file level), so that we can later verify modification requirements have been met.

Finally, once you have your checklist in place you can work with your various functional teams to verify that all physical steps have been take to comply. Has your documentation group updated the product documentation to include the appropriate trademark, copyright and attribution requirements? CHECK. Has your development team met all modification documentation requirements and made sure they didn’t remove any copyright statements? CHECK. Has your legal team reviewed your product EULA agreement to make sure it doesn’t conflict with any of the open source licenses and are they fully aware of any restriction on use and have agreed that your organization can meet these restrictions? CHECK. If you need to provide source code via physical medium or hosted download site, is your organization prepared to fulfill requests? CHECK.

The process of license compliance is not trivial but by taking advantage of license categorization, high-level lists of obligations and triggers, you can make the process manageable.

I invite you to comment and provide insights on how your organization complies with open source licenses. If you are interested in learning more about OLEX or services provided by OpenLogic can assist you in your compliance, please feel free to contact us at sales@openlogic.com.



Follow @openlogic
Follow @cloudswing

Subscribe to The Enterprise Open Source Blog by Email

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.Follow @openlogic
Follow @OSCloudServices

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.