In November 2001, IBM donated a $40 million software investment of what was to become Eclipse to the open-source community. Eclipse was released under the Common Public License (CPL), which evolved into the Eclipse Public License (EPL). The EPL is devised to let all software vendors “play for-profit ball” the way they want. In particular, the CPL/EPL says that “Contributions do not include additions to the Program \[Eclipse\] which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement.”
The term “module” is never defined in the CPL/EPL. It has grown to designate code that sits on top of and uses the application programming interfaces (APIs) of Eclipse and/or of its projects to add value to the off-the-Web Eclipse offering.
In some sense, the EPL is a “mortgage-free” license in that one is allowed to add components and market them in an open-source or closed-source way. You can take and never give back. The EPL allows open-source software loans to default since one can add components on top of Eclipse and market them in an opaque and restricted fashion. This creates the potential for a software subprime crisis: One can borrow and never pay back.
By contrast, the GNU General Public License (GPL) of Linux, GCC, and the GNU project in general is an open-source software loan with a guaranteed return. If you add components to a GPL work, “You must license the entire work, as a whole, under this License \[the GPL\] to anyone who comes into possession of a copy. This License will therefore apply… to the whole of the work, and all its parts, regardless of how they are packaged.”
Towards an Eclipse Crisis?
Today, there are two co-existing Eclipse communities: the contributors, who work on the open-source projects, and the adopters, who develop closed plug-ins and even full-blown distributions including these plug-ins. Naturally, these communities overlap, as adopters may also be contributors to the core projects. (IBM is the obvious example.) By and large, however, these communities differ since there are many more adopters than there are contributors.
Unsurprisingly, there is a love-hate relationship between these two communities. Contributors say, “Hey adopters, stop working for yourself and contribute to the greater Eclipse edifice.” Adopters say, “Hey contributors, we need this feature in the core projects. Please put it in.” Adopters may even say, “Hey contributors, do not put this feature in the core projects! You undermine our for-profit offering!”
The priority in Eclipse is implementing features. Quality focuses on stability and reliability. Efficiency is secondary, and code maintainability is last. As a result, contributor/adopter tensions show up in the code: Is the code easy to read and use for adopters? Is it error-prone? Are the APIs well-defined?
An adopter may say to a contributor, “Your code crashes the platform with scenario X. Can you please fix it?” In all likelihood, the contributor will fix the code. If, on the other hand, the adopter may say “Your API is a bit cumbersome (or error-prone). Can you please rewrite it?” The likely contributor response will be silence.
Will these tensions lead to an Eclipse crisis? Will the instability between contributors and adopters undermine the Eclipse ecosystem? As long as the level of industry adoption continues to grow, probably not. The real danger lies in technology shifts like Rich Internet Apps (RIAs), which shift the user interface framework and experience inside the browser. Such technology shifts may decrease the value of the Eclipse platform and, as it did for real estate, lead to a subprime crisis in the Eclipse ecosystem. Time will tell.
EPL
www.eclipse.org/org/documents/epl-v10.html
GPL