This question has been flagged
5 Replies
13322 Views

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) ?

Avatar
Discard

Al what is in database is data not code (even if it is "Python syntax" wich comes from English language wich was invented ¿?. It meas data is data and can not be contaminated by any licence.

.. hence, since "customizations" that are simply XML a Python code are just "data", they don't fall under AGPL.I would argue that putting those customizations in a module for convenience doesn't change that.

Author

So you find a way to escape the AGPL requirements, just put your whole module in database or between <xml></xml> ? That doesn't seem right.

Well, I am a free thinker, but we must be objective, and I think in this cas it is not Black or White, we have a lot of grays areas.

@Vo Minh Thu, As your all efforts useless on OpenERP, all credited to ODOO now. You out now, people will understand only when they had loss on their creative effort on modules & features.

@Vo-Minh-Thu, now on v8 in modules author details no more see default, all contribution will be lost from community...

Best Answer

There is a mobile client featured in Odoo Open Days 2014 Xpansa (mErp), an android client. It is closed source AFAICS. I don´t know how can that be done with AGPL-3. Check the video:

https://www.youtube.com/watch?v=g6y1j3kTGBQ

Can anyone please explain how can you license this?

 

 

Avatar
Discard

AGPL-3 only by Odoo / fabien, rest integration can be closed source if third party other then odoo build, odoo it self have bad polices in term of license then who cares it !!!

Best Answer
  • 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.

Avatar
Discard
Author
  • It seems you are contradicting yourself: how OpenERP s.a. can "protect" module if it is not by selling a non-AGPL license ? Can you be more specific ?
  • Python code can be edited via the GUI, and stored in database or in XML files, yes. That is still code and is run as part of the OpenERP program.
  • I am not sure about what you mean by your third point. According to your first link, OpenERP s.a. sells something they call AGPL + Private Use, i.e. a commercial license.

Still, thanks for the links.

I'm not in a position to respond to you - these are not 'my' licensing and business model decisions. You should be having this conversation with OpenERP. What I posted is my understanding based on numerous conversations with them, and as a partner who has been selling services (not licenses, not software) for several years.

Any idea how this would apply to third party code with licenses (eg. Slider Revolution)? For example if I write a module that allows for an interface for Odoo to implement Revolution Slider as a snippet in the CMS/frontend, does the AGPL licensing then need to be applied to the javascript and css that powers the slider, or would this still be treated as a separate entity in regards to licensing? I think there's a lot of useful proprietary code sold on places like codecanyon.com that could be very useful to Odoo users (especially for the CMS/frontend) if they could be implemented as modules, however i'm just trying to understand how the AGPL license applies to this type of situation and if the modules and third party code would then need to be bundled separately (ie. module itself is distributed freely while third party code could be purchased and dropped in to the module directory). Any insight on this would be appreciated.

Best Answer

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

Avatar
Discard
Best Answer

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.
     
  • Python, XML, Javascript etc. are they own source code. Basically, by installing Odoo to your users, you are also giving them the source code. That is enough.
     
  • 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.

Avatar
Discard

Are you Confused !!!! doubting ??? Or giving the answer !!!

Best Answer

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. :) 
  • Second point, Keep in mind private python code or private libs never share, just make call from python model files, even give very complicated code name so no one simply understood, you just need to share in only OpenERP Model and OpenER View. Even your private css or javascript keep private, do not hesitate to keep own license files where as it possible. If your business logics keep in seprate file, no worries to share.
  • 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."

 

 

 

Avatar
Discard

The simplest modification check, https://www.odoo.com/web#id=1&view_type=form&model=ir.translation I not freely mark here major security concern here for ERP. Their are many alter way we can break record rules.

Unfortunately some people not wrote, openerp is the hell. sorryopenerp.com as first time launch they indicate good remarks.

I love me some sprite! Jokes aside, this is 100% bullshit. Security through obscurity doesn't work.

It may be possible that Odoo has some secuirty issues, but if you think that it's because it's open source and closed softwares are inherently more secure, you are wrong. Good job downvoting my answer to the user question by the way, real mature.

Baby first understand how odoo provides the license, know their all polices rules. Then try to answer or comment. Are you kidding downvoting you discussing with all people who downvoted you, really first concern your maturity, More important is, first understood license of odoo, check every points then fill positively answer your own directly if you do not like other's comments or answers.