Revise the content regarding Third Party Content

Submitted by Wayne Beaton @wbeaton

Link to original bug (#525252)

Description

From the incubation mailing list:

in the IoT PMC we often review CQs by projects for components which the project relies on during runtime (not optionally but as a full pre-req). Some of these components themselves rely on many other components. We are often asked, whether the project needs to create CQs for all of these transitive dependencies as well (given that they are not optional but required during runtime). The project handbook [1] states that "All third-party libraries required by project code will have to be checked and approved by the IP Team."

Following is a list of cases which constitute a "library required by the project". That list is described as "non-exhaustive" and in fact does not explicitly mention transitive dependencies. My understanding is that transitive deps definitely need to be checked/approved, but I would like to get some feedback e.g. frmo Wayne whether this is actually the case.

The use of "non-exhaustive" is intended to refer to the list of examples. Let's check the language to ensure that this intended usage is clear. We should make it clear that the policy applies to the transitive closure of all dependencies.

There may be some useful words in my response:

-- All content must be taken through the Eclipse IP Due Diligence Process. This includes all dependencies, dependencies of dependencies, etc. [recursive].

FWIW, the operating system and virtual machine are technically dependencies, but we classify them "exempt pre-reqs" per the Guidelines for the Review of Third Party Dependencies (implied, because we don't bother with actual CQs).

This is easy to think about in the context of a monolithic packaged deliverable. Basically anything that's in that hypothetical monolithic package must be taken through the Eclipse IP Due Diligence Process.

It's a little harder to think about when you distribute, say, a Maven JAR. Strictly speaking, you are only distributing that one JAR. But in the process of resolving that JAR, the consumer will need all sorts of other third party content; this content is all "pre-req dependencies" that we need the Eclipse IP Team to review.

Perhaps the most general way of thinking about it is that you need a CQ for all third party content related to your project code that will end up in a product built using your project's technology. It's on this basis that we can, for example, categorize build and test dependencies as "works with". I suspect, however, that I'm venturing off topic...