[Zope-dev] We need to change how code ownership works.

[Jim Fulton]

On Sun, Aug 19, 2012 at 7:01 AM, Lennart Regebro <regebro at gmail.com> wrote:
> On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens at dataflake.org> wrote:
>>
>> On Aug 19, 2012, at 10:17 , Lennart Regebro <regebro at gmail.com> wrote:
>>
>>>> And since it becomes ever easier to accept code from unknown sources (e.g. pull requests) legal code ownership becomes an issue again.
>>>
>>> And that returns me to my first question: Is it really legally
>>> different for a contributor to accept a pull request from a
>>> non-contributor compared with a contributor merging a patch from a
>>> non-contributor?
>>
>> Legally, both are disallowed unless there's some proof (written statement etc) from the code author that he assigns ownership of the patch or the contents of that pull request to the contributor who is doing the checkin.
>>
>> In the past we haven't done a good job of enforcing this clear ownership assignment chain. There are always code patches from non-contributors in the bug tracker that may make it into the code base with the help of a contributor. There's a grey area: Is the act of submitting a patch into the Zope bug tracker enough to signal "I am giving you ownership of this code"? I am not sure.
>>
>> GitHub makes this pulling in of "outside" code even easier. I'm afraid it will become even harder to really maintain this chain of custody.
>
> This is then, IMO a problem that we should fix. What you are in fact
> saying is that the current system are violating people's copyright
> everytime we merge a non-contributors patch. It is unfeasible to not
> merge peoples patches, and I think it is also a big problem that the
> way the ownership of the code works now inhibits the increased
> simplicity of making and merging fixes for non-core contributors.
>
> In other words, we have had an ownership situation which is terrible,
> and nobody seems to have realized this until now. Well, now we know.
>
> As such, the discussion must now shift from "don't do this" to "how do
> we do this". Poeple want to contribute and we should not say "don't do
> that", we have to figure out *how* to make it possible to do that, and
> pretty pronto as well.

IANAL and I'm not even very interested in this discussion, however, I
thought I should point out how the pylons project handles this.
(Apologies, of someone beat me to it and I didn't see it) I think
their solution is rather ingenious.

IIUC, their repositories have CONTRIBUTORS.txt files:

  https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt

Committing your name to this file constitutes signing the
contributor's agreement.

A pull request from a new contributor would presumably have to contain
an update to this file.

Because pull requests are not just patches but retain commit history,
there is a record that a person with a github (or bitbucket, my
current preference) account made the update.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://zo.pe/Kqm