Open source license compliance is the process of ensuring that any product that you deliver to customers (more precisely, any distribution you make to recipients) complies with the licenses of the open source code used within that product. As it turns out, this is both a simple process (at 10000 feet) and a rather complicated process when it comes to details. Here is the 10000 feet perspective.
Step 1 is to know what is in your code. If you never took stock, you don’t know, trust me. If you don’t know, you need to create a so-called bill of materials, that is a list of open source code snippets and components that made it into your product. You can try to do this by hand, but will probably fail in any but the most trivial cases. Tools can help you to walk through your code, identify license texts, and point out similarities to known open source code, so that you can determine your product’s bill of materials.
Step 2 is to take action for all applicable obligations for all licenses of all included code. Each open source line item in the bill of materials has one or more associated open source licenses, and these licenses put obligations on you. Mostly, you are asked to create legal notices and provide them to recipients of your code, like license texts, copyright notices, and so forth. More obscure obligations, like the EPL v1.0 requirement to install a supplier indemnification process at your company, also exist.
As they say, the devil is in the details. Creating that initial bill of materials, even with the help of a professional tool, can be laborious. For this, my students can help. Creating license compliance artifacts for a given bill of materials requires detailed knowledge of licenses and engineering practices. For this, the Bayave GmbH handbook on license compliance can help. Finally, license compliance is only one of many topics within the scope of open source governance. To get a handle on this broad topic, my research group can help. If in need, don’t hesitate to contact us!