Community mailing list archives
Re: Please confirm comments on v9 UIby
ADINS sprl, Christophe HANON
as I am using only OCA or Odoo as a base, I feel safe for now.
I hope you will quickly clear the issue/fear about the gui.
I don't like the idea of a separate gui :
- I think the gui is part of the platform. For me, it is a key differentiator between open-object and other web framework. I really hope that with the LGPL licence we can fight without restriction against other frameworks (Python, Java, Php), this will mean more projects, more business etc
- Fear about incompatibility between two different UI
- Means double testing, double effort to document,... so far gui testing is manual...
- Complicate commercial approach (need to choose up front Enterprise vs Community)
- Cannot distribute freely the new look and feel
- Downloaded version and other distribution - e.g gree-odo will be on the old look and feel... so will give a wrong image of what odoo is
I hope you will find other way to differentiate the two versions to fit your business and let the entire core, ui, all type of views etc free and open-source...
Again, thanks for the Experience days, your attendance to the OCA session and all this great work !
On Wed, Jun 10, 2015 at 9:28 AM, Fabien Pinckaers <firstname.lastname@example.org> wrote:
Raphaël,As Alexandre Fayolle explained at the OCA board meeting: even the Linux kernel allows proprietary modules (example: the NVIDIA drivers). Odoo's modules are exactly like Linux modules. So, we are following Linus position .Now, its important to reassure Odoo users. Even if one may have different interpretation of the license (Linux and RMS may disagree on this), the intention of the copyright owners (Odoo, OCA at least) are clear: we want to protect our users from legal risks and discussions. During Odoo Experience, we (Odoo and OCA) did a statement  that explicitly says that a user of our modules can use proprietary and open source modules together (LGPL & AGPL).With such a public statement, users are protected from legal risks since the copyright owner is the only one that can sue a user. (and we have no intention to do it)Being permissive for users is good as it will avoid fears for customers.But we also think its important to respect open source licenses. If a developer releases a module under LGPL or AGPL, we should enforce the fact that other developers respect his choice.So, we will control what the developers of modules do:- Enforce derivative work for both LGPL and AGPL modules (if someone changes a module,he must release his changes under the same license)- You can not develop a proprietary module that depends (depends in __openerp__.py, orimport in python files) on an AGPL module.To do that, we plan to add automated checks in the apps store to check module licenses and their dependencies.Thanks,FabienPS: I am not an expert, but if we can have proprietary modules and AGPL modules together, it looks like it's because linking is a symmetrical operation in terms of GPL.On Tue, Jun 9, 2015 at 5:58 PM, Raphaël Valyi <email@example.com> wrote:Thanks.Again, just my opinion. But I think we should really talk about this openly because this is a serious issue. I think we had a pretty safe situation before and now we are entering a very uncertain licensing mess, I'm really not sure it would pay off for anybody.I'm not a lawyer either, but I just want to tell that I'm really not sure this is as simple as some people say. In my opinion AGPL modules are called via the dependency injection features in ways that would be equivalent as making direct calls in term of making a combined work.Hello Christophe and others,this is not about the OCA "agreeing" or finding it cool or not, this is about what a lawyer would say with the given licenses. You may find it cool and in a few years a license troll company makes it a business model to sue integrators on users who may infringe licenses (this troll business model absolutely exists with patent infringements for instance and it already does a lot of harm).See http://en.wikipedia.org/wiki/Dependency_injection. Odoo is FULL of this pattern.If the OCA has to hack into the licenses of contributed modules to make this legal, well this is may be technically possible given the OCA CLA, but in any case, that should then be a transparent re-licensing process.
Now imagine the abstract example of a proprietary e-shop who wants to work in a given country. Eventually they are interest in using our big localization to create localized invoices. But calling into our localization directly from the the proprietary e-shop would be illegal as stated by the GPL FAQ about *GPL plugins ( http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#GPLPluginsInNF ). Right?
Now is that legal to make an LGPL framework such as Odoo with a generic create function that would call the create function indirectly of any installed AGPL module (via the "dependency injection") ? Sorry but it looks a bit weak.
If that was true a proprietary program could always write a small LGPL wrapper that would call any *GPL functions indirectly this way and any *GPL program could be hacked. We are not talking about just sending some predefined API message to some *GPL program, we are talking about a plain memory "static linking" in a plain OOP fashion automatic calls back and forth between the proprietary and AGPL code (think about the computed fileds chain once your are inside the create method call stack). IMHO this is just like making a direct link except that there is an un-assuming middleman that would try to hide the illegal linking.
I'm personally in favor of letting main project contributors letting choose themselves for the code they made before changing their license forcefully in ways that are not just a license upgrade, because possibly that would be an even bigger step than moving from AGPL to GPL, possibly an AGPL to LGPL step, that's quite a big step for people who purposely license under AGPL to be protected from the proprietary industry." customer of the enterprise edition will not be allowed to use a community module, which is not licensed under LGPL, with the new UI."PLEASE don't spread this, because it is NOT Correct. There has been a complete agreement between Odoo and the OCA about that. There will be no issue mixing them. Provided that commercial modules don't use AGPL modules. It is also thinkable that OCA will released work under AGPL.There is no magic, but I think we have a unique opportunity to work on a platform where both community driven and commercial offering could live together, lets try it !Having said that I think putting the UI in Enterprise edition is a major mistake...RegardsChristopheOn 08.06.2015 16:12, OpenERP Master wrote: > Thanks for posting a link to the google doc. It is interesting. I > still maintain my original comment, IMO, it is a serious offense to > have any difference in a user experience between versions. I would ask > anyone to provide another successful software package that has such a > setup where there is a different experience between versions. For me, > this is a breaking point, meaning, I won't offer it. I'm sorry, but I > put my foot down. 8.0 works great. Most well known developers have > just started releasing their code for 8.0, haven't even thought about > 9. That is a mile away. Please correct me if my understanding is wrong. Let's have a look into the future: Besides the problem of the maintenance of 2 different UI's, I see a complete separation between Community version and Enterprise edition coming for legal licensing reason. A customer of the enterprise edition will not be allowed to use a community module, which is not licensed under LGPL, with the new UI. Nobody, except of Odoo and maybe official partners, is allowed to develop new modules with the new UI, so all community modules must stay with the old UI, so there will not be any community modules with the new UI anyway. Enterprise customers will be completely locked in if they are not willing to accept different UI's in one software. For me that sounds like a complete split. This is really bad news and if I had seen that coming a year ago, I would have taken another decision. -- twanda AG Ermin Trevisan Artherstrasse 19 CH-6318 Walchwil T +41 41 758 1515 M +41 79 208 7373 E firstname.lastname@example.org www.twanda.ch www.ipadweinkarte.twanda.ch--