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: 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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
