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.
![]()
_______________________________________________