Skip to Content

Understanding Open Source Licenses in the Odoo Ecosystem

When we talk about free or open source software, we often assume that open source means free of charge. But that’s not the case. The fact that the code is available does not mean we can do whatever we want with it: each project defines—through its license—the conditions of use, modification, and redistribution. And those conditions are precisely what make the difference.

What Does Open Source Mean?​

By itself, Open Source simply means that the source code is open and available for anyone to read.

However, open source licenses are social contracts. They define how we collaborate and what we give back to the community in exchange for benefiting from collective work.

A project can be free, but not necessarily permissive. And that’s the key: some licenses prioritize individual freedom (you can do almost anything with the code), while others prioritize reciprocity (if you improve the code, you must share those improvements with everyone else).

Types of Licenses

In general, open source licenses can be grouped into two broad families:

  • Permissive (MIT, BSD, Apache): allow you to use, modify, and redistribute the code—even within closed software. They are ideal for promoting adoption, but they also let companies benefit from community work without giving anything back.
  • Copyleft (GPL, AGPL): impose a condition of reciprocity. If you distribute a modified version, you must do so under the same license. They ensure that the software remains free, even as it evolves.

The practical difference is huge. A module under MIT can be integrated into a commercial solution without having to publish the result. A module under AGPL, however, requires keeping the chain open: whoever modifies it, shares it.

In addition, there’s the LGPL license, which sits somewhere in between. It was originally designed for libraries and doesn’t allow modifying the source code without keeping the same license, but it is permissive regarding derivative work that simply links to it.

The Particular Case of Odoo

Odoo SA originally (back in the TinyERP and OpenERP days) used the AGPL license, but eventually switched to LGPL. This change aimed to strike a balance between openness and business viability. It also allowed the creation of the Odoo Enterprise concept—proprietary code built on top of an open source core. That move made it possible to sell part of the code under commercial terms and shaped Odoo’s current business model.

The Odoo Community Association (OCA), however, operates under a different principle: to protect collaborative work and ensure that improvements remain available to everyone. That’s why, from its inception, it sought to keep most of its code under the AGPL, although it opened the door to some LGPL modules when it made sense—mainly for core or web-related components (like the job queue system).

Why the OCA Maintains the AGPL

The Affero GPL (AGPL) was specifically designed for web and SaaS environments. Unlike the classic GPL, which only requires releasing code when it’s redistributed, the AGPL also covers use over a network. In the Odoo context, this is essential: most implementations are web-based, and without this clause, it would be easy to benefit from community work without publishing the changes.

In other words, the AGPL prevents free-riding. It ensures that any improvement made to the software must also be shared with the community. It’s a way to guarantee reciprocity—to keep alive the core principle of open source: if everyone contributes, everyone benefits.

From time to time, voices within the OCA suggest switching from AGPL to LGPL to attract a wider developer base. In our view, that change would only increase the number of users, not contributors. If derivative work doesn’t need to be shared, fewer people will collaborate. We’d be opening the door for others to use OCA modules freely, without any clear return of improvements to the community. It’s worth remembering that when Odoo itself switched licenses, it caused a split—and that split led to the creation of the OCA, to preserve this open source legacy.

Our Vision

In our projects, we continue to follow the AGPL because we understand its value beyond the legal framework: it’s an ethical commitment. It means respecting collective effort and preventing open work from being privatized. It sometimes explains why certain developments cannot be integrated into private repositories, or why we ask clients to publish specific modifications. But it’s also what allows thousands of companies and developers to work on a common foundation without fear of losing their freedom.

The AGPL is not a limitation. It’s a guarantee of sustainability—a reminder that free software is not just about open code, but about keeping the doors of collaboration open.

How we structure our modules so that they are sustainable in the long term
Good practices to make the modules more sustainable