Open source license compliance: GPL, MIT and Apache

Open source software is free to use, but not free of conditions. Permissive licences such as MIT and Apache 2.0 allow almost any use, including in proprietary products, as long as you keep the required notices; copyleft licences such as the GPL require that, if you distribute software based on GPL code, you license the whole work under the GPL and make the source code available. Managing those conditions, what the industry calls open source license compliance, is now a standard question in investment rounds, acquisitions and customer contracts. This guide is for CTOs, in-house counsel and founders whose products include third-party code.

Key takeaways

Open source licences are copyright licences: using code outside their terms is infringement, and the GPL terminates automatically on breach.
MIT and Apache 2.0 mainly require attribution; Apache 2.0 adds a patent licence that ends if you sue over patents in the code.
GPL obligations are triggered mainly by distributing the software; the AGPL extends them to users interacting over a network with a modified version.
Expect buyers and investors to ask for an inventory of components and licences; ISO/IEC 5230 and ISO/IEC 5962 (SPDX) give a recognised framework.

Why are open source licences an IP issue?

Software is protected by copyright as a computer program if it is original (TRLPI, art. 96 in Spain). The right holder’s exclusive rights cover reproduction, including loading and running where they require a copy, transformation and any form of public distribution (art. 99). An open source licence is the permission that lets you do those acts with someone else’s code. If you step outside its conditions, you are using the code without permission.

The GPL says so expressly. Under GPL version 3 (29 June 2007), any attempt to propagate or modify the work otherwise than as the licence allows is void and automatically terminates your rights (section 8). Version 3 lets a first-time violator recover the licence by curing the violation within 30 days of the copyright holder’s notice; GPL version 2 (June 1991) has no cure period (section 4).

GPL, MIT and Apache compared

Licence	Type	Main conditions	Patents
MIT	Permissive	Keep the copyright notice and the permission notice in all copies or substantial portions	No express patent clause
Apache 2.0	Permissive	Provide a copy of the licence, mark modified files, keep notices and reproduce the NOTICE file attributions	Express patent licence from contributors, terminated if you sue alleging the work infringes a patent
GPL v2	Copyleft	Distributed works based on the program must be licensed as a whole under the GPL, with source code	No express patent licence
GPL v3	Copyleft	As v2 for “conveying”, with detailed rules for providing the corresponding source	Express patent licence from each contributor
AGPL v3	Network copyleft	As GPL v3, plus offering the source of a modified version to users interacting with it over a network	As GPL v3

Sources: MIT License (Open Source Initiative), Apache License 2.0 (January 2004), sections 3 and 4, and the GNU licence texts.

When does the GPL actually bite?

The copyleft obligations attach to distribution. GPL v2 requires any work you distribute or publish that contains or is derived from the program to be licensed as a whole under the GPL (section 2(b)), with the source code (section 3). GPL v3 uses the term “convey” and requires you to license the entire work under the GPL to anyone who receives a copy (section 5(c)), and to provide the corresponding source with object code (section 6).

Three practical consequences follow:

Purely internal use and modification, without distributing copies, does not trigger the obligation to release source.
Software as a service is different under each licence: GPL v3 states that “mere interaction with a user through a computer network, with no transfer of a copy, is not conveying”, but the AGPL v3 requires you to offer the source of your modified version to remote users (section 13).
Shipping GPL code alongside separate, independent programs on the same medium (an “aggregate”) does not extend the GPL to them, but combining code into one larger program generally does.

Apps, firmware, on-premise software and devices are distributed products, so they are where most copyleft issues arise.

Open source in due diligence

In a due diligence, buyers and investors may ask for a software bill of materials, a list of components and their licences. The SPDX specification, a common format for that information, is recognised as the international standard ISO/IEC 5962:2021. For processes, the OpenChain specification became ISO/IEC 5230:2020 in December 2020; it sets the key requirements of an open source licence compliance programme, including roles and responsibilities. Neither is mandatory, but both give a credible answer when a counterparty asks how you manage open source.

A review will typically look for missing attribution files, copyleft components inside distributed products, unclear licences on code copied from forums or repositories, and gaps in the record of which component versions were used.

What this means for your business

Build and maintain an inventory of components and licences for each product, ideally in SPDX format.
Adopt a short open source policy: which licences are pre-approved, which need review (for example GPL and AGPL in distributed products) and who decides.
Check how each product reaches customers: distributed, installed on devices or offered only as a service.
Meet the notice obligations: licence texts, copyright notices and Apache NOTICE files in your distributions.
Reflect open source in contracts: warranties from developers and suppliers, and accurate disclosures to customers and investors.

Our team for software copyright and open source licensing can review your inventory and policy and help resolve conflicts before they reach a deal table.

Where companies get open source wrong

Treating “free” as “unconditional”. Every licence has conditions, even if they are only attribution.
Ignoring how the product is delivered. The same component can be low risk in a hosted service and high risk in a distributed app.
Forgetting the AGPL. Network use of a modified AGPL component can require releasing its source.
No records. Without an inventory, compliance cannot be shown in a due diligence, and remediation becomes a race against the closing date.
Leaving it to the deal. Our IP due diligence for cross-border transactions covers open source, but problems are cheaper to fix months before a transaction.

Frequently asked questions

Can I use MIT or Apache licensed code in a proprietary product?

Yes. Both are permissive licences that allow use, modification and distribution in closed products. MIT requires keeping its copyright and permission notice in all copies or substantial portions. Apache 2.0 requires providing the licence, marking modified files, keeping notices and reproducing NOTICE file attributions, and it ends the patent licence for anyone who sues claiming the work infringes a patent.

Do I have to publish my source code if I use GPL software?

Only if you distribute a work based on the GPL program. In that case the GPL requires licensing the whole work under the GPL and providing the corresponding source code. Internal use does not trigger that obligation, and under GPL v3 offering software over a network without transferring copies is not conveying. The AGPL is stricter for network use of modified versions.

What happens if we breach an open source licence?

The permission falls away and the use can be treated as copyright infringement. GPL v2 terminates automatically on breach. GPL v3 also terminates, but a first-time violator who cures within 30 days of the copyright holder’s notice has the licence reinstated permanently. Breaches also surface in due diligence and can affect valuation or deal terms.

Can IP Global Guard audit our open source use before a funding round or sale?

Yes. We review your component inventory and licences, identify copyleft and attribution issues, propose remediation and draft the open source policy and contract clauses, coordinating with your technical team. We work across Europe, Latin America and Africa from a single point of contact.

How IP Global Guard can help you manage open source risk

IP Global Guard, the intellectual property services line of META Channel Corporation Limited, advises on software copyright, licensing and IP due diligence for companies in more than 25 jurisdictions across Europe, Latin America and Africa, with one strategy and one billing relationship; see our coverage across the corridor.

Tell us which products you distribute, how they reach customers and whether a transaction is coming. We will scope an open source review that fits your timeline. Speak to our software licensing team.

This article is general information, not legal advice, and does not replace an assessment of your specific software and licences.