Community mailing list archives

Re: Odoo v9 Community and Enterprise editions

Akretion, Sebastien Beau
- 05/11/2015 03:14:41
Hi all,

Just a quick note : I am really really not sure about the fact that having an access to the login page is enough to ask the code, indeed you are not logged so are not using the application and you can not ask for the code source. in any case if some of you have doubt on this question the best is to ask the FSF the answer.

In any case it's not the point to debate. Go back to LGPL discution ;)

2015-05-11 8:56 GMT+02:00 Sebastien Beau <>:
Hi Anthony

We can share all customer custom code, but I think it will just sharing a lot of useless code for other partner, this is the only reason that we do not put it on github.
Regarding the CMS, I agree that this can be an issue for some customer / partner, so it will be great indeed to find a solution.

Moving to MIT or LGPL is an extreme move that remove a lot of freedom for partner and customer, and this can not be acceptable. If I will have to sacrifice something, I will prefer to have a CMS under AGPL then an ERP fully under LGPL, because in 99% case nobody will ask the custom code (note theme are data and so not subject to the AGPL licence)

But I think we can have some intermediary solution that can solve your CMS issue. May adding an exception (like you did before moving to LGPL) that explicitly allow to give the code to the company user and not to the portal user can be an acceptable solution for most of partner and customer.


2015-05-11 2:58 GMT+02:00 Antony Lesuisse <>:
On 05/10/2015 02:08 PM, Sebastien Beau wrote:
> This is why the best OpenSource business model is to
> - sell service (support, development, maintenance)
> - using share funding for big "R&D"
> - ask for donation
> This model is totally viable, as the cost are really reduce (not need for big
> marketing investment, cost maintenance share with all the partner, shared code
> review, shared R&D...)

You could add - selling tee-shirts :)

Caveat, the following just reflect my personal opinion.

I dont believe it is a sustainable business model for a software editor.

Donation is the business model of charity and foundations, it could work for 
small projects but not for a product like Odoo, i recommend the following 
article about donation and open source

Crowdfunding can be effective to bootstrap new ideas or finance a specific 
developments but not for day-to-day development. The funding we got from the 
crowdfunding projects we did, didn't cover costs of the actual development.

Building a company just on those 2 revenue lines would be foolish and that's 
the reason none exists.

Now remains selling support, development and maintenance, that's what we did 
with Odoo till now, but with moderate success because it's a doomed strategy. 
This strategy can works for an ISV but not for a global and mainstream 
software editor.

- development: custom development conflict with a generic product vision, it 
defocus the company, and more importantly it's best done by local partners 
with various specific expertise, also pricing vary a lot. That's why there is 
so much value in the partner network and in the community.

- maintenance: the more buggy the software is the more value maintenance has. 
Each time we fix a bug we undermine the value proposition. And yet, we want to 
build a great and bug-free product. Of course maintenance should be part of 
the package, because customers needs to be insured about problems, and no 
software is fully bug free. But selling only maintenance is a commercial nonsense.

- support value also decrease with time, can be handled by a local partner and 
conflict with the product strategy (making the software simple and easy to use).

A software editor can only be successful (and thus a software can only 
succeed) if it can secure a stable revenue stream from a least a subset of its 
users. And remember, if you never pay anything, YOU are the product.

Nowadays the favorite model is to sell subscriptions and sometimes additional 
non recurring fees (usually for consultancy).

For a subscription model to work it needs to come with an exclusive added 
value, whatever the licence. For example RHEL and MariaDB subscriptions 
provides you an exclusive access to their certified binaries. RHEL can be 
labeled as a pure Open Source product because the exclusive stuff is only the 
binaries instead of additional software. This is a neat trick but it would not 
work for Odoo.

RHEL is an exception, all other open source products are financed by selling 
an exclusive superset with a clear value proposition example Redhat JBoss 
Enterprise vs JBoss community.

For Odoo to succeed and to become the leader in management solution, i'm 
convinced that it will need hundreds of man-years of the best people focused 
full time in creating the best software possible. It's not possible to ensure 
that future based on a fragile business model.

Choosing a strong business model is as important as choosing a strong 
technical framework and we need both to succeed.

For my own code my favorite license has always been MIT, because of its 
simplicity. OpenERP switched to AGPL around october 2009, and i can understand 
the reasons of that decision before including a CMS but not anymore.

In practice many people run closed source modules. i'm sure even Akretion does 
it, the Odoo servers of theirs customers are probably running on a public ip, 
i can visit the page (at least the login page) i'm thus entitled to ask for 
the source code of ALL modules. CMS worsened to problem.

I'm entitled to ask the source code of every module of every Odoo server 
listening on a public ip. Does akretion wish that ? (Akretion is just an 
example, it's valid for every partner).

No akertion doesnt want you to get all that code, they want to share SOME of 
it. AGPL makes no sense for a software that is modular, has to be customized 
for very specific use cases and is reachable on internet. That's the reason we 
had the private use exception.

Now LGPL (as opposed to plain GPL) will allow all people (Odoo SA, partners, 
everyone) to mix the opensource part with EULA protected modules. The term NDA 
(which means non diclosure agreement) was incorrectly used in the thread where 
it meant EULA (meaning an EULA that would restrict distribution only, yet to 
be written).

So, yes, if you choose to publish your modules under LGPL it will be possible 
for a proprietary module to override your method and extend your work. 
(Technically it would also be possible without linking to your code, by doing 
rpc calls or direct database access to avoid linking it's just much less 
convenient). I dont think that's evil. Most of you probably already runs very 
specific code with hardcoded data that you dont want to be public. We are just 
making that legal for every user.

The other consequence is that it officially create a market for proprietary 
modules, the market was already there, behind the scene, operating in a gray 
area. The LGPL move doesn't prevent people to publish their open source 
modules. It allow people to publish officially their proprietary one. Let me 
repeat this, everything that was possible before the change still is possible. 
It opens the ecosystem to new possibilities. Every author is free to choose 
the license of its module, whether or not it publishes it by himself or 
through an OCA repository.


Post to: