Analysis of the most common "Odoo" licenses in the context of the Bosnian market

Pročitajte ovaj članak na bosanskom

Introduction

In the “Odoo” ecosystem, we encounter four types of licenses in practice. Two are open-source (LGPL-3 and AGPL-3), and two are proprietary (OEEL-1 and OPL-1). The end client in Bosnia and Herzegovina often does not know which license stands behind the module they use. Yet that difference directly affects the annual cost, the right to modify, the risk of “vendor lock-in”, and the fate of the system if the implementor disappears.

At the very foundation of the platform lies a strategic licensing decision by “Odoo S.A.” that many clients do not notice: Odoo Community Edition is not under AGPL-3 — it is under LGPL-3. That difference is what gives the entire Enterprise business model its technical and legal foundation.

This text is an overview of those licenses from the perspective of a small and underdeveloped market — where budgets are limited, the legal system is slow, and sensitivity to monthly subscriptions is high.

Note: I am not a lawyer. This is a reading of the license texts themselves and the official documentation. For specific legal situations, always consult a lawyer.

The four key licenses

1. LGPL-3 — “Odoo Community Edition” (Odoo CE itself)

Type: Open-source, “weaker” copyleft1. Example: The “Odoo Community” (CE) server itself — the entire github.com/odoo/odoo repository and all its modules (account, sale, purchase, stock, mrp …).

This is one of the most important and most commonly misunderstood facts about the Odoo ecosystem: Odoo CE is not AGPL-3. “Odoo S.A.” deliberately chose LGPL-3 instead of the “stronger” AGPL-3 for CE itself.

Why? LGPL-3 allows proprietary modules to be added on top of the CE base without requiring those modules to be published under the same license. That is exactly what “Odoo S.A.” does with its Enterprise modules (OEEL-1): they are installed on the CE server, use its APIs, but remain proprietary.

Had Odoo CE been published under AGPL-3, the very business model of “Odoo S.A.” — the Enterprise subscription — would not have been possible (or would have required special licensing arrangements). LGPL-3 is therefore a carefully chosen strategic decision that keeps the platform open-source while simultaneously enabling commercial add-ons. This is a fact that the client needs to understand:

When you run “Odoo Community”, you are running LGPL-3 software. When you install account_accountant (OEEL-1) or a third-party module (OPL-1) on top of it, you are installing proprietary code on an open-source base.

2. AGPL-3 — OCA modules and Bosnian localization

Type: Open-source, “strong” copyleft2. Example: The vast majority of OCA modules (account-financial-tools, account-financial-reporting, mis-builder, partner-contact, server-tools …), our l10n_ba Bosnian localization modules.

Unlike the Odoo CE core, the OCA community deliberately chose AGPL-3 — a “stronger” copyleft — for its modules. AGPL-3 closes the so-called “SaaS loophole”: any modification that is “served” to users over the network must be made available under the same license.

In practice, this means that no one can take an OCA module, add their modifications, and sell it as a proprietary Enterprise extension. Every modification must remain in the community. This is the opposite philosophy from what “Odoo S.A.” chose for its CE core, and that is precisely why OCA exists as a healthy counterweight to the commercial vector of “Odoo S.A.”.

A client using an OCA module has the right to:

  • Use the module free of charge.
  • Modify the source code.
  • Distribute their modifications — but under the same AGPL-3 license.

What AGPL-3 means for other Odoo providers and implementors

This is the part of the story that is most often ignored in Bosnian practice — either due to ignorance of the license, or deliberately:

Every Odoo provider who modifies an AGPL-3 module for their client has a legal obligation to make those modifications publicly available under the same AGPL-3 license.

“Publicly available” in the specific context of AGPL-3 means more than the classic GPL obligation. AGPL-3 closes the so-called “SaaS loophole”: if the modified software is served to users over a network (and Odoo is always served over a network — it is a web application), then all those users (including the client’s end users) have the right to request from the provider the complete source code of the modified version.

Practical consequences for the implementor:

  • Internal “customizations” of AGPL-3 modules without public disclosure = license violation. If a provider takes an OCA module (e.g. account-financial-reporting), adds client-specific VAT reports, deploys it on the client’s server, and does not publish the modifications — that is a license violation, even if the client never requests the code.
  • Hiding modifications behind a corporate firewall is not sufficient. AGPL-3 explicitly covers the situation where users access the software over a network within an organization.
  • There is no “client exclusivity”. The provider cannot contractually “buy out” the right to keep modifications private — the AGPL-3 obligation is towards all users of the software, not towards the original author. The only legal way to “privatize” modifications would be for the client and provider to jointly obtain permission from all original authors of the module — which in the OCA context is practically impossible (hundreds of authors per module).

