3 | | It looks to me like this is a pretty conservative interpretation. It is certainly true that you cannot distribute a single binary that mixes GPL'd and EPL'd code, or a binary that calls a shared library where the two have different licenses (although one might claim it's OK if the main binary is GPL and it's the library that is EPL). But something like python-mip is a self-contained program in the Python programming language and it's not being distributed in binary form, but source form. Yes, when it uses Cbc, it calls a shared library that is under the EPL, but since python-mip itself is also under the EPL, this doesn't create any issue. I can't really see how re-distributing python-mip is a problem, regardless of what it is being re-distributed with. It is well-known that "EPL and GPL are incomatible," but I think this incompatibility is referring to a completely different context than we have here. Can someone say exactly which license is being violated and exactly who the violation is occurring? |
| 3 | It looks to me like this is a pretty conservative interpretation. It is certainly true that you cannot distribute a single binary that mixes GPL'd and EPL'd code, or a binary that calls a shared library where the two have different licenses (although one might claim it's OK if the main binary is GPL and it's the library that is EPL). But something like python-mip is a self-contained program in the Python programming language and it's not being distributed in binary form, but source form. Yes, when it uses Cbc, it calls a shared library that is under the EPL, but since python-mip itself is also under the EPL, this doesn't create any issue. I can't really see how re-distributing python-mip is a problem, regardless of what it is being re-distributed with. It is well-known that "EPL and GPL are incomatible," but I think this incompatibility is referring to a completely different context than we have here. Can someone say exactly which license is being violated and exactly how the violation is occurring? |