CRM | e-Commerce | Accounting | Inventory | PoS | Project management | MRP | etc.
OpenERP is distributed under the terms of the AGPL license. Assuming a public-facing OpenERP server, I would like to know what it means for some situations:
Modified and custom modules must be open-sourced under the AGPL. This means that simply changing a few things, even trivial, or assembling a custom module for the sole purpose of adding a few initial data (like a slightly modifed view) place the burden of making the module available to the public. This can require significant resources (e.g. making sure there is no sensible information present, modifying OpenERP to offer a prominent link to download the changes (which will require "open-sourcing" that modification too), hosting the sources, ... is there any provision to not require such small changes to place such burden ?
I wonder how the requirements of the AGPL interact with the ability of OpenERP to be fed Python code by users that is executed just like its own source code. For instance workflow activities can be modified through the web interface and can contain Python code, or XML files often use Python code to specifies domains. Does it mean that the modified workflow activities or the data file must be open-sourced ? If yes, who must open-source such fed Python code on a SaaS, the user or the SaaS company ?
It seems to me that OpenERP as distributed via Launchpad is always distributed under the AGPL license. This means that people, when redistributing modified code, do so also under the AGPL. I also think they retain copyright of their own work. This is especially true for code made available in "merge proposals". How is it possible for OpenERP s.a. to sell OpenERP under a commercial license as part of the OpenERP Enterprise since it seems that code that was contributed back via Launchpad gives to OpenERP s.a. only the rights of the AGPL, not more ? Should OpenERP s.a. also open-source all its custom code running on openerp.com ?
What about the translations ? If I change a translation in database and that translation is publicly visible, should I provide a modified .po file (according to AGPL concept of editable source) ?
The only thing you need to do is make the code available. It can be as simply as a ZIP file on a server. You don't need to modify OpenERP to provide a link to the source code. Also, OpenERP offers a license for users who opt to pay for their Enterprise services that protects modules that users wish to keep undistributed.
Anything done via the UI in OpenERP is stored as a database record, not as code, so is exempt from AGPL.
OpenERP s.a is not selling OpenERP. They are selling services.
These are old links, but may help:
"Services Overview" at http://v6.openerp.com/node/819
"FAQ about Services" at http://v6.openerp.com/node/465
It would be best to contact OpenERP to confirm and expand on this.
This forum is occasionally visited by OpenERP staff, but is not an official channel for contacting them.
About the Open-Sourced SaaS offer:
AGPL speak in terms of the "Users" nothing else, it means if you Use SaaS for your own porpouse OpenERP mandatory need to give you the code (which is done in runbot I think!),
About Web Page, I think it should be "cool" if OpenERP put free this, but at the end of the day, they own the server licence, then they have the power to manage them rules exceptionally (like the private + AGPL paid licence i.e.:)
but BTW, I don't understand the end point of the question, because it is clearly explained in AGPL agreement. It should be great if you share with us the specific extract of the licence which you don't understand to have a more constructive conclusion and answer.
About the data/python code. Al what is in database is data not code (even if it is "Python syntax" wich comes from English language wich was invented Â¿?. It means data is data and can not be contaminated by any licence, because even legally in almost 40 countries exists laws that protect data exchange legally (and any licence can be Over Legally Managed).
First of all, a mandatory link to the AGPL license. My points are not direct answers to your points, so don't look for a 1:1 correlation.
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.
- You have to provide the source code to the user, not to the public. In cases where the server is public then this means that everyone can request the source code, but it's not the default.
If you make a modification for a client and he installs the modified version in his (hopefully private) server, I can't come to you and ask for a copy of your modified version, as I am not an user of your work.
- Regarding the "commercial" license, OpenERP S.A. does not sell Odoo with a license other than the AGPL. They sell services related to Odoo. That's why you can go on GitHub and download and install Odoo, even the SaaS versions.
Also, the AGPL specifically says that you can sell the work: "You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee."
This means that I can sell Odoo. I can take the source code from GitHub, put it in a CD, and sell it to anyone for 10k euros. You can too.
- "Should OpenERP s.a. also open-source all its custom code running on openerp.com ?"
Only the code that counts as an extension of the work and not as an aggregate: "A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate."
Now, here I think things get a little more open to interpretation. For example: is the apps platform an extension? If it is, OpenERP S.A. should provide the source code of the apps platform to any user who asks for it.
- "What about the translations ? If I change a translation in database and that translation is publicly visible, should I provide a modified .po file (according to AGPL concept of editable source) "
Yes (to your user!), and you already do. Unless you don't distribute the modified .po file but keep it secret and get the translations with API calls to your server, which I don't think you do.
In conclusion, I would say that as long as you license your custom modules / modifications as AGPL and give the source to your users, even only if and when they ask for it, you should be ok.
Hello Vo Minh Thu,
OpenER S.A Failed to show spirit in open soruce. Hanging logo / powered by / some interface.....
First of all ODOO/OpenERP failed to show spirit in open soruce, OpenER S.A put hanging license with OpenERP versions, Also changes in polices with all new version.
- First point in questation, really all must needed to consider.
- Here design license is in term of OpenERP framework and ORM related, so if you have any private librarie / commercial libs / own license code keep in seprate python / any file. So always build module where business logic keeps in private file / own license file. and keep just call in OpenERP Model files. So you can share it easily to publicly the module but nerver share your own license / private file to publuicly. No worries for xml and UI, who cares ;)
- Here keep business logic and meaningful code in seperate py and call them in openerp model file, your own file is own now one can force what to do.
- Its depens how smatly you code it. :)
- Third point, Custom code is all your private ad custom configuration is all about to private.
- Regarding fourth point, All changes which held directly in database, does not requires to share publicly. So if you even put xml views body part directly in database, no needed to share.
Finally think all most many begining who even not experts are working on OpenERP, many php developer also doing code even do not put security files, many does security less code and many create security files and security rules very badly... Now point comes where some big organization build good modules from people who badly coded and module hold very bad security. Its E.R.P. solution where many finance transaction going, many private details their. So if big organziation use OpenERP and share module publicly... then some one expert read public module and many expert hacker easily able to hack their organization system in few second, I recently exprienced this things. Also one of client I seen, they get solutions from some expert people, and share code, hacker/cracker read understood code well and crack their API and due to bad security rules all customer data imported externally. So how bad openerp in term of license.
Think if security organization use it and share code, how hacker make them hell, So OpenERP as per license, if you share code hacker can be attack, so you have to keep and use as desktop appliation without internet. :)
So people who expecting to migrate OpenERP for ORACLE think about license before you start it. Your code going to public / hacker / cracker and all can see your code and security rules & they easily know how poor your system.
Also some what put information at http://www.sorryopenerp.com/ is some what valuable as I think, This product is very poor in cloud, even 1GB RAM. With 500MB it always crash.
"AS SECURITY AND SHARED CODE & DUE TO LICENSE, BEWARE BEFORE USE."
About This Community
Odoo Training Center
|Asked: 12/19/13, 7:27 PM|
|Seen: 9128 times|
|Last updated: 3/16/15, 8:10 AM|