[Project-managers] editing external codes

[Matthew Galati]

Here's another similar scenario. Same problem. Concorde (ABCC's TSP 
solver) has the same issue -- uses "new" in protos. I want to include 
Concorde calls in DECOMP. I doubt Concorde team cares to support a new 
version, so I'd need to patch or have an interface header like I mention 
below.

More generally... what about these scenarios:

(1) The case where you have some open source code (say GPL) that is no 
longer supported. The authors have retired. You use it in your COIN code 
- and over time, you want to make adjustments to it - say, to make it 
faster. How do you handle?

(2) The case where you have some open source code (say GPL) that changes 
dramatically its API - and deprecates their old versions (doesn't 
support or keep them online anymore). But, you are happy with the old 
API and don't want to change anything. Can you keep a local copy of 
their old version on your server and distribute with your COIN code? Or 
are you SOL?

Matt

> You haven't talked much to lawyers yet, have you? Bless your innocent heart... :-).

I try my best to avoid them. My Dad (M.D.) use to have a T-Shirt that said "F-ck all the Lawyers". Apologies to anyone out there married to one. Disclaimer: I have a mind of my own and do not necessarily buy into the belief system of my father. Although, after growing up the son of a MD, I think he had the right idea. :)





>   
>> FYI - cliquer is code for finding maximal cliques (its listed in COIN 
>> resources):
>>    http://www.coin-or.org/resources.html
>>    http://users.tkk.fi/~pat/cliquer.html
>>
>> I'll write the author and ask if they want the fix. That would be easier.
>>     
>
> Yes, that would be the easiest solution. If they accept the patches you might
> as well ask them to accept patches that make their code play nicely with C++
> compilers...
>
>   
>> Here's a related question that brings into question the same issues of 
>> licenses and distribution.
>>
>> My project is written in C++. Cliquer is C. I build cliquer with gcc and 
>> the Makefile they provide - and it works fine. I call cliquer via extern 
>> "C"...  However, cliquer, like alot of "old" C code I've seen has some 
>> bad habits that don't play nicely with C++ compilers (like g++). For 
>> example, cliquer's prototypes include the name "new" and "set" as a 
>> variable name. A C++ compiler won't have that. The way I get around this 
>> kind of thing is to write an "interface" header where I wrote my own 
>> prototypes for whatever I actually call from my code, then extern "C" 
>> {#include "cliquerInterface.h"}. Then, of course, I distribute my 
>> cliquerInterface.h. I presume this is all ok wrt to licenses. But, it 
>> gets a little sticky when I start using macro defines that come from the 
>> original cliquer.h. Since I am not including cliquer.h, but rather 
>> cliquerInterface.h, I have to copy the macros over too - which for some 
>> codes is a bunch of stuff. Is that now a license issue? I am taking bits 
>> of the GPL code and distributing it with my code in my interface header.
>>     
>
> IANAL, but this definitely sounds sticky. My gut feeling would be that if a
> small patch accomplishes what is needed to properly compile the code then
> distributing cliquerInterface.h under the CPL is a violation of the GPL (you
> just changed license without the permission of the copyright holder). If the
> patch is larger than the original file then cliquerInterface.h is
> significantly different so that you are the copyright holder, so you can
> release it as you want. But as I said, that's only my feeling and the law
> might say otherwise... 
>
> So the cleanest (legally) solution is if they accept all the patches you make.
> Short of that you can host a copy of cliquer with the patches (giving them
> credit, of course), distribute it under the GPL, and link against that version
> of cliquer. This is perfectly OK, you have every right to fork a GPL code. The
> only sticky part is: where do you host it? You can certainly create a
> sourceforge project. Hosting it on COIN might be possible, too, but I have no
> idea what is the policy for such a project. It never came up and may or may
> not fly. In conclusion: try to convince the authors to accept patches :-).
>
>
>   
>> This license stuff all seems very messy to me. Why can't I add GPL code 
>> in my COIN code and just distribute my stuff GPL and CPL and 
>> 'whoever-wants -it-feel-free-to-use-it- PL'.
>>     
>
> You haven't talked much to lawyers yet, have you? Bless your innocent
> heart... :-).
>
>   
>> Matt
>>     
>
> --Laci
>
>   
>>     
>>> Hi Matt,
>>>
>>> I don't know what Cliquer is, but the ideal case would be that you get 
>>> the Cliquer developers to include your changes in a new version.  They 
>>> would probably be grateful to get fixes that make it work on Windows...?
>>>
>>> Otherwise, you could include patch files in your distribution and tell 
>>> users that want to use Cliquer on Cygwin how they have to apply the 
>>> patches to Cliquer code that they download separately.
>>>
>>> Andreas
>>>
>>> On Fri, 6 Apr 2007, Matthew Galati wrote:
>>>
>>>       
>>>> In one of the examples in my project DECOMP, I use a GPL licensed 
>>>> code (Cliquer). In my INSTALL, I provide the user the option to 
>>>> download and link with it or not (and give them www). It works fine 
>>>> with unix flavors, but Cliquer was never written to run on Windows. I 
>>>> can fix the Cliquer code to compile in Windows with a few ifdef's.
>>>>
>>>> But, now how does this work? I know I am not suppose to distribute 
>>>> Cliquer via svn. If so, I could just provide my "adjusted" Cliquer.
>>>>
>>>> I guess, this is a general question -- how do I distribute 
>>>> derivatives of other external codes to be used with my COIN project?
>>>>
>>>> Thanks,
>>>> Matt