Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] Licensing considerations for EE4J implementation projects



On Wed, Jan 24, 2018 at 5:55 PM, John D. Ament <john.d.ament@xxxxxxxxx> wrote:

John,

My response is addressed to Steve's remark. Nevertheless...

Looking at the cloud foundry IP Policy, I believe you should ask them these questions rather than the EE4J community.

The problem is not with the Cloud Foundry IP. The issue is with the same-license requirement for modifications to the EE4J code licensed under EPLv2.0. One would face a similar problem wherever there is a need to distribute the modified EPL code along with their own code under a different license.

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.

Read Section II.B - "The Apache License 2.0 must be used for any new Projects." This requirement does not specify whether the new project is entirely your own IP or "New Projects Derived from Existing Third Party Materials". So it is understood that it covers both.

-Mrinal

 

John


On 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:
Mike,

Thanks for clarifying this. But could you please explain :

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?

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?

3) 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?

However, I appreciate the need to prevent a proprietary fork.

Hope to hear your opinions on each of the specific points.

Regards,
Mrinal


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



Back to the top