Hello,
We just follow the recommandation of the Free Software Foundation:
- http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright
Most of the good open source software publishers does this. As an
example, here is the one of Canonical (Ubuntu):
- http://en.wikipedia.org/wiki/Canonical%27s_contributor_agreement
Here is the one of FSF Europe and KDE:
- http://ev.kde.org/announcements/2008-08-22-fsfe-welcomes-fla.php
In the future, we will follow the same guidelines as the others:
- when you develop a module, I think it's good that you keep the
copyright on your own module. So everyone apply the copyright and
license he wants to his own module. (but the license has to be
compatible with the AGPL)
- when you do a small merge proposals in the framework or an official
addons, I think it's better that you give the copyright to OpenERP.
If you don't want, we may refuse the merge proposal.
If we want to protect OpenERP in the future, it's very important that
the copyright does not depends on several contributors that can block
any evolution.
Here are three examples we must be able to handle in the future:
- 2 years ago, we decided to change the licence of OpenERP from GPL to
AGPL to enforce the open source nature of OpenERP. If we did not had
the copyright on the code, any contributor may have blocked this
evolution.
- Suppose that in 5 years, we detect a legal issue with the AGPLv3 and
the FSF recommands to evolve to AGPL v4. We want to have the
possibility to do that without taking the risk that any contributor
blocks the situation.
- If someone infridge the AGPL licence of OpenERP, we need to
have sufficient rights to enforce licences in court.
If you don't want to give your copyright for your small contributions,
the FSF proposes also that you put your code in the public domain. It
seems like a good alternative for me.
Please note that it does not change anything for you as everything is
licenced under the AGPL v3 that guarantees you that you can use, modify
and copy the code.
I don't know if Olivier proposed you one contributor agreement or not
yet. If not, I think it seems good to take the one of the FSF Europe:
http://ev.kde.org/announcements/2008-08-22-fsfe-welcomes-fla.php
OpenERP SA seems to have uncovered a new business model with its new
offer to sell its products under a non-AGPL license to those companies
who are afraid of losing a competitive advantage in their specific
business area. This way the customer can escape the obligation that
can arise under certain circumstances under the AGPL, to distribute
any modules that were developed specifically for him. If we can
support the development of the OpenERP products by licensing our
contributions for this specific purpose, we are willing to do so,
preferably by means of a contributor agreement that clearly describes
the rights and obligations of both the contributor and OpenERP SA.
To be more precise on 'strategic aspect' of the optional Private Use
clause of OpenERP Enterprise:
- It's not a business model in it-self (I don't think we will sell
more OpenERP Enterprise due to this; we sell OpenERP Enterprise
because it's a great service not because of legal issues)
- But it's important so that OpenERP can be used by companies that
would never have used it without this clause. We have already 3
customers in this situation. We prefer that they use OpenERP with
private modules (they don't contribute but they finance R&D of new
features) rather than they choose another software to use.
-> As an example, employees of Google can use GPL libs but not AGPL
ones as it's against Google's internal guidelines.
-> If the license of a B2B software becomes a blocking point for
some customers to use it,
A single commercial entity can simply not be trusted to act in the
best interest of an open source community.
I think you work with OpenERP since enough years to know exactly who is
OpenERP SA. To be clear, OpenERP SA is not just a commercial entity ! We
proved since the past 7 years that OpenERP SA is one of the biggest
defender of open source amongst the big open source publisher;
- we never developed any proprietary module
- we published every development we did under AGPL
- we moved to the most strict open source licence: AGPL
- we do not accept to have people that sell modules on OpenERP
- when someone developed commercial modules (like Outlook plugin of
Axelor, we invested ourself to redevelop the same features in open
source)
- we invested a lot to collaborate with the community members on
launchpad to manage bugs, merge proposals, etc.
I don't think they are a lot of community members that can say YES to
these 6 sentences.
In my opinion, licensing issues is not the right debate. The biggest
risk for OpenERP in the future is not related to license or legal
issues. The biggest risk for OpenERP is to not be able to compete with
proprietary softwares in the future.
The world is evolving very quickly. Yesterday you needed to be a 3-tier
application to be in the top. Today you need to be web oriented and
tomorrow you will need to be mobile if you want to be used by customers.
Yesterday an accounting software costed thousands of EUR and today you
can buy some for a few dozens of euros.
If OpenERP wants to survive against proprietary competitors, we need to
evolve very quickly. If we don't we risk to be deprecated in a few years.
In my opinion, the capacity of OpenERP to grow quickly is directly
related to our capacity to generate revenues for the partners (new
features, small improvements) and for OpenERP SA (useability, new
revolutions like the web client or mobile one). These two actors are
today's main contributors of OpenERP.
Now, more seriously, I am a bit fed up of these public debates.
OpenERP is a great project. The community is full of good people. Most
of them are smart and motivated. Partners contribute a lot to the
project and follow the open source rules. OpenERP SA is very engaged in
the open source and invested a lot to help developing partners and the
community.
It's a very good and fun environment and we have the chance that it's
our daily job. We should enjoy working together, we should collaborate
and help each other to build something great that will kick asses to SAP
and Microsoft. Instead of that, we waste time fighting against each others.
I propose to keep things simple. You do what you prefer for your own code;
- you contribute to the core and accept to put in the public domain
or give your copyright agreement (following the FSFE one)
- or you do your improve in your own branch and we can not merge it
in the trunk in order to protect the future of OpenERP.
But, for your decision, keep in mind that the real risk for the future
of OpenERP is not the "commercial entity OpenERP SA". The real risk is
to be deprecated in the future as we did not succeeded to work together
to build something great.
Stefan Rijnhart wrote:
Hi,
In the forum topic on dual license community modules [1] we, like others
before us pointed out that OpenERP SA was not entitled to relicense code
from outside contributors. We were contacted afterwards by Olivier Dony
who asked us whether we would be willing to assign copyright of our
contributions to OpenERP SA. As we believe that this is a topic that is
relevant for the whole community, we choose to answer through the
community mailing list.
Here at Therp we recognize the special role that OpenERP SA has played
in the development of the OpenERP framework. Just as well, the open
source model and the community around the OpenERP have also been major
factors in the success of OpenERP. We want to grant OpenERP SA the
ability to benefit from their efforts, as long as it does not harm the
other factors.
OpenERP SA seems to have uncovered a new business model with its new
offer to sell its products under a non-AGPL license to those companies
who are afraid of losing a competitive advantage in their specific
business area. This way the customer can escape the obligation that can
arise under certain circumstances under the AGPL, to distribute any
modules that were developed specifically for him. If we can support the
development of the OpenERP products by licensing our contributions for
this specific purpose, we are willing to do so, preferably by means of a
contributor agreement that clearly describes the rights and obligations
of both the contributor and OpenERP SA.
As for assigning copyright to OpenERP SA as requested by Olivier, or
even giving a very broad license to OpenERP SA on our contributions,
this would allow OpenERP SA to come up with all kinds of scenarios that
we might not endorse. A single commercial entity can simply not be
trusted to act in the best interest of an open source community. An
elegant solution for this is to have a meritocratic membership
foundation for OpenERP as there is for Plone to decide about these
things and negotiate on behalf of the community. We would probably agree
to assign joint ownership (rather than the actual copyrights) to such a
foundation. If anything, this issue clearly demonstrates the need for
the OpenERP community to organize themselves in such a way. As it is
however, we will not assign copyright to OpenERP SA, and the contributor
agreement should explicitely mention the limitations of the license that
we grant to OpenERP SA on our code to reflect the purpose mentioned
above (i.e. sell a non-AGPL license to individual customers so that they
do not have to share their own customizations).
What we specifically do not want to allow, is for OpenERP SA to branch
off a proprietary version that include bug fixes and functionality that
lacks from the open source version or is added only after a deliberate
delay. The contributor agreement should therefore include a commitment
from OpenERP SA to always make the source code of the product and of any
product derived from it available under the AGPL in a machine readable
form.
Therp invites OpenERP SA to offer us a contributor agreement along these
lines so that we can continue to support OpenERP properly for new and
existing customers, contribute our bugfixes and patches and be a good
citizen in the OpenERP community as well as supporting OpenERP SA in
their business model.
On behalf of the Therp team,
Stefan Rijnhart
[1] http://www.openerp.com/forum/topic26369.html
