On Mon, Jan 20, 2014 at 10:26 AM, Mario Arias <the.clone.mas...@gmail.com>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
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp