[12.0][CHG] Use more permissive licence in some basic l10n-brazil modules #1374
Description
This change will allow to use these basic addons to build addons on top of Odoo Enterprise addons and also nip proprietary localizations in the bud; more on this later.
We are proposing this AGPL to LGPL license change for the addons lead by AKRETION here:
- 1. l10n_br_base - l10n_br_base: more permissive licence: AGPL-> LGPL #1375
- 2. l10n_br_coa (co-authored with KMEE) - l10n_br_coa: more permissive licence: AGPL-> LGPL #1376
- 3. l10_br_coa_simple - l10n_br_coa_simple: more permissive licence: AGPL-> LGPL #1377
We kindly ask the other contributors to accept this move for these modules. The sooner we make the move, the easier it is not betraying third party contributors. (we taked about this a couple of times with @mileo from KMEE and @marcelsavegnago from ESCODOO so this should be no surprise for them).
Rationale
You may all know Odoo SA stance on AGPL: while they moved their own codebase from GPL to AGPL in 2009 to kill private forks (Axelor anyone?), they now avoid AGPL and try to build their commercial offer around proprietary modules...
Especially everytime they go more aggressive in some country, they do it with lock in localization modules... We know this is happening for Brazil, as it happened with Spain or France or USA, or Mexico a few years ago.
While everybody is free to make a judgement, we don't fear this move. We know serious companies will opt for the OCA modules, we just feel sad for the others.
That being said, we know that if we make no move, Odoo SA will repeat his FUD speech about AGPL to sell proprietary localization to large corporations or larger partners: "you know these OCA communists cannot be serious, you cannot be safe with AGPL, you will need to release your customizations to all your competitors and blablabla". If we don't do the move we will have millions invested AGAINST the OCA. If we do the move, these millions will be invested behind the OCA, that's the point.
So we have a double goal to achieve:
- nip proprietary localizations in the bud
- and protect OCA/l10n-brazil from being made proprietary itself!
Indeed in the past AKRETION trained many companies (including KMEE and TRUSTCODE BTW) and many other companies forked our localization work and started making it some kind of illegal localization they would try to resell discreetly, sadly often with the support from Odoo Inc themselves... This double game sucks and this is one of the reasons we co-created to the OCA and put our work under its umbrella. So yes we should absolutely stick to the AGPL for the vast majority of the OCA/l10n-brazil.
About Odoo Enterprise
While Akretion used to sell a few Odoo Enterprise maintenance contracts between 2009 and 2014 when it wasn't based on proprietary Odoo EE code, Akretion now has less than 5% of its customer base using Odoo Enterprise (we even knew from Fabien that as of 2017 Odoo SA never sold as much in Brazil as when Akretion had this open source centered partnership...). Mostly these few current EE customers are customers who switched their implementation partner for Akretion and kept their Odoo EE (yes it happens). So we are not the ones willing to build Odoo EE modules using OCA/l10n-brazil modules.
All we want is nipping proprietary localizations in the bud: if a large Brazilian company like say Magazine Luiza starts to be serious about ERPs and pick Odoo, we don't want them to build atop of the EE Odoo Brazil package, we want them to pick OCA/l10n-brazil. With this change in the basic modules (only), they should be able to keep most of the customization modules private.
Making it easier to migrate from Odoo EE to the OCA
We know that l10n_base or the chart of accounts can quite easily be replicated and maintained as proprietary Odoo EE code. If we don't do this relicensing move this is just what will happen...
Now if companies use l10n_base EE imitations and other charts of accounts, what will happen is that these companies will have their master data trapped in the proprietary EE modules and migrating them to the open source OCA ecosystem will cost more than double. We want to avoid this, we want to make it easy for companies to experiment moving to the OCA open source localization!
Moreover we feel that if Odoo partners in Brazil start using at least these OCA modules even when going Odoo Enterprise, people will start being curious about the OCA and the module quality and in fact bet this will drive many more companies to the OCA and will make these legacy ERP guys change their mind about the open source world without them having to fail their implementations first in the process.
Keep protecting the open source nature of OCA/l10n-brazil with AGPL
While we kindly ask the other module contributors to accept this move in these very base modules, we don't want to change the AGPL license of any fiscal or accounting modules (anything that depends on l10n_br_fiscal or l10n_br_account). The vast majority of OCA/l10n-brazil will stick to AGPL!.
Again we want to make it OK for a big corporation to keep some vertical customization private (according to the set of OCA modules they will depend on), WE DON'T WANT TO MAKE IT OK TO RESELL OCA/l10n-brazil LOCALIZATION EXTENSIONS WITHOUT PUBLISHING THESE EXTENSIONS UNDER AGPL. You are an ERP provider and you use OCA/l10n-brazil to support the Brazilian accounting? - OK then play by the rules and publish your f*kcing code like everybody else is doing here. Free loaders and middlemen are not welcome.
No hidden agenda
We know that people can always feel panicated with licensing changes. However, you can check by yourself that AKRETION strategy IS THE OPEN SOURCE WAY. Indeed we co-created the OCA back in 2013 even before the project started receiving any significant contribution: https://odoo-community.org/page/About
AKRETION is also author or co-author of something between 15% to 20% of all OCA modules worldwide:https://odoo-community.org/shop/page/12?version=14&search=akretion
with more than 250 OCA open source modules and many more non OCA open source ones, mostly (+90% ?) under AGPL!
Akretion also sells no single proprietary module at all, we are not even an Odoo oficial partner anymore (despite having good relations with Odoo SA other than that).
Other OCA/l10n-brazil modules
While AKRETION is not the author of these modules, we kindly suggest KMEE to consider doing the same move for their basic modules that don't depend on l10n_br_fiscal nor l10n_br_account:
- l10n_br_portal (because this is easy were users will interact with AGPL Odoo and eventually ask for all the customization source code)
- payment_cielo
- l10_br_coa_generic (because it's just data and it's better companies use the OCA charts of accounts to migrate later).
REFERENCES
see also this kind of move for other OCA base modules:OCA/connector#356