Community mailing list archives

community@mail.odoo.com

Re: access to code under AGPL v3

by
Skillteam, Houssine BAKKALI
- 01/18/2016 04:52:46
"Graeme who is talking about sueing  OCA? Nore are we telling that anybody is corrupt!"

Yes! You are! How to understand this??

"Those OCA people which were sitting in that meeting seem to be either partners of ODOO S.A. or getting other benefits from them to make such decisions like written in your post. They don't seem to have used their brains to think ahead for future of the community."

And this!

"It also would mean that labels like:

Bronze, Silver, Gold or Platinum Partner could be simply be interpreted as a level those companies might committing license infringements of AGPL. Customers should take that not as a trust worthy label as it might be just the opposite of it!

It is so sad to see that OCA who always says they will take care for the community actually don't care at all about her!"

So far you're alone...
"I am very disappointed at that point about the OCA position. Sorry - but I guess that many others feel the same way right now!"

But I think that Morpheus is looking for you!! Andy you're the one!! You're the choosen one!!

2016-01-18 4:16 GMT+01:00 Andreas Becker <andi@lisandi.com>:
Graeme who is talking about sueing  OCA? Nore are we telling that anybody is corrupt!

The "legal institution" wasn't perhaps a word which could be misunderstood. sorry. 

I meant something like a "court". i.e. a customer gets a notice by a lawyer that he failed to make his code available like Fabien wrote already previously. This case is than perhaps getting to a court "legal institution" who will have to decide about that matter. Now that customer hosts his site with a hoster who will check the module and even change all non OCA modules versions to be from now on the OCA modules version. The court might decide that this is to late and might be good for future time but that the customer failed in the past and he will perhaps get a verdict.

Or take another example as most sites are a mixture of many modules from all kind of authors. now one is the original AGPL one, another is the OCA-AGPL one and perhaps another again an LGPL or even proprietary code.

AGPL and Proprietary code won't work but OCA-AGPL perhaps does, due to that OCA statement.

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__).

Perhaps someone can explain that a bit more understandable in words for someone who has no coding experience like customers! 
What should they look for? 
How can they find out if no module directly depends on his work?

or take the original problem which were the ODOO Themes which use __init.py and __openerp.py.
a customer is using a little bit modified Graphene Theme (different colors) which he has got installed from his developer, who himself got it from another place as most of those Themes are available in git repositories! Now this customer might face 2 problems.
  1. according to what Fabien wrote previously he wants to share the code base with all users who interact with the site according to AGPL. - now perhaps ODOO S.A. will ask him to pay a fine!
  2. he spares out some modules from making their sources available according what Fabien wrote and the AGPL. Now a user who interacts with his site is asking him to make all code according to AGPL available to all users who interact with the site. Which would mean also the code of the Theme and other modules (i.e. proprietary) he has not been published before.
  3. he is following the OCA statement and guidance and only installs OCA modules and the Graphene Theme Module. Ok OCA won't sue him but why should they. ODOO S.A. might get back to him to pay a fine but as the Theme Module is linking to AGPL or LGPL code it has to be AGPL or LGPL too. 
Perhaps someone can clarify what actually the parts in __openerp.py are which show what links and what not.

'name': 'Theme Common',
    'summary': 'Snippets Library',
    'description': 'Snippets library containing snippets to be styled in Less Themes.',
    'category': 'Hidden',
    'version': '1.0',
    'author': 'Odoo SA',
    'depends': ['website_less'],
-----
 'name': 'Bootswatch Theme',
    'summary': 'Support for Bootswatch themes in master',
    'description': 'This theme module is exclusively for master to keep the support of Bootswatch themes which were previously part of the website module in 8.0.',
    'category': 'Theme',
    'version': '1.0',
    'author': 'OpenERP SA',
    'depends': ['website_less', 'website'],
-----
    'name': 'Clean Theme',
    'description': 'Clean Theme',
    'image': 'Clean_description.jpg',
    'category': 'Theme',
    'version': '1.0',
    'author': 'Odoo SA',
    'depends': ['theme_common'],
-----

other themes might depend on
'depends': ['theme_common', 'snippet_google_map', 'website_animate', 'snippet_latest_posts'],

etc.

now take an OCA module which you can download from git

