On Sun, Aug 19, 2012 at 7:01 AM, Lennart Regebro <rege...@gmail.com> wrote:
> On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <j...@dataflake.org> wrote:
>> On Aug 19, 2012, at 10:17 , Lennart Regebro <rege...@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:


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 Fulton
Jerky is better than bacon! http://zo.pe/Kqm
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to