The Hitchhiker’s Guide to Open Source Compliance – Episode 8
Over a year ago, we launched a blog post series called “The Hitchhiker’s Guide to Open Source Compliance” with the purpose of sharing best practices in open source compliance. This is the eight episode, offering general recommendations related to using and contributing to open source projects. For each recommendation, we provide a basic explanation and examples of how possibly this recommendation can be implemented.
Identify all Source Code (Components and Snippets)
Software enters an organization via three main sources:
- New software created by an organization’s own engineers
- Third party commercial software contracted out
- Open source channels
All software should go through the open source compliance to identify the origin and license of all open source components and snippets
Establish a Recurring Scanning Model
Developers may not issue a compliance ticket to request approval to use a FOSS component. Therefore, it is critical to have a method to capture unapproved FOSS that is entering the software stack. This situation can be resolved by running regular full scans for the full software stack every 6-8 weeks and identifying the components that don’t have a corresponding compliance ticket. A new ticket will then be created per component and pushed via the normal compliance verification process.
Verify Compliance on a Case by Case Basis
Approving the use of a FOSS component in one case does not necessarily serve for all cases. As a rule of thumb, each time developers modify a previously approved component or plan to use a previously approved component, the compliance team should rescan the updated source code and the component should pass the compliance checks again.
Upgrade FOSS Components Versions
License changes can occur between version upgrades. When developers upgrade versions of FOSS components, they need to double check that the license remains the same. Otherwise, if there is a change in the license, a new compliance ticket must be issued requesting approval to use the component under a new license.
Resolve All Issues Identified
When source code is scanned and compliance issues are discovered and flagged, there are a number of ways to resolve issues:
- When in doubt with the scan results, discuss with engineering staff.
- Inspect and resolve each file or snippet flagged by the scanning tool.
- Identify modifications introduced to open source software.
- If, for instance, the scanning tool identifies the use of un-approved licensed source code (a snippet) within a proprietary component, this will be reported to Engineering with a request for correction. It is highly recommended to re-scan the source code after Engineering has resolved the issue, to confirm removal of the problematic source code and its replacement with appropriately licensed code.
Add Licensing Information to the Compliance Ticket
In preparation for the legal review, Audit staff must provide the legal counsel with all discovered licensing information for specific components including the source code audit report. These include the COPYING, README, or LICENSE files for open source components, and the licensing agreement for software components received from a third party software provider.
Maintain a Record of Discussion
It is advised to maintain a summary of discussions in the compliance ticket that lead to approval or denial of a specific compliance ticket. Such documentation can prove very useful when attempting to determine the basis on which approval for a specific component or snippet was granted and how issues were resolved.
Include Copyright, Attribution and License Notices
Each compliance ticket for an approved FOSS component should include copyright, attribution and license notices.
Be Clear in the Source Code Written Offer
It is recommended to use clear language for the written offer and be inclusive of all open source included in the product or service. Companies need to ensure that the end users of their products/services know how to locate this information, whether on the product itself, in the product documentation, and/or on a website.
Capture Modifications to FOSS Components
All modifications to open source components should be captured in the revision history (change log file). When redistributing modified open source code, your modifications need to be clearly marked as such, including a copyright line for those modifications (company, year) while preserving the existing copyright lines.
Some companies elect a different approach by providing the original open source code along with the company’s contributed patch files that apply against the original open source code. Following this approach, the company’s modifications are clearly separated from the original open source code.
Maintain a Clean Bill of Materials
With respect to the software bill of materials, it is recommended that any inbound software does not contain undeclared open source. Always audit source code upon receipt from providers; alternatively, adopt a policy that software providers must deliver audit reports for source code they deliver to you as a proof of what open source software is included in their deliverables.
Update Tickets with Retired FOSS Components
If an approved open source package is no longer in use, engineers must re-open the corresponding compliance ticket and update it to reflect that the component is not being used anymore.
Re-scan After Major Source Code Changes
If an approved package went through a major change, engineers must request a new scan of the source code. A major change in the design or implementation often affects architecture, APIs, and use cases, and in some cases may have an impact from a license compliance perspective.
Avoid Unauthorized Copying/Pasting
Engineers must avoid using source code snippets, and avoid copying/pasting open source code into proprietary or third party source code (or vice versa) without prior documented approval. Such actions have serious implications on license compliance.
Avoid Mixing Source Code with Different Licenses
Avoid mixing different open source licenses, as many open source licenses are incompatible with one another. It is highly recommended to seek legal support from your legal counsel on this topic. The legal counsel will determine if the mix of licenses is approved.
Comment Appropriately
Engineers must be careful of what comments they leave in source code. They should not leave inappropriate comments in the source code (private comments, product code names, mention of competitors, etc.).
Do Not Modify Licensing Information
It is highly recommended not to remove or in any way disturb existing copyrights or other licensing information from any open source components that you use. All copyright and licensing information must remain intact in all open source components.
Preserve Original License, Copyright, and Attributions
Whenever you are redistributing open source code, with or without modifications, you must preserve the original licensing information, copyright lines, and other attributions.
Endorse and Promote Wisely
It is highly recommended not to use the name of the FOSS project, authors, or contributors in any marketing, advertising, or documentation (hard copy, digital, or on the web) without prior written permission.
Compliance For Charity
Continuing with the theme of sharing knowledge on open source compliance, we recently launched “Compliance For Charity”, an initiative by FossID for professionals to share knowledge about open source compliance while supporting a charity of their choice. If you are an open source practitioner we invite you to share content about open source compliance, open source security, Software Composition Analysis (SCA), tools and tool chains, etc., and for each approved blog post FossID will sponsor USD 500.00 to a charity chosen by the you.
To learn more and to contribute a blog post to this effort, please visit: https://www.complianceforcharity.org.
