| Re: [ee4j-community] Licensing considerations for EE4J implementation projects |
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