In other words, AGPL-3 is designed precisely to prohibit what many “Odoo partners” in the region quietly do: taking OCA modules, internally modifying them for a client, charging for the development, while the code stays “in the drawer”. This is not a gray area — it is a license violation.

Bring.out strategy

Our l10n_ba modules follow the same philosophy as OCA: AGPL-3, publicly available code, full right of modification for the client. As the sole copyright holders of those modules, we have the right to keep our modifications and client upgrades behind closed doors — a copyright holder is not bound by their own license. However, modifications to all other AGPL-3 modules (OCA and similar) must be publicly published, which we do on our GitHub and git.hodi.ba repositories. Any other implementor who uses our AGPL-3 modules and makes modifications for their clients is obligated to publish those modifications publicly. More about our strategy here.

3. OEEL-1 — “Odoo Enterprise Edition License”

Type: Proprietary, subscription model. Example: The “Odoo EE” server and all Enterprise-only modules sold by “Odoo S.A.”.

This is the license that “Odoo S.A.” sells directly or through its partner network. It is not perpetual, although it is often perceived that way.

Key facts from the official Odoo documentation:

  • The software can only be used with a valid Odoo Enterprise subscription for the corresponding number of users.
  • Upon expiration or termination of the agreement, the license is immediately revoked, and the buyer commits to stop using the Enterprise software.
  • If the client continues using the software after the agreement expires, the contractual penalty is 300% of list prices.
  • Payment is annual, per user, and renews every year.

Some third-party partners occasionally advertise a so-called “lifetime license” as a one-time payment. This is not the official “Odoo S.A.” model — these are arrangements by third parties that do not follow the stream of official Odoo upgrades and support.

4. OPL-1 — “Odoo Proprietary License” (Apps Store)

Type: Proprietary, purchase model (not a subscription). Example: The vast majority of commercial modules on the “Odoo Apps Store”.

This is a license that is often misunderstood. Let us look at what the license text actually says:

  • The software can be used if you have “purchased a valid license from the authors” (typically through the Odoo Apps Store).
  • Modification and execution after modification are permitted.
  • Distribution, sublicensing, and selling copies (including modified copies) are prohibited.

There is no expiration clause. There is no mandatory annual subscription. Once purchased = the right to use persists.

But the following practical limitations are important:

  1. Per-version purchase. OPL-1 modules on the Apps Store are sold per Odoo major version. If you purchased a module for Odoo 17, upgrading to 18 generally requires a new purchase. This is not “license expiration” — it is a commercial practice of packaging by version.
  2. Tied to Enterprise (when used on Enterprise). If an OPL-1 module is installed on “Odoo EE” and the Enterprise subscription expires, the entire Enterprise instance stops working — and the OPL-1 module effectively stops working too, regardless of what the OPL-1 license itself says.
  3. Updates and support. Bug fixes and compatibility with minor upgrades depend on the author’s policy, who often sells annual “maintenance” as a separate service.

OPL-1 on “Odoo CE” — perpetual right of use

This is a key combination that is often overlooked:

If you install an OPL-1 module on “Odoo Community Edition”, you have a perpetual right to use that version of the module.

The reason: OPL-1 does not contain an expiration clause like OEEL-1 does (“upon expiration of this Agreement, this license is revoked immediately”). When an OPL-1 module is combined with a CE base (which is AGPL-3 and without expiration), there is no contractual mechanism that could revoke your right to use it.

Practical limitations still apply:

  • The license is for that specific version (e.g. Odoo 17). Upgrading to Odoo 18 CE generally requires a new module purchase — unless you port the module yourself (see the next point).
  • Without updates from the author, the module may break over time.
  • The Odoo Apps Store ToS3 may impose additional restrictions (e.g. binding to a specific database or domain).

Porting OPL-1 modules between versions

Scenario: a client buys an OPL-1 module for Odoo 16 CE, after two years upgrades to Odoo 17 CE, and themselves (or with the help of an implementor) ports the module to the new version for their own use.

Is this allowed? Yes, OPL-1 explicitly allows it.

The license text says:

  • “may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors”
  • “It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software”

Therefore:

✅ Allowed:

  • Porting the module from v16 to v17 CE (this is “modification”).
  • Running the ported module on v17 CE (this is “executed after modifications”).
  • Keeping the patched version for your internal use indefinitely.

