source/chapters/ip.adoc

////
 * Copyright (C) 2015, 2020 Eclipse Foundation, Inc. and others. 
 * 
 * This program and the accompanying materials are made available under the
 * terms of the Eclipse Public License v. 2.0 which is available at
 * http://www.eclipse.org/legal/epl-2.0.
 * 
 * SPDX-License-Identifier: EPL-2.0
////


////
We regard the following to be proper names:

IP Due Diligence Process (when referring to the Eclipse IP DD process)
IP Team
Contribution Questionnaire
Piggyback CQ
Prerequisite
Exempt Prerequisite
Works With Dependency
Third-party (use a hyphen)

The terms "intellectual property", "project content" and "third-party content" are not considered proper nouns.
////

[[ip]]
== Intellectual Property

The term intellectual property (IP) refers to any sort of creative work, be it literature, art, or software. In the realm of open source software, artifacts like source code, documentation, and images are considered intellectual property. Unless otherwise stated, intellectual property is the property of its creator, who may grant permission for others to use that intellectual property by providing a license.

The ease with which software can be copied and combined makes it challenging to know with confidence if content can be used without running into legal issues. Any sort of serious software development effort must be accompanied by a well-defined IP due diligence process that can ferret out issues and mitigate the risk of leveraging the work of others. IP due diligence is a time consuming process that requires specialized skills and a keen eye for detail.

____
In October 2019, The Eclipse Foundation's Board of Directors approved an update to the IP Policy that introduces several significant changes in our IP due diligence process.

**License certification only for third-party content.** This change removes the requirement to perform deep copyright, provenance and scanning of anomalies for third-party content unless it is being modified and/or if there are _special_ considerations regarding the content. Instead, the focus for third-party content is on _license compatibility_ only, which had previously been referred to as _Type A_ due diligence.

**Leverage other sources of license information for third-party content.** With this change to license certification only for third-party content, we are able to leverage existing sources of information license information. That is, the requirement that the  IP Team personally review every bit of third-party content has been removed and we can now leverage other _trusted_ sources.

**ClearlyDefined is a _trusted_ source of license information.** We currently have two trusted sources of license information: The Eclipse Foundation’s <<ip-ipzilla,IPZilla>> and <<ip-clearlydefined, ClearlyDefined>>. The IPZilla database has been painstakingly built over most of the lifespan of the Eclipse Foundation; it contains a vast wealth of deeply vetted information about many versions of many third-party libraries. ClearlyDefined is an OSI project that combines automated harvesting of software repositories and curation by trusted members of the community to produce a massive database of license (and other) information about content.

**Piggyback CQs are no longer required.** CQs had previously been used for tracking both the vetting process and the use of third-party content. With the changes, we are no longer required track the use of third-party content using CQs, so piggyback CQs are no longer necessary.

**Parallel IP is used in all cases.** Previously, our so-called _Parallel IP_ process, the means by which project teams could leverage content during development while the IP Team completed their due diligence review was available only to projects in the _incubation phase_ and only for content with specific conditions. This is no longer the case: full vetting is now always applied in parallel in all cases.

**CQs are not required for third-party content in all cases.** In the case of third-party content due diligence, <<ip-cq,CQs>> are now only used to track the vetting process. 

**CQs are no longer required _before_ third-party content is introduced.** Previously, the IP Policy required that all third-party content must be vetted by the IP Team before it can be used by {aForgeName} Project. The IP Policy updates turn this around. {forgeName} project teams may now introduce new third-party content during a development cycle without first checking with the IP Team. That is, a project team may commit build scripts, code references, etc. to third-party content to their source code repository without first creating a <<ip-cq,CQ>> to request IP Team review and approval of the third-party content. At least during the development period between releases, the onus is on the project team to -- with reasonable confidence -- ensure any third-party content that they introduce is license compatible with the project’s license. Before any content may be included in any formal release the project team must engage in the <<ip-prereq-diligence, due diligence process>> to validate that the third-party content licenses are compatible with the project license.

**History may be retained when an existing project moves to the Eclipse Foundation.** We had previously required that the commit history for a project moving to the Eclipse Foundation be squashed and that the <<ip-initial-contribution, initial contribution>> be the very first commit in the repository. This is no longer the case; existing projects are now encouraged (but not required) to retain their commit history. The initial contribution must still be provided to the IP Team via <<ip-cq, CQ>> as a snapshot of the `HEAD` state of the existing repository (if any).

The due diligence process for project content is unchanged.

[WARNING]
====
We are in the process of updating this documentation to reflect these changes. All historical information is technically correct, but may no longer be required. If something appears confusing, please connect with {emoEmailLink} for assistance.
====
____

There are different kinds of content (e.g., source code, documentation, and images) to consider. <<ip-project-content,_Project content_>> is content (typically source code) that is produced and maintained by the open source project committers and contributors. <<ip-third-party,_Third-party content_>> generally takes the form of libraries (e.g. modules, or components), source files, images, or other forms of IP that are produced and maintained outside of the scope of the open source project. To mitigate the risk associated with adopting open source in products, the _project content_ and the _third-party content_ that it leverages need to be vetted to ensure that the copyrights expressed are correct, licensing is valid and compatible, and that other issues have been uncovered and properly investigated.

The Eclipse Foundation has a well-defined {ipPolicyUrl}[IP Policy], corresponding IP Due Diligence Process, and an _IP Team_ of dedicated professional IP specialists who perform the heavy lifting in the due diligence process. Committers, the software developers who decide what will become _project content_ and how {aForgeName} open source project will leverage _third-party content_, are responsible for bringing IP issues to the attention of the IP Team.

Most of the _project content_ produced by committers can be pushed into a project repository without any sort of legal review. However, at least in some cases, the IP Team needs to be engaged to review project content that comes from contributors (who are not committers); and there are some cases where even the work of committers needs to be reviewed.

The IP Due Diligence Process focuses on source content. For the purposes of the IP Due Diligence Process, the term _source code_ (or _source content_) refers to the pre-compiled content, including programming language source, configuration and property files, as well as binary things that don't have a pre-compiled form like icons. The IP Due Diligence Process is concerned with reviewing the IP that is either consumed (third-party content) or produced (project content) by the Eclipse open source project. The process doesn't generally focus on compiled content (e.g., the IP Team looks at source code, not JAR files).

The IP Due Diligence Process does not dictate how source code repositories are structured. When the IP Team signals that content can be used, the project team can put content into their repositories in whatever structure makes the most sense. Similarly, the IP Due Diligence Process is not concerned with how third-party content is represented (e.g. how it is integrated into builds) or how it is disseminated.

[NOTE] 
====
The {edpLink} does restrict how content can be disseminated based on the state of the IP review. A Project team can create and distribute milestone builds of any content that has been granted _check-in_ from the IP Team. All content must be approved by the IP Team before the project can engage in a formal <<release, release>>.
====

The entry point into the IP Due Diligence Process is the <<ip-cq,Contribution Questionnaire>>, or _CQ_. Project teams should create a single CQ for the <<ip-initial-contribution,initial contribution>> of project content. The initial contribution is a special type of project content contribution in the sense that it is the first thing that the IP Team will review on behalf of the project team. 

[[ip-ipzilla]]
=== IPZilla

{ipzillaUrl}[IPZilla] is a modified instance of Bugzilla that tracks the progress of the IP due diligence review and approval process. It is the main interaction point between committers and the IP Team. IPZilla is accessible only by committers, Eclipse Foundation member company representatives, and other specifically-designated individuals. Authorized users can review both completed and ongoing reviews via IPZilla. 

[[ip-clearlydefined]]
=== ClearlyDefined

{clearlyDefinedUrl}[ClearlyDefined] is an OSI project that combines automated harvesting of software repositories and curation by trusted members of the community to produce a massive database of license (and other) information about content. The Eclipse Foundation's IP Team works closely with the ClearlyDefined team, providing input into their processes and helping to curate their data.

In rough terms, if the license information for third-party content can be validated by the Eclipse Foundation's <<ip-prereq-diligence, due diligence process>> using ClearlyDefined data, then no further action is required (i.e., no <<ip-cq,CQ>> is required).

[[ip-clearlydefined-identifiers]]
==== ClearlyDefined Identifiers

In order to facilitate the use of automation in the IP due diligence process, the Eclipse Foundation has adopted ClearlyDefined identifiers to identify content.

The notion of an identifier for content is pretty natural for developers who are familiar with technologies like Apache Maven which has well defined means of uniquely identifying content in a well-defined software repository. Maven coordinates -- which combine `groupid`, `artifactid`, and `version` (often referred to as a “GAV”) -- identify a very specific bit of content (especially when combined with a specific source, e.g. Maven Central). For example, `org.junit.jupiter:junit-jupiter:5.5.2` unambiguously identifies content on Maven Central that is known to be under the Eclipse Public License version 2.0 (EPL-2.0). Other systems use different means of identifying content: `node.js`, for example, uses a pURL-like identifier for content in the NPM repository (e.g., `@babel/generator@7.62`).

To bridge the gap between the different means of identifying content (and fill in some of the blanks), we’ve adopted the ClearlyDefined project’s five part identifiers which includes the type of content, its software repository source, its name space and name, and version. ClearlyDefined coordinates are roughly analogous to Maven coordinates, but -- by including the type and source -- provide a greater degree of precision. ClearlyDefined uses slashes to separate the parts of the identifier, so the Maven GAV `org.junit.jupiter:junit-jupiter:5.5.2` maps to `maven/mavencentral/org.junit.jupiter/junit-jupiter/5.5.2` and the NPM identifier `@babel/generator@7.62` maps to `npm/npmjs/@babel/generator/7.6.2`.

[[ip-clearlydefined-using]]
==== Using ClearlyDefined

ClearlyDefined is used as part of the overall <<ip-prereq-diligence, due diligence process for third-party prerequisites>>.

[NOTE]
====
The Eclipse Foundation's <<ip-ipzilla, IPZilla>> is the primary source of information regarding third-party licensing for {forgeName} projects. In cases where IPZilla and ClearlyDefined results differ, IPZilla results take precedence.
====

When content is known to ClearlyDefined and has a _Licensed_ score of at least {clearlyDefinedMinimumScore}, and the _declared_ and all _discovered_ licenses are on the Eclipse Foundation's {approvedLicensesUrl}[approved licenses list], then the content can be used without further action. 

ClearlyDefined provides three different scores. For example:

image::images/clearlydefined-example.png[Screenshot from ClearlyDefined]

Three numbers are highlighted in this screenshot:

// These will generate warnings; the callouts are included
// part of the above image.

<1> The overall score;
<2> The _Described_ score (i.e., completeness of the metadata); and
<3> The _Licensed_ score (i.e., confidence in the licensing). 

In this particular example, the declared and discovered licenses are all on the approved licenses list, and the _Licensed_ score meets the threshold. This content can be used by {aForgeName} project without further consideration.

Note that when the ClearlyDefined record shows any of the following, a project committer must <<ip-project-content-cq, engage with the IP Team via CQ>>:

* `NOASSERTION` appearing as a _declared license_;
* `NOASSERTION` appearing as a _discovered license_;
* No declared license; or
* A _License_ score of less than {clearlyDefinedMinimumScore}.

[[ip-cq]]
=== Contribution Questionnaires

A Contribution Questionnaire (CQ) is the main interface between {forgeName} committers and the IP Team. CQs are used to engage the IP Team in a review of intellectual property when their assistance is required.

A CQ is started when a committer completes a _questionnaire_ regarding a <<ip-project-content-cq, project content>> contribution or <<ip-prereq-cq, third-party content>>. In literal terms, a CQ is a record in <<ip-ipzilla, IPZilla>> that tracks the progress of the approval process. The CQ record is the primary communication channel between the submitting committer and the IP Team. CQ records persist indefinitely.

