Community mailing list archives

Re: access to code under AGPL v3

Camptocamp SA, Joël Grand-Guillaume
- 01/18/2016 07:55:18
Hi Dominique,

You get our point.



On Sun, Jan 17, 2016 at 11:01 AM, Dominique Chabord <> wrote:
hello Maxime,

Thank you for this explanation. It answers the question in a different
way than I thought and it is effective.

I think I was making a mistake when I thought a code or module is a
code or module where ever we get it from.

If I understand correctly your outcome, and if we can differentiate
the same module coming from OCA or coming from an author (probably a
mention is the source), then OCA protection of the user can be

In practice, if an author wishes to enforce a strict interpretation of
the AGPL on a module used by my customer along with a proprietary
module, I can prove him that the code of the module is the OCA one,
and show him that no proprietary module directly depends on his work
by design (__openerp.py__).

Then I can produce a copy of OCA statement or an archive of it if it
is no longer on-line, and, even if IANAL, I feel more comfortable to
prove my good will.

If I'm correct in the above, I think I just understood OCA statement.
I hope I'm not still wrong.

Even if OCA "protection" is theoritical, I understand it is a
realistic move and compromise to keep an AGPL community working in the
V9 proprietary deal.

Thanks again for your patience.

2016-01-16 18:07 GMT+01:00 Maxime Chambreuil
> Hello Dominique,
> As a hoster, if you are installing AGPL modules from the OCA, you are fine.
> If you are installing the same module from a contributor, then this
> contributor can take action for license infringement.
> First, he would have to inform the user, which would inform you. At this
> step, your customer and you can decide to :
> switch to install and use the module from the OCA, and your customer and you
> will be fine;
> remain on his version and then he can sue your customer, who can sue you.
> So the recommendations I give is to use OCA modules because the OCA decided
> to protect the user. If a user uses the contributor version of the module,
> he doesn't have the long term guarantee that this module and its future
> versions will remain available under an OSI compatible license. The
> contributor can decide to close it when migrating to version 9, for example.
> I hope it helps you answer your strategic concerns.
> Regards,
> --
> Maxime Chambreuil
> Ring ID: 239e01f6262afbf3c7d276d2c661173ddddc0340
> Tel: +1 (514) 276-5468 #126
> ----- Le 16 Jan 16, à 6:51, Dominique Chabord <>
> a écrit :
> hello,
> a friend attracted my attention this morning that I've been cited on
> contributor's list for a similar discussion. I'm not part of this list
> because I'm neither a member of OCA nor a contributor (of code). Maxim
> made it clear and he is right.
> Even if I wrote the citation, I was not intended to criticize OCA
> position but to understand it. I just don't repeat it in each sentence
> and i'm not the nasty guy if you read all. I don't aim at rising
> issues, I search answers. I'm globally impressed how OCA succeeded in
> maintaining community unity through these troubled times.
> The reasons why I have to dig strategic aspects a bit further are
> - I 'm a hoster of thousands of Odoo servers and need to understand
> how my business is at risk :
> - I act as a strategic consultant and a prescriber for my direct
> customers (some of them are contributors) and need to build
> recommendations
> I'm sorry for people who would think I'm just noisy, I try not to be.
> Have an excellent day.
> _______________________________________________
> Mailing-List:
> Post to:
> Unsubscribe:
> _______________________________________________
> Mailing-List:
> Post to:
> Unsubscribe:

Post to:



Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28