Open source software is ubiquitous, but licence compliance and IP strategy must align. Permissive licences (MIT, Apache 2.0, BSD) impose minimal obligations—typically attribution and sometimes patent grants. Copyleft licences (GPL, AGPL) require derivative works to be distributed under the same terms, which can "infect" proprietary code if combined incorrectly. The distinction matters: using GPL-licensed code in a SaaS product can force disclosure of your entire codebase under AGPL; permissive licences generally allow closed-source commercial use.
Compliance risks include inadvertent violation, lack of attribution, and failure to distribute source or licence notices. Audits and enforcement have increased; companies have faced litigation and forced relicensing. Establish a policy: track all open source dependencies, review licences before adoption, and maintain an inventory. Tools such as FOSSA, WhiteSource, and Snyk automate dependency scanning and flag incompatible licences. Manual review remains essential for complex or nested dependencies.
Structuring projects that combine open source with proprietary development requires clear boundaries. Use permissive components freely; isolate copyleft code in separate modules or services to avoid triggering disclosure. Consider dual licensing or contributing improvements upstream under the project's licence to build goodwill and reduce maintenance burden. Contributor licence agreements (CLAs) and employer IP policies should clarify who owns contributions and that the company can license them appropriately.
Policy and Process
Establish an open source policy before problems arise. Define which licences are approved, which require legal review, and which are prohibited. Require SBOM updates as part of release cycles. Train developers on licence implications—many violations stem from ignorance rather than intent. Assign ownership for compliance; someone must own the inventory and remediation. Policy without enforcement is ineffective.
Upstream Contributions and Governance
Contributing fixes and features upstream reduces your maintenance burden and builds goodwill. Many projects welcome patches; some require CLA signing or governance review. Understand the project's contribution process before investing. Forking creates a permanent maintenance obligation; prefer contributing to upstream when possible. For critical dependencies, consider joining governance bodies or funding maintainers to ensure project sustainability.
Vulnerability and Security
Open source components carry security risk. Vulnerabilities in widely used libraries can affect thousands of projects; Log4j and similar incidents demonstrated the scale. Dependency scanning should flag both licence conflicts and known CVEs. Patching and upgrading require testing; technical debt accumulates when teams defer updates. Factor open source hygiene into acquisition due diligence—a target with outdated, vulnerable dependencies may need significant remediation before integration.
Due diligence for acquisitions must include a software bill of materials (SBOM). An SBOM lists all components, versions, and licences in a codebase—critical for assessing compliance risk and vulnerability exposure. Regulators and customers increasingly expect SBOMs; the US Executive Order on cybersecurity and similar initiatives have made them a baseline requirement. We evaluate targets' open source posture, remediation history, and SBOM completeness before closing. The cost of fixing compliance issues post-acquisition can materially affect deal economics.