All significant contributions of content to be maintained by {aForgeName} project (<<ip-project-content, project content>>) require a CQ. Projects further may also require a CQ for some pieces of <<ip-third-party, third-party content>> that project content makes direct use of (regardless of whether or not the content is directly distributed by the project. 

CQs are not generally required for ongoing work done by project committers. 

[[ip-initial-contribution]]
=== Initial Contribution

Code provenance tracking is critical (the source of all code that ends up in Eclipse Foundation repositories must be well known). To that end, all new projects are required to make an _initial contribution_ before *any* code is committed to a project's source code repository.

[graphviz, images/ip_ic_overview, svg, width=800px]
.How The Initial Contribution Fits into the Project Creation Process
----
digraph {
	bgcolor=transparent;
	rank=same;rankdir=LR
	
	node [shape=box;style=filled;fillcolor=white;fontsize=12];
	{
		rankdir=TB;
		creation[label="EMO declares\nsuccessful\nCreation Review"];
		provision[label="Eclipse\nWebmaster\nProvisions"];
	}
	initial[label="Committer submits\nInitial\nContribution"];
	
	{
		rankdir=TB;
		checkin[label="IP Team\ngrants\n\"check-in\""];
		parallel[label="IP Team\ncompletes review"];
		approval[label="IP Team\ngrants\n\"approval\""];
	}
	
	{
		rankdir=TB;
		push[label="Committer\npushes to\nProject Git"];
		develop[label="Committers and\ncontributors engage"];
		review[label="Project Team\nengages in a\nRelease Review"];
		release[label="First Release"; style="filled,bold"];
	}
	creation -> provision;
	provision -> initial;
	initial -> checkin;
	checkin -> push;
	checkin -> parallel;
	parallel -> approval;
	push -> develop;
	develop -> review;
	approval -> review;
	review -> release;
}
----

Following a successful Creation Review, the EMO will initiate the provisioning process (Committers provide required paperwork and the Webmaster creates project resources (Git, downloads, website, etc.);

The initial contribution is a snapshot of the existing code base. The initial contribution, like any other <<ip-project-content,project content>> contribution, should contain *only* project content. Any <<ip-third-party,third-party content>> that might be included in the existing source tree should be excluded from the initial contribution and treated as third-party content. The initial contribution is just a snapshot in time: the IP Team does not review history.

Any project committer can start the initial contribution review process by creating a <<ip-cq,CQ>>. The IP Team will review the initial contribution to ensure that it hasn't been copied inappropriately, that licenses are being used correctly, and so forth. As part of this process, the IP Team  will research the source of all code; depending on the size of the contribution, this can be a time-consuming process.

Because a full review can be time-consuming, the IP Team will in most cases start with a cursory review of the content, and -- assuming that no significant issues are uncovered by that cursory review -- will grant _check-in_ indicating that the project team can push/merge the initial contribution into their Git repository (or initiate the transfer of their existing repository) and start working with the code while the IP team continues their review in _parallel_ (they will add completing the review to their work queue and address it in turn).

After _check-in_ has been granted for the initial contribution, the project team should start the due diligence process for their <<ip-third-party,third-party content>>.

[TIP]
====
Eclipse Foundation systems use email to inform and remind interested parties of the various steps in this process. Only the committer who creates a CQ is notified by default, but other committers can be added to a CQ's _CC list_ to be included in the communication. 

The email address that is associated with your Eclipse Foundation account is used; be sure to check spam filters to ensure that these messages are not missed. Send a note to mailto:{emoEmail}[EMO] if you are concerned that you are not receiving these notification.
====

A project cannot make a <<release, release>> until the due diligence on the IP contained in that release -- including project content contributions and third-party content -- is complete. 

[[ip-project-content]]
=== Project Content

[[ip-project-code]]Project Content is content that is managed by the project team. This includes content that is produced by project committers, along with content that is contributed to the project by outside contributors. Essentially, all source code that is contained in a source code repository that is owned and managed by the Eclipse Foundation on behalf of an open source project team is considered project content. We use "content" in a general sense, independent of any particular technology or means of delivery; code, scripts, documentation, and configuration files are all (non-exhaustive) examples content. 

In general, contributions made by project committers do not require review and can be pushed directly into a project repository.

Contributions by others (i.e., developers who are not committers on the receiving project) must be received via an Eclipse Foundation channel (e.g., GitHub pull request, Gerrit review, or attachment on an issue). 

When the contributor has signed the <<contributing-eca, Eclipse Contributor Agreement>> (ECA) and the following conditions are met, a CQ is not required:

* Was developed from scratch; written 100% by submitting contributor;
* Was submitted under the terms of the project license;
* Contains no cryptography; and
* Is it less than 1,000 lines of code, configuration files, and other forms of source code.

If all of these conditions have **not** been met, then a project committer must <<ip-project-content-cq, open a CQ>> to request review by the IP Team before the contribution is pushed/merged.

[TIP]
====
If you're not sure whether or not a CQ is required, or are otherwise concerned that there may be issues with a contribution, create a CQ.
====

All contributions of project content must be tracked in the project's <<ip-iplog,IP Log>>. This is done automatically when the author information is correctly specified in <<resources-commit,Git commit records>> (e.g., the content creator's credentials are correctly recorded in the `author` field of  Git commit records).

Any project committer can <<ip-project-content-cq, create>> a <<ip-cq,CQ>> to submit a project content contribution for review by the IP Team. The project content must be attached to the CQ in source form. A full review can be time-consuming; the IP Team will start with a cursory review of the content, and—​assuming that no significant issues are uncovered by that cursory review—will grant _check-in_ indicating that the project team can push/merge the initial contribution into their Git repository and start working on it while the IP team continues their review in _parallel_. A project cannot make a release that includes the content under review until the due diligence process ​is complete and the content has been approved.

[[ip-ownership]]
==== Copyright

The author of a contribution (or their employer) retains copyright of the intellectual property contained in the contribution. As part of the contribution process, the contributor licenses their contribution under the applicable license(s).

[TIP]
====
The _applicable license_ is typically the project license. Contributions may, however, be received and distributed under different licenses in some circumstances. If you need to accept content under a license that is not the project license, engage with the IP Team for assistance (<<ip-project-content-cq, create a CQ>>).
====

[[ip-project-content-cq]]
==== CQ Workflow for Project Content

In the case where review by the IP Team is required, a project committer must create a <<ip-cq, CQ>>.

[graphviz, images/projectcode-cq, svg]
.CQ Workflow for Project Content
----
digraph {
   graph [ranksep="0.25"; nodesep="0.25"; fontsize=12];
   bgcolor=transparent;
   rankdir=TB;
   splines=curved;
   
   node [shape=box;style=filled;fillcolor=white;fontsize=12]
   edge [fontsize=12]
   
   create [style="filled,bold",label="Create CQ"];
   
   {
      attach [label="Attach code"];
      rank=same; rankdir=LR;
      pmc [label="PMC Approval"];
      checkin [label="Check-in"];
   }
   
   approval [style="filled,bold", label="Approved"]
   
   create -> attach;
   attach -> pmc;
   pmc -> checkin;
   checkin -> approval;
}
----

Creating a CQ for a project content contribution requires two steps. In the first step, a committer must <<pmi-commands-cq, create the CQ record>> by providing basic information about the content. In the second step, the committer must then attach the source code for the content to the newly created CQ. When all information and the source code has been collected, the workflow will connect with the PMC for their approval.

[TIP]
====
When engaged in the workflow to create a CQ for a project content contribution, indicate that the CQ is for "Project Content" on the first page of the wizard and provide the information requested on the following page. Set the value of the "Contribution Record" to some publicly accessible link. This could be a link to a pull request, or -- in the case of an <<ip-initial-contribution, initial contribution>> -- a link to the proposal tracking bug.

After creating the CQ, the committer will be sent an email with instructions to attach the corresponding source code. Bundle the `HEAD` state of the source code into a ZIP file for the attachment.

Be sure to click btn:[Issues addressed, return CQ to IP Team] to release the CQ back to the workflow.
====

The IP Team will engage in two phases. In the first phase, they will perform a rudimentary license check. If the licenses represented in the content are found to be compatible with the project license, the project team will grant _check-in_ meaning that the project team may add the content to a project repository (or engage with the Eclipse webmaster to move an existing repository). The IP Team will add the CQ to their queue for further detailed analysis. When that analysis is complete, the IP Team will mark the CQ as `approved`, indicating that the content is fully vetted for use and may be included in a project <<release>>.

The IP team may require assistance from the project team as it analyzes content. Once that analysis is complete and the IP Team has made a decision, they will outline the next steps directly on the CQ. 

Be advised that this process may take a while. The actual amount of time that it takes to process a CQ depends on numerous factors including the size of the IP Team's work queue, and the nature and size of the contribution.

[[ip-third-party]]
=== Third-party Content

The sort of effort that the IP Team brings to bear on third-party content varies depending on the type. The {ipThirdParty}[Guidelines for the Review of Third-party Dependencies] defines three different types: _Prerequisite_, _Exempt Prerequisite_, and _Works With Dependency_.

[NOTE]
====
The term contribution questionnaire is a bit misleading when it comes to third-party content. Third-party content is not really a contribution to the project, but since the requirements for tracking project content and third-party content is very similar, the same mechanism is used for both.
====

[[ip-prereq]]
==== Prerequisites

[[ip-third-party-prereq]]The simplest form of third-party content is the _prerequisite_ (which is frequently referred to as a _prereq_). Prerequisites are required by the Eclipse project content to provide core functionality (i.e., adopters of Eclipse project content are compelled to adopt the prerequisite content). Prerequisite content is not generally stored in an Eclipse project's source code repositories, but is likely included in build scripts and referenced as runtime dependencies. The entire transitive closure of a prerequisite's dependencies are themselves prerequisites (the dependencies of a prerequisite are themselves prerequisites, recursively).

[graphviz, images/prereq_dependencies, svg]
.Eclipse Project Dependencies
----
digraph {
   graph [ranksep="0.25"; nodesep="0.25"; fontsize=12];
   bgcolor=transparent
   rankdir=LR;

   node [shape=box;style=filled;fillcolor=white;fontsize=12;label="Content"]
   edge [fontsize=12]
   root[label="Eclipse Project\nContent"];

   subgraph cluster_prereq {
      node [fontsize=10;label="Third-party\nContent"]
      prereq1; prereq2;
      ref1; ref2; ref3; ref4;
      label="\"Prerequisite\" Dependencies\n(licenses must be verified)";
      graph[style=dotted];
   }
   
   root -> prereq1;
   root -> prereq2;
   prereq1 -> ref1;
   prereq2 -> ref2 -> ref3
   ref2 -> ref4;
}
----

Examples of Prerequisite dependencies:

* The Java/OSGi manifest for one of the project bundles makes a direct reference to third-party content (either a bundle or package);
* The project content includes an import statement for a package from third-party content;
* The project content imports a third-party library's header file;
* The project content references NPM modules via a `package.json`, `package-lock.json`, or `yarn.lock` file;
* The project's Maven-based build lists a module as a `compile` phase dependency;
* The project content uses reflection or other means to reference APIs and implementation;
* The project content uses OSGi Services to make a reference to a specific implementation of a service; or
* The project content invokes a _command line interface_ (this may actually be an <<ip-third-party-exempt, exempt prerequisite>>).

This list is not intended to be exhaustive, but rather to provide common examples. Fundamentally, when project content makes some kind of use of third-party content, then that content is likely a Prerequisite. Under certain conditions, the content may also be classified as an <<ip-third-party-exempt,exempt prerequisite>> or a <<ip-third-party-workswith,works with dependency>>. 

In the case where {aForgeName} project references code from <<ip-other-projects,another {forgeName} project>> that itself references prerequisites, no further review of that chain of prerequisites is required. Eclipse project teams must only reference release versions of other Eclipse projects in their own releases to ensure that the IP Due Diligence Process has been completed.

[graphviz, images/eclipse_dependencies, svg]
.Eclipse Project Dependencies
----
digraph {
   graph [ranksep="0.25"; nodesep="0.25"; fontsize=12];
   bgcolor=transparent
   rankdir=LR;

   node [shape=box;style=filled;fillcolor=white;fontsize=12;label="Content"]
   edge [fontsize=12]
   root[label="Eclipse Project\nContent"];

   subgraph cluster_eclipse {
      graph[style=dotted];
      label="No further review required";
      node [fontsize=10;label="Content from\na different\nEclipse Project"]
      prereq1; 
      node [fontsize=10;label="Third-party\nContent"]
      ref1;
   }
   
   subgraph cluster_thirdparty {
      graph[style=dotted];
      label="\"Prerequisite\" Dependencies\n(licenses must be verified)";
      node [fontsize=10;label="Third-party\nContent"]
      prereq2;
      ref2;
   }
   
   root -> prereq1;
   root -> prereq2;
   prereq1 -> ref1;
   prereq2 -> ref2;
}
----

[[ip-example-maven]]
===== Maven Example

The following snippet from a Maven `pom.xml` file includes a single dependency that itself has dependencies.

[source, xml]
.Snippet from an example Maven `pom.xml` file
----
...
<dependencies>
   <dependency>
      <groupId>commons-httpclient</groupId>
      <artifactId>commons-httpclient</artifactId>
      <version>3.1</version>
   </dependency>
</dependencies>
...
----

When Maven resolves the dependencies, it must also resolve dependencies of dependencies recursively. The `dependency:tree` plug-in generates a graph of the entire dependency tree (note that the example is abridged).

[source]
.Dependency graph generated by Maven
----
$ mvn dependency:tree
...
[INFO] org.eclipse.dash:good-stuff:jar:0.0.1-SNAPSHOT
[INFO] \- commons-httpclient:commons-httpclient:jar:3.1:compile
[INFO]    +- commons-logging:commons-logging:jar:1.0.4:compile
[INFO]    \- commons-codec:commons-codec:jar:1.2:compile
...
----

Every library in the entire transitive closure of the dependency graph is a prerequisite.

[graphviz, images/mvn-example-dependencies, svg]
.Visualization of the dependency graph (the Maven _type_ and _scope_ have been removed for brevity)
----
digraph {
   graph [ranksep="0.25"; nodesep="0.25"; fontsize=12];
   bgcolor=transparent
   rankdir=LR;
   
   node [shape=box;style=filled;fillcolor=white;fontsize=12;label="Content"]
   edge [fontsize=12]
   
   projectcode [label="org.eclipse.dash:\ngood-stuff:0.0.1"];
   subgraph cluster_dependencies {
      graph[style=dotted];
      label="\"Prereq\" Dependencies\n(licenses must be verified)";
      httpclient [label="commons-httpclient:\ncommons-httpclient:3.1"];
      logging [label="commons-logging:\ncommons-logging:1.0.4"];
      codec [label="commons-codec:\ncommons-codec:1.2"];
   }
   
   projectcode -> httpclient [label="requires"];
   httpclient -> logging;
   httpclient -> codec;
}
----

In this example, `commons-httpclient:commons-httpclient:3.1`, `commons-logging:commons-logging:1.0.4`, and `commons-codec:commons-codec:1.2` must all be <<ip-prereq-diligence, vetted for license compatibility>>.

[[ip-prereq-versions]]
===== Versions of Prerequisites

[[ip-third-party-versions]]Prerequisites are version specific. Since it is possible that problematic intellectual property may be added in a new version of a prerequisite, every version of a prerequisite is treated as distinct content. In practical terms, this means that project teams are required to engage the due diligence process with each separate version of Prerequisite content they require. 

This applies specifically to major and minor versions of prerequisites. 

Project teams are not required to engage with the IP Team to review service releases for third-party content, provided that the service release is based on a release that has either been vetted by the due diligence process. A service release is defined as a release that is backwards compatible and contains only bug fixes. If a project team isn't sure whether or not a particular release is a service release, they should submit the content for review by the IP Team.

[[ip-prereq-diligence]]
===== Due Diligence for Prerequisites

[[ip-third-party-due-diligence]]All prerequisites must be available under a license that is on the Eclipse Foundation's list of {approvedLicensesUrl}[approved licenses for third-party content]. Further, the nature of the license must be verified by a _trusted_ source. When the license for content can be verified by a trusted source of license information, no further action is required (there is no need to seek approval from the IP Team); if there is any question regarding the nature of the license, then project team should create a <<ip-cq, CQ>> to request that the IP Team perform the necessary due diligence on the content.

[TIP]
====
Content that claims to be distributed under a particular license may in fact include content that is distributed under alternative licenses, meaning that the licensing of a particular piece of content may be more complex than even the content authors know.
====

The Eclipse Foundation has two trusted sources of license information: <<ip-ipzilla, IPZilla>> and <<ip-clearlydefined, ClearlyDefined>>.

IPZilla is the primary source of license information for third-party content. If the IPZilla record (<<ip-cq,CQ>>) for third-party content is marked as `approved` or `license_certified`, then it can be used without further action. If, however, third-party content is otherwise marked (e.g., `withdrawn` or `rejected`), then the project team must engage with the IP Team via CQ to get approval to use the content.

If third-party content is not known to IPZilla, then <<ip-clearlydefined, ClearlyDefined>> can be used. When an entry is known to ClearlyDefined and has a _Licensed_ score of at least {clearlyDefinedMinimumScore} and all discovered licenses are on the Eclipse Foundation's {approvedLicensesUrl}[approved licenses list], then the content can be used without further action (for more information see <<ip-clearlydefined-using, Using ClearlyDefined>>). 

[NOTE]
====
The Eclipse Foundation's <<ip-ipzilla, IPZilla>> is the primary source of information regarding third-party licensing for {forgeName} projects. In cases where IPZilla and ClearlyDefined results differ, IPZilla results take precedence.
====

[graphviz, images/ip_prereq_diligence, svg]
.Due Diligence for Prerequisites
----
digraph {
	graph [ranksep="0.25"; nodesep="0.25"; fontsize=12];
	bgcolor=transparent;
	rankdir=TB;
	splines=curved;
	
	node [shape=box;style=filled;fillcolor=white;fontsize=12]
	edge [fontsize=12]
	
	search [style="filled,bold",label="Search IPZilla\nfor Existing CQ"];
	{
		rank=same; rankdir=LR;
		foundCq[shape=diamond;label="Found in\nIPZilla?"];
		cd [label="Search\nClearlyDefined", href="#ip-clearlydefined"];
		cd_score[shape=diamond;label="Score is\n≥ 75"];
	}
	
	{
		rank=same;rankdir=LR;
		isApproved[shape=diamond;label="Approved\nfor use?"];
		cd_licenses[shape=diamond;label="Licenses are\ncompatible?"];
	}
	
	{
		rank=same;rankdir=LR;
		approved[style="filled,bold",label="No further investigation;\nmay be used by\nEclipse Project"];
		cq[style="filled,bold",label="Engage with IP Team\nfor assistance\n(create a CQ)", href="#ip-prereq-cq"];
	}
	
	search -> foundCq;
	foundCq -> cd [label="No"; weight=1000];
	foundCq -> isApproved[label="Yes"];
	isApproved -> approved[taillabel="Yes"];
	isApproved -> cq[taillabel="No"];
	cd -> cd_score;
	cd_score -> cd_licenses[label="Yes"];
	cd_score -> cq:e[xlabel="No"]
	cd_licenses -> approved[taillabel="Yes"];
	cd_licenses -> cq[label="No"];
}
----

When content fails to meet these requirements, the project team must engage with the IP Team via CQ to get approval to use the content.

[TIP]
====
The Eclipse Dash project's <<ip-license-tool, IP License Tool>> will help you determine whether or not a CQ is required.
====

When in doubt, committers should check with the {ipTeamEmailLink}.

[[ip-prereq-cq]]
===== CQ Workflow for Prerequisites

[[ip-cq-workflow]]In the case where review by the IP Team is required, a project committer must create a CQ.

The workflow for creating a CQ for a prerequisite starts with a search of existing CQs. If an existing CQ, marked as either _approved_ or _license_certified_, can be found that is concerned with the same content and version, then no further action is required. That is, committers should **not** create an additional CQ for any content that is already approved; if the content is already approved by an existing CQ, then it can be used without additional due diligence (notwithstanding any caveats or limitations outlined on the CQ).

[graphviz, images/cq_workflow, svg]
.CQ Workflow for Prerequisites
----
digraph {
   graph [ranksep="0.25"; nodesep="0.25"; fontsize=12];
   bgcolor=transparent;
   rankdir=TB;
   splines=curved;
   
   node [shape=box;style=filled;fillcolor=white;fontsize=12]
   edge [fontsize=12]
   
   search [style="filled,bold",label="Search for\nExisting CQ"];
   {
      rank=same; rankdir=LR;
      found[shape=diamond;label="Found?"];
      create [label="Create CQ"];
      attach [label="Attach code"];
   }
   
   {
      rank=same; rankdir=LR;
      none [label="No CQ\nrequired"];
      pmc [label="PMC Approval"];
      checkin [label="Check-in"];
      approval [label="License\nCertified"]
   }
   
   approved [style="filled,bold",label="May be used by\nEclipse Project"];
   
   search -> found;
   found -> none [label="Yes"; weight=1000];
   none -> pmc [style=invis; weight=1000];
   found -> create [xlabel="No"];
   create -> attach;
   attach -> pmc;
   pmc -> checkin;
   checkin -> approval;
   
   none -> approved;
   approval -> approved;
}
----

Creating a CQ for a prerequisite requires two steps. In the first step, a committer must <<pmi-commands-cq, create the CQ record>> by providing basic information about the content. In the second step, the committer must then attach the source code for the content to the newly created CQ. 

When all information and the source code has been collected, the workflow will connect with the PMC for their approval. The PMC's role is to engage in a technical assessment to ensure that the information provided makes sense from a technical perspective; with their approval, the IP Team will engage in their review.

[TIP]
====
When engaged in the workflow to create a CQ for a prerequisite:

* On the first page of the wizard, indicate that the CQ is for a "Third-Party Code Request";
* When specifying the "Name and Version" on the second page of the wizard, use Node, Maven, or <<ip-clearlydefined-identifiers, ClearlyDefined>> identifiers when possible; and 
* On the third page of the wizard, indicate that it is a "Request IP Team Assistance".

After creating the CQ, the committer will be sent an email with instructions to attach the corresponding source code. Bundle the source code into a ZIP file for the attachment.

Be sure to click btn:[Issues addressed, return CQ to IP Team] to release the CQ back to the workflow.
====

The IP Team may require assistance from the project team as it analyzes content. Once that analysis is complete and the IP Team has made a decision, they will outline the next steps. These next steps may -- in the event that the content is rejected -- require that the content be removed from the project's source code repository, or that some part be removed. Most often, the content is _approved_ and the CQ is marked as such.

Be advised that this process may take a while. The actual amount of time that it takes to process a CQ depends on numerous factors including the size of the IP Team's work queue, and the nature and size of the contribution.

[[ip-third-party-exempt]]
==== Exempt Prerequisites

When one follows a dependency graph all the way to the bottom, the entire runtime environment including virtual machines and the operating system are included in the transitive closure of dependencies. Clearly, having the IP team review virtual machines and operating systems is not a great use of time, and -- in the case of closed source operating systems -- just not be possible.

The Eclipse IP Due Diligence Process guidelines provide for a notion of _Exempt Prerequisite_ dependencies, which are not subject to review. According to the guide, content may be considered exempt if it "is pervasive in nature, expected to be already on the user's machine, and/or an IP review would be either impossible, impractical, or inadvisable." The IP Team does not review the source code associated with an Exempt Prerequisite.

One of the key aspects of an Exempt Prerequisite is that the user or adopter is typically the one that actually installs the software and so is the one who must agree to the licensing terms. Content that is declared an Exempt Prerequisite should never be directly distributed by an Eclipse project or otherwise made available without some explicit action from the consumer. 

Any project committer can create a <<ip-cq,CQ>> to submit an Exempt Prerequisite for review by the IP Team. Exempt Prerequisites must be approved by the Eclipse Foundation's Executive Director.

[[ip-third-party-workswith]]
==== Works With Dependencies

The Eclipse IP Due Diligence Process guidelines also define the notion of a _Works With Dependency_ (commonly referred to simply as a Works With) that applies in two different cases. Third-party content may be declared a Works With Dependency when:

* the functionality of Eclipse <<ip-project-content,project content>> is enhanced by the presence of the software, but is otherwise functional and useful without it; or
* there are multiple choices and reviewing all of them is impractical or impossible.

A Works With Dependency is, literally, a dependency that the Eclipse project content will work with when it is available. The fundamental requirement is the Eclipse project content must be useful and adoptable without the Works With Dependency. That is, either the project content provides useful functionality without the Works With Dependency or the Works With Dependency is a suitable alternative for a <<ip-third-party-prereq,Prerequisite>>.

[graphviz, images/prereq_and_workswith, svg]
.Prerequisite and "Works with" Dependencies
----
digraph {
   graph [ranksep="0.25"; nodesep="0.25"; fontsize=12];
   bgcolor=transparent
   rankdir=LR;
   
   node [shape=box;style=filled;fillcolor=white;fontsize=12;label="Content"]
   edge [fontsize=12]
   
   adopter[label="Consumer"];
   root[label="Eclipse Project\nContent"];

   subgraph cluster_prereq {
      label="\"Prereq\" Dependencies\n(licenses must be verified)";
      graph[style=dotted];
      node [fontsize=10;label="Third-party\nContent"]
      prereq1; prereq2;
      ref1; ref2; ref3; ref4;
   }
   
   subgraph cluster_workswith {
      graph[style=dotted];
      
      node [fontsize=10;label="Third-party\n\"Works With\" Content\n(must be reviewed by IP Team)"]
      workswith;
      subgraph cluster_workswith_transitive {
         label="\"Works With\" Dependencies\n(No due diligence required)";
         graph[style=dotted];
         node [fontsize=10;label="Third-party\nContent"]
         workswith1; workswith2; workswith3;
      }
   }
   
   adopter -> root;
   adopter -> workswith [xlabel="requires"];
   
   root -> prereq1 [label="requires"];
   root -> prereq2 [label="requires"];
   prereq1 -> ref1;
   prereq2 -> ref2 -> ref3
   ref2 -> ref4;
   
   root -> workswith[style="dotted";label="optional"];
   workswith -> workswith1;
   workswith -> workswith2 -> workswith3;
}
----

As with an <<ip-third-party-exempt,Exempt Prerequisite>>, a Works With Dependency should never be directly distributed or otherwise made available without some explicit action from the consumer. The consumer is responsible for making the Works With Dependency content available and otherwise agreeing to the terms for that content.

It's enough to just create a <<ip-cq,CQ>> to register the use of Works With Dependency without seeking IP Team approval for its dependencies. Works With Dependencies must be approved by the Eclipse project's PMC.

[[ip-third-party-test]]
==== Test and Build Dependencies

Test and Build Dependencies are also categorized as <<ip-third-party-workswith, works-with dependencies>>.

[WARNING]
====
This document applies specifically to open-source libraries and tools only; it does not apply to the use of proprietary tools. Use of proprietary tools is covered by the {proprietaryToolsUrl}[Using Proprietary Tools] Eclipse Board resolution.
====

Test and build dependencies are those third-party libraries and tools that are considered non-distribution contributions. That is, these libraries are not actively distributed by the project via any generally-accessible `eclipse.org` property. These libraries and tools may, for example, persist on the build server which is accessible only to Eclipse committers; they may not, for example, persist on the `eclipse.org` download or archive servers, web server, or any source code repository. Eclipse project content (e.g., build scripts) distributed via `eclipse.org` source code repositories may contain references to these libraries and tools (but not the libraries/tools themselves). Project documentation should list these dependencies, how they are obtained (either manually or automatically via scripts), and other issues (especially licensing).

[NOTE]
====
This applies to third-party content that is required exclusively to facilitate build and test. Any dependencies that are required by downstream consumers of the Eclipse software are <<ip-third-party-prereq, prerequisites>> as defined by the Guidelines for the Review of Third-party Software)  and must be taken through the due diligence process as such. 
====

To declare build and test test dependencies, create a <<ip-cq, CQ>>:

* Enter a title containing the terms "test-only dependencies", "build-only dependencies", or "build- and test-only dependencies" (or similar);
* Enter a description that indicates that the CQ is for test/build-only dependencies, and set the CQ type to "works with"; and
* Enter "various" in the _license_ field and "binary" in the ;

* List all the third-party dependencies -- one on each line -- along with version information.

For example:

----
This is an umbrella CQ for all dependencies of the Eclipse Tycho project which are only needed to compile and execute unit and integration tests for Tycho. 

These artifacts are *not* redistributed by the Tycho project and are strictly only needed to compile and run tests for tycho itself. 

The following bundles from orbit are required by Tycho as test-only dependencies:

Bundle-SymbolicName : Bundle-Version
=============================================
com.ibm.icu:4.2.1.v20100412
javax.xml:1.3.4.v201005080400
org.apache.ant:1.7.1.v20090120-1145
org.junit:3.8.2.v20080602-1318
org.junit:3.8.2.v20090203-1005
----

[TIP]
====
When the list of build and test dependencies is long, it might be easier to include it in a comment after the CQ is created.
====

Project teams may create multiple test and build CQs.

[TIP]
====
You will need PMC approval. You may be able to hasten approval if you work with your PMC prior to creating the CQ to ensure that they understand your requirements.
====

If you have any questions or concerns, please contact EMO.

[[ip-piggyback]]
==== Piggyback CQs

[WARNING]
====
Piggyback CQs are not longer required or supported.
====

[[ip-other-projects]]
==== Content from Other Eclipse Projects

IP Team review or approval is *not* required for {aForgeName} open source project to use _released_ content from another {forgeName} open source project as part of a release (a project may use unreleased content from another project in milestone builds). A release of one project should *never* include unreleased content from another project.

When {aForgeName} projects makes direct use of third-party content inherited by consuming another {forgeName} open source project, that content must be treated as a prerequisite dependency.

[[ip-license-tool]]
=== License Tool

The {licenseToolUrl}[License Tool] was created with a command line interface that takes a list of dependencies as input and generates output that matches content to license information obtained from trusted sources, and identifies the content that needs further scrutiny (i.e., it lists all content for which license information cannot be found in one of the approved sources). We created it with a command line interface so that the initial version of the tool could be used on a variety of technologies.

[WARNING]
====
The License Tool is a prototype that is intended to assist with the process of determining the licenses of third-party content and help the committer identify intellectual property that require further scrutiny. The tool, like any tool, is only as good as the input provided. The License Tool's documentation provides examples of how dependency lists can be generated; these examples should be regarded as such: examples of how to construct a dependency list. Ultimately, is the responsibility of committers to understand the nature of their project and the third-party content it requires.
====

What the License Tool does is relatively simple:

It first sends the content list to <<ip-ipzilla, IPZilla>>; if an entry has been vetted by the IP Team and has been approved for use, then it is marked as `approved` . If an entry has been vetted by the IP Team and flagged as somehow problematic, it will be marked as `restricted`.

It then sends the content that has not been flagged as either `approved` or `restricted` to <<ip-clearlydefined, ClearlyDefined>>; ClearlyDefined matches are marked as `approved`.

Everything else is marked `restricted`. The License Tool lists all content that ended up marked as `restricted` as requiring further scrutiny. It is this list of content that requires further scrutiny that the project team must engage on with the <<ip-prereq-diligence, IP Team via CQ>>.

For many build technologies, it is relatively easy to generate lists of dependencies directly (e.g., the Maven Dependencies plugin). There are some specific examples in the prototype tool’s README (e.g., Maven-, Gradle-, NPM-, and Yarn-based systems). Project teams that use technologies that do not provide easily parsed/converted dependency lists can manually generate a list and feed that to the tool. 

[[ip-iplog]]
=== IP Logs

An IP Log is a record of the intellectual property contributions to a project. This includes such as a list of all committers, past and present, that have worked on the code and (especially) those who have made contributions to the current code base.

[NOTE]
====
An IP Log is a record of intellectual property for an entire project. The purpose of the IP Log review is to confirm that the project team understands the {ipPolicyUrl}[Eclipse IP Policy] and is implementing the supporting processes. An IP Log is not intended to reflect the intellectual property included with any particular release.
====

The IP Log is a big part of the official <<release, release cycle>>. You are required to submit your project's IP Log prior to scheduling a release, or restructuring review. We encourage you to keep your IP log current rather than rushing at the end. The IP Log includes important information about your project that lets adopters know where all the code comes from, who owns the copyrights, and so forth. 

Specifically, the log tracks:

* Licenses;
* Past and present committers;
* Third-party content; and
* Contributions from outside the project (i.e. non-committers)

[[ip-iplog-generator]]
==== IP Log Generator

The Automated IP Log Tool automatically generates an IP Log using information that is available to the Eclipse Foundation. The list of contributors, for example is automatically generated using information extracted out of the project's source code repositories.

The IP Log generator pulls information from multiple location to assemble the log:

[graphviz, images/ip-log-generator, svg]
.Sources for the IP Log generator
----
digraph {
	// Graph properties
	bgcolor=transparent
	
    graph [ranksep="0.25", nodesep="0.25"];
    
	// Nodes that define the key points in the process
	node [shape=box;style=filled;fillcolor=white;fontsize=12]
	git [label="Git", group="g1"]
	committer [label="Committer Activity", group="g2"]
	pmi [label="Repositories\n(PMI)", group="g1"]
	contributions [label="Git Contributions"]
	licenses [label="Licenses\n(Foundation DB)", group="g2"]
	generator [label="IP Log Generator", group="g1"]
	contributions_bugzilla [label="Contributions\n(Bugzilla)"]
	iplog [label="IP Log", group="g1"]
	
	git -> committer
	git -> contributions
	pmi -> generator
	pmi -> committer
	pmi -> contributions
	committer -> generator
	contributions -> generator
	licenses -> generator
	contributions_bugzilla ->generator
	generator -> iplog
}
----

* The list of third-party content used by the project comes from _IPZilla_;
* The project source code repositories are scanned to identify non-committer authors of contributions; 
* The committer list, which includes everybody who has ever held committer status the project (regardless of whether or not they have ever made any contributions of intellectual property) comes from the _Foundation_ database; and
* License information is obtained from the _Foundation_ database

To fully leverage the value of the Automated IP Log Tool, the project team needs to:

* Keep project <<pmi-metadata,metadata>> up-to-date;
* Follow the guidelines for handling <<resources-commit,Git contributions>>; and
* Create <<ip-cq,CQ>> (CQs) where appropriate

The Automated IP Log tool populates the _Contributors_ section with information gathered from the project's source code repositories (source code repository paths specified in the the _Source Repositories_ section in the project metadata). This section lists contributions from non-committers (this is time-sensitive, so contributions made by current committers before they became committers will also be included). Only non-committer contributions are recorded in the generated log. 

<<resources-commit,Git commits>> contributed by non-committers are identified by the author credentials on the commit record; the _Author_ field must be set to the identity of the actual author of the commit.

The Third-party Software section of the log is populated from IPZilla. The IP Team will mark your contributions in such a way that they will appear in the log. If third-party software is not appearing properly, contact the {ipTeamEmailLink} to make corrections.

[TIP]
====
Use the <<pmi-commands-iplog, Generate IP Log>> tool on a specific <<pmi-project-page, project page>> in the <<pmi,Project Management Interface (PMI)>> to generate and submit the IP Log for review.
====

[[ip-faq]]
=== Frequently Asked Questions

[qanda]
Can <<ip-third-party,third-party content>>  be included in an Eclipse project's source code repository? ::

Yes. Third-party content can be included in binary form (e.g. source and binary JAR files) in a project's source code repository if that makes technical sense for the project.
+
Third-party content that is stored in the project repository as source code is effectively a _fork_ of that third-party content. This is a bit of a grey area in that it is _third-party content_ that will be ultimately treated as <<ip-project-content,_project content_>> (i.e. contributors may potentially modify it). 
+
Third-party _source code_ must be reviewed by the IP Team (i.e., open a <<ip-cq,CQ>>) before it may be included in a project repository.

The IP Due Diligence Process says that I need to create a CQ for project content contributions that exceed 1,000 lines of code; how do I calculate lines of code? ::

The short version is that the Eclipse Foundation trusts the judgment of Eclipse committers regarding how lines of code should be calculated. What we're interested in is net new intellectual property. With this in mind, it's not generally correct to just add the number of lines added to the lines removed; it's also not generally correct to use the difference of these numbers to determine the true number of lines in a contribution. Again, as a committer we trust your judgment.
+
If a contribution contains significant new functionality, or if you are not certain of the provenance or are otherwise concerned that there may be intellectual property issues with a contribution (of any size), then the IP Team needs to be engaged.
+
If you're not sure, create the <<ip-cq,CQ>>.

Can my release use unreleased content from another Eclipse open source project? ::
No. A release may only use released content from other projects. A project may disseminate milestone builds that include unreleased content, but the upstream content must be released before a downstream project can include the content in their own release.

Are project websites subject to the IP Due Diligence Process? ::
Website content is separate from project content. Project teams are expected to respect licenses for all web site content, but are not required to submit website content (including third-party libraries) for review by the IP Team.

My IP Log contains outdated third-party dependency information. How do I update this information?::
Send an email to the {ipTeamEmailLink}, providing a list of CQs to be marked as either:
+
* "unused" - not currently used, but potentially may be in the future or 
* "obsolete" - obsolete and no longer in use.
+
The IP Team will make the necessary adjustments

What is "Type A" and "Type B" due diligence?::
Versions of the Eclipse Foundation's Intellectual Property Policy prior to October 2019 referred to two different types of intellectual property due diligence, named _Type A_ and _Type B_. Project teams were able to choose the type of IP due diligence that they wanted for their project: Type A which was concerned with validating that the licenses of the content were compatible with the project license, and Type B which offered a more thorough check including provenance and other deep analysis. We phased out Type B in October 2019, and now focus solely on license compatibility for third-party content.

Do I need to create a CQ for a service release of third-party content? ::
A CQ is not required for a service release that is based on an resolved version of third-party content.

What do you do with the IP Log? ::
IP Log reviews occur in two stages. In the first stage, the EMO performs a technical assessment to make sure that the artifacts produced by the project are properly accounted for in the IP log. You may be asked to assist with the resolution of any discrepancies found during this assessment. In the second stage, the IP Team reviews the log to ensure that it matches their records. The IP log review concludes with approval by the IP Team.

When should I submit the IP Log for review? ::
The IP Log should be submitted for review by the IP Team two weeks before the planned end date for a <<release-review, review>> or (if code moves are involved) a restructuring review. Note that the date of your review may be different from the date of the actual release.

How precise must the "required by" date for the IP Log be? ::
The "required by" date is intended to give the IP Team help to prioritize the processing of the IP Log against other requirements. The date selected should be at least one week in advance of the conclusion date of any corresponding <<release-review, review>>. 

We submitted an IP Log for our release, but we've made some changes since then that will end up in the release, should we resubmit the IP Log? ::
The purpose of the IP Log review is to checkpoint the IP Due Diligence Process and ensure that nothing is slipping through the cracks; an IP Log is not intended to be an accurate reflection of exactly what is in any particular release.

Are there other reasons to submit the IP Log for review? ::
Generally no. If the IP Team requires an IP Log review outside of the context of a release or restructuring review, they'll ask for it. It is not generally necessary to submit an IP Log for review outside of the context of a review. It is, however, good practice to do your own review of the generated IP Log periodically to make sure that it accurately reflects the state of the project.
	
How do I fix problems with the generated IP Log? ::
The IP Log is generated based on data from Eclipse Foundation servers. If the log is being generated incorrectly, then the underlying data needs to be fixed. If you spot a problem, send a note to mailto:{emoEmail}[EMO].

[[ip-parallel-ip]]What is Parallel IP? ::

The parallel IP Process allows {aForgeName} projects to make use of project code contributions and third-party content before they are fully approved by the IP Team. In versions of the IP Policy prior to 2019, projects needed to meet specific requirements to be able to leverage the Parallel IP. This is no longer the case: full vetting is now always applied in parallel in all cases.