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

Adrian Buehlmann adrian at cadifra.com
Tue Oct 9 09:26:47 CDT 2012


On 2012-10-09 13:59, Laurens Holst wrote:
> Op 09-10-12 13:42, Adrian Buehlmann schreef:
>> On 2012-10-09 13:04, Laurens Holst wrote:
>>> 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).
> 
> Doesn’t change the fact that Facebook owns the copyright of the C code 
> that Bryan wrote, and you don’t. Copyright doesn’t have a concept of 
> “prior art” (that’s patents). And algorithms can’t be copyrighted.

Right. But prior art can't be patented. Which is relevant here.

> I’m just pointing out the legal differences here, since you raised that 
> topic. No need to “LOL” at me.

And no need to lecture me either. What I've done complies with all
rules. And if you still haven't noticed, I'll repeat it again for you:
it wasn't even intended to be included.

>>> 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.
> 
> Fine, be that way :). Mercurial development isn’t a social, 
> collaborative effort, after all.
> 
>>> 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.
>>
> 
> Patches include author information, are submitted in a sequence and 
> eventually applied as commits. So there’s your “version control” (note: 
> quoted) that I was referring to. You can submit a patch on top of 
> Bryan’s patches,

No, I can't, if it's not pushed to any repo yet.

> or ask Bryan to make the desired modifications,

I can, but I don't have to.

> and
> that way the author attribution in the author field will stay intact.

The key point here is that I don't have to get permission from Bryan to
split his patches or wait until he eventually pleases to do so (or not).
Like it or not.



More information about the Mercurial-devel mailing list