Revising the Eclipse IP Policy: Contribution Questionnaires

Posted on 3 mins read

The Eclipse Foundation is in the process of making a major update to our Intellectual Property Policy. The Eclipse Foundation’s Board of Directors voted in favour of the revisions during their October 21, 2019 meeting. Now comes the hard work of actually updating our processes that implement the policy.

For Eclipse project teams, the important changes are these:

  • The definition of Distributed Content has been updated to refer only to content associated with a Release;
  • Third-party content due diligence be concerned with license compatibility only; and
  • Parallel IP applies in all cases.

Prior to this revision, the notion of distribution applied to everything. Every file on the download server, every reference to third party content, and every Git commit was considered a form of distribution; and every form of distribution was subject to the IP Due Diligence process. That is, the Eclipse Foundation’s Intellectual Property Team (IP Team) was required to review most project code contributions, and every leveraged third-party library before an Eclipse Project team could use it. This also required, because we just didn’t have the resources to fully vet the entire history, that existing projects moving to the Eclipse Foundation would have to collapse and cut off their history.

With this change, every single Git commit is no longer considered to be distributed content. So, to start, existing projects that move to the Eclipse Foundation no longer have to collapse their history. Further, project teams can now push commits that reference third party content without first checking that third party content with the IP Team. Likewise, milestone builds on the download server are also not considered distributed content, so they too may leverage and reference content without first checking with the IP Team.

Before a project team may make a release (as that term is defined in the Eclipse Development Process), the team must validate that their content is all license compatible with the project. We do this today as part of the IP Log review that accompanies a release review. We will continue this practice with a bit of a change: in addition to the IP Log that we generate automatically based on data managed by the Eclipse Foundation, we’re going to need project teams to provide us with a list of content (bill of materials) that’s included in the release (see how this looks for Maven builds).

Validating at the end of a development cycle is just asking for trouble, so project teams need to do two things:

  • Apply some reasoning regarding third party content (and transitive dependencies thereof) to ensure that what they select is under licenses that are likely compatible with the project license; and
  • Use tools that we provide to periodically validate that their project content is compatible with the project license.

Note that all content, including the transitive dependencies of leveraged third party content is subject to the Eclipse Foundation’s Intellectual Property Due Diligence Process.

It’s important to note that we’re not asking project teams to vet their own content, only that they apply some entry-level reasoning about the content that they choose to leverage. The IP Team will be available to help when project teams identify content for which the license is not clear, or is otherwise confusing. The same tools that the IP Team uses to assess licenses (and identify problematic content) will be accessible to all; ideally, these tools will be integrated into build workflows so that issues can be identified and addressed early.

Unsurprisingly, the question that we’ve been asked the most is “do I need a CQ?”

Stop creating piggyback CQs right now.

As we move forward, CQs will only be required for content that require scrutiny by the IP Team (and for content that includes cryptography; more on this topic later).