Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse.org-architecture-council] Revising the Eclipse IP Policy: Third Party Content

Hey folks...

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

https://waynebeaton.wordpress.com/2019/10/09/revising-the-eclipse-ip-policy-third-party-content/

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.

Thanks,

Wayne

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.



Back to the top