In the discussion of CPLEX versus Gurobi software, the discussion took an interesting turn when it came to open source (like that of COIN-OR). Sebastian, bemoaning the cost of commercial packages such as CPLEX said:
I think another long-term way to make OR feasible in situations where the cost of Cplex cannot be justified is to invest in the long term development of open source alternatives. The COIN-OR solvers are quite good already (for LP and general non-linear programs they are even competitive with state-of-the-art). Moreover the CPL license IBM chose is very liberal and allows the solvers to be tightly integrated into commercial products without further obligations.
If more companies would support the development as a long-term investment it could be in their best interest.
Shiva, an OR practitioner for a decade replied:
Sebastian: We did investigate open-source methods (including COIN), but after reading the fine print, legal departments tend to shoot it down with prejudice to avoid exposing the company to potential lawsuits down the road. It was another frustrating experience, since like all O.R folks, I love what COIN’s been doing.
Larry, of IEOR Tools, replied:
Shiva, Great points on barrier to entry. I too have been caught in that world of justifying an IT expense for the sake of desicion modeling. For instance, one kind find a decision analysis by just using a spreadsheet. Is it optimal? No. Does it offer a solution? Yes. The key is to justify the long term gains of optimal decision processes. I believe that is the trick.
Yet I have definitely found a great niche and I think the OR community can great help with this issue. Open Source software has the added benefit of community support, development, and implementation without the cost structures. It’s something I have started talking about on my blog. I believe it can have profound affects on the OR community.
I repeat all this because this is one of the best exchanges we have had on MTORB. I am part of COIN-OR (a member of the “Strategic Leadership Board”, though I feel at sea at this compared with my more experienced colleagues). And it does interest me why more people don’t use COIN-OR. For me, there are issues with documentation: I don’t have a lot of time when I learn a new tool, and much open source stuff doesn’t have documentation and examples at the level of commercial software. I spent a summer working with Symphony, now at COIN-OR, and it was great fun. I even put together a document on my experience that was part of the distribution at one point. But I am not sure how many summers I can spend on working through new software. So I use COIN-OR software but not as much as I should.
I am also interested in why people do use COIN-OR and other open source tools. I very much welcome thoughts on this issue, and thank Sebastian, Shiva, and Larry for getting this going.
Many companies do make use of open-source software, but I expect legal concerns–whether well-founded or not–will continue to play a role in slowing its adoption. For people whose companies have rejected the use of open-source software such as COIN-OR, I’m curious about your understanding of the reason, especially if fear of litigation is part of the reason. I can think of three main concerns:
– Warranty: Open-source licenses include explicit disclaimers of warranty and open-source projects typically have little capital. So if a company uses open-source tool X in a product and it is sued because of some defect in tool X, then it doesn’t really have anyone it can sue in turn. But my guess is that this hardly ever happens, and I think proprietary licenses typically also try to limit this sort of liability.
– Fear of copyright infringement: If a company licenses software Y and it later turns out that there is a copyright holder for software Y that didn’t agree to the use (presumably because their code was used without permission), then the company will have to either stop using Y or make a deal with the copyright holder. This is true for both proprietary and open-source software, but there is a perception that the risk is greater that this will happen in open-source projects. Again, I’m not sure how often such a lawsuit has occurred. Nevertheless, it’s important for open-source projects to carefully track the copyright holders for their code.
– Share-alike requirements: Some open-source licenses include provisions that require users to share works that are derived from the open-source code under certain conditions. The Common Public License (CPL) used by most COIN-OR projects requires this under certain conditions (though typically it does not). Even if a company never expects to use the software in a way that would trigger the conditions, there is some extra responsibility for the company, which may cause concern.
I work for a company (Google) that uses a variety of open-source code under a variety of licenses and is engaged with the open-source community. Nevertheless, using code that is licensed under a well-known permissive license such as the Apache License 2.0 or the “new” BSD license makes life particularly easy, in part because it removes the third concern above.
For those who have had companies decide not to use open-source software–especially COIN-OR–for legal reasons, I’m curious if you feel it was some of the reasons above or some other reasons.
Disclaimers:
I’m a former member of the COIN-OR Strategic Leadership Board. My opinions here are my own and not necessarily those of my employer.
These are general observations from my work experience over the years. COIN-OR was not an option primarily because it can become a legal minefield down the road. I’m not a lawyer, but one example – the patent defense clause in the IBM-CPL license can potentially cause future headaches.
If not for all this legalese, a personal choice would be COIN-OR over cplex/xpress/etc because:
a) Some IT managers and non-OR folks tend to assume that all the ‘magic’ is within expensive commercial cplex-like solvers (and thus easily reproducible by competitors) and little credit goes to the O.R heavy lifting – tight reformulations / robust solution methodology / decompositions that we diligently devise to make the whole thing work.
b) its ‘free’, makes the O.R dev team self-sufficient, and COIN gets some well-deserved collaborative benefits.
Personally I can live with a lack of documentation because the alternative is worse. At the end of the day, however well documented, randomized heuristics will still give your customer inconsistent responses with no quality assurance.
Brady, great comments on the “fears” of open source software. Here are my thoughts on a some ways to help debunk those fears. Open source is meant to a be a collaborative effort. A free commodity if you will. The “software” is not what is sold it is the ideas and solutions behind the software that make a difference. I’m not a legal expert but I can share my opinions.
Warranty. The community shares the risk. If one fails then all fails. Then the community rises to help the one that failed. It is for the greater interest of the community that the failure is resolved quickly and amicably. Differences in development, implementation, and standardization can definitely exist. Even “forks” can evolve from an original collaboration. Yet this is just an evolution to a better idea. So the risk should be shared on the whole community.
Copyright infringement. As I mentioned earlier the software is not the big winner it is the solutions, ideas, and services that the software supports. Software is only a tool to be used by the practitioners. If I have a closed source product then potentially I am just alienating myself from what the community can improve, advance, and evolve. Open source is about a freedom of speech and not just cost.
Share-alike. Similar in vain to copyright infringement. If sharing is prohibited then so is academic achievement. The community loses when one can not share. Yet sharing should not be considered a hindrance but an opportunity. Individuals and organizations become empowered with new ideas. Is competition stifled? Not at all. A good idea is always a good idea.
Just a few thoughts. I guess I sound more like an idealist but in all honesty I’m not. I think as practitioners of our trade we should share our tools and learn. Some may be better “wielding” those tools and that is okay.
Michael,
Have you looked into the Microsoft Solver Foundation? It is fairly new, and the licensing is not the best, but they do have an “Express Edition” that is free for use in single-client software applications. I believe it’s the same code-base they use for the Excel Solver only with much higher constraint allotments. Can be used with any of the .NET languages seamlessly. Not the best for large propblems (as you’ll need the $$$ Enterprise License), but for classroom and smaller apps it seems perfect.
Actually the licensing for the MS Solver Foundation is based on a mixed bag of licenses. From the MS Solver Foundation website…
– Source code files are governed by the MICROSOFT PUBLIC LICENSE (Ms-PL)
– Binary files are governed by MSDN CODE GALLERY BINARY LICENSE
– Documentation files are governed by CREATIVE COMMONS ATTRIBUTION 3.0 LICENSE
The Microsoft Public License is free software but it not GPL compatible according to the Free Software Foundation.
Larry, good to know. It’s all very confusing to me. The forums had a back-and-forth with those in charge and they basically said the Express and Standard versions could be used in business deployed applications as long as they weren’t client-server. I’ll try and find the link.