Community mailing list archives
Re: access to code under AGPL v3by
Camptocamp SA, Joël Grand-Guillaume
Hi Dominique,You get our point.
On Sun, Jan 17, 2016 at 11:01 AM, Dominique Chabord <email@example.com> 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 invoked. 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 <firstname.lastname@example.org>: > 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 <email@example.com> > 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 : http://sisalp.com > - 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: https://www.odoo.com/groups/community-59 > Post to: mailto:firstname.lastname@example.org > Unsubscribe: https://www.odoo.com/groups?unsubscribe > > > _______________________________________________ > Mailing-List: https://www.odoo.com/groups/community-59 > Post to: mailto:email@example.com > Unsubscribe: https://www.odoo.com/groups?unsubscribe