Community mailing list archives
Re: Enterprise: Is it allowed to use AGPL community modules?by
Akretion, Raphael Valyi
On Mon, Oct 5, 2015 at 1:44 PM, Alan Bell <firstname.lastname@example.org> wrote:
The non AGPL accounting module can't list the AGPL localisation module in the depends line of the manifest file. So if for example you have an AGPL UK localisation with a specific chart of accounts and you want to write an HSBC bank integration module that needs the chart of accounts from the localisation module then the bank integration thing can't be proprietary as it builds on the work done in the localisation module. If the non-AGPL accounting module really doesn't care what localisation pack is installed, it isn't a dependency, it isn't a derived work, then there isn't a problem, you can install both and they can work together,
Except it's just too easy to avoid. So imagine you want your proprietary HSBC bank module to be triggered by some button "do_bank_intergaton_stuff(...)" of the AGPL localization but you cannot have the AGPL module "depend" on your proprietary module. So you take the LGPL parent of the localization, you fork it and add a void method called do_bank_intergation_stuff(...). You also add this method in a released AGPL fork. Now you override this method too in your proprietary module. Now the AGPL localzation interact with your proprietary module just as you like without you having to have any explicit dependency. At some point this hidden dependency feature happens with all core ORM methods via the dependency injection I just mentioned.
So I say this is technically just too easy to wire AGPL and proprietary modules together without using that "depends" keyword at all.