Intellectual Property

In the world of open source, Committers are ones who hold they keys. Committers decide what code goes into the code base, they decide how a project builds, and they ultimately decide what gets delivered to the adopter community.

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.

This post is based on a talk that Gunnar Wagenknecht and I delivered at the Open Source Leadership Summit 2017 and Devoxx US 2017. This content was recently published in the All Eyes on Open Source issue of JAX Magazine.

In 2016, we introduced the notion of license certification intellectual property (IP) due diligence (“Type A”) into the Eclipse IP Policy with a goal in mind to automate the certification process. At that time, we started a process of evaluating tools that could be used for automatic validation and eventually discovered Scancode.

Late last week, I pushed out an update to our documentation regarding the legal documentation requirements for Eclipse projects that Sharon Corbett and I have been working on over the past quarter. In the process, we moved the guidelines off of the main website and rolled them in to the Eclipse Project Handbook. Our primary goal in revising this documentation was to make it more generally applicable to all open source projects and bring us more in line with what the rest of the open source world does.

The Eclipse Intellectual Property Policy defines two types of intellectual property (IP) due diligence for third party content. The so-called Type A Due Diligence is concerned exclusively with license certification; and Type B Due Diligence is concerned with license certification, provenance checking and a deep dive scan of the content for various anomalies.

Regarding the analysis of Type A third party content, the IP Policy makes this statement:

Some time ago, the Eclipse Foundation’s Board of Directors passed the following resolution.

RESOLVED, that previously approved dependencies of Eclipse projects can be reviewed and approved by the EMO as follows: a) Service releases (e.g. x.y., bug fixes, security fixes) will require no review. b) Minor revisions (e.g. x..) will require a reduced review by the EMO. c) Major revisions (e.g. ..) will require a full review by the EMO.

All third party content must be taken through the Eclipse Foundation’s Intellectual Property (IP) Due Diligence Process before being used by an open source project hosted by the Eclipse Foundation. This includes all third party content that is incorporated into project code, included in builds, or otherwise required by the project code to provide functionality.

The Eclipse Foundation’s Intellectual Property (IP) Policy was recently updated and we’re in the process of updating our processes and support infrastructure to accommodate the changes. With the updated IP Policy, we introduced the notion of Type A (license certified) and Type B (license certified, provenance checked, and scanned) due diligence types for third-party dependencies that projects can opt to adopt.

Long-time Eclipse Committer, Ian Bull initiated a interesting short chat on Twitter yesterday about one big challenge when it comes to intellectual property (IP) management. Ian asked about the implications of somebody forking an open source project, changing the license in that fork, and then distributing the work under that new license.