[Coin-discuss] license issues

[Matthew Saltzman]

On Mon, 18 Sep 2006, Ted Ralphs wrote:

> As for why we chose the CPL and not the GPL, the answer to that question
> is not very straightforward, but, as previously pointed out, a big
> reason is that it is more friendly to commercial use. A lot of companies
> will not touch GPL'd code with a ten-foot pole because it is not
> possible to include GPL'd code in a proprietary product, whereas the CPL
> makes this fairly easy. Since we generally want to encourage commercial
> use of COIN software and since IBM, who contributed much of the initial
> code in COIN, was already comfortable with it, we chose the CPL as our
> recommended license. (Disclaimer: This is just my own interpretation of
> Foundation policy).

Just a historical note:  The original COIN-OR code base (OSI, CGL, BCP, 
VOL, Utils, DFO) was first released by IBM under the IBM Public License 
(IPL).  IBM developed the CPL at least in part in response to our desire 
to accept outside contributions and publish them under a license that was 
IPL compatible but did not mention explicitly that IBM was the owner.  As 
they owned the entire code base at that point, IBM agreed to let us 
republish it all under the CPL.  That action was in keeping with their 
original plan to spin the project off to the community.

You would have to ask the IBM legal team what their precise issues with 
the GPL were/are (good luck!).  Suffice to say here that (1) they very 
likely would not have consented to republishing under the GPL, and (2) 
they very likely would not consent to publishing new contributions under 
the GPL.  (Actually, the first condition is sufficient to prevent COIN-OR 
from publishing most of our current code base under the GPL, as IBM is the 
owner of all of that original code base--though not all subsequent 
contributions--plus most of CLP, CBC, multifario, NLPAPI, SVM-QP, and some 
of Ipopt.)  There are also several people in the COIN-OR organization who 
find the GPL's conditions too restrictive for their tastes or purposes.

>
> To clarify whether the CPL requires changes to the code to be released
> open source, the CPL does require that "improvements" to CPL'd code be
> contributed back to the owner of that code under the CPL if such
> improvements are redistributed. However, the CPL allows for users to add
> separate "modules" to CPL'd code that are under a different (possibly
> proprietary) license. In other words, if one wanted to build a GUI
> interface for CLP or even to add a new algorithm for solving LPs to it,
> it would be OK to sell the resulting product commercially, even if the
> additional module was not released under the CPL (or even not open
> source). This is not allowed under the GPL. (Disclaimer: These opinions
> are just my own interpretation).

I pretty much agree with Ted's take (and Brady's below).  The main 
distinction is what constitutes a "derived work" and what sorts of burdens 
are inherited by various kinds of derived works.  In this matter, the CPL 
and the LGPL are very similar.  The GPL additionally asserts that a 
program that links to a library through an API is a derived work of the 
library and requires that the derived work inherit the GPL if the library 
is GPL.  This is probably the single most controversial clause in the GPL, 
and it can have some rather bizarre side effects.

The FSF's primary problem with compatibility actually relates to the 
patent clauses in the CPL, not the commercializability of added components 
that mutually link with CPL code.  The LGPL takes a similar view of 
commercialization of code linking to it.  The LGPL ("Lesser GPL") is a 
concession to reality, though.  If Stallman had his way, there would be no 
LGPL.

John's original question had to do with whether the two codes could be 
distributed together.  The GPL's answer is that a you can't create a 
binary that either statically or dynamically links a GPL code and a CPL 
code.  You can distribute the two source libraries together and allow the 
user to build the binary for themselves.  John says, "Perversely, it seems 
that it is easier to use IPOPT in commercial projects than in free 
projects!"  That is more the fault of the GPL than the CPL, IMHO.

If John's group is the sole owner of the code they want to link, there are 
probably some options they have to make their code compatible with ours. 
I don't know if IBM would consent to dual-licensing Ipopt, but I doubt it. 
CppAD is now dual-licensed (CPL and GPL), but that has no IBM code.

