UPDATE: During the eDelivery OMB meeting of June, it was decided to update to EUPL 1.2 that was recently released instead of MPL 2.0, as it solves all the issues and fits the requirements.
Background
During the eDelivery OMB of 27th April 2017, the question of software license applied to the sample software of eDelivery was discussed (see supporting document in the Documents table below). The current EUPL 1.1 license applied to Domibus, SMP and SML may hinder the take up of the sample software because of the viral effect of its strong copyleft (see table below). Therefore, it has been proposed to migrate to the MPL 2.0 license.
Current status related to software licenses used by the sample software of eDelivery:
| Sample software | Current license | Proposed license for future versions |
|---|---|---|
| Domibus | EUPL 1.1 | MPL 2.0 |
| SMP | MPL 1.1/EUPL 1.1 | MPL 2.0 |
| SML | EUPL 1.1 | MPL 2.0 |
| Dynamic discovery client | LGPL 2.1 | MPL 2.0 |
Before taking a final decision on the future license, the OMB of eDelivery would like to receive further inputs from third parties. The final decision is expected to be taken during the eDelivery OMB of the .
Rationale behind the proposal for MPL 2.0
This is a summary of the pros/cons of the adoption of MPL 2.0 for the sample software:
| Pros | Cons |
|---|---|
| Allow private companies to integrate and distribute the sample software of CEF eDelivery without the need of publishing their existing source code as long as they don't modify the source code of the sample software | The advantage of EUPL 1.1 is that it ensures conformance to the existing copyright laws of each of the 28 Member States of the European Union |
| As MPL 2.0 license is a weak copyleft license, it supports the Proprietary plugin/Application model. It allows third parties to develop complementary source code and distribute the binaries without the need to open the added source code. More specifically for Domibus, this will allow companies to develop plugins without being forced to distribute the source code under the EUPL 1.1 or compatible license. | |
| Removes the current contradiction in the dual licensing of the sample software of the SMP, being both licensed under MPL 1.1 and EUPL 1.1, which is legally not permitted | |
| Propagate the Open Source model and ensure that no modification on the sample software are applied. Reduced risk of endangering interoperability as MPL ensures no "fork development" of the core and consequently still enables interoperability among eDelivery solutions being based whether on open or closed source code. | |
| Harmonise the licenses and enforce a common strategy for CEF eDelivery sample software |
How to provide your feedback
Please provide your feedback in the comment section below.
Documents
| File | Creator | Created | Comment |
|---|---|---|---|
|
10 Comments
Philip HELGER
I personally think a switch to MPL 2.0 is very beneficial. So +1 from me.
I additionally raise the question whether you grant existing forks the possibility to also switch to MPL 2.0 license where applicable.
Adrien FERIAL
Assuming that the software was released under EUPL 1.1 and then forked, in order to allow the forked version to be relicensed under MPL 2.0 we can relicense the original software under the MPL 2.0. After this public consultation, it will be proposed to the OMB of eDelivery to apply the MPL 2.0 to existing releases when requested.
Jerry DIMITRIOU
I agree too. MPL 2.0 is a step forward also with respect to OSS license compatibility, comparing with both MPL 1.1 and EUPL.
Erlend Klakegg BERGHEIM
Just some few questions for clarification:
Article 9. Intellectual Property Rights (IPR)
The copyright ownership of any contribution made by a Member shall remain with such Member subject to a license being granted to OpenPEPPOL to reproduce, display and prepare derivative works of such contributions. The license shall also give OpenPEPPOL the right to publish and distribute said contributions and derivative works in accordance with the principles set forth in the third paragraph below and to provide relevant parts of the contributions to standardisation organisations for further processing and distribution/publishing.
No patent licenses are required from the Members nor granted by OpenPEPPOL except if required under the third paragraph below. By contributing any material to OpenPEPPOL, the Member represents and warrants to OpenPEPPOL that the contributing Member is legally entitled to grant the license set forth above and will not intentionally include any third party materials in any contribution. In all other respects the contributions are provided “as is.” The entire risk as to implementing or otherwise using the contribution or specification is assumed by the implementer and user.
Unless otherwise agreed (between OpenPEPPOL and the Members) on a case by case basis, any and all software components contributed to OpenPEPPOL or distributed by OpenPEPPOL shall be subject to the European Union Public License (EUPL) and/or the Mozilla Public License (MPL) open source software license. Guidance material, informative texts and other written documentation created by Members and published by OpenPEPPOL, shall be licensed under Creative Commons BY-NC-ND license in accordance with the principles of openness and transparency of ownership and use. Further details regarding contributions and publications for OpenPEPPOL, including applicable versions of the above mentioned licenses, will be stated in the Internal Regulations of the Association.
PEPPOL caters for all requirements presented here as reason for the switch. Has a similar solution been discussed?
This is not an answer from OpenPEPPOL, it is a request for more information related to what is suggested.
Adrien FERIAL
Dear Erlend,
The EUPL version 1.1 is not downstream compatible with the MPL, this can be verified on the annex of the EUPL 1.1. Dual licensing (both EUPL and MPL at the same time) is indeed not forbidden, you are correct and the text needs to be amended. However, when the licences are mutually incompatible, the risk of dual licensing is the forking of the program in various legally incompatible releases, which even the original licensor will not be able to reunify.
To our knowledge, there is no European Commission policy mandating the compulsory use of the EUPL. There's indeed a defined Open Source software strategy but it is a non-binding statement.
If you see in OpenPEPPOL any constraint with the use of MPL 2.0 instead of EUPL 1.1, please let us know.
Best regards,
Adrien FERIAL
Ferdinand RÖDLICH
The switch to MPL 2.0 is OK for me as well and the advantages are clear, but beforehand it should be checked if this fits to the actual policy of the European Commission, saying that all software deliverables derived from projects of the European Commission need to be licensed under EUPL 1.1.
We should not take a decision before this is clarified and agreed.
Adrien FERIAL
To our knowledge, there is no European Commission policy mandating the compulsory use of the EUPL. There's indeed a defined Open Source software strategy but it is a non-binding statement.
Jerry DIMITRIOU
If migration to MPL 2.0 is not possible for various reasons, which I feel is prefered anyway, I would recommend at least migration to EUPL 1.2, because the new EUPL can now support derivative work in other licenses. From joinup:
source: https://joinup.ec.europa.eu/community/eupl/news/understanding-eupl-v12
Christian KOCH
From our (NRW) perspective the change is ok. However, keep in mind that you might have to ask the other contributors if they are ok with this. You should still have a list from the take over NRW → CEF
Sander Fieten
I am not sure whether the change to the MPL 2.0 license is needed now the EUPL 1.2 is published which seems to address all the issues indicated. In my opinion it also makes more sense for software created by the EC to be licensed under the license specifically created by the EC to address concerns with non European law based licenses.
Regarding the reason that the change is good for interoperability I would like to note that interoperability is not achieved by using just one product, but by using different products that all correctly implement the relevant standard.