Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Revising the Eclipse IP Policy: Third Party Content

Hi Wayne,

This certainly looks like it is moving in the right direction! The npm dependency trees are certainly large and complex and having tooling and simpler flows to maintain/check IP compatibility is great. 

In the Java (Eclipse plug-ins) space there has always been quite a lot of resistance in individual projects about adding new dependencies, both from the IP and the technical side. Reducing the IP barriers is good. On the technical side the PMCs have always voted on third party dependency inclusion. I don't know how important that part of the flow is going forward. Do the PMCs regularly (ever) reject dependencies? I assume this is most concerning in the projects that come together under the release train.

I am looking forward to getting access to the tooling too. Does npm support mean yarn support too, or in this context does that mean some more work too.

Unfortunately I will not be able to make it to EclipseCon this year to discuss in person, so I look forward to the discussions continuing once everyone returns.


Jonah Graham
Kichwa Coders

On Thu, 10 Oct 2019 at 12:56, Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Hey folks...

This is not my best work, but I figured getting the information out was better than another few days of wordsmithing...

By way of specific example, I ran the prototype tool discussed in this post on the Eclipse Sprotty code. When I naively ran "npm install" on sprotty, it pulled in 680 different NPM libraries (Sprotty has a yarn.lock file that narrows this list considerable, but I was going for it). Of those 680 dependencies, the tool identified six that required further scrutiny from the IP Team (which I submitted as a single CQ). We resolved those six, fed the results back into the system, and when we now re-run the prototype tool, it comes back with 100% pass. With the IP Policy changes that we're proposing in place, Sprotty is basically done after creating a single CQ (FWIW, we did also independently validate the intellectual property via the process that we currently have in place to implement the IP Policy as it exists today).

The intention is that CQs will become the manner in which project teams engage with the IP Team only when they encounter problematic content.

The prototype tool is something that I hacked together in PHP that only runs on our system. I'm in the process of migrating it to a Java library that can operate independently. My hope is that I'll have it far enough along to contribute it to the Eclipse Dash project and solicit your input before I get on the plane to attend EclipseCon.

Here are some thoughts to seed future discussion...

A means of capturing dependencies for various technologies. I've got regular Maven builds and NPM sorted out. I'm not quite sure what to do with Tycho builds since the Maven Dependency plugin doesn't seem to consistently work on those builds (I'm not actually sure if this is a real problem as the dependencies that are hard to determine tend to come from Eclipse p2 repositories which, I think, we can make a reasonable claim are likely pretty clean from an IP POV; this requires further investigation). For some technologies (e.g., C make files, I think that we're just going to have to have project teams manually assemble and maintain a list of dependencies.

The prototype tool just generates a list based on the input. We can make it do useful things like create CQs based on problematic content that it identifies. There's an opportunity to create a Maven plugin that integrates this into a build.

You'll notice that we're working with the ClearlyDefined project. I'll discuss this relationship and how we're leveraging (and adding to) their work as part of this.

Eliminating and replacing IPzilla is on our to-do list for 2020.

We have a BoF scheduled to discuss changes to the IP Policy on Tuesday night at EclipseCon. This topic will otherwise be my main focus during the conference, so please feel free to connect with me outside of scheduled sessions.

Comments welcome.




Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

_______________________________________________ mailing list

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

Back to the top