Free and Open Source Software (FOSS) is "free", right? Free as in speech, and sometimes free as in beer. But the intellectual property expressed in FOSS code does not inhabit the public domain. Nearly all FOSS code is distributed under one or more free and open source licenses -- all binding agreements subject to copyright law.
Internal usage of free and open source code almost never triggers the terms of the licenses governing that code. Instead, FOSS licenses are invoked typically under two circumstances:
Redistribution of source code and/or binaries derived therefrom (most common)
Presentation of an online service, usually over the Internet (less common)
Compliance with FOSS licenses should not be left until a redistribution event or the launch of a service implemented with open source. This blog lays out exactly what those compliance activities entail.
Compliance Activities
The primary activities involved in FOSS license compliance include identifying all open source software components, tracking and documenting licenses, reviewing and approving usage, fulfilling license obligations such as attribution and source code distribution, conducting regular audits, and maintaining compliance records to ensure ongoing legal adherence.
Identification and Inventory
Organizations must identify every FOSS component used in and referenced by their software, including dependencies and transitive packages, and compile a software bill of materials listing the origin and applicable license for each line item.
License Review and Approval
Legal and engineering teams need to review the licenses for the items in a BOM, assess compatibility and restrictions among them (e.g., copyleft requirements), and approve or deny the inclusion of given components, documenting obligations that must be met upon release.
Obligations Fulfillment
Compliance means meeting the explicit requirements of each license: providing attribution, including license notices, distributing source code when necessary, and maintaining proper documentation and disclosures in product releases.
Continuous Monitoring and Auditing
Regular code reviews, audits, and automated scans are performed to track new or changed open source components, ensuring ongoing compliance and immediate mitigation of identified violations or risks.
Record-keeping and Documentation
Organizations need to maintain compliance records, including copies of licenses, proof of attribution, fulfillment measures, and audit trails to demonstrate compliance in case of legal inquiry or product release.
These core activities are often embedded in a formal compliance program and supported by automated tools—such as software composition analysis (SCA), license management platforms, and CI/CD integrations—to reduce manual errors and improve efficiency.
Compliance and Test Automation
Product testing and hence test automation are typically performed during development, QA and other pre-release life-cycle phases. As such, there is a natural assumption that open source compliance requirements, prototypically invoked when code is redistributed, don't apply to software in this domain, but they do.
Let's examine the test automation use cases that involve compliance activities.
Test Code Embedded in Product BOM
When test harnesses are part of a SaaS or on‑premises solution, or if test frameworks are embedded into tooling customers can run (e.g., self‑test suites shipped with an appliance, health‑check or validation tooling), those components become part of the distributed or offered software and must comply with the accompanying licenses.
Test Code Shipped to Ecosystem Partners
When test code is shipped embedded in a product or included in an SDK, or If unit, integration, or system tests are bundled with binaries, source, or SDKs delivered to partners, any open source components in those tests trigger the usual license obligations (attribution, notice files, copyleft conditions, etc.). This requirement is especially important for frameworks, sample projects, and reference designs that include automated tests.
Test Code Published as Open Source
When test code is published as open source or shared with third parties who then publish that code on GitHub, contributing them to an open source project, or sharing them with partners/vendors means you are distributing that code and must:
Choose and declare a license for your own test code.
Respect the licenses of any third‑party libraries, snippets, or test assets you embed (e.g., GPL vs MIT requirements, attribution, NOTICE files).
Company Merger or Acquisition
Another form of re-distribution is when the organization itself changes hands.
The acquiring company inherits the compliance obligations of the acquired organization, including attribution, source‑code disclosure, and patent grants. If the acquired org was out of compliance, the acquirer may face demands to release source, cease distribution, or pay damages and settlement costs.
Valuation, deal structure, and closing risk from FOSS issues are now routinely flagged in technical due diligence and can impact valuation, trigger indemnities/escrows, or even derail a deal.
Best Practices for FOSS Compliance in Test Automation
Establish Policies - Establish a formal FOSS policy, defining approved, restricted, or prohibited licenses types and licenses. Include stakeholders like engineering and legal teams for buy-in and create processes for license reviews during development and deployment of test code. Integrate compliance into the software development lifecycle, starting with early code reviews.
Know your code - Maintain a detailed inventory or Software Bill of Materials (SBOM) tracking open source components, licenses, and versions. Conduct regular audits to identify dependencies and changes. Consider using SPDX identifiers for accurate license tracking and compatibility checks.
Inventory dependencies - Modern software projects don't just contain the code you can directly in your build scripts and software repositories. Open Source programs AND original code written by your organization and your partners make reference to myriad other software - libraries, drivers, macros, etc. - all of which are accompanied by licenses and carry compliance obligations.
Automate Inventory Management - Deploy SCA (Software Composition Analysis) tools to inventory the code and licenses in your test and test automation software stacks. Do not attempt to take inventory manually, no matter how simple your test / test automation stack appears. Generate attribution notices and disclosures via these tools before releases.
Train your team - Train architects, developers, testers and engineering managers on the nature and implications, obligations, and compatibility of FOSS licenses to prevent inadvertent misuse and violation of terms. Regularly revisit the topic with updates to your testing stack, licenses and best practices.
Fulfill License Obligations - Create checklists for notices, source code availability (for copyleft licenses), and preserving copyright headers. Address conflicts by seeking alternatives, re-licensing, or legal exceptions. Monitor for license changes for included and referenced projects and document compliance steps for audits.
Next Time
In future blogs on Compliance, we'll cover choosing and using SCA tools and compliance challenges like Snippets.