Open Source Software Licence: A Complete Guide

An open source software licence determines what others can and cannot do with your code. Whether you are releasing a project, contributing to one, or incorporating open source components into a commercial product, the licence you choose or encounter carries real legal weight.

This guide breaks down the major open source software licence types, their obligations, compatibility considerations, and compliance requirements. This content is educational and should not be treated as legal advice. Consult a qualified attorney for guidance specific to your situation.

What Is an Open Source Software Licence?

An open source software licence is a copyright licence that grants users permission to use, modify, and distribute source code under defined conditions. Without a licence, software defaults to "all rights reserved" under copyright law, meaning no one else can legally copy, modify, or distribute it.

The Open Source Initiative (OSI) maintains the Open Source Definition, which sets 10 criteria a licence must meet to qualify as open source. These include free redistribution, access to source code, permission for derived works, and no discrimination against persons, groups, or fields of endeavour.

Key characteristics of OSI-approved licences include:

• Free redistribution without royalty or fee requirements
• Source code access either included or made easily available
• Derived works permitted with distribution allowed under the same or compatible terms
• No usage restrictions on who can use the software or for what purpose
• Technology neutrality without requiring acceptance through a click or specific medium

As of 2024, the OSI has approved over 80 licences, though a small number dominate the vast majority of open source projects.

Types of Open Source Software Licences

Open source licences fall into two broad categories: permissive and copyleft. The distinction matters because it determines what obligations downstream users and developers have.

Permissive licences

Permissive licences impose minimal restrictions. They typically require attribution (keeping the copyright notice) and a disclaimer of warranty, but they allow derivative works to be distributed under any terms, including proprietary ones.

The most widely used permissive licences are:

1. MIT License. The simplest and most popular open source licence, used by projects like Node.js and React. It permits commercial use, modification, distribution, and private use with only two conditions: include the copyright notice and the licence text.
2. Apache License 2.0. Similar to MIT but adds an explicit patent grant and a patent retaliation clause. Used by projects like Kubernetes and Android. Contributors grant a royalty-free patent licence, and anyone who initiates patent litigation loses their licence.
3. BSD Licenses (2-Clause and 3-Clause). Nearly identical to MIT. The 3-Clause version adds a restriction against using the project's name for endorsement. Used by FreeBSD and many academic projects.
4. ISC License. Functionally equivalent to MIT, with slightly simplified language. Used by OpenBSD and npm.

Copyleft licences

Copyleft licences require that derivative works be distributed under the same or a compatible licence. This creates a "share-alike" obligation that prevents open source code from being absorbed into proprietary products without contributing changes back.

The major copyleft licences are:

1. GNU General Public License (GPL) v2 and v3. The most well-known copyleft licence. Any software that links to or incorporates GPL code must be released under the GPL. Version 3 adds protections against patent claims and anti-circumvention laws (DRM). Used by Linux, WordPress, and GIMP.
2. GNU Lesser General Public License (LGPL). A weaker copyleft that allows proprietary software to link to LGPL libraries without triggering the copyleft requirement. Modifications to the LGPL library itself must still be shared. Used by many C/C++ libraries.
3. GNU Affero General Public License (AGPL) v3. Extends the GPL to cover software accessed over a network. If you modify AGPL software and let users interact with it over a network (such as a web application), you must make the source code available. Used by MongoDB (before its licence change) and Nextcloud.
4. Mozilla Public License (MPL) 2.0. A file-level copyleft. Modifications to MPL-licensed files must remain under the MPL, but you can combine MPL files with proprietary code in a larger project. Used by Firefox and Thunderbird.

How to Choose an Open Source Software Licence

Selecting an open source software licence depends on your goals for the project and how you want others to use your code.

If you want maximum adoption

Choose MIT or Apache 2.0. Permissive licences remove barriers to adoption because companies can incorporate your code into proprietary products without legal concern. Apache 2.0 is preferable if patent protection matters.

If you want to keep derivatives open

Choose GPL v3 or AGPL v3. Copyleft ensures that improvements to your software remain available to the community. Use AGPL if your software runs as a web service, since the standard GPL does not trigger its sharing requirement for server-side use.

If you want a middle ground

Choose LGPL or MPL 2.0. These allow your library or specific files to be used in proprietary contexts while requiring that modifications to your code itself stay open.

Decision factors

Consider these questions before selecting a licence:

• Will the project include third-party dependencies with their own licences?
• Do you want to allow proprietary forks?
• Is patent protection relevant to your technology?
• Will the software be deployed as a service (SaaS)?
• What licences do similar projects in your ecosystem use?

Open Source Software Licence Compliance

Using open source software in your products comes with legal obligations. Non-compliance can lead to litigation, injunctions, and forced disclosure of proprietary source code.

Attribution requirements

Almost every open source licence requires attribution. At minimum, you must:

• Retain the original copyright notice in the source code
• Include a copy of the licence text with distributions
• Clearly identify which components are open source in your documentation

Copyleft compliance

If you use GPL, LGPL, or AGPL code, additional obligations apply:

1. Source code availability. You must offer the complete corresponding source code to anyone who receives the binary. For GPL v3, this includes installation instructions for user-modified versions.
2. Licence propagation. Your combined work must be distributed under the same copyleft licence (for GPL) or compatible terms.
3. No additional restrictions. You cannot impose terms that restrict the rights the licence grants, such as requiring NDAs or fees for access.

Practical compliance steps

Organizations that use open source should implement a structured compliance programme:

1. Maintain a Software Bill of Materials (SBOM) listing all open source components, their versions, and their licences
2. Use automated scanning tools (such as FOSSA, Snyk, or Black Duck) to detect open source dependencies
3. Review licence compatibility before adding new dependencies
4. Establish an approval workflow for new open source components
5. Train developers on licence obligations and contribution policies

The Linux Foundation's OpenChain Project (ISO/IEC 5230:2020) provides a standardized framework for open source licence compliance programmes.

Licence Compatibility and Conflicts

Not all open source licences work together. Combining code from differently licensed projects can create legal conflicts that prevent distribution.

Common compatibility issues

• GPL v2 and Apache 2.0. Incompatible in one direction. Apache 2.0 code cannot be included in GPL v2 projects because Apache 2.0 adds patent retaliation terms that the GPL v2 does not permit. However, GPL v3 resolved this by explicitly accommodating Apache 2.0.
• GPL and proprietary code. Combining GPL code with proprietary code in a single programme creates a derivative work that must be released under the GPL. This is often called the "viral" nature of copyleft.
• LGPL and static linking. Static linking to an LGPL library may trigger the copyleft requirement, while dynamic linking generally does not. The LGPL v2.1 includes specific provisions for this distinction.

Dual licensing

Some projects use dual licensing to offer the software under both an open source licence and a commercial licence. This allows the maintainer to grant proprietary use rights to paying customers while keeping the community version under a copyleft licence. MySQL (GPL plus commercial), Qt (LGPL plus commercial), and MongoDB (SSPL plus commercial) have all used variations of this model.

Open Source Licences and Privacy Obligations

An open source software licence governs how code can be used and distributed, but it does not address data privacy. If your open source software, or any product built with open source components, collects personal data from users, separate legal obligations apply.

Under the GDPR (Regulation (EU) 2016/679), any controller or processor handling personal data of EU residents must provide a privacy notice covering the legal basis for processing, data retention periods, and data subject rights (Articles 13 and 14). Under the CCPA (California Civil Code Section 1798.100 et seq.), businesses collecting California residents' personal information must disclose what data they collect and allow consumers to opt out of its sale.

These obligations apply regardless of whether the underlying software is open source or proprietary. If your project collects user data, analytics, crash reports, or telemetry, you need a privacy policy that meets the requirements of applicable privacy laws.

Open Source Software Licence Enforcement

Open source licence enforcement has a real track record. Violations can carry significant consequences, particularly for copyleft licences.

Notable enforcement cases

• BusyBox litigation (2007 to 2011). The Software Freedom Conservancy filed multiple lawsuits against companies distributing BusyBox without complying with the GPL v2. Most cases settled with the defendants agreeing to release source code and pay damages.
• Artifex Software v. Hancom (2017). Artifex sued Hancom for using Ghostscript, dual-licensed under the GPL and a commercial licence, without obtaining a commercial licence or complying with the GPL. The court allowed the GPL enforcement claim to proceed, treating the GPL as an enforceable contract.
• Free Software Foundation v. Cisco (2008). The FSF sued Cisco (via its subsidiary Linksys) for GPL violations in router firmware. The case settled with Cisco appointing a Free Software Director and making source code available.

Enforcement mechanisms

Enforcement typically follows a graduated approach:

1. Community notification. Maintainers or organisations like the FSF contact the alleged violator privately.
2. Cure period. Many licences, including GPL v3 (Section 8), provide a 30-day cure period for first-time violators to come into compliance.
3. Legal action. If informal resolution fails, copyright holders can file suit for injunctive relief and damages under copyright law.

Open Source Governance and Contribution Policies

If you maintain an open source project or contribute to one, governance policies help manage legal risk.

Contributor licence agreements (CLAs)

A CLA is a legal agreement between a contributor and the project maintainer that grants the maintainer specific rights over the contribution. CLAs typically grant a copyright licence and a patent licence, and they confirm the contributor has the right to make the contribution. Projects like Apache, Kubernetes, and Google's open source projects require CLAs.

Developer Certificate of Origin (DCO)

An alternative to CLAs, the DCO is a lightweight statement that contributors sign off on (using git commit -s) to certify they have the right to submit the code. The Linux kernel and many CNCF projects use the DCO instead of a CLA.

Governance best practices

• Choose a licence before accepting any contributions
• Document your contribution policy in a CONTRIBUTING file
• Decide between CLA and DCO and communicate the requirement clearly
• Maintain a clear intellectual property policy for the project
• Consider joining a foundation (Apache, Linux, Eclipse) for legal infrastructure

Tools like TermsBox can help you generate the supporting legal documents your project needs, including a privacy policy for your project website and terms of service for any hosted services.

Frequently Asked Questions

What is an open source software licence?

An open source software licence is a legal agreement that grants users the right to use, study, modify, and distribute the software's source code. Each licence type sets specific conditions, ranging from highly permissive (MIT, BSD) to copyleft (GPL), which require derivative works to remain open source.

Can I use open source software in a commercial product?

Yes, most open source licences explicitly allow commercial use. However, copyleft licences like the GPL require you to release derivative works under the same licence, which may affect proprietary products. Permissive licences like MIT and Apache 2.0 allow commercial use with fewer restrictions.

What happens if I violate an open source licence?

Violating an open source licence can result in copyright infringement claims, injunctions requiring you to stop distributing the software, and mandatory release of proprietary source code under copyleft licences. The Software Freedom Conservancy and the Free Software Foundation actively enforce GPL compliance.

Do I need a privacy policy if my open source project collects user data?

Yes. Open source licences govern code distribution, not data collection. If your software collects personal data, you must comply with privacy laws like the GDPR (Article 13) and the CCPA (California Civil Code Section 1798.100), which require a clear privacy policy regardless of how the software is licensed.