Re: [Zope-dev] We need to change how code ownership works.
Wolfgang Schnerring writes: > * Lennart Regebro [2012-08-19 13:01]: >> On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl wrote: > As far as I understand it, the legal lynchpin is that using Github > (strongly) encourages merging code contributions of people that did not > sign a contributor agreement -- which is the same situation as if > someone attaches a patch file to a bug tracker ticket, but will be much > more frequent and likely to happen. > > Could we, then, adopt a policy that we only merge pull requests (or > whathaveyou) from people that have signed a contributor agreement? > a) Tres, Jens: Would that work from a legal perspective? > b) Ross, Alex: Would that still yield the advantages of the distributed > source control model? +10 Absolutely, seems like the best way to do this is to use the existing zopefoundation github org and ensure that we only add members with merge/push permission that have signed the agreement. https://github.com/zopefoundation Ross ___ 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 )
Re: [Zope-dev] We need to change how code ownership works.
* Lennart Regebro [2012-08-19 13:01]: > On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl wrote: >> 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. > 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. Yes, please, let us try and shift the discussion from "stop it right there!" to "how can we make this work?". I think this means taking seriously both sides of the story, a) Using Github is found to be quite attractive by lots of people. b) We need to be diligent in maintaining the chain of custody of code so the copyright situation is kept clean. As far as I understand it, the legal lynchpin is that using Github (strongly) encourages merging code contributions of people that did not sign a contributor agreement -- which is the same situation as if someone attaches a patch file to a bug tracker ticket, but will be much more frequent and likely to happen. Could we, then, adopt a policy that we only merge pull requests (or whathaveyou) from people that have signed a contributor agreement? a) Tres, Jens: Would that work from a legal perspective? b) Ross, Alex: Would that still yield the advantages of the distributed source control model? What other solutions would be possible? Wolfgang ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
On 20 August 2012 01:44, Ross Patterson wrote: > > > For me the discussion sounds a little like a general denial against > > github using the legal story as rationale. > > +10. I'm so glad others are saying the things I think need saying. > > I *am* a signed ZF contributor and from experience, the likelihood of > such stop energy or other unpleasantness prevents me from contributing > to Zope projects nearly as much as I'd like or could. This is a > sterling example. > > To be clear, I'm not invalidating legal concerns, I'm only frustrated > that those representing those concerns are taking a hard line on only > one concern without seeming to accept multiple invitations to work the > problem from all represented concerns. I'm grateful to the others for > trying so hard to kickstart a healthy level of participation in > zc.buildout development once again. > It is mildly interesting to compare the volume of discussion about Zope development vs the volume of discussion about where not to do Zope development on this list in the last few days. I think Jens is right to point out the legal concerns, which many of us don't fully understand. I think it might have been more effective had it pointed out why people should care, rather than just saying "this is the rule". Martin ___ 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 )
[Zope-dev] zope-tests - FAILED: 118, OK: 16
This is the summary for test reports received on the zope-tests list between 2012-08-18 00:00:00 UTC and 2012-08-19 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received [1]Repository policy check found errors in 274 projects Total languishing bugs for zope2: 0 [2]Total languishing bugs for zope: 63 [3]Total languishing bugs for zopeapp: 1 [4]Total languishing bugs for zopetoolkit: 200 Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.8 : Linux Zope-2.13 Python-2.6.8 : Linux Zope-2.13 Python-2.7.3 : Linux Zope-trunk Python-2.6.8 : Linux Zope-trunk Python-2.7.3 : Linux [5]winbot / ZODB_dev py_265_win32 [6]winbot / ZODB_dev py_265_win64 [7]winbot / ZODB_dev py_270_win32 [8]winbot / ZODB_dev py_270_win64 [9]winbot / z3c.form_py_265_32 [10] winbot / z3c.ptcompat_py_265_32 [11] winbot / zc.catalog_py_265_32 [12] winbot / zc.configuration_py_265_32 [13] winbot / zc.lockfile_py_265_32 [14] winbot / zc.monitor_py_265_32 [15] winbot / zc.ngi_py_265_32 [16] winbot / zc.queue_py_265_32 [17] winbot / zc.sourcefactory_py_265_32 [18] winbot / zc.table_py_265_32 [19] winbot / zope.annotation_py_265_32 [20] winbot / zope.app.applicationcontrol_py_265_32 [21] winbot / zope.app.appsetup_py_265_32 [22] winbot / zope.app.authentication_py_265_32 [23] winbot / zope.app.basicskin_py_265_32 [24] winbot / zope.app.broken_py_265_32 [25] winbot / zope.app.component_py_265_32 [26] winbot / zope.app.container_py_265_32 [27] winbot / zope.app.content_py_265_32 [28] winbot / zope.app.debug_py_265_32 [29] winbot / zope.app.dependable_py_265_32 [30] winbot / zope.app.error_py_265_32 [31] winbot / zope.app.exception_py_265_32 [32] winbot / zope.app.folder_py_265_32 [33] winbot / zope.app.form_py_265_32 [34] winbot / zope.app.generations_py_265_32 [35] winbot / zope.app.http_py_265_32 [36] winbot / zope.app.i18n_py_265_32 [37] winbot / zope.app.interface_py_265_32 [38] winbot / zope.app.locales_py_265_32 [39] winbot / zope.app.localpermission_py_265_32 [40] winbot / zope.app.pagetemplate_py_265_32 [41] winbot / zope.app.principalannotation_py_265_32 [42] winbot / zope.app.publication_py_265_32 [43] winbot / zope.app.publisher_py_265_32 [44] winbot / zope.app.renderer_py_265_32 [45] winbot / zope.app.rotterdam_py_265_32 [46] winbot / zope.app.schema_py_265_32 [47] winbot / zope.app.security_py_265_32 [48] winbot / zope.app.server_py_265_32 [49] winbot / zope.app.session_py_265_32 [50] winbot / zope.app.testing_py_265_32 [51] winbot / zope.app.wsgi_py_265_32 [52] winbot / zope.app.zcmlfiles_py_265_32 [53] winbot / zope.app.zopeappgenerations_py_265_32 [54] winbot / zope.applicationcontrol_py_265_32 [55] winbot / zope.authentication_py_265_32 [56] winbot / zope.browser_py_265_32 [57] winbot / zope.browsermenu_py_265_32 [58] winbot / zope.browserpage_py_265_32 [59] winbot / zope.browserresource_py_265_32 [60] winbot / zope.cachedescriptors_py_265_32 [61] winbot / zope.catalog_py_265_32 [62] winbot / zope.component_py_265_32 [63] winbot / zope.componentvocabulary_py_265_32 [64] winbot / zope.configuration_py_265_32 [65] winbot / zope.container_py_265_32 [66] winbot / zope.contentprovider_py_265_32 [67] winbot / zope.contenttype_py_265_32 [68] winbot / zope.copy_py_265_32 [69] winbot / zope.copypastemove_py_265_32 [70] winbot / zope.datetime_py_265_32 [71] winbot / zope.deferredimport_py_265_32 [72] winbot / zope.deprecation_py_265_32 [73] winbot / zope.dottedname_py_265_32 [74] winbot / zope.error_py_265_32 [75] winbot / zope.event_py_265_32 [76] winbot / zope.exceptions_py_265_32 [77] winbot / zope.filerepresentation_py_265_32 [78] winbot / zope.formlib_py_265_32 [79] winbot / zope.generations_py_265_32 [80] winbot / zope.hookable_py_265_32 [81] winbot / zope.i18n_py_265_32 [82] winbot / zope.i18nmessageid_py_265_32 [83] winbot / zope.index_py_265_32 [84] winbot / zope.interface_py_265_32 [85] winbot / zope.intid_py_265_32 [86] winbot / zope.keyreference_py_265_32 [87] winbot / zope.lifecycleevent_py_265_32 [88] winbot / zope.location_py_265_32 [89] winbot / zope.login_py_265_32 [90] winbot / zope.mimetype_py_265_32 [91] winbot / zope.minmax_py_265_32 [92] winbot / zope.pagetemplate_py_265_32 [93] winbot / zope.password_py_265_32 [94] winbot / zope.pluggableauth_py_265_32 [95] winbot / zope.principalannotation_py_265_32 [96] winbot / zope.principalregistry_py_265_32 [97] winbot / zope.processlifetime_py_265_32 [98] winbot / zope.proxy_py_265_32 [99] winbot / zope.ptresource_py_265_32 [100] winbot / zope.publisher_py_265_32 [101]
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
Robert Niederreiter writes: > On 19.08.2012 10:30, Jens Vagelpohl wrote: >> >> On Aug 19, 2012, at 10:17 , Lennart Regebro 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. > > I just wonder why this works then for other projects like plone or > pyramid which basically follows similar rules as the ZF with a signed > contributor agreement required in order to make core contributions. > > http://plone.org/foundation/contributors-agreement/agreement.pdf/view > > https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt > > btw - pyramid seem to have a very pragmatic approach for the signing > process ;) > > Either way - SVN or GIT - it is just a question IF merging code from a > non-contributor is done BY a contributor, not HOW. > > For me the discussion sounds a little like a general denial against > github using the legal story as rationale. +10. I'm so glad others are saying the things I think need saying. I *am* a signed ZF contributor and from experience, the likelihood of such stop energy or other unpleasantness prevents me from contributing to Zope projects nearly as much as I'd like or could. This is a sterling example. To be clear, I'm not invalidating legal concerns, I'm only frustrated that those representing those concerns are taking a hard line on only one concern without seeming to accept multiple invitations to work the problem from all represented concerns. I'm grateful to the others for trying so hard to kickstart a healthy level of participation in zc.buildout development once again. Ross ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
Hi Jens, On 2012-08-19 06:51:47 +, Jens Vagelpohl said: On Aug 19, 2012, at 0:01 , Alex Clark wrote: Hi Jens, On 2012-08-18 07:49:59 +, Jens Vagelpohl said: Hi Alex, Please revert this checkin. You can't just take core software pieces from Zope Foundation-hosted repositories and move them somewhere else. Thanks! I think you are confused. I would suggest you ask Jim Fulton about it, as he moved Buildout to GitHub months ago. Both 1.6.x and 2.x are under active development there. Again, there's a confusion about perceived and legal ownership. You care about legal ownership because it's your job to do so. I care about helping people and shipping code because that's my job. The only thing I feel like I am confused about is why the ZF is asking me to make a change when the action-that-matters was taken months ago by someone else? Why are you making an example out of me? Shouldn't you instead address the "real" issue (which is that Jim moved Buildout)? The code is still there in the previous revision. I didn't maliciously destroy anything. Why does the ZF feel so strongly about the issue that they need to ask me to revert an innocous, nothing-but-well-intentioned change? Have we not lost our way a bit, if this is the case? What good is the legal protection of our software, if we are just sitting around fighting about it, instead of building the software? Sorry, Jens, I don't mean to accuse you or Tres in any way. I just don't understand this situation -at-all- and I don't understand why the "right" thing to do in this case is to focus all this attention on my trivial commit, which obviously alerted you to a situation that had already begun months ago, without me. Alex jens ___ 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 ) -- Alex Clark · http://pythonpackages.com ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
Hi Tres, On 2012-08-19 15:52:52 +, Tres Seaver said: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/18/2012 09:58 PM, Alex Clark wrote: Hi, On 2012-08-19 01:24:31 +, Lennart Regebro said: On Sat, Aug 18, 2012 at 11:03 PM, Tres Seaver wrote: Because the ability to check into svn.zope.org is based on a "chain of custody" managed by the ZF (web account, verified e-mail address, and SSH key). J. Random Hacker's account on Github has no such chain. Sure, but Random J Hacker shouldn't have write permission to the repository, so I don't understand why that makes a difference. IANAL but from my perspective the legitimate issue here is that Domen Ko?ar has not signed the Zope Contributor's Agreement, but Jim has added him to the Buildout organization on GitHub and he has been committing fixes. If I were the ZF, I would either: - Make sure everyone in any ZF organizations on GitHub (e.g. buildout) has signed the contributor agreement, or - Declare that nothing on GitHub (or at least in the buildout organization) is a valid contribution to "the work". In either case, AFAICT zc.buildout development has stopped on svn.zope.org and started on GitHub so let us let the commit stand to reflect this real world circumstance. Alex, please revert the commit removing the ZF's copy of the code in SVN. I don't really feel comfortable doing that (for a variety of reasons). But if you or anyone else wants to do it, I won't object. Would you mind doing it for me, if you feel that strongly about it? Probably something like: $ svn cp -r127509 svn+ssh://svn.zope.org/repos/main/zc.buildout/trunk svn+ssh://svn.zope.org/repos/main/zc.buildout/trunk Thank you and sorry for the trouble, Alex Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAxC9QACgkQ+gerLs4ltQ7gOgCfd+h0SnF8jVLNTaJIldH4qbQV +pEAoK7Qc7WVZ2whyA1UOSCYqQc1cNp3 =6T6l -END PGP SIGNATURE- ___ 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 ) -- Alex Clark · http://pythonpackages.com ___ 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 )
Re: [Zope-dev] We need to change how code ownership works.
Lennart Regebro writes: > On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl wrote: >> >> On Aug 19, 2012, at 10:17 , Lennart Regebro 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. +10. Thanks so much for saying this. Ross ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
On Sun, Aug 19, 2012 at 5:49 PM, Tres Seaver wrote: > The point is that the identity of the committer on Github is not tied to > the ZF's machinery for contributions, which means that it cannot be used > to preserve the "chain of custody" under the contributor agreement. What stops us from fixing this problem? //Lennart ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/18/2012 09:58 PM, Alex Clark wrote: > Hi, > > On 2012-08-19 01:24:31 +, Lennart Regebro said: > >> On Sat, Aug 18, 2012 at 11:03 PM, Tres Seaver >> wrote: >>> Because the ability to check into svn.zope.org is based on a >>> "chain of custody" managed by the ZF (web account, verified e-mail >>> address, and SSH key). J. Random Hacker's account on Github has >>> no such chain. >> >> Sure, but Random J Hacker shouldn't have write permission to the >> repository, so I don't understand why that makes a difference. > > > IANAL but from my perspective the legitimate issue here is that Domen > Ko?ar has not signed the Zope Contributor's Agreement, but Jim has > added him to the Buildout organization on GitHub and he has been > committing fixes. If I were the ZF, I would either: > > - Make sure everyone in any ZF organizations on GitHub (e.g. buildout) > has signed the contributor agreement, or - Declare that nothing on > GitHub (or at least in the buildout organization) is a valid > contribution to "the work". > > In either case, AFAICT zc.buildout development has stopped on > svn.zope.org and started on GitHub so let us let the commit stand to > reflect this real world circumstance. Alex, please revert the commit removing the ZF's copy of the code in SVN. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAxC9QACgkQ+gerLs4ltQ7gOgCfd+h0SnF8jVLNTaJIldH4qbQV +pEAoK7Qc7WVZ2whyA1UOSCYqQc1cNp3 =6T6l -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/18/2012 09:24 PM, Lennart Regebro wrote: > On Sat, Aug 18, 2012 at 11:03 PM, Tres Seaver > wrote: >> Because the ability to check into svn.zope.org is based on a "chain >> of custody" managed by the ZF (web account, verified e-mail address, >> and SSH key). J. Random Hacker's account on Github has no such >> chain. > > Sure, but Random J Hacker shouldn't have write permission to the > repository, so I don't understand why that makes a difference. The point is that the identity of the committer on Github is not tied to the ZF's machinery for contributions, which means that it cannot be used to preserve the "chain of custody" under the contributor agreement. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAxCv4ACgkQ+gerLs4ltQ7hDgCfaQN7zti4rJ6vxCOGMPK/GLoc r8QAoJry8boBEq1l3OIrO61KrAQQwUT1 =F7Vv -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
Hi On 2012-08-19 11:05:39 +, Lennart Regebro said: On Sun, Aug 19, 2012 at 12:16 PM, Jens Vagelpohl wrote: Speaking for myself as ZF representative, it is my duty to make sure that chain of custody for the code is upheld and safeguarded. Convenience, which I feel is driving the move towards GitHub, is nice to have. But I would not do my job if I didn't make extra-sure that any move for Zope Foundation code did not fulfil all legal requirements before spending much thought on convenience. Absolutely, and you are doing a good job as well, as you have no identified a problem that we have been having for a long time, before the problem actually turns legal. That's an amazing relief, because it means we can fix it. FWIW I have pointed Domen Kožar at the contributor agreement instructions located here: - http://docs.zope.org/developer/becoming-a-committer.html and he is interested in signing. What I'd like to see is this issue addressed by a lawyer so we can figure out how to make GitHub work for Zope. If Jim's work on Buildout 2 on GitHub is considered a fork, then I think something is wrong with our process. Here are some scenarios to demonstrate what I think the important issues we must clarify are: Scenario 1 -- - Alex has signed the contributor agreement and commits code to svn.zope.org, no problem. Scenario 2 --- - Alex has signed the contributor agreement and commits patches from other people (who have not signed the agreement) to svn.zope.org, not allowed, IIUC. Scenario 3 --- - Alex has signed the contributor agreement and commits code to GitHub/buildout, no problem. Scenario 4 --- - Alex has signed the contributor agreement and commits patches from other people (who have not signed the agreement) to GitHub/buildout not allowed, IIUC. Scenario 5 --- - No commits from anyone who has not signed the contributor agreement are allowed. If we can all agree on the above, then the only thing left AFAICT is for the ZF to "bless" GitHub/buildout as a ZF repository and have a lawyer confirm that this blessing has merit from a legal perspective. Alex //Lennart ___ 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 ) -- Alex Clark · http://pythonpackages.com ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
On 2012-8-19 12:59, Robert Niederreiter wrote: On 19.08.2012 12:16, Jens Vagelpohl wrote: Done by a contributor with some clear gesture from the non-contributor that code ownership is going into the hands of that contributor. How does this 'clear gesture' from the non-contributor look like right now? A patch attached to an email or a bug report? As Lennard pointed out, how does this differ from a pull request attached to a repository? A simple solution to allow pull requests but keep the submitter-has-signed-policy check is to only allow pull requests made from a ZF-owner repository. github allows pull requests from a different branch within the same repository which makes this very easy. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 )
Re: [Zope-dev] We need to change how code ownership works.
The Plone Foundation adopted a policy for this, see http://plone.org/foundation/materials/foundation-resolutions/patch-policy-052011 As we don't have any terms of service stating so for any of our issue trackers, we don't get any copyright assignments for reported bugs or proposed patches. Patches can be sent we private email, posted to bug trackers, on paste.org like services or sent via pull requests. All of those are legally the same and it's the responsibility of the person doing the checkin to validate the copyright situation. That said a lot of patches don't actually contain any creative work that falls under the copyright rules. This last point is the reason most projects aren't very strict about this issue. Hanno On 19.08.2012, at 13:01, Lennart Regebro wrote: > On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl wrote: >> >> On Aug 19, 2012, at 10:17 , Lennart Regebro 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. > > //Lennart > ___ > 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 ) ___ 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 )
Re: [Zope-dev] We need to change how code ownership works.
On 19.08.2012 13:01, Lennart Regebro wrote: On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl wrote: On Aug 19, 2012, at 10:17 , Lennart Regebro 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. Would it stand the law if there would be a written statement inside the relevant projects stating out that the ownership of code changes as soon as an outside patch gets applied? robert //Lennart ___ 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 ) -- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
On Sun, Aug 19, 2012 at 12:16 PM, Jens Vagelpohl wrote: > Speaking for myself as ZF representative, it is my duty to make sure that > chain of custody for the code is upheld and safeguarded. Convenience, which I > feel is driving the move towards GitHub, is nice to have. But I would not do > my job if I didn't make extra-sure that any move for Zope Foundation code did > not fulfil all legal requirements before spending much thought on convenience. Absolutely, and you are doing a good job as well, as you have no identified a problem that we have been having for a long time, before the problem actually turns legal. That's an amazing relief, because it means we can fix it. //Lennart ___ 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 )
[Zope-dev] We need to change how code ownership works.
On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl wrote: > > On Aug 19, 2012, at 10:17 , Lennart Regebro 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. //Lennart ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
On 19.08.2012 12:16, Jens Vagelpohl wrote: On Aug 19, 2012, at 10:55 , Robert Niederreiter wrote: https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt btw - pyramid seem to have a very pragmatic approach for the signing process ;) An approach I doubt will hold up in a court of law. We require and have wet signatures, which makes me feel a lot more "on the safe side". Thats fine to everyone i think. Referring to github this would require to give write access only to people who have signed the agreement. Either way - SVN or GIT - it is just a question IF merging code from a non-contributor is done BY a contributor, not HOW. Done by a contributor with some clear gesture from the non-contributor that code ownership is going into the hands of that contributor. How does this 'clear gesture' from the non-contributor look like right now? A patch attached to an email or a bug report? As Lennard pointed out, how does this differ from a pull request attached to a repository? For me the discussion sounds a little like a general denial against github using the legal story as rationale. Speaking for myself as ZF representative, it is my duty to make sure that chain of custody for the code is upheld and safeguarded. Convenience, which I feel is driving the move towards GitHub, is nice to have. But I would not do my job if I didn't make extra-sure that any move for Zope Foundation code did not fulfil all legal requirements before spending much thought on convenience. Also perfectly fine. Maybe it's anyway a good idea to find a process enabling contributors going to github with ZF code. robert jens ___ 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 ) -- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
On Aug 19, 2012, at 10:55 , Robert Niederreiter wrote: > https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt > > btw - pyramid seem to have a very pragmatic approach for the signing process > ;) An approach I doubt will hold up in a court of law. We require and have wet signatures, which makes me feel a lot more "on the safe side". > Either way - SVN or GIT - it is just a question IF merging code from a > non-contributor is done BY a contributor, not HOW. Done by a contributor with some clear gesture from the non-contributor that code ownership is going into the hands of that contributor. > For me the discussion sounds a little like a general denial against github > using the legal story as rationale. Speaking for myself as ZF representative, it is my duty to make sure that chain of custody for the code is upheld and safeguarded. Convenience, which I feel is driving the move towards GitHub, is nice to have. But I would not do my job if I didn't make extra-sure that any move for Zope Foundation code did not fulfil all legal requirements before spending much thought on convenience. jens ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
On 19.08.2012 10:30, Jens Vagelpohl wrote: On Aug 19, 2012, at 10:17 , Lennart Regebro 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. I just wonder why this works then for other projects like plone or pyramid which basically follows similar rules as the ZF with a signed contributor agreement required in order to make core contributions. http://plone.org/foundation/contributors-agreement/agreement.pdf/view https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt btw - pyramid seem to have a very pragmatic approach for the signing process ;) Either way - SVN or GIT - it is just a question IF merging code from a non-contributor is done BY a contributor, not HOW. For me the discussion sounds a little like a general denial against github using the legal story as rationale. robert jens ___ 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 ) -- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
On Aug 19, 2012, at 10:17 , Lennart Regebro 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. jens ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
On Sun, Aug 19, 2012 at 8:49 AM, Jens Vagelpohl wrote: > > On Aug 18, 2012, at 21:46 , Lennart Regebro wrote: > >> Yes, but my question is why this changes with github. > > GitHub is a third party infrastructure run by other people. I cannot > ascertain how well it enforces our requirement that all checkins must be from > signed contributors only. I have to say that I find it to be without any reasonable doubt without question that you can only wrote to a repository if you have write access. Questioning this is to me somewhat surprising, and we might as well claim that we can't ascertain how well the current SVN server enforces our requirements, as we don't know what undiscovered security holes it might have. > Furthermore, I cannot ascertain that private contributor data remains private > (email addresses etc). Is this really a requirement? Why is this a requirement? All you need to enter at github is an email (which in practice is all we can verify in ZF as well, as all communication is by email). Why does this email address have to remain private? > 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? //Lennart ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
On 19 August 2012 08:00, Jens Vagelpohl wrote: > > On Aug 19, 2012, at 3:58 , Alex Clark wrote: > > > IANAL but from my perspective the legitimate issue here is that Domen > Kožar has not signed the Zope Contributor's Agreement, but Jim has added > him to the Buildout organization on GitHub and he has been committing > fixes. If I were the ZF, I would either: > > > > - Make sure everyone in any ZF organizations on GitHub (e.g. buildout) > has signed the contributor agreement, or > > - Declare that nothing on GitHub (or at least in the buildout > organization) is a valid contribution to "the work". > > > > In either case, AFAICT zc.buildout development has stopped on > svn.zope.org and started on GitHub so let us let the commit stand to > reflect this real world circumstance. > > Right now it can only be the second option. There's no "ZF organization" > on GitHub. Legally, the zc.buildout fork now existing on GitHub is > independent of the ZF, and the developers maintaining it are acting > independent of the ZF. Don't get me wrong, they have every right to do so. > But right now they cannot claim their software as being part of the Zope > Foundation set of software. The same is true for all packages forked onto > GitHub that were maintained on svn.zope.org before. > It may be useful for the sake of this thread to articulate why the people who did fork it and move it to GitHub might benefit from the above. Martin ___ 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 )
Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
On Aug 19, 2012, at 3:58 , Alex Clark wrote: > IANAL but from my perspective the legitimate issue here is that Domen Kožar > has not signed the Zope Contributor's Agreement, but Jim has added him to the > Buildout organization on GitHub and he has been committing fixes. If I were > the ZF, I would either: > > - Make sure everyone in any ZF organizations on GitHub (e.g. buildout) has > signed the contributor agreement, or > - Declare that nothing on GitHub (or at least in the buildout organization) > is a valid contribution to "the work". > > In either case, AFAICT zc.buildout development has stopped on svn.zope.org > and started on GitHub so let us let the commit stand to reflect this real > world circumstance. Right now it can only be the second option. There's no "ZF organization" on GitHub. Legally, the zc.buildout fork now existing on GitHub is independent of the ZF, and the developers maintaining it are acting independent of the ZF. Don't get me wrong, they have every right to do so. But right now they cannot claim their software as being part of the Zope Foundation set of software. The same is true for all packages forked onto GitHub that were maintained on svn.zope.org before. This may change in the future should the ZF one day embrace GitHub as the canonical repository, but that hasn't happened at this point. jens ___ 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 )
