<div dir="ltr">There is a lot of legal grey area in all of this. Dual-licensing of Cbc_C_Interface.h itself might be possible, but I'm not sure it's necessary. As far as I understand, the EPL would not prevent someone from writing code to the Cbc API and distributing that code under the GPL. I would think code that calls the Cbc C interface and would be part of GLPK would be fine without any change to the licensing of Cbc. Dual licensing all of Cbc and its dependencies is not really an option. This has been discussed in the past and would be extremely difficult (if not impossible) to do.<div><br></div><div>The idea of licensing an API separately from the project itself has always been a difficult concept for me to wrap my head around. I'm not aware that any of the commercial solvers have separately licensed their APIs. It's hard to imagine that the API itself would be considered substantive intellectual property, although I guess it's possible that for some software, the API itself would reveal enough about the inner workings of a given code that it would be considered part of the innovation. <div><br></div><div>In any case, there are lots of open source codes that are written to the APIs of the commercial solvers, and this seems to be at least implicitly OK with the vendors, even though I don't think permission to do this has explicitly been granted. For Cbc, I think it's explicitly OK. This would only be an issue if Cbc were under the GPL.</div><div><div><div><br><div><div><div>Ted</div></div></div></div></div></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 22, 2015 at 11:13 PM, Noli Sicad <span dir="ltr"><<a href="mailto:nsicad@gmail.com" target="_blank">nsicad@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I just like to point out that the timeline when gurobi and cplex<br>
wrappers for glpsol were created.<br>
<br>
Gurobi wrapper was created discussed in Feb. 2011 and Andrew wrote the<br>
cplex wrapper in July 2011 after somebody was asking for it.<br>
<br>
I think the solution is to create a CBC_C_interface.h like CPLEX.h and<br>
Gurobi.h and license as it as dual license - LGPL and EPL. Then<br>
everything would be legal.<br>
<br>
Or far better relicense CBC solver as a dual license - LGPL and EPL.<br>
<br>
Here's example of dual license - LGPL and EPL.<br>
<br>
<a href="https://github.com/jgrapht/jgrapht/wiki/Relicensing" target="_blank">https://github.com/jgrapht/jgrapht/wiki/Relicensing</a><br>
<br>
MathProg works in LGPL, as in this case, lp_solve.<br>
<br>
<a href="http://lpsolve.sourceforge.net/5.5/MathProg.htm" target="_blank">http://lpsolve.sourceforge.net/5.5/MathProg.htm</a><br>
<br>
Thanks.<br>
<br>
Regards, Noli<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 3/22/15, Ted Ralphs <<a href="mailto:ted@lehigh.edu">ted@lehigh.edu</a>> wrote:<br>
> Miles is correct. Although it is commonly done, you technically cannot<br>
> create works that combine code under the GPL and the EPL. It is a violation<br>
> of the GPL. Even the author of the GPL'd code cannot technically distribute<br>
> combinations, but the author is obviously free to create an exception in<br>
> the license for certain kinds of combinations. I requested such an<br>
> exception be made to allow GMPL to be combined with other solvers, but I<br>
> never got a response. I think it is clear that this is informally<br>
> permissible, but the license of GMPL still technically disallows it.<br>
><br>
> From the standpoint of making the combination work programatically, you<br>
> have the choice of either wrapping GMPL around Cbc (as is done with CPLEX<br>
> and Gurobi) or Cbc around GMPL (as is already half implemented in Cbc). I'm<br>
> not sure which is easier, but it might be that mimicking what is done with<br>
> CPLEX/Gurobi would be the path of least resistance. I hadn't thought of<br>
> that before.<br>
><br>
> An even nicer solution would be to create a wrapper that uses the Open<br>
> Solver Interface, which would provide links to all solvers with Osi<br>
> implementations (<a href="https://projects.coin-or.org/Osi/" target="_blank">https://projects.coin-or.org/Osi/</a>). Of course, OsiCbc is<br>
> not very well maintained at the moment (though I plan to change this in the<br>
> long run), so that might not be a good solution for Cbc right now, but it<br>
> would be very useful in general.<br>
><br>
> To link to Cbc in the same way as Gurobi and CPLEX, you could look at the<br>
> recently developed C interface:<br>
><br>
> <a href="https://projects.coin-or.org/Cbc/browser/releases/2.9.3/Cbc/src/Cbc_C_Interface.h" target="_blank">https://projects.coin-or.org/Cbc/browser/releases/2.9.3/Cbc/src/Cbc_C_Interface.h</a><br>
><br>
> This should allow everything to be done in almost exactly the same way as<br>
> with Gurobi and CPLEX. In that case, the combined code would be a<br>
> contribution to Glpk, though, I suppose, not Cbc. It would be nice if we<br>
> could got the license issues worked out somehow to make this all<br>
> technically legal.<br>
><br>
> Cheers,<br>
><br>
> Ted<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Dr. Ted Ralphs<br>Professor, Lehigh University<br>(610) 628-1280<br>ted 'at' lehigh 'dot' edu<br><a href="http://coral.ie.lehigh.edu/~ted" target="_blank">coral.ie.lehigh.edu/~ted</a><br></div></div>
</div>