Community mailing list archives
Re: "The way to iOdoo" (was: Re: Odoo v9 Paid Apps)by
Thanks Alberto for the clarification to laymen: this is indeed the risk we are facing.
Please remind that OCA promotes OSI compliant licenses (http://opensource.org/licenses/alphabetical), not only AGPL3.
Contributor is free to select the license fitting his opensource ideology.
OCA is investigating the possibility to keep the protection of the selected license (even AGPL) and allow to work along closed license within Odoo package (core+Enterprise) so that end user can enjoy the full spectrum of modules (OCA+Odoo+Enterprise) without the risk of closing the OCA modules source.
2015-05-15 3:47 GMT+08:00 Alberto Barrionuevo <firstname.lastname@example.org>:
On 14/05/15 20:34, Stefan wrote: > On 14-05-15 20:12, Nicholas Burdick wrote: >> All, >> >> Can someone help clarify for me here? As I understand AGPL (which >> admittedly isn't my expertise), any part of these modules that >> interact with the AGPL Odoo core and are also AGPL, isn't that correct? >> >> I guess I don't understand why people believe that paid modules go >> against the open source nature of Odoo? The core of the system is >> still Open Source and a good chunk of these modules are going to be >> open source is well. >> >> Would love to get the clarification, thanks. > > Hi Nicholas, > > Odoo SA has announced that Odoo will be relicensed as LGPL. This opens > the way for closed source apps. While you can also ask money for AGPL > apps, it is likely that most of the paid apps will be under a > restrictive license. [Disclaimer: Explanation in plain words, because it is more complex] The other key issue is that this legal move of Odoo to LGPL from AGPL allows to any well funded IT corporation, for example, to create a kind of "Google Odoo" or "Microsoft Odoo" or "iOdoo". It would just need to take over all the LGPL code, extend it with rich featured closed code, and serve it as a cloud service. Under the LGPL the current or improved core would remain free, but in practical terms nobody would get ever access to such a source code as you do not get access to the Google Docs actual code. Historical contextualization: The LGPL is the most permissive license created by the FSF to allow to be mixed with closed code, when the AGPL is exactly the contrary, the less permissive one (so the one that better warranties the freedom of the code). The FSF does not recommend to use LGPL for generic code. It was intended mainly for libraries that need to be included into any kind of code, open and closed one. For generic code the FSF recommends GPL if it is not going to be served as cloud, and AGPL (Affero GPL) if it is going to be served as cloud. On this point you can understand why OCA is not interested in to release its modules as LGPL and was maintain them as only-AGPL. If they would move to the permissive LGPL the said big corporation (including Odoo,S.A.) may be able to develop and close their "Google Odoo" or "Microsoft Odoo" or "iOdoo" including in its features-for-free not only the Odoo S.A. code, but also all the 5.000 OCA modules. So with such a move any big player would be able to create a kind of closed-source monster cloud Odoo service with more functionality (the extension) than the current open Odoo. As I understand Odoo,S.A. is not afraid of such a movement because it have done already such an extension of rich features with its upcoming closed apps in Odoo v9. So Odoo,S.A. has an advantage of 1 or 2 years on the competitive development race. But anyway I perceive the movement quite risky for Odoo,S.A. itself because there may be very much better funded corporations that may win such a development race on the medium/long term. Another interpretation may be that any/some important shareholder(s) or bondholder(s) of Odoo,S.A. is/are interested in to open the door to closed Odoo's removing the current AGPL protection to its code not for the final interest of Odoo,S.A. but others one (a kind of EEE strategy ). What I've described is not anything that never happened in the FLOSS history. It is exactly what Apple did doing with MacOS X, that is an extension of the permissively licensed Darwing (a BSD variant actually). Also it is similar to what Apple did for many years forking the LGPL'ed KHTML to core their Safari. Luckily, in this case, after many years of community requests, finally it was renamed and released under the open WebKit community and used by Safari (closed), Chromium (open), Chrome (closed), KDE Rekonq (open), Opera (closed) and many others. Regarding the possible EEE strategy of the shareholder(s) is more or less what Oracle actually did with many of the Sun Microsystem open source projects (OpenOffice, MySQL, OpenSolaris, etc.), forcing at the end to the community to fork all them and to create foundations as OCA to manage each one. [Disclaimer: End of simplifications] Best, //Alberto.  http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
+86 186 21 36 16 70