[ccan] iniparser re-branding

[Tim Post]

All,

On Thu, Nov 11, 2010 at 8:02 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> On Thu, 11 Nov 2010 12:11:16 am ndevilla at free.fr wrote:
>> Hi guys:
>
> Hi Nicolas,
>
>   I put Tim's contribution in the repo (as the CCAN maintainer), but barely
> looked at it and have never used it, so my answers are a bit limited.
>
>   Thanks for raising this; I think I would have been less polite :)
>
>> Just found out today about CCAN, which sounds like a neat idea.
>> I also found out that 'iniparser' was included in the list of modules
>> and there are several points I would like to stress:
>>
>> - The original MIT license included in iniparser has been stripped out.
>> The whole point of the MIT license is that the license file is viral.
>> Stripping it out simply violates the whole idea.
>
> Erk, that looks bad.  This was contributed a while ago, when we didn't tend
> to drop license files in directories; looks like Tim simply included your
> license in every .c and .h file though?
>
> (A lawyer contacted me previously on the licenses question, so now we usually
>  put a LICENSE file or symlink; serendipitiously as of last night, ccanlint
>  checks for this)
>
> So now it should probable have a LICENSE symlink to ../../licenses/BSD-MIT;
> I'm pretty careful to include the relevant licenses/ files in the standalone
> tarballs, too.
>
>> - Tim added his name on top of source files below mine, claiming a copyright
>> 2009. I would appreciate adding a bit more details about what parts exactly
>> he claims copyright on, i.e. how different is ciniparser from iniparser?
>
> Does Tim have a useful diff?  Or was it just packaging changes?

It was a lot of packaging changes as well as features that I ended up
backing out prior to sending to ccan. I implemented some
more tokens in the parser itself (such as include, and a few others)
and basic transactional support in the dictionary.

Anyway, at that time, I did what I always do and added my copyright in
the header. Then, later, backed out a few things because
they were still a bit too problematic to ship.

There are also the tests and (more than) several bugfixes (mostly
realized through the tests). This was well over a year ago, I'm not
sure where those diffs went.

>
>> Found on this mailing-list:
>> "I am not the original author, I just took something that was abandoned and
>> useful and cleaned it up a bit."
>> Yet my e-mail address is present in the original tarball and googling 'iniparser' would have given you the URL to the iniparser web site, which has been up since 1996. This project is not abandoned. Actually, a newer version should be released soon, including some bugfixes and enhancements suggested by many contributors. Do you plan to backport these at some point?
>
> Yes, clearly Tim was wrong; I think he'll be happy to know this, too.
>
> IMHO updating ciniparser would be silly.  Since it's obviously not abandoned
> we should just remove it from CCAN.  Tim?

At the time (this was well over a year ago) the author (I don't recall
on what page) was pretty clear about not wanting /
having time to review patches, and noted that the code was on github
for anyone to fork.

There had not been activity in github for quite some time.

So, I dropped the module (that I had been working with for a few
months) into CCAN with the expectation that I'd
be happy to maintain it.

I don't see how I did anything wrong, given the circumstances at the
time? There was most decidedly no malice intended.

Still, if it is, indeed actively maintained, I'd agree with dropping it.

>
>> There are two obvious options here:
>> - You can fork the code, take ownership and maintain it but keep the
>> original license somewhere, respecting the MIT license terms.
>
> My policy as CCAN maintainer is to accept code unless there's obvious license
> issues (even if only under junkcode/).  But I don't see the point in copying
> whole libraries from elsewhere.

The license is defined at the top of each file, it's just not
retrieved when someone downloads just
that module (with or without dependencies)



Regards,
--Tim