19 Guidelines for Free and Open Source Software Usage

The Hitchhiker’s Guide to Open Source Compliance – Episode 8 Over a year ago, we launched a blog post series…

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.

Learn the most relevant open source rules with our FOSS guide

Identify all Source Code (Components and Snippets)

Software enters an organization via three main sources:

  1. New software created by an organization’s own engineers
  2. Third party commercial software contracted out
  3. 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.

Frequently Asked Questions

  1. How can organizations effectively enforce compliance with these guidelines? Implementing effective compliance requires a multifaceted approach. Organizations can consider the following strategies:
    • Education and Training: Regularly educate employees and stakeholders about open source compliance, emphasizing the guidelines and their significance.
    • Automated Tools: Invest in tools that scan code repositories, identify open source components, and assess license compatibility.
    • Policy Integration: Integrate compliance policies into development workflows, ensuring that developers are aware of their responsibilities.
    • Legal Review: Engage legal experts to review licenses, assess risks, and provide guidance.
    • Audits and Monitoring: Conduct periodic audits to verify compliance and monitor ongoing adherence.
  2. What are the consequences of non-compliance with these guidelines? Non-compliance can have serious repercussions:
    • Legal Risks: Violating open source licenses may lead to legal action, fines, or injunctions.
    • Reputational Damage: Non-compliance tarnishes an organization’s reputation, affecting trust among users, partners, and investors.
    • Operational Disruptions: Infringing licenses can disrupt development, delay releases, and impact project timelines.
    • Financial Costs: Legal fees, settlements, and license rectification efforts can be financially burdensome.
  3. Are there specific examples or case studies illustrating successful compliance efforts? While the article doesn’t provide specific case studies, organizations can learn from successful compliance stories:
    • Google: Google’s compliance efforts involve automated scanning, robust policies, and legal support.
    • Red Hat: Red Hat’s commitment to compliance has contributed to its reputation as a leader in open source.
    • Automotive Industry: Automotive companies have navigated compliance challenges by collaborating with industry bodies and sharing best practices.

Other Articles relevant