Page navigation
Questions and Answers from OpenERP Communities
Question: The new license (AGPL) has raised the question whether OpenERP s.a. will
continue to apply the same codebase as the “public” OpenERP distribution. Could this be
guaranteed ?
Of course, our goal has always been to be fully open source. The AGPL is a stronger
guarantee for the community that any improvement on the software will be published. We
want, and we always wanted, to have only one base which is the same for every one (see other
question about AGPL later)
Question: How to prevent a situation OpenERP (Saas offer) becomes a competitor of the
community members / partners with their own SaaS offer ?
OpenERP is free as in freedom. With OpenERP, everyone is free to launch is own SaaS offer,
including OpenERP SA. You cannot ask OpenERP sa to not launch its own SaaS offer, as we
invest millions of EUR each year to improve the product.
Question: All the licenses on the code in the trunk changed from GPL to AGPL. Is such
change legally possible for an existing open source product like OpenERP ? Or is in the
opinion of OpenErp the copyright on all the code in the trunk proprietary ?
Yes, because we have the copyright on the whole code of the server, web client and addons.
We did not apply this change on modules for which we do not own the copyright (like
community addons). If we made a mistake and you made some contribution on which you
have a copyright, report to us and we will find a solution. We applied this on the
trunk/development version only.
Question: Allows AGPL still the creation of an OpenERP fork which needs to contain a
copyrighted trademark?
This change of license was requested by the community and was decided because it provides
a stronger Open Source protection for software that runs over a network. It is only meant to
close a hole in the GPL when the software is not distributed to the users, but only used over a
network. This is typically the case for OpenERP server, and the Free Software Foundation
itself recommends using AGPL “for any software which will commonly be run over a
network” (http:/
Now, what do you mean by a copyrighted trademark ?
• Neither the AGPL nor the GPL allow distributing software with proprietary
developments on an open source project. Every contribution has to be open source.
• As we own the original copyright, we can choose to publish our work under any
license. However anyone else working on OpenERP code needs to abide by the what
this license permits.
• The AGPL is not different from the GPL in this regard
Recommendation: If Openerp s.a. takes the community seriously the general strategic
directions and change in license policy should be shared and discussed in an early stage.
This change in the licence is not related to our opinion only. The AGPL change in the licence
has been requested by the community and partners for several months and we followed their
recommendation because it allows a better protection on the open source nature of OpenERP.
Recommendation: At the community days OpenERP s.a. said that only clients with a
maintenance contract get a direct security fix and that the community has to wait until the
next stable release. For a healthy open source project, this is an unacceptable policy. The
community should be able to retrieve such fix from the code repository as soon as available.
No, this is not the case. Every bugfix (from maintenance contracts or directly from our R&D)
is applied on the public repository directly. It's important that the community works on the
same version than everyone else.
The only bugfixes we do not publish directly are bugfixes related to security holes. In such
special cases, it's important that we release the bugfix for the customers one month before a
public announcements on the security issue. So that real customers have a delay of one month
to migrate their instance before the security hole becomes public.
Recommendation: Participants that contribute (not only to code, but also translations,
bugreport, bugfixes, community tasks) must get credits for their work. For example: In the
case that a person contributes substantially to a code improvement it is important that this is
also mentioned in the official release. Nearly all modules / addons bear uniformly the
copyright of OpenERP s.a. (c.q. Tiny SPRL), irrespective of their actual contributors.
Sure, third-party modules that are promoted to official addons of course bear the name of their
authors if it was correctly set. And module files themselves contain the GPL license header
and the name of the original author if it's not OpenERP (as long as the author sets it properly,
again). For code patches and merge proposals we always try to set the contributor of the code
as the author in the commit, that's the correct way to give credit to a developer (check the
history for example on http:/
For translations unfortunately Launchpad does not allow us to export the name of the
contributors.
We also mention the list of Launchpad bugs in release notes, so anyone can see who reported
and who worked on any given bug.
TOOLS
Question: Does OpenERP s.a. use internally a different Source Management System
(Subversion) for version control than the official launchpad branches making it impossible
for the community to follow exactly what is happening in the source code?
No, we have always been very clear on this topic. We are the most open source and
transparent possible. Everything we do is published on Launchpad, just have a look at the
number of commits per day.
Question: How is it possible that Dutch (NL) translations got lost using the community tools
while merging the translations into the stable release?
It's not clear if you are talking about bug 439241 or something else. Management of
translations via Launchpad is currently not perfect: translations are synchronized
automatically for trunk (5.2/6.0), but must still be done manually for stable (5.0). In the past
we have had issues with the import/export process of Launchpad as well.
Starting with the next version the process should be much simpler for everyone, as Launchpad
will synchronize everything automatically in both directions, so no manual step will be neeed.
Please see this post trying to clarify the current translation process:
http:/
Note: normally Launchpad never forgets manual translations on Rosetta (at worst they are put
as suggestions), so even if they were never checked in as .po files in the code repository you
should be able to restore them. But until release 6.0 it might be a good idea to export a backup
of the translations you do on Rosetta in the stable/5.0 branches.
Recommendation: The OpenObject platform is a nice generic framework for business
applications. However, in order to gain its full potential the documentation of the API should
be improved.
Yes, documentation is quite important. The past months, we released several new
documentations: functional books, reviewed technical guide, a technical memento, etc. And
we will continue to invest on documentation.
Recently we have also automated the generation of the framework API documentation from
the docstrings in the Python code itself. So the documentation you see on
http:/
date and matches the API closely (still, it needs to be improved further, of course).
We also consider that having a good and continuously improving documentation is a
community process. Everyone is free to contribute to the documentation, the doc repository
which produces the doc.openerp.com website is public for every member of the community.
The latest contributions we made on the technical documentation:
• http:/
• http:/
• http:/
FUNCTIONALITY
Question: Will OpenERP s.a. develop a procedure so that the community can influence the
core functionality of OpenERP s.a.?
The procedure already exists, any member of the community can develop his own branch with
his own features and propose for merging. Merges are processed at least once a week.
For suggestions, you can write a bug or a blueprint.
Question: At the community days OpenERP s.a. said that required localizations will be
incorporated in the core. Does this mean, that the Dutch community can decide what are
necessary adaptations for the Dutch market and can develop software solutions accordingly,
upon which OpenERP s.a. incorporates this software in the core OpenERP distribution ?
What (and/or certify) if quality standards are fulfilled?
Yes, if you have dutch modules, you can submit them before May 1st and we will review and
integrate them in next release if they are good enough.
QUALITY
Question: Could OpenERP sa elaborate in more detail on the announces new quality and
testing processes ? What kind of testing is done and on which platforms ? Will the applied
test scripts & tools come available for the community / partners ?
We are working on several testing approaches:
• A continuous integration server that runs all tests at each commit: test.openobject.com
• A full set of scenario tests implemented in YAML:
http:/
12.html
• The firsts tests developped in the trunk are described here:
http:/
Question: Is there a central list of bugs that is easily accessible by everyone? Above I.T. has
found two bugs in the year end closing. These bugs will actually change the balance slightly
in a way that is not easily found. We've come to the conclusion that either no company closes
the year in OpenErp or there are a lot of broken administrations in OpenErp. We've submitted
the bug and patch, but nobody has looked at them. Are there any procedures to check
submitted bugs? The bug is here: https:/
The normal process is to report bugs on launchpad. We have a full time dedicated team that
fixes bugs reported on launchpad. Currently, they fix about 90% of the bugs reported. But
sometimes they do not notice that a bug is much more important than another (whishlists).
The openerp-drivers team in launchpad (which is composed of members of the community) is
in charge of pointing us which are the most important bugs so that we don't miss important
ones.
Specific bugs like this one most likely need to be discussed by experts on the matter, so
sometimes our teams ask the OpenERP expert teams to participate in the discussion around a
specific bug before accepting/implementing a solution.
Question: The website claims that the OpenERP code runs on python 2.4. This is no longer
true for the openerp-client that contains code that is specific for newer Python versions. What
kind of checks are executed to ensure that it runs on the supported platforms?
Every commit on OpenERP is tested by the continuous integration framework on
test.openobject.com which works on Python 2.5 (2.5.2 to be precise), which is the official
version as of OpenERP 5.2/6.0.
If you notice a commit in OpenERP 5.0 that does not work with Python 2.4, please report it as
a bug, as we do not yet have separate continuous integration servers.
Question: OpenErp claims to support asset management. However, this module is broken.
Claiming functionality while it doesn't work harms the reputation of OpenERP. For this
reason it is very important that functionality communicated by OpenERP is working. Is
OpenERP aware of any other communicated functionality that is not working.
We do not claim to have a fully featured asset management module. This module
(http:/
We try to keep a clear distinction on what's maintained and fully working and what's not. It's
why we launched the quality certification on modules.
Question: Could OpenERP elaborate in more detail on the plans to improve the quantity and
quality of the documentation? When possible it would be nice when the English
documentation could be reviewed by an English native speakers.
We think it's the role of the community to improve the documentation. We do our best to
improve the documentation at each new version. But we strongly request the community to
help us in this very big task:
http:/
http:/
The OpenERP documentation project on Launchpad is open to everyone, you don't special
access to directly contribute or correct it directly.
We are also working on a way to publish the translated versions of the documentation on
doc.openerp.com.
Recommendation: Ensure that reported bugs and repair patches are included in the new
official releases.
That's what we do: 90% of the bug reported on launchpad are fixed. We clearly assign bugs to
releases, for each new release.
Recommendation: The mismatch between the “promised” and “actual” content and timing of
new releases has caused problems in the past. The Dutch community recommends OpenERP
s.a. to be realistic in announcing forthcoming functionality. Announcements of things that
will not be realized has a negative impact on the perception of OpenERP in the market /
community.
SCALABILITY
Question: The core of OpenERP is single thread so you can not benefit from multi-core
processors. Are there any plans to make OpenERP multi thread ?
OpenERP is already multi-threaded, you are mistaken. You are maybe referring to the Python
GIL.
The GIL as no impact on Open ERP as PostgreSQL and C libraries (cPickle, etree) consume
most of the time. The GIL only has significant impact when the bottleneck is python, which is
not the case in Open ERP. Moreover, it seems that the GIL is faster (because it simplifies) in
multi-threaded programs that use a lot of C libraries or in/out calls. (which is the case of Open
ERP),
Here is a discussion about this on the forum, read the posts of Fabien:
http:/
CONTRIBUTION DUTCH COMMUNITY:
Question: Has OpenERP sa any thoughts / ideas / suggestions how the Dutch community
could contribute to the OpenERP developments in the most efficient and constructive way?
The answer is the same as for the everyone in the community:
• Develop modules and push them on the OpenERP addons-community branch on
Launchpad. This is the branch we look into for finding new modules to be integrated
in new versions.
• If you have a clean localisation for Dutch accounting, send your modules to
lpi@openerp.com, before the 1st of may. We will review and apply our quality
certification process to integrate it in the core in next version.
• Translate the documentation, we need this for the book mainly:
http:/
• Contribute in the normal way: translate on Launchpad, report bugs and fixes, discuss
on the forum and mailing-lists, ...
Last updated 648 days ago by Anne Sedee (Therp)
