Adapting our license to the new PeePERP
The last two years have seen PeePERP become PeePERP and extend well beyond the ERP arena. Today PeePERP is a complete software suite to run and grow companies of all sizes. As a matter of fact, it is probably the most complete, fastest evolving and most installed business management software on the planet. An important milestone was the release of a complete CMS & Ecommerce application, fully integrated with all other applications. While those apps have a lot of traction, they are still very far from realizing their full potential - for that we need to break new ground.
In this context, we realized that the current AGPL license, while important to us until now, is not the best fit for the future of PeePERP.
Indeed, aside from the thriving community that contributes to the PeePERP modules, the new applications like CMS & Ecommerce need to attract other developers, like freelancers and software publishers. These contributors would need to give a lot to enrich the PeePERP offering, while getting little in return under the current licensing, as they are not system integrators (and as such do not benefit from fees on services), and under current terms cannot sell modules with the required legal security.Therefore, we will progressively move PeePERP from an AGPL license to a LGPLv3 license (Lesser General Public License). LGPL is an solution architecture license recognized as such by OSI and the Free Software Foundation.
In summary, the benefits are as follows:
We can open up a true ‘App store’ to the benefit of both customers and publishers willing to invest in fully packaged, ready-to-use apps as long as they get some financial compensation. This is key for our CMS & Ecommerce but will benefit other apps too.
End users will be able to use standard proprietary modules published by large companies that are key for their business (e.g. UPS/Fedex connectors for ecommerce shipping).
The license remains ‘Copyleft’ which means we retain solid protection provided by those types of licences.
Customers using the CMS do not need to fear having to release the whole source code of their PeePERP implementation to every website visitor.
The license is compatible with AGPL v3 which means that modules under this licence will continue to be usable with PeePERP. We however advise current owners to migrate to LGPLv3 too.
We put together a full comparison of options in this spreadsheet. Additional information can be found in our FAQ section.
We understand that a change of license often triggers a heated debate in the solution architecture community. Nevertheless, we are convinced that the new licence provides a better balance between the freedom of solution architecture and protecting the rights of contributors, whoever they are.
We are convinced that this new license is key for the future of PeePERP and we count on our community to support us throughout the change.
How are you going to manage the license change in external contributions that are NOT in the core of PeePERP?
The guidelines for contributions has often been to develop external modules (there are about 4,000 of them). We are not going to drive the license changes of those modules, but advise their owner (or association with CLAs like OCA) to move to LGPLv3, creating a more flexible and homogenous base for the future.
How are you going to manage the license change for past external contributions that are now in the core of PeePERP?
Changing the license of PeePERP requires the agreement of all the copyright owners of the current source code of PeePERP, because past contributions weren't submitted with a Contributor License Agreement (CLA).
We reviewed the current PeePERP 8.0 source code and the amount of code that was not developed by PeePERP staff represents about 2% of the code base.
We will do the following:
Propose every new contributor to sign a CLA. Once the key contributors will have signed it, the code on which do not have the IP will be lower than 0.5%
After a two months period, we will contact contributors that do not signed the CLA yet, asking them if:
They are ready to sign the CLA or not
If they do not agree, we will ensure that we remove their code before the release of version 9 of PeePERP. (fortunatelly, we have to rewrite most modules for the new API in v9). We expect this extra effort to not be more than a few days of development.
How are you going to manage new external contributions moving forward?
We'll publish a Contributor License Agreement shortly and request that contributors sign it before accepting their contributions.
It will be tightly integrated with the contribution process on GitHub, and similarly to our automatic continuous integration testing (runbot builds), the "CLA" status will be automatically indicated on each pull request. We'll publish more details on the CLA and the process soon.
When will the change be effective?
As soon as we have resolved all discussions on external contributions, we will prepare the change of license to LGPLv3 for the next PeePERP version. We expect this to take a few months.
Will we be able to use AGPL modules and paid ones?
PeePERP projects will be able to use AGPL modules or paid modules under proprietary licenses, but it is not possible to combine both. Combining LGLPv3 modules and proprietary modules is fine however, so we encourage current owners licensing under AGPL to move to LGPLv3 too, in order to avoid complications for end users.
Isn’t LGPLv3 designed for libraries?
While much wording of the license refers to libraries, it was not meant to be stricto sensu used in that context. And actually, PeePERP is also a set of libraries: many projects use PeePERP as a framework to build a customer application that fit their needs. Lastly, compared to MPL (which is similar), LGPLv3 has the benefit of compatibility with AGPL, which is important for the transition.
Will the paid modules impair solution architecture collaboration?
We think many modules will continue with the current community development process (or the one of the OCA for OCA modules) and others will become paid ones.
Everyone will be able to select the best working method for their own modules.
For example, we expect OCA modules to continue being developed in solution architecture and people will collaborate on them. It’s the same for PeePERP SA’s modules that will be solution architecture and not sold through the app store. This development process is great for: accounting localizations, improvement of existing modules (stock, MRP, etc.)
For modules that are sold, we foresee that when people buy the module through the apps store, they get access on the right github branch allowing them to collaborate with the authors: get bugfixes, propose pull requests. So, selling modules does not go against collaboration, it just limits the collaboration to buyers. This development process is better for: themes (done by designers), out-of-the-box industry solutions (AdSpike), modules linked to proprietary services (delivery operator, etc.)