At our recent face-to-face Board meeting earlier this month, an agreement in principle was made to move ahead with the largest overhaul of our intellectual property processes since the inception of the Eclipse Foundation 12 years ago. Now, don’t get too excited because months of work are going to be required before the new policies are approved, and the implementation of new processes are completed. But I did want to share the direction we are heading in with the community to get your input and feedback.
What do we do today?
The Eclipse Foundation takes a very rigorous approach to intellectual property management. As far as I know, we are the only open source foundation to have a dedicated staff whose sole responsibility is the review all of the code distributed by Eclipse Foundation projects. The easy part is the code that is written by Eclipse committers. The far more time-consuming piece is a detailed review of all of the dependencies used by or distributed with Eclipse projects. That dependency review includes checking license compatibility, scanning the code to look for potential issues, and checking in on the provenance of the code in question. That last piece (“provenance”), can be particularly time-consuming because it involves answering questions like “was the code ever re-licensed from licenseA to licenseB, and if so how was permission obtained from the contributors?”. Or “how does this project manage contributions to it?” To my knowledge, no other open source foundations or communities do the level of detailed analysis that we do.
The good news is that the Eclipse community and the IP team staff at the Eclipse Foundation can take a great deal of pride in knowing that what ships from Eclipse has been well reviewed, and can be safely consumed by users and adopters in downstream products. The bad news is that this is a lot of work for the projects, and can be very time consuming for everyone involved.
What are we changing?
The proposal is pretty simple. In the future Eclipse projects will be able to decide what level of IP due diligence they want performed for each of their releases. For the purposes of this discussion, let’s call them “Level 1” and “Level 2”, although there is a high probability that those labels will change.
“Level 2” “Type B” is what we do now. No change.
“Level 1” “Type A” takes a much simpler approach for dependencies. Basically, all that will be checked is license compatibility with the project license(s). We won’t do code scans or provenance analysis of any of a Level 1 Type A project’s dependencies. However, all of the existing processes around managing the code which is developed by or contributed to Eclipse projects will continue. (This includes things like committer agreements, CLAs, and git signed-off-by, etc.)
The decision on which level type a project wants can be specified on a per-release basis. So, for example, if a project wants have a very fast release cycle (e.g. ship something every 4 weeks) but still wants to ship a fully reviewed major release once a year, that would be a supported use case. The authority to make this decision rests with the project lead for the project.
This new approach will have particular value for new projects at the Eclipse Foundation. Rather than waiting for their dependencies to be cleared by the IP team, once the project can self-certify that all of their dependencies have compatible licenses they will be able to check-in their code and start working at Eclipse. We are hoping that this is going to reduce the ramp-up time for a new project from months to about a week. As part of making this happen we will need to find a scan tool which give an accurate report of licenses contained in code artifacts that is usable by developers. If anyone knows of any such tools, please let me know!
Why are we doing this?
There are lots of reasons, ranging from resources to agility to changing industry perceptions around risk in open source. But the most important one is that we want to help Eclipse projects be more successful. We have a lot of process that our projects need to deal with, and for a great many of them the IP requirements exceeded what their users and adopters required. So the time for a re-calibration has come.
When is this going to get done?
It’s hard to say with certainty, but our goal is to have this fully implemented by the end of this year. There are two major components to making that happen:
- We have to make some significant changes to the Eclipse Foundation IP Policy, and have those reviewed and approved by the Board of Directors. That is going to take a few months.
- We need to implement some changes in our tools and processes to support this. That includes changes to the Project Management Infrastructure (PMI) to track the IP
levelreview type for a release, finding and hosting a license scan tool that committers can use to self-certify their dependencies, etc.
Where do we discuss this?
I’ve opened bug 496959 to discuss this, and to track all of the pieces that will go into its implementation. I am really looking forward to hearing from the community about this proposal. Personally, I am very excited by it, and think that a lot of projects will be as well.
Caveat: All of this assumes that the necessary changes are approved by the Board of Directors. The Board makes the call on these policies, and when they see the final edits to the IP Policy perhaps they will have a change of heart. But obviously if I thought that outcome wasn’t a high probability I wouldn’t be talking about this yet.
Edit: The original post has been edited to reflect that the we’ve decided to refer to the IP reviews as “Type A” and “Type B”, rather than “Levels”.