>
> For a more in-depth analysis of several open source licenses (including
> the CPL and GPL), Lawrence Rosen's book, "Open Source Licensing:
> Software Freedom and Intellectual Property Law," is recommended and
> available on-line (in open source fashion):
>
> http://www.rosenlaw.com/oslbook.htm
>
> For IBMs interpretation of the CPL, see their FAQ here:
>
> http://www-128.ibm.com/developerworks/library/os-cplfaq.html
>
> I hope this helps clarify some things.
>
> Cheers,
>
> Ted
>
>
> Andreas Waechter wrote:
>> Hi,
>>
>> Just a minor insignificant correction:  Ipopt was originally contributed
>> by CMU, since it was written there.  However, since I then went to IBM,
>> we decided to release it under a license that IBM would be happy with
>> (and would allow me to keep working on it), and that was the CPL.
>>
>> Andreas
>>
>>
>> On Mon, 18 Sep 2006, Brady Hunsaker wrote:
>>
>>> I'll try to help clarify some of the confusion about COIN-OR's license
>>> policy.  I'm a member of the Strategic Leadership Board, so I feel
>>> qualified for that.  As to the legal questions of license specifics,
>>> I'll make a personal statement at the end.
>>>
>>> COIN-OR allows project contributors to choose any software license
>>> that is approved by the Open Source Initiative.  Dual-licensing is
>>> also allowed, and we currently have one case of a dual-license (user's
>>> choice of CPL or GPL). Both the CPL and GPL are approved as
>>> open-source licenses by the Open Source Initiative.
>>>
>>> Most of the current code is licensed under the CPL, so we encourage
>>> new project contributors to consider the CPL for compatibility.  This
>>> is not required, however.  It is up to the project contributor.
>>>
>>> IPOPT was originally contributed by IBM.  IBM chose to use the CPL for
>>> all the open-source code it has contributed to COIN-OR.  I don't know
>>> all the reasons for this, but here are a few points:
>>> - IBM wrote the CPL to be exactly the way they want it.
>>> - The CPL has clauses relating to patents; the GPLv2 does not.
>>> - In my personal understanding, the CPL is closer to the LGPL,
>>> allowing use as a library or separate module without the requirement
>>> that other code have the same license.
>>>
>>> I hope that clears up some of the main COIN-OR questions.  If not,
>>> I'll be happy to try again.
>>>
>>> ----
>>>
>>> As to the legal relationship of licenses, I can only speak for myself
>>> (not for COIN-OR).  My understanding is similar to what Bill has
>>> written below. IBM wanted to engage both research and industry
>>> communities when it contributed IPOPT, and evidently believes that the
>>> CPL is the best way to do that, despite the relative frequencies of
>>> licenses in other projects.  The LGPL would be similar in some key
>>> ways, but I believe IBM probably evaluated it and explicitly deciding
>>> against it.
>>>
>>> Unfortunately it's not possible to release binary code that combines
>>> code under the CPL and GPL or LGPL.  It is possible to release source
>>> code that interoperates, but the user would always be required to
>>> collect the two different codes and compile them locally.  For
>>> example, some COIN-OR projects allow the user to link to code under
>>> the GPL, such as gzip and bzip2 compression libraries.  This is not
>>> enabled by default, and we do not expect to be able to distribute
>>> binaries with this feature because of license incompatibilities.
>>>
>>> Brady
>>>
>>> Hart, William E wrote:
>>>> John:
>>>>
>>>> I didn't help develop CPL, but my understanding is that the principal
>>>> motivation for CPL was that it enabled commercial entities to use the
>>>> code without enforcing code-distribution requirements on them.  Thus,
>>>> someone like IBM could integrate CPL code, modify it, and distribute it
>>>> commercially without being required to redistribute those changes to the
>>>> public.
>>>>
>>>> This sort of policy goes against the grain of the GNU open source
>>>> distribution policy, but in practice I have observed that commercial
>>>> entities using CPL code remain interested in fostering improvements in
>>>> the code.
>>>>
>>>> It's clear to me that this sort of license is not what you're interested
>>>> in for ASCEND.  I don't think you could argue that IPOPT _should_ be
>>>> distributed with the LGPL license.  However, the IPOPT developers are
>>>> free to license IPOPT under LGPL as well, for inclusion in a project
>>>> like ASCEND.
>>>>
>>>> --Bill
>>>>
>>>>> -----Original Message-----
>>>>> From: coin-discuss-bounces at list.coin-or.org
>>>>> [mailto:coin-discuss-bounces at list.coin-or.org] On Behalf Of John Pye
>>>>> Sent: Monday, September 18, 2006 9:09 AM
>>>>> To: Discussions about open source software for Operations Research
>>>>> Subject: Re: [Coin-discuss] license issues
>>>>>
>>>>> Hi Bill,
>>>>>
>>>>> I'm not all that clear on it myself. I found these comments on
>>>>> Wikipedia:
>>>>> http://en.wikipedia.org/wiki/Common_Public_License
>>>>>
>>>>> CPL would be one of the less common open source licenses. Given that
>>>>> it's said to be incompatible with the far-and-away most common open
>>>>> source license, namely the GPL, I'm curious why it was that CPL was
>>>>> chosen for COIN? I wonder if you could perhaps explain what the
>>>>> conditions were that you wanted to enforce?
>>>>>
>>>>> In the case of my project, ASCEND, for example, we wanted to make a
>>>>> completely free modelling tool that could not be swallowed up inside
>>>>> a larger commercial piece of software without our explicit agreement.
>>>>> Perhaps it is important that use of IPOPT and other COIN software be
>>>>> allowed inside commercial stuff. In that case, perhaps the LGPL
>>>>> would be a better choice than the CPL?
>>>>>
>>>>> Cheers
>>>>> JP
>>>>>
>>>>> Hart, William E wrote:
>>>>>
>>>>>> FYI, the discussion that JP refers to is available at:
>>>>>>
>>>>>>  http://www.gnu.org/licenses/license-list.html
>>>>>>
>>>>>> I can't say that I understand the gist of the incompatibility...
>>>>>>
>>>>>> --Bill
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: coin-discuss-bounces at list.coin-or.org
>>>>>>> [mailto:coin-discuss-bounces at list.coin-or.org] On Behalf Of John Pye
>>>>>>> Sent: Monday, September 18, 2006 7:59 AM
>>>>>>> To: coin-discuss at list.coin-or.org
>>>>>>> Subject: [Coin-discuss] license issues
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I've just come across COIN and the IPOPT solver, and was thinking
>>>>>>> about looking at it as a possible open source alternative to the
>>>>>>> CONOPT solver that we currently rely on for some of the
>>>>> functionality
>>>>>>> in the ASCEND modelling environment (another CMU project).
>>>>>>>
>>>>>>> I was wondering why IPOPT has chosen the Common Public License.
>>>>>>> According to the GNU website, this license is not
>>>>> compatible with the
>>>>>>> GPL, which means that although IPOPT is open source, we
>>>>> can't legally
>>>>>>> distribute it with our software. Perversely, it seems that it is
>>>>>>> easier to use IPOPT in commercial projects than in free projects!
>>>>>>>
>>>>>>> Is there a good reason why the CPL is applied to IPOPT -- perhaps
>>>>>>> another license could be used instead, such as the GPL or LGPL
>>>>>>> license?
>>>>>>>
>>>>>>> I note that this discussion also appears to have taken place on
>>>>>>> the CppAd list, and the Boost license was suggested there as an
>>>>>>> alternative.
>>>>>>>
>>>>>>> Cheers
>>>>>>> JP
>
>

-- 
 		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs