MicroProfile/3rdPartyDependencyProcess

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.