[ccan] iniparser re-branding

[Adam Kennedy]

The main advantage of having code inside of the repo compared to
outside is that stuff that is inside the repository is inside the
dependency graph. Which means other modules can depend on it and deps
get included automatically.

This is main reason that CPAN is such a huge vortex that eventually
sucks anything Perl into it. If you have non-CPAN code, then you can't
write anything in CPAN that depends on it. And therefore such code
tends to be unpopular and eventually get abandoned.

The only Perl code I know of that manages to life a reasonable life
outside of the CPAN are huge end user applications like wikis or big
CMS products. Thing that other code generally won't be depending on.

So if iniparser is removed from the repo, nobody else can write a CCAN
package that depends on iniparser. It becomes an external dependency
someone has to fulfill, which ultimately is just too darned
inconvenient as the dependency graph grows.

This is all completely parallel to the legal/other issues, just an
observation on why it's generally better to have things inside the
dependency graph rather than outside.

Adam K

On 11 November 2010 11:02, 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?
>
>> 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?
>
>> 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.
>
> (I've moved some of my own libraries into ccan, but my aim is that the CCAN
> ones will become the master copies in future).
>
> While we're discussing it, I wonder if you have any other nice code lying
> around you want to submit to CCAN? :)
>
> Thanks,
> Rusty.
> _______________________________________________
> ccan mailing list
> ccan at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/ccan
>