I sit on the “Strategic Leadership Board” of COIN-OR (COmputational INfrastructure for Operations Research). There is a lot of great code at COIN-OR, and I find it very useful in my research.
Despite being on the SLB, I get very confused when it comes to open source. It seems that 90% of the discussions on the SLB hinge on either legal issues with regards to open source licenses or on the paperwork necessary to satisfy COIN-OR’s process for meeting those legal issues. It is rather unsatisfying: all of us on the SLB would rather talk about operations research and software rather than legal stuff.
A big part of the issue is the proliferation of “open source” licenses. Check out the listing at opensource.org. There are 65 licenses listed! Who can keep track of all those? And, while there are some sites to help you pick a license, things get more complicated when you combine codes under different licenses.
At COIN, there are a few different licenses used, but the most common is CPL (Common Public License), due in part to the influence IBM has had in supporting COIN.
IBM and Eclipse have announced that the Eclipse standard ECL will supersede CPL. See the postings by Ed Burnette at ZDnet, and by Mike Milinkovich of the Eclipse Foundation (thanks Robin for the pointers!). Mike explains why this superseding was done:
License proliferation in open source is a real issue. It costs businesses to review multiple licenses, and the plethora of licenses can be confusing to someone starting a new open source project.
Over the past five years we have seen the Eclipse Foundation go from a good idea that might work to one of the most successful open source communities out there. We have seen the Symbian Foundation adopt the EPL as its license, thereby bringing a huge community and code base in its own right to the EPL, plus demonstrating the utility of the license well outside of the Java domain that it is best known in. More recently, Google also added the EPL as one of the licenses it supports on Google Code. It is clear that if we wanted to consolidate on one license, that the EPL made the most sense.
Generally I am very happy about this. There will be some immediate hassles as we try to sort out what this means and how this affects COIN-OR. But perhaps this move to EPL will grow larger, and we can get on to the business of creating great code, rather than getting stuck on legal issues.
I do have one question to all developers of open source software in operations research: are you happy with EPL as a license? Are there aspects of that license that you find troubling? Is anything a deal-breaker, meaning you would not license under EPL but instead would insist on another open source license for your work?
Michael,
As I pointed out, the two licenses are virtually identical. The costs and risks of changing should be very low.
But if anyone has any questions, we would be happy to talk to them about it.
Thanks!
I like the idea of license de-proliferation a lot, but wonder about the EPL solely because it still seems like an example of a needlessly proliferated license. In the broader open source world there seem to be four equivalence classes of licenses, represented by the GPL, LGPL, BSD/MIT/X11, and public domain licenses. Why not cut to the chase and use one of those?
I think Kevin is right, according to several statistics, GPL is the most employed license, before LGPL, and BSD-like ones.
EPL is really yet-another-license, the fact is that it was design specially for Eclipse… it does not appear to be a good way of fighting license proliferation.
Further readings:
Why “should use an existing widely-used license compatible with the General Public License (GPL), particularly the GPL, LGPL, MIT/X, or BSD-new licenses” : http://www.dwheeler.com/essays/gpl-compatible.html
Details ont the EPL : http://en.wikipedia.org/wiki/Eclipse_Public_License
You’re question about license proliferation is not new to say the least. I have been doing some reading on this issue as of late and I have to say that the only real ones that can answer your question is the organization that issues the license. It is really a matter of the business model put in place.
To understand “open source” and “free software” probably one needs to understand its history. A good read on the open source movement is The Cathedral and The Bazaar by Eric Raymond. Its available, you got it right, free! Perfect for your Kindle.
http://www.catb.org/~esr/writings/cathedral-bazaar/
But really to answer your question about being happy with “XYZ” license. Does it fit with what SLB is trying to achieve? Think of it as an OR problem. What is the objective to my license? Does the objectives of my organization fit with the license? What are the constraints of applying said license?
In my personal opinion all of these licenses are essentially based on the granddaddy of them all, the GPL. The different flavors of licenses are a reflection of different organizational decisions. You may find what works for Eclipse may not work for SLB. I’m sorry I am somewhat vague on the answer. Yet that is the beauty of Operations Research in that from difficult challenges come very elegant answers.
As you can see I definitely have a passion for the FLOSS (free libre and open source software).
Many businesses are quite leery of the GPL, primarily because of the “work as a whole” clause, which precludes redistribution of a combined work unless all components can be distributed under the terms of the GPL. Whether those concerns are justified or not, and whether the characterization is fair or not, this clause is why the GPL is referred to by some as “viral”. Also, the IBM Public License (the precursor to the CPL) was developed when the GPL v2 was current, and that version did not address some concerns that IBM had about patent protection. As it turned out, the CPL developed a significant following among commercial firms (including Microsoft). The patent clause was still a concern for the companies in the Eclipse consortium, so they negotiated the minor change in the EPL.
(Lawrence Rosen’s Open Source Licensing book (a must read, if you want to get into this topic in detail) has some very kind words about the CPL.)
It is unfortunately easy for licenses to run afoul of GPL incompatibility by imposing even mild restrictions. The GPL compatibility page back in the v2 days stated that the CPL’s patent clause was a good idea, but it still made the licenses incompatible. There are variants of the GPL that incorporate exceptions to make them more palatable (see MySQL’s “open-source exception”, for example), but companies that don’t have significant legal expertise in open source may still be nervous about using them.
Unfortunately, the objective function in COIN-OR’s license-selection problem is multicriteria…
I wrote: “The GPL compatibility page back in the v2 days stated that the CPL’s patent clause was a good idea, but it still made the licenses incompatible.” But I should have pointed out that the licenses remain incompatible even with GPL v3. The reason given on the GPL compatibility page is the fact that the CPL requires adjudication of disputes in New York State, whereas the GPL does not.
“The reason given on the GPL compatibility page is the fact that the CPL requires adjudication of disputes in New York State, whereas the GPL does not.”
And it is things like this that makes me despair for open source. It is on the heads of pins that the various schisms occur. And with schisms comes paralysis.
OK to be fair, that’s sufficient to establish incompatibility, but it’s likely there are more incompatibilities if one digs deeper into the wording of the two licenses.
On the other hand, I agree that the letter of the law seems to trump the spirit in many cases.
Another thing that should be considered is the additional hurdles new licenses introduce for distributors.
A concrete example: nobody can legally distribute a binary version of the COIN-OR Cbc solver which supports the AMPL-compatible GNU MathProg language, although code exist in the COIN-OR repository. The reason is that this code links against GLPK which is licensed under the GPL.
I am personally very happy COIN-OR comes with a liberal license that encourages commercial use. I can invest time learning to use the COIN-OR packages and safely know I can always use them in the future, commercially or not.
Yet, I would prefer if the license would be the LGPL such that it becomes compatible with most other open-source software. The spirit of the LGPL and CPL/EPL seem very similar but I am sure there exist legal and specific issues which prevent a simple dual-licensing.
I absolutely agree that licenses should not be proliferated needlessly. Anybody thinking about creating YAOSL should definitely think seriously about why an existing license (preferably one of the “Big 9“) could not work for them.
But history plays an important role, here. When the IPL/CPL was created, the (L)GPL had no patent clause. Now it does, but there is a large body of work under CPL that could be hard to change. And there may be other philosophical/legal reasons for not having one license to rule them all.
Dual licensing is, of course, a matter for the authors/owners to decide, though one can hope they are receptive to the desires of their communities. Also, although dual licensing solves the problem of distributing combined works, it is not free of potential pitfalls. One can easily imagine, for example, a license fork, where partisans of one license or the other create derived works and elect to distribute them under only one of the two licenses.
In my spare time I’ve been trying to put together a small user app to be released under an open-source license. In this app I’ve borrowed library code from several open-source projects. I’ve already (a) gotten a major headache trying to sort out compatibility issues among licenses and (b) had to yank out one chunk of third-party code and replace it with different third-party code to escape the GPL. I may be missing some of the finer points, but so far it seems like most of the non-GPL licenses play well together (at least for an end-use application), but GPL creates hurdles.
From my perspective, the licensing mess is a deterrent to the production of new open-source software. If I have something that works for me, I’m willing to share it, but I don’t have the time (or expertise) (or interest) to spend sorting out the license spaghetti. If EPL became a dominant choice, I’d be quite happy. The problem, though, is that an awful lot of software is out there under GPL, and GPL’s high visibility probably makes it the default choice for many new developers who haven’t stopped to analyze the alternatives.
In drools-solver (= tabu search combined with a rule engine) we use ASL, because the parent project, drools (= the rule engine) uses ASL.
ASL (apache software license) or LGPL doesn’t matter much, as they are both commerical friendly and get along. EPL falls in that catagory too I think.
GPL is commercial unfriendly and IMHO is bad for non-end user projects as it hurts adoption.
PS: More info about Drools-solver in this article:
http://java.dzone.com/articles/solving-planning-problems-intr
Has any research been done into how many businesses use open source projects without a) checking the license to see if this has any detrimental impact or b) giving anything back to the open source projects. I can bet this is a huge can of worms waiting to bite a lot of companies on the bottom. I cant ever remember being asked to check a license on any open source project by a boss, so imagine most companies are not even aware of the dangers they are exposing themselves to
I don’t know of any, and I’m not sure how you’d gather reliable data points in a case like this.
As for (a), not reading licenses is simply bad practice, whether we are talking about open-source or proprietary software. They are, after all, basically contracts between the developer/seller and the user. The case law on the binding nature of shrink-wrap licenses is still pretty murky AFAIK, but I believe there is a recent precedent supporting the binding nature of open-source licenses.
For (b), note that there is no obligation to “give back” to the community, as long as the software is used only in house and isn’t redistributed. It’s always appreciated, but it is pointedly not a requirement of open-source licenses. And the manner of “giving back” isn’t specified anyway, beyond the requirement to make available to one’s users–and allow redistribution of–source for the original or derived works. Again, there are conventions, but they are not legal requirements.
(IANAL, of course. Consult an actual L for advice about any particular circumstances.)