[PATCH 1 of 6 A2 series] pathencode: add _lowerencode function

Adrian Buehlmann adrian at cadifra.com
Tue Oct 9 06:42:26 CDT 2012


On 2012-10-09 13:04, Laurens Holst wrote:
> Op 09-10-12 01:07, Adrian Buehlmann schreef:
>> On 2012-10-08 19:35, Adrian Buehlmann wrote:
>>> Sure.
>>>
>>> On 2012-10-08 19:17, Bryan O'Sullivan wrote:
>>>> On Sat, Oct 6, 2012 at 4:52 AM, Adrian Buehlmann <adrian at cadifra.com
>>>> <mailto:adrian at cadifra.com>> wrote:
>>>>
>>>>      This code was originally published by Bryan O'Sullivan
>>>>      <bryano at fb.com <mailto:bryano at fb.com>>
>>>>      on 2012-09-10 <tel:2012-09-10> as part of a bigger patch, which
>>>>      wasn't included.
>>>>
>>>>
>>>> Please don't change the attribution on patches you didn't originate. I
>>>> don't want to have to explain to Facebook's legal team why your name is
>>>> on a commit even though Facebook owns the rights to the code.
>>>>
>>>> If you'd like me to extract a hunk of a patch and resubmit it by itself,
>>>> just ask.
>> Some further notes on the legalese involved here.
>>
>> Your dislike has been well noted here.
>>
>> But:
>>
>> If you send a patch to this list, you publish it. You've thus created a
>> derived work, which was published under the GPL too. I am thus free to
>> take and bend your patch in whatever ways I please.
>>
>> I don't have to wait with my modifications until your patch hits the
>> main Mercurial repo. Because your patch may not even reach the main repo
>> ever.
>>
>> I "own" the code as much as you or Facebook do.
> 
> No, not really; there is a significant difference between owning the 
> copyright and being licensed by the copyright owner to modify the code 
> under the conditions of the GPL. GPL does not reassign copyright (in 
> fact in many countries copyright always belongs to the author or his 
> employer and can not be reassigned).

LOL. In particular when I wrote the original code in Python, which Bryan
now writes a new version in C of it. I don't doubt he has a copyright in
that C code he writes!

And the original Python code was all based on ideas published by Matt
Mackall on this very list here (the hybridencode strategy). So it's
likely all based on prior art (FWIW).

> Having the patch’s author reflect the author of the code makes it easier 
> to determine who authored it. Of course you do attribute in the 
> description, however that is less obvious and can’t be easily used to 
> perform queries such as “retrieve all changesets by author X” or 
> “retrieve a list of source code contributors” or “find all lines touched 
> by author X that have not been modified since”.

I am perfectly fine with attributing this patch to Bryan if he likes.

What I do not like is if someone tells me what I have to do and what I
don't have to do. I do not have to ask for permission of Bryan to split
his patch.

I have several times hinted to him that his giant patches are hard to
review. And I was trying to see what can be achieved speedwise if we
would take some parts of his code instead of trying to cram in the whole
thing.

> These queries are useful in various situations. E.g. if the Mercurial 
> code base would need to be relicensed, they need to contact all 
> individual copyright owners to agree to it. Or if person X contributed 
> code even if his employer never gave permission for that, and all code 
> authored by that person would need to be removed.
> 
> So although technically you are permitted to create a derived work under 
> the terms of the GPL, there are advantages to “version controlling” 
> these modifications or asking the original author to make these 
> modifications in a code review. As an additional benefit, this will also 
> probably be appreciated by the original author, rather than someone 
> taking your code and running away with it.

We are not in Kindergarten here. You don't have to explain to me how
version control is useful. What we are talking about here is a way to
collaborate about things that are not yet under version control in the
mercurial main repo.



More information about the Mercurial-devel mailing list