What is the best open source license?

Choosing an open‑source license is a bit like choosing a marriage contract for your code. The decision may seem trivial at first, but it determines everything: who can use your work, how, and under what conditions. Yet most developers and companies spend less time thinking about their licence than naming their variables. The result: projects blocked by legal issues, lost contributions, or startups that discover too late they cannot monetize their software as planned. The question of the best open‑source licence keeps resurfacing in technical discussions, and the honest answer is that there is no universally superior licence. It all depends on your goals, business model, and the community you want to build. This guide details every major option to help you decide.

Understanding the stakes of choosing an open‑source licence

Choosing a licence is not a mere administrative formality. It is a strategic decision that influences a project's trajectory for years, even decades. A wrong choice can make a project unusable for certain companies, discourage contributors, or, on the contrary, open the door to an appropriation you did not anticipate.

In 2026, with the proliferation of SaaS models, cloud platforms, and generative AI that consumes open‑source code at massive scale, these stakes are more concrete than ever. Open‑source licence disputes have multiplied in recent years, and several large firms have had to modify their licensing strategy (HashiCorp, Redis, Elastic) amid tensions between openness and commercial viability.

The distinction between free software and open source

People often confuse free software with open source, but the nuance matters. Free software, as defined by the Free Software Foundation (FSF) of Richard Stallman, rests on four fundamental freedoms: run the program, study its workings, redistribute copies, and distribute modified versions. The emphasis is on ethics and user freedom.

Open source, promoted by the Open Source Initiative (OSI), shares most of these principles but takes a more pragmatic approach. The OSI focuses on the primary objective of Open‑Source software: better quality, faster innovation, reduced costs. The difference is chiefly philosophical, yet it shows up in licence choice. A project that declares itself free software will often favour a strong copyleft licence like the GPL, whereas an open‑source‑oriented project may opt for a permissive licence such as MIT or Apache..

This distinction is not merely academic. It determines the culture of your project and the type of contributors you will attract.

Key criteria: protection, sharing, and commercial use

Three main axes differentiate open‑source licences from one another. The first is the level of code protection. Some licences require that any modification remain open (copyleft), others do not. The second axis concerns the sharing conditions: can you redistribute the code under a different licence? Must you credit the original author? The third axis, often the most decisive for companies, relates to commercial use. All OSI licences permit commercial use, but the terms vary considerably.

Concretely, ask yourself these questions before picking a licence:

• Do you want modifications of your code to remain open?
• Are you okay with companies embedding your code in proprietary products?
• Do you need protection against patent litigation?
• Will your software be primarily used via the cloud or on‑premises?

Your answers will naturally steer you toward one family of licences rather than another.

Permissive licences: freedom above all

Permissive licences are the simplest and most popular. Their principle: you give away your code with minimal constraints. The user may do whatever they want, including integrating it into proprietary software. This is where the main difference between Open Source and proprietary software lies: you must retain the copyright notice and the original licence. This flexibility explains their massive adoption, especially by large tech companies.

In 2026, permissive licences dominate GitHub. Platform data shows MIT and Apache 2.0 alone account for over 60 % of licensed repositories. The popularity stems from a simple calculation: fewer constraints mean less friction for adoption.

MIT licence: simplicity and popularity

The MIT licence fits on a few lines. It allows anyone to use, copy, modify, merge, publish, distribute, sub‑license, and sell the software, provided they keep the copyright notice. That’s it. No patent clause, no copyleft, no legal complexity.

This simplicity makes MIT the most used licence worldwide. React, Vue.js, Ruby on Rails, jQuery, projects reaching millions of developers, are MIT‑licensed. For an individual developer or a small team that wants maximum code diffusion without legal headaches, MIT is often the default choice. The flip side is the total lack of protection: a company can take your code, improve it, and never share the improvements. If that worries you, MIT is not for you.

BSD licences: maximal flexibility for developers

Apache 2.0 is similar to MIT at its core but adds two important elements. First, an explicit patent grant: each contributor automatically licenses any patents that read on their contributions. Second, a termination clause: if a user files a patent‑infringement lawsuit concerning the software, their licence is automatically revoked.

These protections make Apache 2.0 the preferred choice for enterprise‑grade projects. Kubernetes, Android (in part), TensorFlow, and many Apache Foundation projects use this licence. For a French company developing an open‑source project and fearing patent litigation, especially in an international context, Apache 2.0 offers stronger legal security than MIT. The text is longer and more complex, but that complexity serves a precise purpose.

BSD licences: maximal flexibility for developers

The BSD family includes several variants. The most common in 2026 is the BSD 2‑Clause (“Simplified”), virtually identical to MIT. The BSD 3‑Clause adds a restriction: you may not use the project's or contributors' names to endorse a derived product without written permission.

FreeBSD, NetBSD, and many networking components use BSD licences. Practically, the difference with MIT is marginal, but BSD has a longer Unix heritage and remains popular in OS‑related and networking‑infrastructure projects. If you are torn between MIT and BSD 2‑Clause, the decision is mostly cultural: MIT dominates the web/JavaScript ecosystem, BSD the system‑level ecosystem.

Copyleft licences: guaranteeing the longevity of open code

Copyleft rests on a strong idea: if you use free code, your modifications must stay free. It is a voluntary constraint designed to prevent appropriation of code by actors who would contribute nothing back. Copyleft splits the community. Its supporters see it as the only real guarantee of software freedom; its critics view it as a barrier to adoption and commercial innovation.