❌ Not allowed:

  • Sharing or selling the ported version to another client.
  • Publishing the ported version on GitHub, even for free.
  • Sublicensing to anyone.
  • Publishing the modified module under a different license.

The boundary is drawn strictly around distribution, not around modification.

Comparison table

LicenseTypePayment modelModificationDistributionPerpetual?
LGPL-3Open-source copyleft (weaker)Free✅ Yes✅ Yes, under LGPL-3✅ Yes
AGPL-3Open-source copyleft (stronger)Free✅ Yes✅ Yes, under AGPL-3✅ Yes
OEEL-1ProprietaryAnnual subscription⚠️ Limited❌ No❌ No (expires with agreement)
OPL-1ProprietaryOne-time purchase per version✅ Yes (for own use)❌ No✅ Yes (for purchased version, on CE)

Where each license is most commonly used — concrete examples

LicenseWho deliversHow it is obtainedConcrete examples
LGPL-3”Odoo S.A.” (for the CE core)git clone github.com/odoo/odooThe entire Odoo Community server — the Odoo CE “framework” itself and all CE modules (account, sale, purchase, stock, mrp, hr, website, mass_mailing …). This license is a deliberate strategic choice by “Odoo S.A.” that enabled them to add proprietary OEEL-1 modules on top of the CE base.
AGPL-3OCA community, “bring.out”GitHub OCA organizations, implementor repositoriesOCA repositories (account-financial-tools, account-financial-reporting, mis-builder, partner-contact, server-tools, bank-payment, queue …), our l10n_ba Bosnian localization modules
OEEL-1Exclusively “Odoo S.A.”Mandatory annual subscription through “Odoo S.A.” or an authorized partneraccount_accountant (advanced accounting functionality), accountant, documents, sign (electronic signature), studio (visual builder), marketing_automation, quality, helpdesk, appointment, voip, planning — the entire odoo/enterprise repository
OPL-1Third-party authors (partner companies, freelancers)Odoo Apps Store (apps.odoo.com), one-time purchase per versionCommercial modules from companies such as Cybrosys, Almighty CS, Edge Technologies, Softhealer, Preciseways — typically vertical modules (restaurant POS add-ons, special reports, custom dashboards, connectors for third-party services)

What this practically means

  • “Odoo S.A.” chose LGPL-3 for the CE core itself, not AGPL-3. This choice is the foundation of their business model: only LGPL-3 allows proprietary OEEL-1 code to be installed on CE. Under AGPL-3, this would be legally complicated or impossible.
  • Odoo S.A. through OEEL-1 subscriptions sells its most valuable part — the account_accountant module (and everything that comes with it) is available only to clients paying an active Enterprise subscription. Without that subscription, the module stops working.
  • The OCA community publishes almost exclusively under AGPL-3 — the “stronger” copyleft license that prevents anyone from taking an OCA module and “locking” it into a proprietary product. That is why OCA is a healthy counterweight to the commercial direction of “Odoo S.A.”.
  • The Odoo Apps Store is a marketplace for OPL-1 modules. It is the “middle ground”: the author sells their work, but without a subscription — once purchased = perpetual right for that version.
  • “bring.out” delivers its modules (l10n_ba, accounting extensions, specialized integrations) under AGPL-3 — the same model as OCA, with full right of modification for the client. We do not use LGPL-3, which would allow others to internally modify our base localization modules at clients without the obligation to contribute changes back to the community.

What this means for the Bosnian market

1. The subscription model is expensive in a low-income country

Bosnia and Herzegovina is a small and underdeveloped market. Only organizations of the size of “JP Elektroprivreda BiH”, “BH Telecom”, or “Bingo” can afford million-level ERP budgets. For small and medium enterprises, the annual per-user subscription (OEEL-1) quickly turns into a significant operating cost — and, more importantly, into a risk if a particular year turns out to be bad.

2. The “300% penalty” clause is realistically uncertain

The OEEL-1 clause about a 300% penalty on list prices sounds intimidating, but in the Bosnian legal environment its real enforceability is unclear. In any case, for the client the very possibility of such a clause is reason for caution.

3. Rights protection is a difficult process

Licenses are contractual constructions that derive their value through effective legal enforcement. In Bosnia, the judicial process is slow, expensive, and uncertain. This applies in both directions: both for us who develop modules, and for the client who purchases.

For us, this practically means that we cannot consider the license as our primary weapon for protecting investment. That is why we chose the “behind closed doors” strategy — we keep development private, and deliver to the client under AGPL-3. This is a temporary model. We hope that in the near future we will secure the conditions to transition development to a classic open development model within the Bosnian open-source community. That is why we are investing efforts to make hodi.ba — the Bosnian “Odoo” open-source community — come to life.

4. OPL-1 on an open-source platform = a smart middle option for vertical solutions

The combination “Odoo CE + OPL-1 module” is an often underrecognized option:

  • The client receives a perpetual right to use that version.
  • No annual “racket”.
  • If the author disappears, the client still has the installation package and can continue working on that version.
  • Maintenance and upgrades are contracted as a separate service — transparently.

This is a model that makes sense for protecting the intellectual property of vertical solutions by Bosnian providers, where clients gain stability without the burden of annual subscriptions.

5. AGPL-3 and “no vendor lock-in”

Our Bosnian localization (l10n_ba) is delivered under AGPL-3. The practical consequence for the client: if they are not satisfied with our services, they can continue development with other contractors. This is a freedom that is often undervalued in this market, but which becomes crucial in crisis situations.

Recommendation: AGPL-3 for the base, OPL-1 for narrow verticals

Not every module needs to be under the same license. From the perspective of a small market, it makes sense to purposefully choose the license according to the type of module:

AGPL-3 for base and localization modules

For everything that constitutes the infrastructure of the system — Bosnian localization, chart of accounts, VAT treatments, fiscalization hooks, basic partner and banking integrations — AGPL-3 is the natural choice.

Reasons:

  • Base modules are “public goods”. They must not be owned by a single provider because every Odoo project in Bosnia depends on them. Locking basic localization behind a proprietary license harms the entire community.
  • Longevity. Base modules are used for 5–10 years, go through many Odoo versions, and must keep up with legislative changes. The open-source model ensures that the module survives even if the original author loses interest.
  • Multiple contributors. It makes sense for multiple companies and developers to work in parallel on base modules. AGPL-3 enables this; a proprietary license closes it off.

OPL-1 for vertical and niche solutions

For more narrowly specialized solutions — integrations with specific hardware (POS terminals, fiscal printers), vertical modules for specific industries (dental office, veterinary station, auto repair shop), advanced connectors for third-party services, custom dashboards for specific business domains — OPL-1 makes sense.

Reasons:

  • Small market segment, high development cost. A vertical solution for, say, 20 dental offices in BiH requires months of development. Without some form of protection, that development is financially unsustainable.
  • OPL-1 does not take away the client’s freedom. As we have shown, on a CE base OPL-1 gives the client a perpetual right of use and the right to modify for their own use. The only real restriction is distribution — which in practice means the author protects their sales model, not their control over the client.
  • Clear separation of platform and vertical IP. The system base remains open (CE + AGPL-3 localization), while vertical IP is clearly delineated. The client knows exactly what is “theirs” and what is “purchased”.

What to avoid: the “OEEL-1 locked sandwich”

The combination “OEEL-1 base + OPL-1 verticals” looks like a “serious enterprise solution” but in essence means that the client cannot take a single step without an active Enterprise subscription. When that subscription expires, the entire system (both the platform and the verticals) stops working. For a small market with uncertain budgets, this is the worst of all options.

Why an “open-source bias” is good for the Bosnian market

This text is not neutral. We openly acknowledge a positive bias towards open-source licenses and we believe that this bias is good for a small market like ours. Here is why:

1. Ecosystem instead of monopoly

An open-source platform enables multiple smaller companies to simultaneously work on quality ERP solutions with relatively small budgets. Instead of one or two companies having a monopoly over the platform, we have a situation where:

  • 5–10 small implementors can independently build functionalities.
  • Each of them can bring a piece of expertise (accounting, manufacturing, trade, logistics …) into a shared open-source fund.
  • Clients choose between implementors based on quality of work, not based on “who holds the key to the software”.

This is contrary to the model of large ERP providers (SAP, Oracle, Microsoft, Odoo S.A.) who operate in the Bosnian market as a closed cartel — the partner network is weak, options are expensive, and a client in a bad relationship has no way out.

2. The client is not “sentenced” to a single vendor

The greatest benefit of open-source ERP for the client is not the price. The greatest benefit is the freedom to change the provider.

With proprietary solutions, a client dissatisfied with the provider has difficult options: either endure, or launch an expensive and risky migration to another platform. With AGPL-3 solutions, a third option becomes real: changing the provider without changing the platform. The code is open, the source materials exist, any other competent team can take over development.

This freedom also disciplines the provider itself. We at “bring.out” know that our clients can leave, and that forces us to make the quality of our service real, not dependent on contractual lock-in.

3. Competitive value is built on know-how, not on sales

On closed platforms, the provider’s commercial capability often surpasses their technical capability. The client buys the illusion of a “big provider” — presentations with global logos, “enterprise grade” marketing rhetoric, promises of an “army of consultants”. And then in the implementation phase, that illusion melts away: one or two developers show up, communication drags on, escalation to “headquarters” never reaches a real engineer.

The open-source model does not allow such a distance between sales and implementation. Why?

  • The code is public. The client can (or can bring an expert to) look at the actual state of the module before purchasing. There is no “black box” selling.
  • References are real implementations. On GitHub you can see who committed what, how many pull requests were merged, who responds to issues.
  • The price is not in the license, but in the service. This means the client pays for what they actually need — analysis, development, implementation, support — not a subscription that “opens the door”.

Result: the competitive field is measured by know-how, team quality, and support capability — not by the sales team’s ability to make a good impression at the first meeting.

4. A realistic perspective for small enterprises

A Bosnian small and medium enterprise with a budget of, say, 10,000–30,000 BAM for ERP will never be a priority for large global providers. But such a client is a priority for a small open-source implementor who for the same budget can deliver:

  • An Odoo CE base (free license)
  • An AGPL-3 Bosnian localization (free license)
  • Focused customization for the specific business activity
  • Direct communication with the developer who understands the code

This model is not sustainable for every market, but it is sustainable for Bosnia and Herzegovina — because our market is naturally structured for small and agile, not for large and expensive.

Conclusion

  • LGPL-3 is the license of the Odoo CE core itself — strategically chosen by “Odoo S.A.” because it enables commercial OEEL-1 add-ons on top of an open-source base.
  • AGPL-3 is the natural choice for localization and shared modules — the OCA community and our l10n_ba use the “stronger” copyleft because it prevents a third party from “locking” base modules into a proprietary product.
  • OPL-1 is a smart choice for narrow verticals and niche solutions — the author protects their development, but the client (on a CE base) receives a perpetual right of use and the right to modify for their own use.
  • OEEL-1 is a subscription with all the risks of a subscription. For a small market with uncertain budgets — a serious burden.

For a small market like Bosnia and Herzegovina, the combination “CE (LGPL-3) + AGPL-3 localization + OPL-1 for narrow verticals” provides the best balance of flexibility, cost, and legal security. The “OEEL-1 subscription” model is more appropriate for mature markets with a strong partner network and a fast legal system.

Above the technical analysis of licenses stands a broader story: open-source bias is not ideology, but realpolitik of a small market. In a market of our size, the open-source model enables more players, healthier competition, and clients who choose providers by quality, not by lock-in. For Bosnia and Herzegovina, this is the best framework we currently have at our disposal.

Ernad Husremovic bring.out doo Sarajevo hernad@bring.out.ba

References

Footnotes

  1. LGPL (Lesser GPL) is a “weaker” copyleft because it allows linking (dynamic invocation) with proprietary code without requiring that proprietary code to become open-source. Modifications to the LGPL library itself must still be published under LGPL, but programs that merely use that library as a separate component can remain proprietary. In the Odoo context, this distinction is mostly academic because the Odoo architecture itself does not clearly distinguish “linking” from “modifying” — all modules are loaded into the same Python process. ↩

  2. Copyleft is a legal mechanism of open-source licenses that inverts the logic of copyright: instead of prohibiting copying, the license obliges anyone who distributes modified or derived software to publish that software under the same license. The goal is to protect the freedom to use, modify, and share from “closing” — no one can take open-source code, add their modifications, and then distribute the result as a proprietary product. The term is a playful wordplay opposite “copyright”: instead of “all rights reserved”, copyleft says “all obligations transferred”. The GPL family (GPL, LGPL, AGPL) are the most well-known examples of copyleft licenses; the opposite are “permissive” licenses (MIT, BSD, Apache) that allow code to be incorporated into proprietary products without the obligation to publish modifications. ↩

  3. ToS = “Terms of Service” — a legal document that the operator of a platform (in this case “Odoo S.A.” as the operator of the Apps Store) imposes on all platform users as a condition of use. It is important to distinguish ToS from the software license itself: the license (e.g. OPL-1) regulates rights over the code, while ToS regulates conditions of use of the sales channel (the Apps Store). The Apps Store ToS may introduce additional restrictions that the OPL-1 license itself does not mention — such as binding the purchased module to a specific Odoo database or domain, limitations on the number of installations, or a module registration requirement. ToS is not unlimited — it cannot retroactively “nullify” rights that the license grants — but in practice it defines an additional layer of rules that the client accepts by purchasing through the Apps Store. ↩