| Re: [ee4j-community] Licensing considerations for EE4J implementation projects |
Looking at the cloud foundry IP Policy, I believe you should ask them these questions rather than the EE4J community.
It does seem they make it clear that there's two parts to this - license of the project and license of the third party dependencies.
JohnOn Wed, Jan 24, 2018 at 5:01 AM Mrinal Kanti <mrinal.kanti@xxxxxxxxx> wrote:While I await a response for the 3 questions that I asked in my previous post, I would also like to add to my response to Steve's question "how licensing EE4J under the EPLv2 takes options off the table for an ISV targeting Cloud Foundry?"
Due to the same license requirement for modifications made to EE4J code licensed under EPLv2.0, an ISV would have to split their Product into two separate package distributions:
1) Their own original work licensed under Apache 2.0 license
2) The modified EE4J code licensed under EPLv2.0 License (irrespective of how small it is)
Cloud Foundry may not accept (2) as per their IP policy mentioned earlier. Since (1) above depends on the availability of (2), then the ISV would not be able to distribute their Product at Cloud Foundry if it contains/depends on modified EE4J code.
Am I missing something here?-Mrinal______________________________On Wed, Jan 24, 2018 at 2:21 AM, Mrinal Kanti <mrinal.kanti@xxxxxxxxx> wrote:Mrinal3) Having eclipse plugins under Apache 2.0 license is one thing, but do we have any examples where someone has modified an EPL licensed plugin and released the derivative work under Apache 2 license? Even a scenario where someone has modified Eclipse platform code (which is EPLv2) and then released an RCP application under Apache-2?2) I see your point that "the scope of the EPL-2.0 copyleft is restricted to the source code that is being modified", but could you please confirm that the statement remains valid even in the scenario when the entire Product A constitutes a Derivative Work?1) What about "on-premise" deployment of the same Product A on customer's cloud premises? Does it not constitute a distribution in that scenario?Mike,Thanks for clarifying this. But could you please explain :However, I appreciate the need to prevent a proprietary fork.Hope to hear your opinions on each of the specific points.Regards,On Wed, Jan 24, 2018 at 1:17 AM, Mike Milinkovich <mike.milinkovich@eclipse-foundation.org > wrote:______________________________On 2018-01-23 2:10 PM, Mrinal Kanti wrote:
My understanding is that if an ISV makes changes to the EE4J implementation projects for building, say, Product A, under EPLv2 to make them "cloud foundry ready" then they would have to ensure that Product A does not constitute a Derivative Work. Because if it does, then I understand from the reference cited below that the Product A would have to be released under EPLv2 license as well. This can further have a transitive impact on other downstream products which are indeed derivative works of Product A. In this scenario, I believe, usage of EPLv2 eliminated the option of releasing Product A (and possibly, other downstream products) to be released under Apache-2 license.No. That is incorrect. You seem to have a fundamental misunderstanding of how the EPL works.
First off, the copyleft provisions of the EPL-2.0 only apply if the modifications are distributed. In the cloud scenario where they are hosted on servers your company owns or rents, those provisions don't apply.
Secondly, the scope of the EPL-2.0 copyleft is restricted to the source code that is being modified. If Product A is built on top of the EPL-2.0-licensed software platform it can use any license it wants, including Apache. This "building on top" scenario is by far the most common one. The venerable Eclipse IDE ecosystem has lots of plug-ins under the Apache license, for example. The only source code you would need to make available under the EPL-2.0 would be changes to the existing EPL-2.0-licensed files which you then distributed outside of your organization. This ensures that your product doesn't ship a proprietary fork of the code that the community has provided you. But to reiterate: you can choose whatever license you want for your product code written on top of the EE4J platform. Furthermore, the EPL allows you to re-license the binaries and distribute the binaries under any license (including proprietary) that conforms with the requirements of section 3.1(b) of the EPL.
Copyleft is a feature not a bug. The EPL-2.0 was constructed to be the most commercially-friendly copyleft license available.
_________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community