# -*- coding: utf-8 -*-
##############################################################################
#
#    Copyright (C) 2011 Agile Business Group sagl (<http://www.agilebg.com>)
#    Copyright (C) 2011 Domsense srl (<http://www.domsense.com>)
#
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU Affero General Public License as published
#    by the Free Software Foundation, either version 3 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU Affero General Public License for more details.
#
#    You should have received a copy of the GNU Affero General Public License
#    along with this program.  If not, see <http://www.gnu.org/licenses/>.
#
##############################################################################
{
    'name': "Account Invoice Template",
    'version': '0.1',
    'category': 'Generic Modules/Accounting',
    'description': """
Templates for Invoices
User can configure invoice templates, useful for recurring invoices.
The amount of each template line can be computed (through python code)
or kept as user input. If user input, when using the template, user has to fill
the amount of every input lines.
The invoice form allows lo load, through a wizard, the template to use and the
amounts to fill.

Contributors
------------
Lorenzo Battistini <lorenzo.battistini@agilebg.com>
Leonardo Pistone <leonardo.pistone@camptocamp.com>
Franco Tampieri <franco@tampieri.info>
""",
    'author': "Agile Business Group,Odoo Community Association (OCA)",
    'website': 'http://www.agilebg.com',
    'license': 'AGPL-3',
    "depends": ['account_move_template'],
    "data": [
        'invoice_template.xml',
        'wizard/select_template.xml',
        'security/ir.model.access.csv',
    ],
    "active": False,
    "installable": False
}

Here the OCA get's mentioned as 'author'

-----

# -*- coding: utf-8 -*-
##############################################################################
#
# Copyright (c) 2012 Camptocamp SA (http://www.camptocamp.com)
# All Right Reserved
#
# Author : Ferdinand Gassauer (ChriCar Beteiligungs- und Beratungs- GmbH)
#
# WARNING: This program as such is intended to be used by professional
# programmers who take the whole responsability of assessing all potential
# consequences resulting from its eventual inadequacies and bugs
# End users who are looking for a ready-to-use solution with commercial
# garantees and support are strongly adviced to contract a Free Software
# Service Company
#
# This program is Free Software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
#
##############################################################################
{ 'sequence': 500,
"name"         : "Fiscal Year extended Info"
, "description"  : """
Allows to store additional data (dates) per fiscal year
    * date of balance resolution
    * date filing balance to commercial register
    * date publishing balance to public
    * date filing fiscal declaration
"""
, "version"      : "1.0"
, "depends"      : 
[ "account"
#, "report_webkit"
, "one2many_sorted"
]
, "category"     : "Accounting & Finance"
, "author"       : "ChriCar Beteiligungs- und Beratungs- GmbH"
, "website"      : "http://www.camptocamp.com/"
, "data"         : ["fiscalyear_view.xml"]
, 'installable': False
, 'application'  : False
, "auto_install" : False
}

or take the above one from OCA repository and you don't see any remark that it is also OCA as an author.

or take the next also published in the OCA repository

# -*- coding: utf-8 -*-
{ 'sequence': 500,
"name"         : "Product Partner Moves"
, "version"      : "1.0"
, "author"       : "ChriCar Beteiligungs- und Beratungs- GmbH"
, "website"      : "http://www.chricar.at/ChriCar"
, "description"  : """Shows stock move quantities for each partner and period.
It's not a sale statistic, this has to be done from invoices.
Adds partner, transaction type and period to stock move.
"""
, "category"     : "Warehouse Management"
, "depends"      : ["stock", "sale", "purchase", "chricar_view_id", "c2c_stock_accounting"]
, "init_xml"     : []
, "demo"         : []
, "data"   : ["partner_product_view.xml"]
, "auto_install" : False
, 'installable': False
, 'application'  : False
}

also here we have no OCA involvement.

The examples from above are just taken from OCA and various other online repositories. 

So what would be now the best way for customers to check wether a module is an OCA module or not if even the modules listed in the OCA repository contain quite often OCA not as an author? This is really not easy for customers and hosters to accomplish!


IMHO section 2.1b in that OCA-CLA needs to be changed like Jairo suggested:

That means that you can wake up one day and realise that module you contributed last week under AGPL is today LGPL, BSD or Apache. Not fun either.
IMHO it's time to drop that. Instead, the CLA should state that no contributions under non-OSI licenses will be taken, and that you get for granted that your contribution will never be sublicensed without your consent.
The one with the right to licenses the code in a community is the one who pays for it or the one who writes it. Nobody else.
There's a wide range of opinions about what open source should be, and there is a licence for each of those. But when working in a community, the first thing you need is respect. And that goes by respecting each contribution's license.


Here you can actually see what could happen. Already the community part seems to be very very small in comparisson to the Enterprise part. If now modules get relicensed to be LGPL and than this coded gets extended only in proprietary modules - which means future enhancements won't be accessible anymore even for the developer who wrote the LGPL part originally, than this is no more funny. It can mean that the community version will get smaller and smaller. OCA already recommended to switch to Enterprise Edition!

