MicroProfile/3rdPartyDependencyProcess

New process on 3rd Party process effective from Oct 2019

Effective from October 2019, Eclipse IP process on 3rd part content has been updated. More details can be found from the blog from Wayne Beaton. I have summarised what meant for us as follows.

Dev stage

During the development, we are push commits that reference thir party content without first checking with the IP Team. For any new third party dependencies, check their license against the approved licencses from Eclipse Foundation. If it is on the list, the library is likely safe to use.

Release stage

1. No need to engage with Eclipse IP team via CQ. No need to create any piggyback CQs.

2. Check the third party dependency against the ClearlyDefined database.

3. If exists, no op. Otherwise, create CQs for the third party libararies not already avaiable on ClearlyDefined.

Helpful command for determining dependencies

Use Maven to help determine the list of your dependencies. You can then compare these to what's already been vetted by Eclipse and/or previous MicroProfile releases. The following is an example of comparing the list of dependencies for a given Component at the previous 1.0 release (assuming it's clean) and the latest 2.0 release... If you are performing a 1.0 release, then you'll have to evaluate each of your top-level dependencies as potential Contribution Questionnaires.

Note: We are only concerned with the top-level dependencies used by each Component (the dependencies that start with "+-" or the final "\-" in the maven dependency tree). The sub-branches of the dependency tree do not have to be processed, since they are assumed to be okay due to the top-level dependency clearance.

git clone <MP Component>
cd <MP Component>
git checkout 1.0
mvn dependency:tree -Prelease | egrep -oh '^\[INFO\] (\+|\\)\-.*(:compile|:provided)$' > dep.1.0
git checkout 2.0
mvn dependency:tree -Prelease | egrep -oh '^\[INFO\] (\+|\\)\-.*(:compile|:provided)$' > dep.2.0
diff dep.1.0 dep.2.0

Old Process: Contribution Questionnaires (CQ)

All software contributed to or used by an Eclipse project needs to be properly vetted by the Eclipse Intellectual Property Office (IPO). This vetting is initiated by a Contribution Questionnaire. Once a Contribution Questionnaire is created, it is turned into an IPZilla bug tracker. All interaction with the IPO is then done via the associated bug tracker.

As an example, our Initial Contribution to Eclipse was tracked via this CQ.

Source Originality

Whenever a Release is created for the overall MicroProfile project, an IP review is required. This process should cover any updates required for our Initial Contribution vetting. That is, as a component is developed, all of us need to keep an eye on the source that is being integrated into our product to ensure we understand it's origin and license.

3rd Party Open Source

Many of the open-source packages that MicroProfile utilizes are already vetted and approved by Eclipse (ie. JSR APIs, Apache Commons libraries, etc). In this case, we can piggy-back on top of the work that has already been done. But, a CQ is still required. When creating a CQ for 3rd Party content, you enter the name and version of the software in use. Most times, the software is registered under the Maven artifactId (ie. commons-io or commons-lang3). Once you start typing, Eclipse will be searching for a match. Be creative. If you can't find a match, then you'll have to go through the full CQ process. A piggy-back CQ is very easy to process.

Build and Test Dependencies

All of the build and test dependencies that we use is a special case for the 3rd Party open source. Instead of creating individual CQs for every piece of build and test software (ie. arquillian, maven, hamcrest, etc), we can group the request into a single CQ. This link has a good description of this process.

Since the MicroProfile project is developing individual components (config, fault tolerance, metrics, etc), the initial set of Build and Test CQs were created on a per-component basis. Here is an example Build and Test CQ.

Type A vs Type B Due Diligence

This CQ Section of our process is a synopsis of a much longer discussion that happened in our Google group and the associated CQs. We learned a great deal during this initial IP vetting process. One of the key items is the use of Type A vs Type B Due Diligence. For our initial efforts, Type A (licensing review) is much easier to process, especially for our preliminary component releases. Type B is a much more thorough review of the material. Once we get through these initial reviews with Type A, we may change to Type B. But, for now, Type A reviews are sufficient.

Spreadsheet

To help with keeping track of our 3rd Party Dependency clearances, I have created this Google Sheet (spreadsheet). Please reference this spreadsheet as you are creating or updating your pom.xml files with your component's dependencies. It is currently sorted on the name of the 3rd Party Dependency, which is normally based on the Maven artifactId. We will need to keep this up-to-date for the overall MicroProfile project. (Let Kevin know if you don't have access to this spreadsheet.)

A flowchart, if you are interested...

Eclipse also provides this flowchart as a guide to help find your way through their IP process... It's not for the faint of heart, but it did help with deciphering some of the ins and outs of the process.