I’ll start this discussion with some background…
Under the original Eclipse Foundation Intellectual Property (IP) Policy, every bit of third party content needed to be thoroughly reviewed before it could be used by an Eclipse project. And the reviews were thorough: license scan, provenance check, scan for anomalies, … Reviews of third party content literally took days, weeks, and months. All of that review needed to be complete before the project team could commit any code that made any reference to that third party content.
As you might imagine, the time required to engage in all of that analysis was somewhat inconvenient for project teams, so we introduced the notion of Parallel IP. The idea behind the introduction of Parallel IP was that the IP Team could perform a cursory check of the content and grant checkin, thereby authorizing the project team to commit code into their repository that leverages the content, while the IP Team engaged in their more thorough review in parallel. The project team needed to wait until that thorough review was complete before engaging in a release. Initially, Parallel IP was available only to Eclipse projects in the Incubation Phase; it was later extended to Eclipse projects in the Mature Phase, but only for new versions of third party content that had already been reviewed and approved.
Parallel IP made the process better. Committers only had to wait for a day or two before they could leverage new third party content. It worked well for those Eclipse projects that engaged in annual releases, but as more and more Eclipse projects increased their release frequency, the time required to complete reviews of third party content (and the lead time required to engage with the IP due diligence process ahead of a release) became a problem (it’s likely more accurate to say that the existing problem became more acute).
To accommodate those projects that needed to move quickly, we introduced the notion of license check only IP due diligence and gave Eclipse project teams the ability decide what sort of IP due diligence they’d like to engage. We helpfully labeled the new type of IP due diligence as Type A (license check only) and the classic thorough IP due diligence as Type B (license check, provenance check, and anomolies scan). We introduced some automation that leveraged open source tools to scan and automatically approve third party content submitted for Type A review. Based on the rate of adoption, Type A was very successful.
It’s worth pointing out that our Type A, even though it is less thorough than our Type B IP due diligence, it is still far more than any other open source organization does. In fact, our Type A provides a far more thorough review of third party content than most organizations engage in.
While the introduction of Type A made the IP due diligence process flow faster for Eclipse project teams, it didn’t address the underlying problem: that the process required that every single bit of third party content must be reviewed before it can be used in any capacity.
The October 2019 updates that we introduced to the Eclipse Foundation’s IP Policy changes an important definition that lets us turn the process around. The definition of the term Distributed Content had previously forced us to implement a process that required the review of all third party content before any use or reference to it could be committed to an Eclipse project’s source code repository. By narrowing the definition of Distributed Content to refer only to content that is included in a release, Eclipse project teams may now push commits that reference third party content without first checking with the IP Team during a development cycle. It’s only when it comes time to release that we need to certify that the third party content included in and referenced by the release is license compatible.
This change shifts some of the onus onto the project team. Before pushing a commit that leverages third party content, a committer will need to (at least informally) check to see if the license on that content is compatible with the project license. We’re not expecting that project committers do any sort of deep analysis, only that they review the licensing terms on the content (if the third party content’s license in on the Eclipse Foundation’s Approved Licenses list, then you’re probably okay). If there’s any question, or a committer feels that shenanigans might be afoot, they can engage with the Eclipse Foundation’s IP Team for help. Primarily, committers need to provide some scrutiny to the license of the content that they adopt to avoid surprises when it comes time to certify compliance ahead of a release.
With no requirement to review content in advance, there is no requirement to engage with the Eclipse IP Team via contribution questionnaires (CQs) for every single piece of third party content. Instead, we can leverage the vast database of intellectual property metadata that we’ve assembled over the years to validate an entire dependency list as a unit (I posted about this a couple of weeks ago). For those readers who have been part of our community for a while, this means that there is no longer any requirement to create piggyback CQs. Further, we’re leveraging other sources of intellectual property metadata (e.g., ClearlyDefined), which means that there is generally no longer any requirement to create CQs of any kind. In practice, we will continue to use CQs to engage the Eclipse IP Team to research and vet content for which information is not already available, or to investigate content when we detect shenanigans (we will also continue to use CQs to track project code and third party content that includes cryptography).
Our intent is to make as many of the changes work as possible using the process and infrastructure that we currently have in place. In 2020, we will start researching and evaluating new tools; our hope is that we will be able to implement our updated process using existing open source tools. In the meantime, we have some tools that we’ve been using internally to validate license compliance of third party content and are working on making these tools available in a form they can be leveraged by committers (we’ve just started capturing requirements on, and will track progress using Bug 553016).
We’ve only just gotten approval for the policy changes and have only just started implementing process changes. We appreciate your patience and we work to make all of this happen. We’re tracking our progress on Bug 552967.