Reality lies between the two extremes. Copyleft enabled major projects like Linux, GCC, and WordPress. Yet it also caused some companies to avoid GPL components outright, fearing “contamination” of their proprietary code. That term, often used pejoratively, reflects a genuine concern: integrating GPL code into your software obliges you to distribute the whole software under GPL.

GNU GPL v3: the cornerstone of free software

The GPL version 3, released in 2007 and still widely used in 2026, is the best‑known copyleft licence. Its central mechanism: any derivative of a GPL‑licensed program must itself be distributed under the GPL, with source code accessible. v3 added protections against “tivoisation” (hardware lock‑down that prevents running modified versions) and a compatibility clause with Apache 2.0.

Linux (the kernel) uses GPL v2, while GCC, Bash, and many GNU tools use GPL v3. For a project whose mission is to stay free no matter what, GPL is the logical choice. However, be aware of its implications: many SaaS‑oriented companies refuse to integrate GPL components into their products. This is not spite; it is a legal and commercial reality.

LGPL: the compromise for software libraries

The LGPL (Lesser GPL) was created specifically for software libraries. Its principle: you may link your proprietary software to an LGPL library without your software becoming GPL. However, any modifications to the library itself must remain under LGPL and be shared.

It is a smart compromise. The GNU C Library (glibc), Qt (in part), and GTK are LGPL‑licensed. This allows these libraries to be used in commercial software while ensuring that improvements to the library benefit everyone. For a developer building a library who wants both commercial adoption and protection of the library’s code, LGPL is often the most suitable answer.

AGPL: addressing Cloud and SaaS challenges

GPL has a blind spot: it only triggers upon distribution of the software. If a company modifies GPL code and runs it solely on its servers without distributing it, it has no obligation to share the changes. This is sometimes called the ASP “gap” (Application Service Provider), and it matches the cloud‑computing model.

The AGPL (Affero GPL) plugs that gap. It adds a clause: if users interact with the software over a network (typically a web app), the modified source must be made available. MongoDB used AGPL before switching to its own SSPL (not OSI‑approved). Grafana, Nextcloud, and Mastodon are AGPL‑licensed.

For a vendor offering a server‑side product who wants to prevent cloud giants from offering a managed version without contributing back, AGPL is the most direct legal tool. Beware: this licence scares many enterprises. Google, for example, bans the use of AGPL code in its internal projects.

Comparison according to project objectives

Instead of hunting for the “best” licence in absolute terms, it is more useful to reason by objective. Two scenarios recur constantly in discussions: maximizing adoption or protecting your work. These goals often conflict, and the licence choice is the main lever to balance them.

Below is a quick comparison table of the major licences:

Which licence favours massive adoption?

If your priority is that the greatest number of people and companies use your code, the choice narrows to MIT or Apache 2.0. Both remove almost all entry barriers. Large tech firms have internal policies that automatically approve these two licences, which is not the case for GPL or AGPL.

The React case is illustrative. Facebook originally released React under a BSD licence with a controversial patent clause, sparking community outrage. The switch to MIT in 2017 removed all hesitation and accelerated adoption. Likewise, Kubernetes under Apache 2.0 benefitted from a permissive licence that helped create a massive ecosystem of cloud providers, tools, and distributions.

If you are building a library, framework, or tool that you want to become a de‑facto standard, a permissive licence is almost always the right pick. You sacrifice control over downstream changes, but you gain diffusion. In the open‑source world, diffusion is often the most valuable resource.

Which licence protects your intellectual property?

If your goal is to prevent a competitor from taking your code, improving it, and selling the result without sharing back, copyleft licences are your ally. GPL v3 guarantees that any distribution of a derivative includes the source under the same licence. AGPL extends that guarantee to network‑based use.

Many open‑source vendors in 2026 adopt a dual‑licensing model: the code is offered under AGPL for the community, and under a paid commercial licence for companies that do not wish to accept copyleft obligations. This is the model used by GitLab, Mattermost, and numerous French open‑source startups. It works well when you are the primary contributor and hold copyright over the entire codebase.

Caution, however: copyleft protection is not absolute. Enforcement relies on the willingness and capacity to pursue legal action, which demands resources. The Software Freedom Conservancy regularly brings GPL enforcement lawsuits, but the process can be lengthy and costly.

Conclusion : comment sélectionner la licence idéale

There is no single answer to the question of the ideal open‑source licence. The choice depends on three factors: your philosophy (total freedom or mandatory reciprocity), your business model (services, dual‑licensing, or purely community‑driven), and your target ecosystem (traditional enterprises, startups, open‑source community).

For a personal project or a technical library, MIT remains the most pragmatic choice. For an enterprise project with patent issues, Apache 2.0 provides real additional security. For a server‑side software you want to protect from cloud exploitation without contribution, the AGPL combined with a commercial licence is the proven model. And for a project campaigning for free software, GPL v3 remains the reference.

The trap to avoid is not choosing at all, or choosing without understanding the implications. A project without a licence is not open source: by default copyright applies and nobody can legally use your code. Spend time reading the licence texts, consult OSI and FSF resources, and if your project has commercial dimensions, have your choice vetted by an intellectual‑property lawyer. One hour of legal advice today can spare you months of complications tomorrow.