← Back to team overview

openerp-community team mailing list archive

Re: OpenERP CMS: How does licensing model apply to website modules ?

 

On Mon, Jan 20, 2014 at 10:26 AM, Mario Arias <the.clone.master@xxxxxxxxx>wrote:

> That is the problem.
> Clients in general don't care about open or closed source. They just need
> to fullfill a need and that is not for free...
>
> They are paying us (all of us) for the services so it is not take without
> giving....
>
> So any website related module has to be available to everybody? Or are
> there any limits or specific scenaries ?
>
> Regards
>

Hello,

technically, the only OpenERP Javascript lib that lies on the web front-end
module is licensed under MIT now:
https://github.com/akretion/openerp-web/blob/trunk-website-al/addons/web/static/src/js/openerpframework.js

This is the lib that communicates with the OpenERP server with JSON.

So if you develop something like a pure client-side Javascript price
comparator, it doesn't create shared objects with any AGPL code and only
communicate with AGPL OpenERP via JSON messages, just like a web app can
query AGPL MongoDB.

So for the very limited code that lies on the Javascript side, if you only
need openerpframework.js or if you even don't need it at all your
Javascript code insn't contaminated by the AGPL I think.

Now, that only holds of that facing Javascript, any web module in Python
creates shared structures with community and OpenERP SA AGPL code on the
server and should hence conform to the AGPL license, that is inform the
user how they can download the source code of all these modules.

I personally like a lot that OpenERP went to AGPL by 2009. Today we have an
eco-system that is much more open source than for instance with something
like Magento. Now it has advantages and shortcomings. The fact that there
will be no code exclusive ownership certainly limits the project to receive
some investments, so it develops slower, but it certainly develops in a
more sustainable way (unlike something like Magento where no module reuse
another, where no sustainable knowledge is built).

In my experience, there is a huge market of companies that prefer to have
something that work for cheap (collectively maintained) than something only
them own. In fact when your release the knowledge required to implement
OpenERP, it doesn't matter too much if your competitor has the same code if
they don't have the same knowledge to fit them to their need.
But the front end really is the thing that carries the branding of a
company to the exterior world. And it's also exposed to the public, so easy
to figure out and copy. So I think this is cool that on the front-end the
AGPL contamination have limits like we know have with the MIT license of
the openerpframework.js lib.

Notice that is you work on some very ambitious web project where investment
might need to be protected, with OOOR https://github.com/akretion/ooor you
can have not only the Javascript libs non AGPL, but also all the Ruby
server code, that is the equivalent of the new OpenERP web modules. So, by
respecting the natural frontier of the AGPL license, it opens non AGPL
horizons without breaking the "social contract" of the core of OpenERP (the
AGPL license is the "social contract", the only contract, that the
community accepted to built that ecosystem of thousand of modules and help
OpenERP fix thousands of bugs during the last 5 years, it should absolutely
be protected).


Just a final note: I think I share the enthusiasm of Joël for the v8
modules in exactly the same sense: for interacting with the logged users,
it will certainly revolution the ERP landscape as for the online web
presence for anonymous navigation, it will certainly meet some market, but
probably not change things that much.


Best regards,

-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com

Follow ups

References