Community mailing list archives

Re: Please confirm comments on v9 UI

Giovanni Francesco Capalbo
- 06/10/2015 07:08:49
Fabien often referred to a "clear path" from community to enterprise
during odoo days 2015. Two different UI's doesn't seem like the best way
to promote that.
If the 2-UI model holds, It appears to me that ther will be serious
consequences in training (re-training) users and consultants.

Also technical concerns:
1.What if a well designed module for UI-1 might not turn out as well on
UI-2 (either way around)?
2. Will odoo have to maintain both UI's? If not, will XML menu
structures thought for the new UI be workable in the old one? or will
community version have an organizational mess?

Giovanni Francesco Capalbo - Ontwerp en implementatie

Therp - Maatwerk in open ontwikkeling

tel:  020 3093093

On 10-06-15 12:22, Hans Yonathan wrote:
> Completely agree with Christophe,
> And by they way you must take into account that not all user are clever; if there’s something different they will loss and complain about the system.
> (even we have this a lot even when we just migrate version 7 to version 8 which is not really completely change on the GUI)
> And imagine if you are a consultant, and you must study 2 version of GUI?
> It will be a lot to remember.
> Thank You.
> Best Regards,
> * Hans Yonathan *
> * Odoo Support *
> FALINWA Limited
> Expert in Finance, Information System & Business Intelligence
> Odoo Silver Partner
> Website:   None [1]
> Tel. 13670137019 (China - Shenzhen)
> * From: * Christophe Hanon []
> *Sent:* Wednesday, June 10, 2015 5:41 PM
> *To:* Community
> *Subject:* Re: Please confirm comments on v9 UI
> Thanks Fabien,
> 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 !
> Kind regards,
> Christophe
> On Wed, Jun 10, 2015 at 9:28 AM, Fabien Pinckaers < [2] > 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 [1].
> 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 [2] 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, or
> import 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,
> Fabien
> PS: 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.
> [1] [3]
> [2] [4]
> On Tue, Jun 9, 2015 at 5:58 PM, Raphaël Valyi < [5] > wrote:
> 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).
> 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.
> See [6] . Odoo is FULL of this pattern.
> 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 ( [7] ). 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.
> 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.
> 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.
> 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.
> Thanks.
> On Tue, Jun 9, 2015 at 4:38 AM, Christophe Hanon < [8] > wrote:
> " 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...  Regards
> Christophe
> On Tue, Jun 9, 2015 at 1:39 AM, Ermin Trevisan < [9] > wrote:
> On 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 [10] [11] [12]       _______________________________________________
> Mailing-List: [13]
> Post to: mailto: [14]
> Unsubscribe: [15]
> --
> Christophe Hanon - ADINS
> Tel +32 (0) 10 81 47 32 [16]
> Fax + 32 (0) 10 81 91 84 [17]
> Mobile +32 (0) 475 63 79 65 [18]
> None [19]   &  None [20]
> ADINS est signataire -numéro d'enregistrement 435 - de la charte de déontologie
> « eTic » consultable à  l'adresse   None [21]  .
> _______________________________________________
> Mailing-List: [22]
> Post to: mailto: [23]
> Unsubscribe: [24]
> --
> Raphaël Valyi
> Founder and consultant
> [25]
> +55 21 3942-2434 [26]
> None [27]
> _______________________________________________
> Mailing-List: [28]
> Post to: mailto: [29]
> Unsubscribe: [30]
> _______________________________________________
> Mailing-List: [31]
> Post to: mailto: [32]
> Unsubscribe: [33]
> --
> Christophe Hanon - ADINS
> Tel +32 (0) 10 81 47 32
> Fax + 32 (0) 10 81 91 84
> Mobile +32 (0) 475 63 79 65
> None [34]   &  None [35]
> ADINS est signataire -numéro d'enregistrement 435 - de la charte de déontologie
> « eTic » consultable à  l'adresse   None [36]  .
> _______________________________________________
> Mailing-List:
> Post to:
> Unsubscribe:
> _______________________________________________
> Mailing-List:
> Post to:
> Unsubscribe:
> [1]
> [2]
> [3]
> [4]
> [5]
> [6]
> [7]
> [8]
> [9]
> [10]
> [11]
> [12]
> [13]
> [14]
> [15]
> [16] tel:%2B32 %280%29 10 81 47 32
> [17] tel:%2B 32 %280%29 10 81 91 84
> [18] tel:%2B32 %280%29 475 63 79 65
> [19]
> [20]
> [21]
> [22]
> [23]
> [24]
> [25]!/rvalyi
> [26] tel:%2B55 21 3942-2434
> [27]
> [28]
> [29]
> [30]
> [31]
> [32]
> [33]
> [34]
> [35]
> [36]