Why does OCA not restrict which modules get published on OCA and which not. Finally it would be good to see ONLY OCA modules listed there, which all of them contain OCA also as an owner/author of the code. or simply mke at least another repository where i.e.
  1. integrate odoo-code-search into that website would make it even easier for customers to find the correct versions - with or without OCA
  2. keep the OCA repository where you ONLY include those modules which have also OCA as an "author"
  3. keep the OCB as is
  4. add an OCC where you collect and list all code which is available about Odoo - so the OCA would be a centralised place for customers and developers and they don't need to search the net at multiple places for any answers.
All of this is getting more and more complex as deeper you have a look at it and the longer you will wait to solve the issue the more difficult it will be to solve it at all!

We need clear and understandable/plausible arguments, as we are the ones selling a product/service to customers and only want to avoid that actually anybody and at least avoid that customers get sued. That is the point and therefore we need very clear explanations about what can be done and what not.

For customers it is mostly not obvious which module got included and most of them don't know the licenses which might be assigned to them and now they also have to differentiate between AGPL by OCA and AGPL by the author only modules, which makes things even more complicated.

The goal of OCA as I understand is as Dominique stated above. It is a "realistic move and compromise to keep an AGPL community working".

As Fabien has written further at the beginning of that Thread:

> 2/ Is it correct that the code to be provided access to, would be only the modules used publicly on the website (and not a module that is used internally - only in the backend)?
No, you must provide ALL modules. (as they have to be AGPLv3 too)

The move to Version 9 is not really a valuable move as as soon as an AGPL module gets included again the AGPL rule will be the one which has to be followed as it has been stated already here on the list by someone else and this is what Fabien just answered in Question 2 above. Even if this site includes proprietary code.

So the solution OCA has chosen was to write a statement, which is quite different from what it should be and what actually the original GNU AGPL License is trying ensure. If I understood it right. The OCA won't sue anybody who will mix up their code together with proprietary code.

The last is actually against the AGPL regulations but only the copyright holders can enforce it.

"In any case,  it is the copyright holders choice to enforce their license, not the other way around."

So indeed all customers must make sure first that they ONLY use OCA modules. As soon as another module might get used to they perhaps will be again in doubt about what might happen and which AGPL/LGPL/OCA-Statement AGPL will be the actual one used. This is not at all an easy task for customers and even not for developers or agencies or hosters. Most Odoo sites are IMHO a mixture of OCA and non OCA modules!  

Maxime wrote:

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 :
  1. switch to install and use the module from the OCA, and your customer and you will be fine; 
  1. 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.

As maxime states here there probably are 2 versions of the same module - am I right?

Can't the developer still publish a new version with another license and stop maintaining the older than OCA module?
Or worst case OCA is using their right to relicense the module and it gets to be LGPL so that all future developments could be included than in proprietary code which won't be anymore accessible to the original developer?

What is the benefit in that case that OCA holds the license?

Perhaps it is only a wording problem as Maxime is using "user" in perhaps a different way like mentioned in the AGPL. 

The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.

if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.


But as mentioned already we probably won't find the answer here on the mailing-list as there are to many blocking factors! 

I still hope and put my Thumbs up for the OCA to find a solution which will fit all.

Have a nice day Andi



With kind regards,
Mit freundlichen Grüßen,
Con un cordial saludo,
Cordialement,
с сердечным приветом,
เรื่องที่เกี่ยวกับชนิด,
與親切的問候,

 ANDI BECKER

CEO/General Manager LisAndi Co., Ltd.

--------------------------------------------------

LisAndi Co. Ltd., Phuket, Thailand (lisandi.com)
15/21 M.2 Viset Road, Rawai, Muang, Phuket, Thailand 83130

VoIP:   +49 (0)711 50 88788 50
Fax:     +49 (0)711 50 88788 50
Skype:          lisandi
Facebook:     andibecker
Google Talk/Facetime/eMail:  andi@lisandi.com

--------------------------------------------------

This email may contain confidential and/or privileged information. If you are not the intended recipient (or have received this email by mistake), please notify the sender immediately and destroy this email. Any unauthorized copying, disclosure or distribution of the material in this email is strictly prohibited. Email transmission security and error-free status cannot be guaranteed as information could be intercepted, corrupted, destroyed, delayed, incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which may arise as a result of email transmission

On Sun, Jan 17, 2016 at 5:01 PM, Dominique Chabord <dominique.chabord@sisalp.org> 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 <maxime.chambreuil@savoirfairelinux.com>: > 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 <dominique.chabord@sisalp.org> > 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:community@mail.odoo.com > Unsubscribe: https://www.odoo.com/groups?unsubscribe > > > _______________________________________________ > Mailing-List: https://www.odoo.com/groups/community-59 > Post to: mailto:community@mail.odoo.com > Unsubscribe: https://www.odoo.com/groups?unsubscribe

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe