See all blog posts
To continue Open Liberty’s contributions as a compatible implementation for the MicroProfile and Jakarta EE specifications, we are strongly considering relicensing Open Liberty under the EPLv2 public license. We hope to make this change early in 2023 and are seeking feedback from the community on this decision now. We want to give the community an opportunity to provide feedback on this process. Earlier this week, I created a GitHub issue to track making this change and we invite you to provide feedback in comments in that issue. The intent of this blog post is to both solicit feedback and to explain the reason we are considering this change.
Open Liberty and the EPL
When we created Open Liberty in 2017, we looked at a number of open source licenses that existed at the time and chose to use the Eclipse Public License (EPL). Shortly before we released Open Liberty, the Eclipse Foundation released the Eclipse Public License v2 (EPLv2). At the time, we discussed changing the license, but decided against it because it would delay releasing Open Liberty without much benefit.
Open Liberty as a compatible implementation in the spec finalization process
Moving on 5 years, many things have changed, including the move of the MicroProfile and Java EE (now Jakarta EE) standards to Eclipse under the Eclipse Foundation Specification Process (EFSP). The EFSP says that to release a specification (such as a MicroProfile or Jakarta EE specification) there must be an implementation of that specification that is licensed under either the EPLv2, Eclipse Distribution License, or Apache License 2. Open Liberty has been used as a compatible implementation for finalizing MicroProfile and Jakarta EE specifications but Open Liberty is distributed under none of these licenses.
This was an oversight by all involved, but it means we have a choice: we either relicense Open Liberty to a license that the EFSP allows for spec finalization, or we don’t use Open Liberty to finalize specifications. Providing compatible implementations for use in spec finalization is an important part of defining a specification and I have been proud that Open Liberty has been able to take this role in the past and I would like to continue to do this into the future.
Implications of changing from EPLv1 to EPLv2
I’m not an expert on licenses, but my understanding is that the changes between v1 and v2 clarify the language of the original license rather than granting any additional rights over the source code. There are updates for secondary licenses, but Open Liberty is not using those capabilities of the license so it is not relevant to Open Liberty. The EPLv1 license has language to simplify relicensing to new versions of the license.
We welcome feedback on this proposed relicensing
The result is that we want to relicense Open Liberty from EPLv1 to EPLv2 early in 2023. Although we believe that relicensing from EPLv1 to EPLv2 is uncontroversial and relatively straightforward, we want to solicit feedback from the community ahead of making any change. If you have feedback on this change, please let us know in this GitHub issue before the end of 2022. Some of the changes for relicensing are less disruptive when the codebase is subject to less change, which is the case over the year-end break, so we hope to make a final decision early in the new year.
