Open Source Compliance
GlobalB Law advises technology companies on open-source licence compliance, inbound and outbound licence compatibility, and the contractual and IP risks embedded in software stacks that rely on open-source components.
Open-source software underpins virtually every commercial product, but the legal obligations it creates are widely misunderstood. Copyleft licences such as the GPL family impose distribution and source-code disclosure obligations that can, if ignored, expose a company's entire proprietary codebase to third-party access demands. Permissive licences such as MIT and Apache 2.0 impose fewer conditions but still require attribution, patent-licence notices, and, in some cases, disclaimer preservation. Compliance failures are regularly cited in M&A due diligence and have blocked transactions.
GlobalB Law conducts open-source licence audits for companies preparing for investment, acquisition, or a major product release. We work with software-composition analysis tools to generate a complete bill of materials, classify each component's licence obligations, and identify conflicts between inbound licences and the company's intended distribution model, including SaaS delivery, embedded products, and API exposure.
For companies that contribute to open-source projects or wish to open-source their own code, we draft contributor licence agreements (CLAs), dual-licence structures, and outbound licence policies that preserve commercial flexibility while meeting community expectations. We also advise on the interaction between open-source obligations and other IP frameworks, including patent pools and FRAND licensing commitments.
What we do
Services in this practice
الأسئلة الشائعة
الأسئلة المتكررة
Does using open-source code in our SaaS product trigger copyleft obligations?
It depends on the specific licence and how the code is integrated. The GPL v2 and v3 copyleft obligations are typically triggered by distribution of modified source code, not by SaaS delivery, the so-called SaaS loophole. However, the GNU Affero General Public Licence (AGPL) was specifically designed to close that loophole: AGPL copyleft is triggered when users interact with the software over a network. We analyse each component's licence and integration method to give a precise answer.
We are preparing for a Series A. Our investor has requested an open-source audit. What does that involve?
An open-source audit typically involves generating a software bill of materials (SBOM) using composition analysis tooling, reviewing each component's licence, identifying any copyleft obligations that affect the company's proprietary code, and confirming that attribution notices are in place. The output is a compliance report and a remediation plan for any identified issues. We produce investor-ready documentation.
Can we use GPL-licensed code and still keep our product proprietary?
The GPL licence requires that any software you distribute that incorporates or is derived from GPL code must itself be distributed under the GPL, including with source code. For SaaS products, the trigger is generally not met for GPL (but is for AGPL). For on-premise or embedded products, GPL incorporation typically precludes keeping the combined work proprietary. We assess the specific integration and advise on architectural alternatives where needed.
We want to open-source part of our codebase as a marketing strategy. What legal steps are required?
Before open-sourcing, you need to confirm that you own or have rights to all code you intend to release, identify and resolve any third-party IP in the codebase, choose an appropriate outbound licence, and implement a CLA for future contributors. We also advise on the commercial-exception model if you want to offer the open-source version free while selling a commercial licence, a common strategy for developer-tools companies.
ابدأ الآن
احجز موعداً
أخبرنا عن قضيتك وسنوصلك بالمحامي المناسب.