Skip to first unread message
Mrinal Kanti
Jan 23, 2018, 4:06:50 AM1/23/18
to Eclipse MicroProfile
I have initiated a discussion (https://dev.eclipse.org/mhonarc/lists/ee4j-community/msg00976.html) at the EE4J discussion group to discuss any impact of the EPL licensing for EE4J implementation projects on the larger Java EE community keeping MP also in perspective. I understand from various comments and other sources that MP may face incompatibility issues with EPLv2 (in its current form). I am starting this discussion here to discuss potential MP specific issues with regards to EPL licensing of EE4J. If those issues are generic enough and applicable to the larger EE4J or even the yet larger Eclipse ecosystem please feel free to articulate that accordingly and raise it there.
The intent here is to identify, validate and address any potential license compatibility issues (however speculative they may seem) early on so that any potential license compatibility risk can be identified and addressed in a timely manner.
-Mrinal
DISCLOSURE: I am not aware if there are any policies that prevents discussing/speculating licensing issues in public forums. If there are any such policies in enforcement then please advise accordingly.
The intent here is to identify, validate and address any potential license compatibility issues (however speculative they may seem) early on so that any potential license compatibility risk can be identified and addressed in a timely manner.
-Mrinal
DISCLOSURE: I am not aware if there are any policies that prevents discussing/speculating licensing issues in public forums. If there are any such policies in enforcement then please advise accordingly.
John D. Ament
Jan 23, 2018, 7:46:55 AM1/23/18
to Eclipse MicroProfile
Mrinai,
Are you referring to my comment about relicensing my IP under the EPL? Or something else?
John
Mrinal Kanti
Jan 23, 2018, 9:50:02 AM1/23/18
to microp...@googlegroups.com
Sorry, I did not follow your question. Which IP are you referring to?
--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/zrYweCB1X6Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/d1a69e62-43b9-4d93-a895-11270721b42c%40googlegroups.com.
Kevin Sutter
Feb 1, 2018, 4:15:17 AM2/1/18
to Eclipse MicroProfile
Mrinal,
MicroProfile is Apache v2 licensed. The top-level EE4J project has chosen the EPL v2 license. These are not conflicting licenses. That is, if MP would consider integrating with the EE4J top-level project (instead of the current Technology project), then moving from the current Apache v2 license would not be a requirement. We could stay with the Apache license.
-- Kevin
MicroProfile is Apache v2 licensed. The top-level EE4J project has chosen the EPL v2 license. These are not conflicting licenses. That is, if MP would consider integrating with the EE4J top-level project (instead of the current Technology project), then moving from the current Apache v2 license would not be a requirement. We could stay with the Apache license.
-- Kevin
Mrinal Kanti
Feb 1, 2018, 7:28:24 AM2/1/18
to Eclipse MicroProfile
Kevin,
That is perfectly correct as long as MP doesn't modify any code/APIs of EE4J. If MP is only adding on top of EE4J APIs and implementations via extensions or modules then this is a not an issue at all. Again, if we are confident that MP, even in future, shall never need to modify any EPLv2 licensed code then I do not see any concerns. My original concern was with respect to modifications to EE4J code. Say, if any proposed MP feature requires any modifications to EE4J code then how do you plan on packaging and distributing the modifications under Apache 2 license?
Sure, we can independently package and distribute only the relevant modifications under EPLv2 but then those modifications would have to be distributed as a separate package. I anticipate that this may create issue while distributing it through Cloud Foundry which apparently accepts Apache 2 licensed code only. Refer my scenario at: https://dev.eclipse.org/mhonarc/lists/ee4j-community/msg01020.html
Even I prefer that MP should remain under Apache 2 license. I am concerned that if EE4J implementations remain under EPLv2 then this would create packaging and distribution issues for MP and other developers if they need to make any modifications to the EE4J implementations, say, in order to make them "cloud ready". In that case, it would be difficult for independent developers such as ISVs to use the modified EE4J code if they plan on building and distributing MP based services on Cloud Foundry.
If the MP team is confident that they would never modify EE4J code (which is under EPLv2) in future then I do not see any issues with the current licensing model at all.
Please feel free to correct me.
-Mrinal
That is perfectly correct as long as MP doesn't modify any code/APIs of EE4J. If MP is only adding on top of EE4J APIs and implementations via extensions or modules then this is a not an issue at all. Again, if we are confident that MP, even in future, shall never need to modify any EPLv2 licensed code then I do not see any concerns. My original concern was with respect to modifications to EE4J code. Say, if any proposed MP feature requires any modifications to EE4J code then how do you plan on packaging and distributing the modifications under Apache 2 license?
Sure, we can independently package and distribute only the relevant modifications under EPLv2 but then those modifications would have to be distributed as a separate package. I anticipate that this may create issue while distributing it through Cloud Foundry which apparently accepts Apache 2 licensed code only. Refer my scenario at: https://dev.eclipse.org/mhonarc/lists/ee4j-community/msg01020.html
Even I prefer that MP should remain under Apache 2 license. I am concerned that if EE4J implementations remain under EPLv2 then this would create packaging and distribution issues for MP and other developers if they need to make any modifications to the EE4J implementations, say, in order to make them "cloud ready". In that case, it would be difficult for independent developers such as ISVs to use the modified EE4J code if they plan on building and distributing MP based services on Cloud Foundry.
If the MP team is confident that they would never modify EE4J code (which is under EPLv2) in future then I do not see any issues with the current licensing model at all.
Please feel free to correct me.
-Mrinal
On Thursday, February 1, 2018 at 2:45:17 PM UTC+5:30, Kevin Sutter wrote:
Mrinal,
MicroProfile is Apache v2 licensed. The top-level EE4J project has chosen the EPL v2 license. These are not conflicting licenses. That is, if MP would consider integrating with the EE4J top-level project (instead of the current Technology project), then moving from the current Apache v2 license would not be a requirement. We could stay with the Apache license.
-- Kevin
On Tuesday, January 23, 2018 at 2:50:02 PM UTC, Mrinal Kanti wrote:
Sorry, I did not follow your question. Which IP are you referring to?
On Tue, Jan 23, 2018 at 6:16 PM, John D. Ament <john.d...@gmail.com> wrote:
Mrinai,Are you referring to my comment about relicensing my IP under the EPL? Or something else?John
On Tuesday, January 23, 2018 at 4:06:50 AM UTC-5, Mrinal Kanti wrote:I have initiated a discussion (https://dev.eclipse.org/mhonarc/lists/ee4j-community/msg00976.html) at the EE4J discussion group to discuss any impact of the EPL licensing for EE4J implementation projects on the larger Java EE community keeping MP also in perspective. I understand from various comments and other sources that MP may face incompatibility issues with EPLv2 (in its current form). I am starting this discussion here to discuss potential MP specific issues with regards to EPL licensing of EE4J. If those issues are generic enough and applicable to the larger EE4J or even the yet larger Eclipse ecosystem please feel free to articulate that accordingly and raise it there.
The intent here is to identify, validate and address any potential license compatibility issues (however speculative they may seem) early on so that any potential license compatibility risk can be identified and addressed in a timely manner.
-Mrinal
DISCLOSURE: I am not aware if there are any policies that prevents discussing/speculating licensing issues in public forums. If there are any such policies in enforcement then please advise accordingly.
--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/zrYweCB1X6Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages