Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://www.eclipse.org/projects/handbook/ below:

Eclipse Project Handbook | The Eclipse Foundation

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 identify issues and mitigate the risk of leveraging the work of others. IP due diligence is a time consuming process that requires specialised skills and a keen eye for detail.

The Eclipse Foundation’s IP Team does not (and cannot) give legal advice. Rather, the team leverages their experience, along with various resources, to identify licenses in content, and make judgement calls as to whether or not licenses be being used in a consistent and compatible manner.

There are different kinds of content (e.g., source code, documentation, and images) to consider. For the purposes of the Eclipse Foundation’s IP Due Diligence Process, we consider all types of content, not just code, to be intellectual property that is subject to the process (even when we say code--especially in the context of IP due diligence—​you should assume that we mean content).

Project content is content (typically source code) that is produced and maintained by the open source project committers and contributors. 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.

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.

If you’ve been around for a while, you may be looking for things that no longer exist. We’ve retired IPZilla along with the term Contribution Questionnaire, we’re now able to leverage a wider variety of open source licenses, and we lean much more heavily on automation than ever before. There’s more information about these changes in the History section of this chapter.

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 images or 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. Project teams should organise content in their source code 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.

The Eclipse Foundation Development Process 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 their content before it is fully vetted by the IP Due Diligence Process, but all content must be fully vetted before the project can engage in a formal release.

The means for committers to engage in the IP Due Diligence Process is by creating a review request issue.

The Eclipse Foundation has a well-defined 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 an Eclipse open source project will leverage third party content, are responsible for bringing IP issues to the attention of the IP Team.

The Eclipse Dash License Database (or, more simply, the Dash Database) is a database that contains the license information collected via the Eclipse Foundation Intellectual Property Due Diligence Process. It contains license information gathered and curated by the Eclipse Foundation’s IP Team. The Dash Database is accessed via API only; the Eclipse Dash License Tool is the primary means of accessing this resource.

IPLab is a repository on the Eclipse Foundation’s GitLab infrastructure that is dedicated to tracking the due diligence review process and conclusions for Eclipse project and third party content. Issues on that repository are used to request reviews, and track the review process and results.

Data collected in IPLab is used as a source for the Eclipse Dash License Database.

ClearlyDefined is an OSI project that combines automated harvesting of copyright and license information from software repositories and curation thereof by trusted members of the community to produce a massive database of information about content. The Eclipse Foundation’s IP Team works 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 due diligence process using ClearlyDefined data, then no further action is required. The Eclipse Dash License Tool uses ClearlyDefined as a source of license information (and is the easiest way for Eclipse committers to leverage ClearlyDefined).

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

In the time since we made this decision, Package URL has emerged as a superior choice. We will update our services to use Package URLs by early 2025.

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 namespace and name, and version/revision. 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.

ClearlyDefined is used as part of the overall due diligence process for third party prerequisites. The Dash Database is the primary source of information regarding third party licensing for Eclipse projects. In cases where the Dash Database and ClearlyDefined results differ, the Dash Database results take precedence.

When content is known to ClearlyDefined and has a Licensed score of at least 60, the declared and all discovered licenses are on the Eclipse Foundation’s approved licenses list, and all of the licenses are mutually consistent, then the content can be used without further action.

Note that when the ClearlyDefined record shows any of the following, a project committer must engage with the IP Team to review the content (use the Eclipse Dash License Tool):

• NOASSERTION appearing as a declared license;

• NOASSERTION appearing as a discovered license;

• No declared license; or

• A License score of less than 60.

When an existing project migrates to the Eclipse Foundation, we refer to the existing code (when one exists) as the Eclipse open source project’s initial contribution. An initial contribution is basically the first set of project code contributions to the new Eclipse project. An initial contribution typically takes the form of an entire existing source code repository or some snapshot of an existing code base.

All Eclipse open source project content must be kept in source code repositories that are managed by the Eclipse IT Team. Our current options are GitLab or GitHub.

In the case of an existing repository, the project team has some choices:

Move the existing repository. At the project team’s request, the Eclipse IT Team can move existing source code repositories on GitHub into an organisation managed by the Eclipse Foundation. This is the best option when a project team wants to preserve their repository’s status with existing forks, retain existing issues, stars, etc. If the repository is private, it must be made public before the move. Note that GitHub does a good job of setting up redirects that will ensure that the project’s existing community can find them.

Push to a new repository. At the project team’s request, the Eclipse IT Team can create new source code repositories on either GitLab or GitHub into which the project team can push existing content. This option is best in the case that there is good reason to leave an existing repository in place, or when a project team needs to move an existing private repository into the open. The project team can decide whether or not to push the entire history or just a snapshot from the existing repository. As a best practice, an existing repository that gets "left behind" should be updated to include a pointer to the new repository and marked as archived.

Combinations are also possible. As part of the Eclipse open source project creation process, the EMO asks the project team to capture their requirements and will facilitate discussion between the project team and the Eclipse IT Team to implement those requirements.

We must complete the open source project creation process before we move any existing source code repositories or create new ones. Following a successful Creation Review, the EMO will initiate the provisioning process. It is during the provisioning process that we activate project committers, move/create source code repositories, and create other project resources.

The short version of the process is this:

• Complete the proposal process and creation review;

• Project team and EMO works with Eclipse IT Team to set up source code repositories;

• The EMO initiates the intellectual property review of the default branch of all repositories; and

• The EMO IP Team will inform the EMO when the reviews are complete

As a general rule third party content should not be included in project repositories. Typically, third party content is pulled in by some form of build process after developers have cloned the repository (for example, developers might pull in required NPM modules via a package-lock.json file).

In the case where third party content must be represented in a project repository, we would consider that a project code. Whether or not the content is modified, it would effectively be considered a fork.

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

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 content that is contained in a source code repository that is owned and managed by the Eclipse Foundation on behalf of an Eclipse 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 of content.

Contributions made by Eclipse committers do not require review by the Eclipse IP Team and can be pushed directly into a project repository. Notwithstanding project-specific rules, project committers can push their own content directly into project repositories. While content produced by other Eclipse committers does not require review by the Eclipse IP Team, it must still be accepted by project committers. Project committers should engage the Eclipse IP Team if they have concerns regarding the provenance of any contribution.

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

All contributors must sign the Eclipse Contributor Agreement (ECA).

Further investigation is required when any of the following conditions are met:

• The content has been copied, or is based on content that has been copied (that is, the content was not 100% authored by the submitting contributor);

• The licence terms of the content are other than the terms of the project license;

• The content contains cryptography; or

• The content contains more than 1,000 lines of content (including documentation, code, configuration files, and other forms of source code).

When further investigation is required, a project committer must engage with the IP Team to request their review before the contribution is pushed/merged.

Do not change the licence of content that you copy or fork.

Any project committer can engage with the IP Team to review a project content contribution. 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.

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).

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 to request assistance.

The term third party content refers to any content that is leveraged by the Eclipse project that is not produced and/or maintained as an asset of the project. This includes content from other Eclipse projects.

This includes (for example):

• References in a Java®/OSGi manifest that makes a direct reference to third party content (either a bundle or package);

• Imports of packages in Java source;

• Includes of header files in C/C++;

• References to NPM modules via a package.json, package-lock.json, or yarn.lock file;

• References to Go modules via a go.sum file;

• Entries in the dependencies section of a Maven pom.xml file;

• Use of reflection or other means to reference APIs and implementation;

• Use of OSGi Services to make a reference to a specific implementation of a service; and

• Invocation of a command line interface.

This is list is not exhaustive. The exact nature of the dependencies and how they are specified varies from technology to technology.

The set of dependencies also includes third party content that is referenced by third party content, whether or not it is directly referenced by the Eclipse project content. That is, the dependencies of an Eclipse project includes the entire transitive closure of the immediate dependencies.

Eclipse Project Dependencies

The pedantic reader will observe that one can follow the chain of dependencies all the way down to silicon.

We cut the dependency graph off at the platform. The definition of platform varies by technology and intention. In general, we regard the platform as the layer(s) that adopters of the Eclipse software install independently as a foundation for the project software.

For example:

• For a Java-based application, the Java runtime would be the platform;

• For an application based on Jakarta EE technology, the application server would be the platform;

• For an NPM application, node would be the platform; and

• For a native application, a Linux based operating system, Windows, or MacOS would be the platform.

This is list is not exhaustive.

We regard the platform as something that the adopter installs and agrees to the licensing terms independently from the project content. If you’re bundling the platform with your project’s binaries, for example, then the platform is a dependency. If a layer of software is installed as part of installing your project’s artifacts (e.g., via Maven), then that layer of software is a dependency.

If you’re not sure ask the IP Team for assistance.

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

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).

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.

Visualisation of the dependency graph (the Maven type and scope have been removed for brevity)

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 vetted for license compatibility.

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.

This section 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 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).

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

Perhaps the most challenging aspect of intellectual property due diligence is determining whether or not content distributed under one license may consume content distributed under a different license. All too often, the answer is: "it depends".

Our goal is to provide as much information as possible so that, ultimately, the adopters of Eclipse project code (with assistance from their own legal counsel) can decide whether or not licenses are consistent and compatible.

Our approved licenses page lists licenses that we believe are generally compatible with most Eclipse project licenses. As stated on the page, "licenses on this list are not necessarily compatible with every Eclipse Foundation project license, or with each other."

Licenses that are not included on this list are not necessary prohibited. Rather, they may require more thought and careful review.

When in doubt, check with the EMO IP Team.

If your project leverages build technology that pulls third party content from well-defined software repositories (e.g., Apache Maven pulling from Maven Central, a yarn.lock or package-lock.json file), consider using the Eclipse Dash License Tool to automatically create IPLab issues for you.

Note that the Eclipse Dash License Tool is only capable of creating issues for content that it either discovers from your build or that you feed to it. It will not, for example, find third party content that is buried in your code. If you’ve, for example, added some JavaScript library in a lib directory or similar, then you may have to manually create a request to vet that content and manually track your project’s use of that library.

If you cannot use the Eclipse Dash License Tool, you can manually create a request:

Project Content is any content that will be maintained by the project team. Basically anything that a contributor or committer will put into a project’s source code repository (generally in source form) is project content. This includes content that the project team forks (the premise being that forked content effectively becomes indistinguishable, at least conceptually, from project content).

Note our careful use of the term content. This includes source code, documentation, configuration, etc.

Third party Content is defined as content that is leveraged or otherwise referenced by project code. Third party content is typically (although not necessarily) acquired from software repositories (e.g., Maven Central or NPMJS) during builds.

When creating a review request issue, please provide as much information as you can. If information is missing, or you are not certain how information should be provided, provide what you can and the IP Team will work with you to sort it out.

GitLab issue use Markdown, so use Markdown syntax when specifying information. Our scanners parse information out of the issue description, and so are most likely to be successful (and require less time-consuming manual intervention) if you stick to the format specified.

Set the title to a valid identifier

Multiple kinds of identifiers are supported. When you use one of the supported formats, IPLab will use the information provided locate the source. Issues that have a valid supported identifier for a title will be automatically processed and so will likely be resolved quickly.

The following identifier formats are supported:

• ClearlyDefined ID: {type}/{source}/{namespace}/{name}/{revision}

• Maven GAV: {groupid}:{artifactid}:{revision}

• Package URL: pkg:{type}/{namespace}/{name}@{revision}

• GitHub Commit URL: https://github.com/{org}/{project}/commit/{ref}

• GitHub Pull request URL: https://github.com/{org}/{project}/pull/{id}

Setting the title to any of the following identifiers (which all resolve to the same content), for example, will point IPLab to the same source:

• maven/mavencentral/org.apache.maven.enforcer/enforcer-api/3.1.0

• org.apache.maven.enforcer:enforcer-api:3.1.0

• pkg:maven/org.apache.maven.enforcer/enforcer-api@3.5.0

IPLab will resolve the source for a pull request to the patch file that corresponds to the pull request. Patch files always require a manual review from the IP Team.

Don’t include extra information in the title. If you need to provide extra information, add it to the description.

Identify the Eclipse open source project

We need you to identify the Eclipse open source project that is accepting this contribution. Note that we need you to specify an Eclipse open source project, not a GitLab or GitHub project (provide that in the Git repository field).

In the template replace <project name> with the name of your Eclipse project (e.g., Eclipse Dash) and <project id> with the project’s id (e.g., technology.dash):

Project: [Eclipse Dash](https://projects.eclipse.org/projects/technology.dash)

Provide Basic Information

In the Basic Information section, provide as much information as you can, including the license of the content as you understand it as an SPDX identifier, and URLs that points to the binary and sources of the content.

Provide a Pointer to Source

The Source field is the important one. The scanner looks for content of the form:

[Source](<url>)

We need pointers to specific versions of content, ideally in an archive format (e.g. a ZIP file). That is, please do not provide a pointer to a repository on GitHub; rather, provide a pointer to a specific downloadable ZIP archive associated with the particular release.

For example:

[Source](https://github.com/kataras/iris/archive/refs/tags/v12.1.8.zip)

We need to have a source pointer. If you cannot (or do not) provide it, processing will be delayed while we hunt it down.

The source must be one of the following:

• A URL pointing to an archive (e.g., *.zip, *.tar.gz)

• An attachment;

• The URL for an Eclipse GitLab merge request (e.g., https://gitlab.eclipse.org/eclipse/technology/dash/org.eclipse.dash.handbook/-/merge_requests/1); or

• The URL for a GitHub pull request, (e.g. https://github.com/eclipse/dash-licenses/pull/278).

If you’re not sure, do not provide source pointer; instead, describe the information you do have and the IP Team will configure the request accordingly.

The value you provide for the source pointer will short circuit any attempt by IPLab to automatically identify the source. That is, IPLab will always use the source pointer that you provide.

Provide additional Information

Please provide any additional information that you think might be useful to assist the IP Team in resolving this issue in free form text after the basic information.

Don’t Apply Any Labels

The scanner will only automatically scan issues under the following conditions:

1. The issue is open;

2. The issue has a valid ClearlyDefined id; and

3. The issue either has no labels or has the Review Needed label applied.

   Issues that do not meet these criteria are ignored.

If you’re only pulling in a subset of the source code and have the means to bundle that up into a ZIP file, you can use that ZIP file as an attachment.

When you drop an attachment on the GitLab issue, you’ll see something like this in the text:

[built-in-extensions-1.64.2.tar.gz](/uploads/9d97a24028eb76fab91a139945d1e005/built-in-extensions-1.64.2.tar.gz)

The scanner will know what to do if you change it to:

[Source](/uploads/9d97a24028eb76fab91a139945d1e005/built-in-extensions-1.64.2.tar.gz)

FWIW, it also handles the case when just drop the attachment as the URL (this is not supported by Markdown, so it may not render as expected, but the tool can deal with it):

[Source]([built-in-extensions-1.64.2.tar.gz](/uploads/9d97a24028eb76fab91a139945d1e005/built-in-extensions-1.64.2.tar.gz))

The Eclipse Dash License Tool takes a list of dependencies as input, 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). It is available as both a command-line interface and a Maven plugin.

The Eclipse Dash License Tool is intended to assist with the process of determining the licenses of third party content and help committers 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 queries the Eclipse Foundation’s Dash Database;

  • 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 already been flagged as either approved or restricted to 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.

An Maven plugin is provided that can be used by project teams that leverage Maven pom.xml files for build.

The Eclipse Dash License Tool’s Maven plugin in action

A CLI interface is also provided. 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 Eclipse Dash License Tool’s README (e.g., 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.

The Eclipse Dash License Tool can create issue against IPLab for content that any content that the tool determines requires further review by the IP Team.

To use this feature, you must:

• have committer status on an Eclipse project; and

• get an authentication token (scope: api) from gitlab.eclipse.org;

When using the command-line version of the tool:

• include the -review option;

• pass the token via the -token option; and

• pass the project id via the -project option.

When using the Maven plugin:

• pass the token via the -Ddash.iplab.token=<token> option; and

• pass the project id via the -Ddash.projectId=<project> option.

For example:

$ mvn org.eclipse.dash:license-tool-plugin:license-check -Ddash.projectId=technology.dash -Ddash.iplab.token=...

Do not share your access token.

Eclipse open source projects are required to track their intellectual property contributions, as well as their use of third party content. We rely on the Git log to track contributors and contributions.

Eclipse open source projects are required to maintain a software bill of materials (SBOM). Project teams should leverage standard SBOM formats such as SPDX or CycloneDX. "About" files (about.html) serve this purpose in Eclipse Platform plug-ins, and NOTICE files or summary files generated using the Eclipse Dash License Tool can also serve as SBOMs.

Please ensure that any merge/pull requests that come to you project correctly identify the contributor and that the contributor is covered by the Eclipse Contributor Agreement. Further, ensure that your project’s third party content is accounted for in either a notice file (consider using the summary output from the Eclipse Dash License Tool to generate this).

OpenChain ISO/IEC 5230:2020 defines the key requirements of a quality open source license compliance program. The Eclipse Foundation IP Due Diligence Process is self-certified as OpenChain ISO/IEC 5230:2020 conformant.

As part of a progress or release review, the EMO validates that the project is correctly implementing the Eclipse Foundation intellectual property due diligence process. Upon successful completion of the review, the project can claim OpenChain conformance for a year (after which the project team need to engage with in another review).

The EMO list of projects that we consider to be in good standing with regard to implementing the Eclipse Foundation Development Process and Intellectual Property Due Diligence Process, and — by extension — are regarded as OpenChain conformant. Eclipse projects in good standing can claim ISO/IEC 5230:2000 conformance.

Eclipse projects that are in good standing may opt to display an OpenChain ISO/IEC 5230:2020 Conformance Badge on their website.

The Eclipse Foundation’s Board of Directors has approved various updates to the Eclipse Foundation’s IP Policy over the years that have introduced significant changes in our IP due diligence process. In this section, we highlight some of them.

The 2022 update to the Eclipse Foundation’s IP Policy, approved by the Board of Directors in June 2022, resulted in the following changes:

The Eclipse Public License is no longer special. The Eclipse Foundation was originally conceived as a single-license foundation, but that hasn’t been true for a very long time. With this change, we acknowledge that our open source projects leverage a variety of licenses and that no single one among them is special (but we still love and highly recommend the Eclipse Public License). All language and provisions that positioned the Eclipse Public License as being in any way special have been removed from the IP Policy.

Focus on License Compliance. With this change we’ve switched to focus entirely on license compliance. Specifically, our IP Due Diligence focuses on ensuring that the licenses involved (both project and third party) are co-compatible (that is, do the licenses actually work together) rather than conforming to a list of licenses that have been deemed acceptable. The IP due diligence process still reviews content to ensure that we understand the state of the content licenses, and continues to rely on existing sources of license information in the reviewing process.

With this change, we can no longer assume that Eclipse open source projects can just use the products of other Eclipse open source projects without license compatibility checks. Due to the fact that our projects have been using a variety of licenses for some time, this isn’t actually new, but we’ve highlighted it here to draw attention to the fact that we are putting additional focus into reviewing license compatibility, and this extends to Eclipse open source projects using other Eclipse open source projects.

License approval processes are managed by the EMO without requirement for Board approvals. We are no longer required to go to the Board of Directors to get approval for our open source projects to use content under licenses that we haven’t encountered. We no longer have a strict "approved licenses" list. There are still restrictions on what licenses can be used, but these restrictions are based on whether or not the licenses actually work together and whether or not license terms align with our open source rules of engagement (e.g., licenses do not restrict fundamental freedoms).

The Guidelines for the Review of Third Party Dependencies as been revoked. This is related to our focus on license compliance. The Guidelines for the Review of Third party Dependencies described notions of prerequisite, works with, and exempt prerequisite dependencies which provided different mechanisms by which third party content could be consumed by Eclipse open source projects (works with and exempt prerequisite in particular described means by which we could short circuit the due diligence process for content under licenses that might otherwise not be supported by the then-IP Policy). WIth our focus on license compliance, these considerations are no longer necessary.

IPLab replaces IPZilla. We announced the retirement of IPZilla in September 2022 and moved aggressively to retire it completely by the end of December 2022. IPZilla was the tool that we used to request and track the progress of intellectual property reviews. With this update to our process, we now use IPLab, an issue tracker and repository on our GitLab infrastructure that we use to request and track intellectual property reviews. The Eclipse Dash License Tool integrates with IPLab to automate much of the process of requesting reviews (which required significant manual work with IPZilla).

No more Contribution Questionnaires. With the retirement of IPZilla, we also retired the term contribution questionnaire along with its acronym, CQ. You can call the issues on IPLab whatever you want: issues, IP review requests, tickets, etc.

SBOMs replace IPLogs. Eclipse open source projects are no longer required to submit an IP Log as part of a progress or release review. Instead, we rely on the Git log to track contributions to a project along with a Software Bill of Materials (SBOM). At the time of this writing, SBOMs take several different forms. For our immediate purposes, about.html files serve this purpose in Eclipse Platform plug-ins, and NOTICE files or summary files generated using the Eclipse Dash License Tool serve as SBOMs. In the future, the EMO will work with projects to leverage standard SBOM formats such as SPDX or CycloneDX.

Automate everything that can be automated. We’ve implemented some tools, starting with the Eclipse Dash License Tool to automate as much of the process as possible. We continue to investigate options that improve the quality of our results while reducing the amount of investment required by committers and the EMO.

The 2019 update to the Eclipse Foundation’s IP Policy, approved by the Board of Directors in October 2019, makes the following changes:

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 Dash Database and ClearlyDefined. The Dash Database has been painstakingly built over most of the life span 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, 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 an Eclipse Project. The IP Policy updates turn this around. Eclipse 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 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 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 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 CQ as a snapshot of the HEAD state of the existing repository (if any).

The due diligence process for project content is unchanged.

1. Can 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 fuzzy area in that it is third party content that will be ultimately treated as project content (i.e. contributors may potentially modify it).

   Third party source code must be reviewed by the IP Team (that is, open a Content Review Request) before it may be included in a project repository.

2. The IP Due Diligence Process says that I need to request a review 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 judgement 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 judgement.

   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 a Content Review Request.

3. 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.

4. Are project websites subject to the IP Due Diligence Process?

   Project website content is separate from project content. Project teams are expected to respect licenses for all website content, but are not required to submit website content (including third party libraries) for review by the IP Team.

5. 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.

6. What is Parallel IP?

   The parallel IP Process allows an Eclipse 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.

7. Do I have to use the Eclipse Dash License Tool?

   No. The Eclipse Dash License Tool is provided as a convenience. It works with a variety of technologies, but not all.

8. Can I count on the Eclipse Dash License Tool to detect all of my third party dependencies?

   No. In fact, the Eclipse Dash License Tool doesn’t actually detect any dependencies. The Maven plugin uses the dependency resolution mechanism that is built into Maven, so the Maven plugin only knows what Maven knows. If your Maven-based build does funky things like grab code from random URLs, the tool won’t detect that. For other technologies, the command-line version of the Dash License Tool only knows about the dependencies that you send to it.

9. What happened to IPZilla and Contribution Questionnaires (CQs)?

   IPZilla was retired in 2022 and replaced with IPLab. We’re all taking steps to purge the term CQ from our brains.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4