[12.0][CHG] Use more permissive licence in some basic l10n-brazil modules

[rvalyi]

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:

1. nip proprietary localizations in the bud
2. 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

cc @renatonlima @mileo @marcelsavegnago

[rvalyi]

about the non surprise factor/no hidden agenda: me talking about this LGPL move when we created the l10n_br_coa module 1 year ago (with an answer from @mileo):
#841 (review)
#946 (comment)

as for l10n_br_base this was talked about also a couple of times at least in the 2 last years, in chat or video meeting though I couldn't find links.

[rvalyi]

another similar recent move with the datamodel module: OCA/rest-framework#166

[rvalyi]

Outro examplo de módulo básico que mudou para LGPL na OCA OCA/server-env#77 ...

[marcelsavegnago]

Bom dia @mileo. Tudo bem? Tem pode nos dar algum retorno sobre esta questão ? conseguiu evoluir algo internamente na KMEE ?

[marcelsavegnago]

Bom dia @mileo. Tudo bem? Tem pode nos dar algum retorno sobre esta questão ? conseguiu evoluir algo internamente na KMEE ?

[marcelsavegnago]

ping @mileo

[marcelsavegnago]

Boa tarde @mileo. Tudo bem? Pode nos dar algum retorno sobre esta questão ? conseguiu evoluir algo internamente na KMEE ?

[marcelsavegnago]

@rvalyi I recently followed a license change and @hbrunn made an important comment that may help to unlock the issue of licenses for the modules mentioned in this Issue as we are not getting feedback from those involved..

[mileo]

Boa tarde @mileo. Tudo bem? Pode nos dar algum retorno sobre esta questão ? conseguiu evoluir algo internamente na KMEE ?

Boa Tarde Pessoal,

Na minha opinião devemos pensar em alguma alteração de licença somente quanto a localização estiver mais completa, com SPED por exemplo. Até lá não vejo vantagem a não ser permitir a criação de componentes fechados.

Mas vocês que são a favor da alteração podem dar mais detalhes das vantagens dessa mudança nesse momento.

Att

[rvalyi]

Olá @mileo , qdo mais tarde se muda uma licença mais chato fica de ter o acordo dos contribuidores e de tb não trair as expectativas deles. E a tendência é aumentar os contribuidores, principalmente depois que tiver mais módulos migrados para a v14. Se vc fizer módulos de SPED ou outros novos módulos, idealmente vc bota eles direitamente na licença que vc quer sem ter que mudar depois...

Ficamos firmes atrás da AGPL na hora da queda de braços com a Odoo SA em 2015 para ver se a gente conseguia impedir de aparecer a versão fechada Odoo Enterprise, mas a partir do momento que a OCA meio que perdeu essa queda de braço, já faz menos sentindo.

A outra questão é que como eu expliquei, a localização é modular, não se trata de mudar a licença dos principais módulos, mas apenas de alguns módulos fáceis para a Odoo SA ou algum parceiro safado copiar sem ter problema. Se a gente não der esse passo, daqui pouco vai ter um montão de gente que vai instalar algum Odoo Brazil Enterprise no futuro, vai ficar insatisfeito assim como em qualquer lugar do mundo, só que pela questão do master data ser completamente diferente, essa galera não terá mais uma saída para a OCA, mudar custaria tanto dinheiro que o cara ficará preso na localização proprietária que terá instalado. Poderia ser clientes nossos se a migração fosse fácil...

Por fim, num ecossistema sempre mais permissivo, mudar a licença desses alguns módulos para LGPL3 é mandar um sinal verde para as empresas maiores que vão criar bastante código custom por cima, de que eles não vão ter risco de ter que revelar segredos industriais próprio tendo que publicar os módulos deles, que seja verdade ou o simples resultado de FUD, inclusive do próprio pessoal da Odoo SA. Bom se o cara faz um módulo que estende l10n_br_fiscal ou l10n_br_account terá que ser código AGPL, mas liberando o l10n_br_base isso já libera muitas customização sem noia de levar um processo por usar AGPL sem publicar. E pelo contrário, na ausência desse sinal verde uma galera vai investir nas futuras alternativas permissivas em vez de investir na OCA.

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.