|
1 | 1 | # Compliance |
| 2 | +Compliance with licenses for third-party software is a very broad topic which was historically separated into two distinct domains: |
| 3 | +- Licenses for commercial software products where a purchasing department or |
| 4 | +similar organization has the primary responsiblity for negotiating license |
| 5 | +terms and conditions and an IT group has primary responsibility for tracking compliance with the license (e.g, number of seats, etc.). Commercial license |
| 6 | +agreements are private (although the supplier may make standard license |
| 7 | +agreement text available publicly). |
| 8 | +- Licenses for open source software where anyone in an organization can |
| 9 | +acquire and use the software. Someone using open source software may be |
| 10 | +required to agree to license terms when downloading the software, but there is normally no contract or other agreement recorded in the organization. Many organizations today have created an OSPO (Open Source Program Office) or |
| 11 | +similar group to track compliance with open source licenses. Open source licenses are public but there are typically no counter-signed license |
| 12 | +agreements. |
| 13 | + |
| 14 | +In both domains legal staff have typically been responsible for setting |
| 15 | +policies and monitoring compliance with those policies. |
| 16 | + |
| 17 | +For modern software development the boundary between commercial and open |
| 18 | +source licenses has become fuzzy with the increasing use of so-called "dual" |
| 19 | +licenses (with a choice of commercial or open source license for the same software), "source available" licenses (which have characteristics of both |
| 20 | +commercial and open source licenses) and various pseudo-open source licenses. |
| 21 | +The reality for modern software development is that you need to identify the |
| 22 | +specific license terms and conditions for any third-party software that you |
| 23 | +use and report it in SBOMs and other documentation |
2 | 24 |
|
3 | 25 | ## Identify licenses for software and for data |
| 26 | +The first task for license compliance is to identify and document all third-party software that you use - regardless of whether the usage is |
| 27 | +internal- only or external to your organization. |
| 28 | + |
| 29 | +ScanCode from AboutCode is the industry-leading software scanning tool |
| 30 | +and it is embedded in many open source SCA (Software Composition Analysis) projects including [FOSSology](https://www.fossology.org/) and [ORT](https://oss-review-toolkit.org/ort/). ScanCode is also embedded in many commercial |
| 31 | +SCA products. There are three primary ScanCode projects: |
| 32 | +- [ScanCode Toolkit](https://scancode-toolkit.readthedocs.io/en/stable/) is a set of code scanning tools that detect the origin (copyrights, authors, URLs, etc.) and license for any type of sofware. It uses a robust set of rules to detect more than 2,400 licenses and also clues to partial license text. You can use the Toolkit as a library or command line utility. |
| 33 | +- [ScanCode.io](https://scancodeio.readthedocs.io/en/latest/) is an |
| 34 | +application (Web UI and API) where you can run standard or custom pipelines to |
| 35 | +identify licenses, copyrights, packages, dependencies and vulnerabilities. It also has pipelines to match deployment "binaries" (compiled or interpreted) to |
| 36 | +corresponding source. You normally run ScanCode.io as a Docker container. |
| 37 | +- [ScanCode LicenseDB](https://scancode-licensedb.aboutcode.org/) is the |
| 38 | +reference database for the 2400 licenses detected by ScanCode. It is limited |
| 39 | +to public license texts but not to only those licenses that meet the OSI definition of open source. ScanCode's objective is to identify licenses regardless of whether they are open source, proprietary or in-between. Each |
| 40 | +license in the LicenseDB is labelled with a License Category, such as 'Copyleft', 'Permissive' or 'Public Domain'. |
| 41 | + |
| 42 | +There are also other [AboutCode projects](/#scancode-projects) that are components or extensions of ScanCode. |
4 | 43 |
|
5 | 44 | ## Apply license usage policies** |
| 45 | +The only feasible way to automate license compliance for third-party software |
| 46 | +is to define and apply license policies that are easy for anyone in your |
| 47 | +organization to recognize. |
| 48 | + |
| 49 | +[DejaCode](https://dejacode.readthedocs.io/en/latest/) incorporates a |
| 50 | +License Library including the current **ScanCode LicenseDB** data and any licenses that you choose to add to the Library. The **DejaCode** license |
| 51 | +management features include: |
| 52 | +- _License conditions_ document standard license terms and conditions like specific attribution or redistribution obligations, patent-related conditions, warranty disclaimers, usage restrictions and more. |
| 53 | +- _License profiles_ provide an easy way to group a set of commonly recurring |
| 54 | +_License conditions_ for license review and assigning a usage policy. |
| 55 | +- _License usage policies_ allow to define any number of license policies. A |
| 56 | +common approach is to start with a simple set of policies like 'Recommended', 'Approved', Restricted', and 'Prohibited'. Later you can refine your approach |
| 57 | +to define more granular policies, such as more granular policies for |
| 58 | +internal-only versus external use. |
| 59 | + |
| 60 | +In **DejaCode** you can define _License usage policies_ at the component, |
| 61 | +package, product-component or product-package levels. Both **ScanCode Toolkit** and **ScanCode.io** can apply license policies that you create in **DejaCode** (or some other system that can define comparable policies). A license policy |
| 62 | +is documented in a YAML file. |
6 | 63 |
|
7 | | -## Produce SBOMs |
| 64 | +## Produce SBOMs |
| 65 | +Two primary use cases for an SBOM (Software Bill of Materials) are license |
| 66 | +compliance and vulnerability risk management. License compliance is a strong |
| 67 | +use case for an SBOM because license data are much less volatile than |
| 68 | +vulnerability data. |
| 69 | + |
| 70 | +- [DejaCode](https://dejacode.readthedocs.io/en/latest/) provides features to |
| 71 | +import, edit and export SBOMs in CycloneDX (versions 1.6, 1.5 or 1.4) or SPDX format (version 2.3). For CycloneDX you also have an option to export a |
| 72 | +combined SBOM + VEX document. SBOM data are stored in **DejaCode** Products. |
| 73 | +A Product can be third-party or first-party (or second-party:customer). You |
| 74 | +can define a Product at any level - e.g. some may be at a component or assembly level. You can experiment with the Product/SBOM features with a free [DejaCode trial account](https://public.dejacode.com/account/register/) |
| 75 | +- [ScanCode.io](https://scancodeio.readthedocs.io/en/latest/) provides |
| 76 | +features to import and export SBOMs in CycloneDX (version 1.7, 1.6, 1.5 or |
| 77 | +1.4) or SPDX format (version 2.3 or 2.2). You can use the `'load_sbom` |
| 78 | +pipeline to load one more SBOMs as a Project and use `add-on` pipelines to |
| 79 | +enrich the data before you export it as an SBOM. You can also export Project data in JSON or XLSX format. If you need to edit an SBOM, you should use **DejaCode** instead of **ScanCode.io** |
8 | 80 |
|
9 | 81 | ## Automate compliance |
| 82 | +Two common and key obligations for compliance with open source software |
| 83 | +licenses are: |
| 84 | + |
| 85 | +### Attribution |
| 86 | +Almost all open source licenses, except for "Public Domain", require some form |
| 87 | +of attribution in source code, derivative works or documentation (or all of these) if you distribute the open source software in your products or |
| 88 | +otherwise. It is usually simpler to provide attribution generously for any |
| 89 | +open source software that you distribute rather than try to track and comply with more granular attribution obligations. |
| 90 | + |
| 91 | +- [DejaCode](https://dejacode.readthedocs.io/en/latest/) provides a highly |
| 92 | +customizable feature to generate an Attribution Notice. You can customize the |
| 93 | +document format (Jinja2 template) for your organization and fine-tune the |
| 94 | +Notice contents when you generate a Notice for a Product. |
| 95 | +- [ScanCode.io](https://scancodeio.readthedocs.io/en/latest/) can generate an |
| 96 | +Attribution Notice for a Project using an HTML template that you can customize |
| 97 | +directly in **ScanCode.io** settings. |
| 98 | +- [AboutCode Toolkit](https://aboutcode.readthedocs.io/projects/aboutcode-toolkit/en/latest/) is a set of command line tools to document the provenance of your code and generate Attribution Notices. You can generate an Attribution Notice from ABOUT files (small YAML files) inside a codebase or |
| 99 | +from JSON, CSV or XLSX input files. |
| 100 | + |
| 101 | +### Redistribution |
| 102 | +Some open source licenses require that you offer to redistribute source code |
| 103 | +for an open source project - these are typically called "Copyleft" licenses. |
| 104 | +If you distribute open source software under a Copyleft license there are two |
| 105 | +common obligations: |
| 106 | +- You make an offer in your Attribution Notice to redistribute the source code. |
| 107 | +- You are prepared to redistribute that source code on request - this often |
| 108 | +includes an obligation to provide instructions and tools to build from source. |
| 109 | +You can use the *DejaCode** to track Product packages or components that are subject to source redistribution obligations and their deployment/distribution |
| 110 | +status. **DejaCode** also provides reports to create a source redistribution |
| 111 | +checklist in case you receive a request for source. |
| 112 | + |
10 | 113 |
|
11 | | -- Generate compliance artifacts (e.g. attribution notices) |
|
0 commit comments