The Eclipse Foundation is home to a family of projects related to enterprise software development. Its Executive Director Mike Milinkovic has very kindly supplied the data for an Open-By-Rule evaluation. In his submission Mike actually scored the first point higher and I reduced his +1 for “open” down to zero because the Board is controlled by paid seats, but otherwise I agree with his evaluation, giving an overall score of +8 on the -10 to +10 scale. Eclipse definitely qualifies as “open-by-rule” according to the benchmark.
| Rule | Data | Evaluation | Score |
| Open, Meritocratic Oligarchy | Directors | The Board of Directors is a mix of “Strategic Members” and elected members representing the community. There are a total of six elected representatives on a board of eighteen. There are no seats reserved for any company. Each Strategic Member company must re-commit both its dollar and headcount (8 FTE) commitments to Eclipse on an annual basis. Score 0 for pay-to-play-controlled Board that does no harm to the overall community.
(Mike notes: “Although some may question the notion that there is a meritocracy involved where there Board has many corporate members who are there by virtue of their financial and resource commitment to the community, in practice this works extremely well. What we have ended up with is a mix of large and small companies who are strategically committed to the success of the community. This commitment is tangible and re-evaluated annually.” ) The Architecture and Planning Councils share a similar mix, but the vast majority of members are there by virtue of their activity or leadership of a Project Management Committee. In the case of the Architecture Council, the vast majority of members have been elected by the existing members based on clearly meritocratic basis. Score +1 for meritocratic, +1 for oligarchy, in the technical leadership. |
+2 |
| Modern license | Eclipse Public License v1.0 | The EPL is an OSI-approved license with a well-written patent license clause very similar to that of the ASL 2.0. The EPL is a “weak copyleft” license and is particularly well suited as a license for a shared platform for an ecosystem that includes both open source and commercial adopters. | +1 |
| Copyright accumulation | There are no copyright assignments at Eclipse at all. | There are no copyright assignments at Eclipse at all. Every single contributor, no matter how large or small, makes their contributions under the EPL. We have complete symmetry between inbound and outbound licensing. | +1 |
| Trademark policy | Please see the logo guidelines | The trademarks policy keeps the Eclipse name, and the name of all of its projects and their namespaces in trust for the entire Eclipse community. No trademark using entity has any more rights than another. The Eclipse Foundation is a not-for-profit entity which has no commercial motive for the control or exploitation of any of its trademarks.
(Mike adds: “Caveat: Prior to the creation of the Eclipse Foundation as an independent entity, IBM followed a laissez faire policy towards the Eclipse trademarks and the marks of the various projects inside the Eclipse community. As a result, there are uses of “Eclipse” and other marks which have been grandfathered which would otherwise be in violation of our trademark.”) |
+1 |
| Roadmap | Roadmap | The Eclipse Foundation publishes an annual roadmap each year which pulls in the release plans of the vast majority of its projects.Each year the Eclipse community releases an annual release train combining the work of a significant subset of the Eclipse community’s projects. All of the requirements, planning and execution of the release train is done is done in an open and transparent manner. | +1 |
| Multiple co-developers | Commits | Across the Eclipse community there is a very diverse collection of companies and individuals involved in projects.They also transparently publish all sorts of metrics regarding diversity and activity. | +1 |
| Forking feasible | There are no licensing or copyright assignment barriers to forking. However, the continuing predominance of IBM committers on the Eclipse platform itself means that forking that particular piece of the Eclipse community would be difficult. | 0 | |
| Transparency | Minutes site (includes minutes for Board, Council and Membership meetings) | Eclipse publishes minutes of all of its meetings.The Board operates under a mix of Chatham House rules and a requirement that not detailed personnel or financial information be published. All other minutes are made available. | +1 |
| Summary (scale -10 to +10) | +8 |
I’m grateful to Mike for the work he’s contributed here – thanks! If you’d like to submit the data to help me test the benchmark on your community, please do.
Filed under: Governance, Links, Open Source | Tagged: Eclipse, Open-By-Rule |
Wild Webmink 
[…] ☆ Is Eclipse Open-By-Rule? Wild Webmink […]
Hi Simon,
Eclipse is a very important IDE and developer framework for the Java Developer Community.
At the moment some projects are facing some uncertenty with the licensing issues, if they want to publish a GPL licensed plugin and/or use GPL licensed code in their Eclipse based project.
The JGrass developer community tried with an Open Letter to get some clear answers, but it seams that there is no really clear answer to the issue and the risk get’s delegated to the developer community. Andrea Antonello published a summery at http://code.google.com/p/jgrass/wiki/Epl_Gpl
Considering this situation I would not give a full point at the “Modern License” section, because EPL is creating issues in collaboration between Free Software developer communities.
Best regards
Patrick
EPL is a “modern license” in the sense I’ve clarified in the benchmark, namely that it is an OSI-approved license that ensures patent protection between project participants. It’s not obvious to me why someone creating a plug-in for a project would choose to use any license other than the license the project has chosen for itself. If Eclipse was infrastructure software needing to be combined in production with software under the GPL I could perhaps understand the need for GPL compatibility and score it correspondingly; why is this such an issue for a development tool?
I am not very satisfied by your definition of “modern license”, because licenses should protect software freedom and enable cooperation between software projects in the first place. It is fine that a “modern license” has to be OSI-approved and ensure patent protection, but it should not create unnecessary incompatibilities between free libre open source software projects.
About non-EPL plug-ins: Consider that Eclipse is not just an IDE, many projects use Eclipse as a framework, some kind of layer between the JVM and the Business Logic. In these case the framework implies that sw cannot be released as GPL. Except you get the permission to introduce a compatibility clause from all copyright holders. Which in large cooperative communities is not feasable. The bad side effect is, that large cooperative communities split up into EPL-compatible and EPL-incompatible subgroups.
License incompatibilities are the natural consequence of a decision to use copyleft. Nothing much any of us can do about that no matter how much we want it – nothing to do with license modernity.
Patrick,
I share your understanding of the issues. License incompatibility is a serious issue that has negative side-effects for developers and communities. Unfortunately, it is a fact of life that must be dealt with. FLOSS is wonderful stuff, but it does not mean that developers can mix and match whatever code they want, with no regard to the licenses under which that code is made available by the copyright holders.
But once again I disagree with the suggestion that GPL compatibility is the definition of a modern license. The EPL does an excellent job of protecting software freedom, and is well liked by our community. If developers want to make use of our frameworks, they should respect the wishes of our community and use an EPL-compatible license.
I agree that the license eclipse uses isn’t ideal. It is a reason to avoid code published under it unless you can use it in isolation. There have been various calls to the Eclipse Foundation to make it compatible with the GPL (especially after GPLv3 made sure all patent stuff is compatible with how the EPL does things). Personally till the EPL is upgraded to be compatible with at least GPLv3 I would give zero point for modern license.
Mark, seams you are right. Sad but true.
I completely respect the desire of developers, communities and companies to select the GPL as their license of choice. But I would hope for the same respect in return. In other words, I heartily disagree that the definition of a “modern license” should be conflated with GPL compatibility. They are quite separate and distinct definitions.
@Patrick – I disagree that there is no clear answer available. We worked long and hard with the FSF to arrive at an answer in response to the open letter from the JGrass community. I think you are perhaps mistaking an answer which you don’t like with an answer which is unclear 🙂
The blog entries from the FSF[1] and EF[2] linked to at the end of Andrea Antonello’s article state that the EPL and the GPL are incompatible. You _cannot_ license an Eclipse plug-in under the GPL unless you have sufficient rights to create a license exception allowing linking to the EPL-licensed Eclipse platform.
I am not sure how those blog posts could be worded any more clearly. If you have some specific advice, I would certainly appreciate it.
Thanks.
[1] http://www.fsf.org/blogs/licensing/using-the-gpl-for-eclipse-plug-ins
[2] http://mmilinkov.wordpress.com/2010/04/06/epl-gpl-commentary/
@Mike yes you are probably right, it is stated clearly. And yes I really don’t like the situation that projects like jgrass have to split up into 2 subprojects: 1 which can be used as Eclipse plugin and a second which is clean from EPL code and can be used together with all the other GPL libraries in the GRASS developer community.
I wonder if for the Eclipse Foundation is working to find a solution for those Eclipse plugin developers, who would like to exchange code/knowledge with other GPL projects.
Patrick, At the moment at least, regrettably we do not have a solution for those Eclipse plugin developers who would prefer to use the GPL. I have frankly heard of no one within the Eclipse project community who is pushing to rewrite the EPL. And without something close to a consensus amongst those who contribute code under the EPL today, I don’t think there is much motivation to re-visit the issue.
Mike, thank you for the clear answer. This is very helpful for us, because we get often asked about this issue and now we can answer, that (even in the long run) there is no other solution for GPL projects to get all copyright holders (of all code, libraries and future linked code) to sign a compatibility exception or to avoid EPL licensed code. Second is very sad, because Eclipse is a very nice platform in the Java world, we have promoted a lot in the past years.
Presumably this would also limit the ability of Eclipse and OpenJDK to be distributed together?
Unclear at the moment. OpenJDK makes use of the Classpath Exception, which may allow the combination. It’s something that we are looking at right now. But the topic is moving at lawyer speed 🙂