We need to change how code ownership works.
On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens@dataflake.org> wrote:
On Aug 19, 2012, at 10:17 , Lennart Regebro <regebro@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. //Lennart
On 19.08.2012 13:01, Lennart Regebro wrote:
On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens@dataflake.org> wrote:
On Aug 19, 2012, at 10:17 , Lennart Regebro <regebro@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. 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
The Plone Foundation adopted a policy for this, see http://plone.org/foundation/materials/foundation-resolutions/patch-policy-05... 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 <regebro@gmail.com> wrote:
On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens@dataflake.org> wrote:
On Aug 19, 2012, at 10:17 , Lennart Regebro <regebro@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.
//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 )
On Sun, Aug 19, 2012 at 1:38 PM, Hanno Schlichting <hanno@hannosch.eu> wrote:
The Plone Foundation adopted a policy for this, see http://plone.org/foundation/materials/foundation-resolutions/patch-policy-05...
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.
I Am Not A Lawyer, but this sounds reasonable, and if it's good enough for the Plone foundation, it's good enough for me. :-) //Lennart
Lennart Regebro <regebro@gmail.com> writes:
On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens@dataflake.org> wrote:
On Aug 19, 2012, at 10:17 , Lennart Regebro <regebro@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.
+10. Thanks so much for saying this. Ross
* Lennart Regebro <regebro@gmail.com> [2012-08-19 13:01]:
On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens@dataflake.org> 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
Wolfgang Schnerring <ws@gocept.com> writes:
* Lennart Regebro <regebro@gmail.com> [2012-08-19 13:01]:
On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens@dataflake.org> 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
On Aug 20, 2012, at 8:18 , Wolfgang Schnerring <ws@gocept.com> wrote:
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?
Maintaining the chain of custody doesn't just consist of selecting pull requests or patches coming from somewhere. It also means verifying the contributor - be it the one who is creating the patch or pull request or the one who is merging new code into the repository - is who he claims to be. In the current setup the verification of the merging contributor is done using unique SSH logins with keys for every contributor, which works very well. By the way, there's no problem converting project repositories on an as-needed basis to Git repositories in the current infrastructure. But I feel the discussion is more about "GitHub or nothing". Apologies to anyone who feels offended, I'm just speaking privately here under the impression that no one has mentioned any alternative solution. Moving away from any specific solution and speaking with my Zope Foundation hat on candidates must fulfil requirements like these (I don't claim completeness here, suggestions are welcome): - Read access for everyone including anonymous viewers - Write access for signed contributors only - Signed contributors must be able to create new repositories themselves (current analogy: A contributor adds a new project on svn.zope.org) - Good verification that a login to the chosen system represents a specific person/contributor (current example: access via unique SSH logins with keys) - Only ZF-appointed contributor admins may open access for contributors after receiving and verifying signed contributor agreements (currently Andreas Jung as officially appointed contributor committee member and Christian Theune as board member and contributor committee member handle this job) - Only ZF-appointed contributor admins (see above) may change or revoke access privileges for contributors - a reasonably convenient web view onto the repositories/projects for visitors and contributors - a reasonably convenient way (e.g. web admin capabilities) for the ZF contributor adminstration to do their job jens
On Mon, Aug 20, 2012 at 9:07 AM, Jens Vagelpohl <jens@dataflake.org> wrote:
Maintaining the chain of custody doesn't just consist of selecting pull requests or patches coming from somewhere. It also means verifying the contributor - be it the one who is creating the patch or pull request or the one who is merging new code into the repository - is who he claims to be. In the current setup the verification of the merging contributor is done using unique SSH logins with keys for every contributor, which works very well.
Once again I have to say that I think it's beyond any reasonable doubt that whoever is using a github account is the owner of that account. Somebody could steal an SSH key as well. I'm pretty sure that the claim "I know it says that Jens did the checkin, but in fact it was me, I had stolen his account, so therefore I own the copyright" is hardly a claim that will hold up in a court of law.
- Read access for everyone including anonymous viewers
Github: Check.
- Write access for signed contributors only
Github: Check.
- Signed contributors must be able to create new repositories themselves (current analogy: A contributor adds a new project on svn.zope.org)
Github: Check.
- Good verification that a login to the chosen system represents a specific person/contributor (current example: access via unique SSH logins with keys)
Github: Check.
- Only ZF-appointed contributor admins may open access for contributors after receiving and verifying signed contributor agreements (currently Andreas Jung as officially appointed contributor committee member and Christian Theune as board member and contributor committee member handle this job)
Github: I don't know. I took the liberty of adding you to one of my repos as collaborator, but I didn't find any way to change your privileges so that you also could add collaborators, so someone else have to answer that more closely. (I removed you as a collaborator again, but just FYI: If anyone wants write access to my github repos you'll probably get it. :-) )
- Only ZF-appointed contributor admins (see above) may change or revoke access privileges for contributors
Same thing, no?
- a reasonably convenient web view onto the repositories/projects for visitors and contributors
Github: Check
- a reasonably convenient way (e.g. web admin capabilities) for the ZF contributor adminstration to do their job
Github: Check The discussion is not github or nothing, but almost. Github makes open source easier. I got angry when Plone moved to github with basically no discussion, but there is no doubt that it was the right decision. //Lennart
On Mon, Aug 20, 2012 at 9:19 AM, Lennart Regebro <regebro@gmail.com> wrote:
Github: I don't know. I took the liberty of adding you to one of my repos as collaborator, but I didn't find any way to change your privileges so that you also could add collaborators, so someone else have to answer that more closely. (I removed you as a collaborator again, but just FYI: If anyone wants write access to my github repos you'll probably get it. :-) )
And I just realized that this test was completely pointless, as I was testing on repositories, but what we are takling about is "Organizations" like https://github.com/collective and https://github.com/plone. I'm 99% sure that Github fulfills the requirements here as well. I for example, have write access to the repos in the Collective, I can create new repos, but I do not have admin rights, showing that there is separation between collaborators and admins, and that therefore only Andreas and Christian could be made admins, fulfilling the requirement here as well. Hence I'm 99.8% sure that Github fulfills all the requirements, and that we can move development of various parts to Github with no problem. The patch/merge problem exists as of today, with or without Github, and needs to be fixed in any case. The Plone patch policy is one option there. //Lennart
Jens Vagelpohl wrote:
Maintaining the chain of custody doesn't just consist of selecting pull requests or patches coming from somewhere. It also means verifying the contributor - be it the one who is creating the patch or pull request or the one who is merging new code into the repository - is who he claims to be. In the current setup the verification of the merging contributor is done using unique SSH logins with keys for every contributor, which works very well.
This is how github works, too. The only difference is that the admin UI for changing your SSH key is on the github site, not the ZF site.
By the way, there's no problem converting project repositories on an as-needed basis to Git repositories in the current infrastructure. But I feel the discussion is more about "GitHub or nothing". Apologies to anyone who feels offended, I'm just speaking privately here under the impression that no one has mentioned any alternative solution.
There are alternative git solutions, all of which would be preferable to the current SVN setup. GitHub is just a hosted service that many of us are already using and have admin helper tools for. By the same token, the "let's not use github" side of this discussion feels to me like "self-hosted or nothing". We absolutely should have backups/mirrors of what's on github, but we shouldn't abandon the idea of using github because we're only going to be using 40% of the great things it adds on top of git, rather than 100%. Matt
Hi, I am interested in both legal and practical issues. Here is a simple and clean solution to handle both: 1- ZF maintains its own github-like infrastructure based on self hosted open source software. Any tool can be used, as long as this tool has UI for managing code reviews and merge requests in an easy way. There are many good candidates for that. 2- The current contributor policy of ZF is maintained. All official merges go through ZF infrastructure which is controlled by ZF community. 3- A mirror of ZF code is maintained officially on external proprietary tools such as Github (found to be quite attractive by lots of people, just like Linus himself found bitkeeper attractive some years ago). Whenever fashion evolves and something else than github becomes "à la mode", an official mirror can be set on such tools. 4- Users of github or whatever "à la mode" proprietary tools are free to prepare their merges there. However, whenever it comes to an official merge, ZF infrastructure is used. This approach protects from: - legal risks posed by github - instabilities due to ever changing fashion in code hosting (sourceforce then google code then bitbucket then github then etc.) - destruction, traceability or security issues posed by cloud infrastructure not controlled by ZF (logs, bugs, forums, not only code) This approach enforces: - freedom for fashion victims to follow latest fashions - freedom for dinosaurs to benefit from community controlled infrastructure and open source tools - freedom for fashion dinosaurs to benefit from both worlds Regards, JPS.
* Lennart Regebro <regebro@gmail.com> [2012-08-19 13:01]:
On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens@dataflake.org> 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 )
On Mon, Aug 20, 2012 at 10:28 AM, <jp@nexedi.com> wrote:
This approach protects from: - legal risks posed by github
Such as?
- instabilities due to ever changing fashion in code hosting (sourceforce then google code then bitbucket then github then etc.)
Sure. At the cost of a lot of extra complexity, that is.
- destruction, traceability or security issues posed by cloud infrastructure not controlled by ZF (logs, bugs, forums, not only code)
What would these be.
This approach enforces: - freedom for fashion victims to follow latest fashions
Making it easy to contribute is not a fashion but a fundamental part of how good open source works. //Lennart
Hi, On Mon, Aug 20, 2012 at 11:09 AM, Lennart Regebro <regebro@gmail.com> wrote:
On Mon, Aug 20, 2012 at 10:28 AM, <jp@nexedi.com> wrote:
This approach protects from: - legal risks posed by github
Such as?
I'll let Jean-Paul elaborate, but I suppose it could be something along the lines of GitHub suddenly disappearing with (some of) your content (code, forum posts, metadata like group associations) or making some other unwanted use of it, and you having no legal recourse because of some small print in some EULA somewhere that someone didn't bother to fully read.
- instabilities due to ever changing fashion in code hosting (sourceforce then google code then bitbucket then github then etc.)
Sure. At the cost of a lot of extra complexity, that is.
- destruction, traceability or security issues posed by cloud infrastructure not controlled by ZF (logs, bugs, forums, not only code)
What would these be.
c.f.: https://github.com/blog/1068-public-key-security-vulnerability-and-mitigatio... The point is not that these can't happen to ZF repos, but that ZF would have no recourse to fix the issue except to wait on GitHub to act on it.
This approach enforces: - freedom for fashion victims to follow latest fashions
Making it easy to contribute is not a fashion but a fundamental part of how good open source works.
Yes, and both you and I are around long enough to remember when SourceForge w/ SVN was the easiest way to get others to contribute, which is why Plone originally selected it. Now it's GitHub and git. By fashion JP doesn't meant to say that the selection was frivolous, but that the same criteria can lead to selection of different tools/services at different points in time. In any case, this discussion seems to be converging, which is excellent. It is also one of those discussions that could be solved in less than an hour by folks talking over beverage, but takes a ton of attention bandwidth and time when discussed over e-mail. So I'd like to reinforce Vincent Pelletier's invitation to the Zope4 sprint that is going to be hosted in Lille next week[1] for which both Jens Vagelpohl and Laurence Rowe have confirmed their presence. [1] http://www.erp5.org/Zope4Sprint2012 I'm sure we can hash out a solution that works for everybody in a very short amount of time. Cheers, Leo
On Mon, Aug 20, 2012 at 11:58 AM, Leonardo Rochael Almeida <leorochael@gmail.com> wrote:
Hi,
On Mon, Aug 20, 2012 at 11:09 AM, Lennart Regebro <regebro@gmail.com> wrote:
On Mon, Aug 20, 2012 at 10:28 AM, <jp@nexedi.com> wrote:
This approach protects from: - legal risks posed by github
Such as?
I'll let Jean-Paul elaborate, but I suppose it could be something along the lines of GitHub suddenly disappearing with (some of) your content (code, forum posts, metadata like group associations)
We need backups, yes.
making some other unwanted use of it, and you having no legal recourse because of some small print in some EULA somewhere that someone didn't bother to fully read.
I have absolutely no idea what kind of legal but unwanted use that could be, except spamming email addresses of course.
The point is not that these can't happen to ZF repos, but that ZF would have no recourse to fix the issue except to wait on GitHub to act on it.
OK, that's the first good argument I have heard. //Lennart
Am 20.08.2012, 11:09 Uhr, schrieb Lennart Regebro <regebro@gmail.com>:
Such as?
As previously noted: the T&C's in particular the indemnification clause. Plus, the usual when dealing with an apparently free service provided by a company beholden to VC's. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
On 20.08.2012 12:10, Charlie Clark wrote:
Am 20.08.2012, 11:09 Uhr, schrieb Lennart Regebro <regebro@gmail.com>:
Such as?
As previously noted: the T&C's in particular the indemnification clause. Plus, the usual when dealing with an apparently free service provided by a company beholden to VC's. There are lots of very famous os projects hostet on github - which - without any doubt raises the reputation of github itself.
https://github.com/popular/starred i doubt that github i willing to get into the doghouse by doing really nasty things - and thus getting into risk of loosing projects. lots of you also use gmail, g+ or other stuff, where i have more concerns about abuse than at github... even the linux kernel guys seem to prefer the benefits of github. https://github.com/torvalds/linux still, all your concerns are reasonable, but the claimed implications should stay lifelike. Robert
Charlie
-- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at
Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter <rnix@squarewave.at>:
There are lots of very famous os projects hostet on github - which - without any doubt raises the reputation of github itself.
ah, the common cold defence: everyone has it so it must be good.
https://github.com/popular/starred i doubt that github i willing to get into the doghouse by doing really nasty things - and thus getting into risk of loosing projects.
This is pure speculation, or are you privy to board decisions at Github.
lots of you also use gmail, g+ or other stuff, where i have more concerns about abuse than at github...
This irrelevant in the context of ownership and copyright.
even the linux kernel guys seem to prefer the benefits of github. https://github.com/torvalds/linux
Yes, promotional materials would have nothing to do with the commercial nature of the service. Not that I'm against a commercial service provider.
still, all your concerns are reasonable, but the claimed implications should stay lifelike.
I raised a specific objection: that the onus is on anyone with a Github account to demonstrate their code does not violate any patents in the case of a claim feels like a pretty real threat to me. Again, as Jens has repeatedly said we should not conflate the separate items of toolchain and service provider. Zope Foundation has hardware and a proven track record in hosting. Is anyone actually criticising this? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
On 08/20/2012 12:39 PM, Charlie Clark wrote:
Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter <rnix@squarewave.at>: even the linux kernel guys seem to prefer the benefits of github.
Yes, promotional materials would have nothing to do with the commercial nature of the service. Not that I'm against a commercial service provider.
In this case also untrue as far as I know: Linus only setup a mirror on github to have some way to publish a git tree after the kernel.org comprise. He was also very explicit about not willing to use any github features. Wichert.
On 20.08.2012 12:49, Wichert Akkerman wrote:
On 08/20/2012 12:39 PM, Charlie Clark wrote:
Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter <rnix@squarewave.at>: even the linux kernel guys seem to prefer the benefits of github.
Yes, promotional materials would have nothing to do with the commercial nature of the service. Not that I'm against a commercial service provider.
In this case also untrue as far as I know: Linus only setup a mirror on github to have some way to publish a git tree after the kernel.org comprise. He was also very explicit about not willing to use any github features.
See my presious mail, i already revised this.
Wichert.
_______________________________________________ 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
On 20.08.2012 12:39, Charlie Clark wrote:
Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter <rnix@squarewave.at>:
There are lots of very famous os projects hostet on github - which - without any doubt raises the reputation of github itself.
ah, the common cold defence: everyone has it so it must be good. no, just a manner of chance.
and even if, git is not proprietary.
https://github.com/popular/starred i doubt that github i willing to get into the doghouse by doing really nasty things - and thus getting into risk of loosing projects.
This is pure speculation, or are you privy to board decisions at Github.
see above, git is not proprietary. nobody is trapped inside github at all if nasty things happen.
lots of you also use gmail, g+ or other stuff, where i have more concerns about abuse than at github...
This irrelevant in the context of ownership and copyright.
you came up with concerns against VC's. So in which context was this meant then? -Robert
Charlie
-- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at
Am 20.08.2012, 12:50 Uhr, schrieb Robert Niederreiter <rnix@squarewave.at>:
On 20.08.2012 12:39, Charlie Clark wrote:
Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter <rnix@squarewave.at>:
There are lots of very famous os projects hostet on github - which - without any doubt raises the reputation of github itself.
ah, the common cold defence: everyone has it so it must be good. no, just a manner of chance.
and even if, git is not proprietary.
Git is the tool and not the service.
https://github.com/popular/starred i doubt that github i willing to get into the doghouse by doing really nasty things - and thus getting into risk of loosing projects.
This is pure speculation, or are you privy to board decisions at Github. see above, git is not proprietary. nobody is trapped inside github at all if nasty things happen.
Changes to the T&C's that substantially affect this can happen at any time.
lots of you also use gmail, g+ or other stuff, where i have more concerns about abuse than at github...
This irrelevant in the context of ownership and copyright. you came up with concerns against VC's. So in which context was this meant then?
Without wanting to start a diatribe against VC's: the key term was "beholden to". VC's are understandably interested in a quick and substantial return on their investment and will do whatever it takes to achieve that. They are not philanthropists and ownership is a key lever for them. This is a fundamentally different proposition to paying for a service from a company or setting up an organisation to do it yourself. There is no free lunch. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
On 20.08.2012 12:39, Charlie Clark wrote:
I raised a specific objection: that the onus is on anyone with a Github account to demonstrate their code does not violate any patents in the case of a claim feels like a pretty real threat to me. i agree. but even here i wonder whats the difference if someone claims copyright on code which was committed at github vs. code which was committed somewhere else.
Again, as Jens has repeatedly said we should not conflate the separate items of toolchain and service provider. Zope Foundation has hardware and a proven track record in hosting. Is anyone actually criticising this?
No. -Robert
Charlie
-- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at
On Mon, Aug 20, 2012 at 6:39 AM, Charlie Clark <charlie.clark@clark-consulting.eu> wrote: ...
Again, as Jens has repeatedly said we should not conflate the separate items of toolchain and service provider.
+1
Zope Foundation has hardware and a proven track record in hosting. Is anyone actually criticising this?
FTR, in the case of svn.zope.org, it's ZC hardware and hosting with a lot of much appreciated help from Jens. We're doing a pretty ok job (if you ignore a near catastrophe) in providing what is, by today's standards, a bare-bones service. User management is awkward. We lack any automated support for review, and a number of other services provides by github and bitbucket. svn.zope.org doesn't take much of my time most of the time, but it's still a potential (and occasional real) time suck for me that I'd love to jettison. Life is short, why do this ourselves when there are excellent services available? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm
Am 20.08.2012, 13:25 Uhr, schrieb Jim Fulton <jim@zope.com>:
FTR, in the case of svn.zope.org, it's ZC hardware and hosting with a lot of much appreciated help from Jens.
My mistake, I thought that Foundation owned it's own hardware. I must have misinterpreted something.
We're doing a pretty ok job (if you ignore a near catastrophe) in providing what is, by today's standards, a bare-bones service. User management is awkward. We lack any automated support for review, and a number of other services provides by github and bitbucket.
svn.zope.org doesn't take much of my time most of the time, but it's still a potential (and occasional real) time suck for me that I'd love to jettison.
This is a very good reason to examine the services of a commercial provider (independently of the discussion or what tools are required or desirable). Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
Hi,
We're doing a pretty ok job (if you ignore a near catastrophe) in providing what is, by today's standards, a bare-bones service. User management is awkward. We lack any automated support for review, and a number of other services provides by github and bitbucket.
There are now open source, self hosted and resilient alternatives with same level of ease. Having such alternatives provided officially by ZF does not prevent fans of <name any commercial service here> from using it.
svn.zope.org doesn't take much of my time most of the time, but it's still a potential (and occasional real) time suck for me that I'd love to jettison.
Nexedi is ready to: - spend time with assigned workforce - donate hardware In order to make sure that buildout / Zope development infrastructure remains operated by community with garanteed data resiliency (logs, forums, not only code), auditability (signed contributor documents, certificates, connection logs).
Life is short, why do this ourselves when there are excellent services available?
For the same reasons as Linux and open source in general exist. Because there is no proof that such services will remain excellent (see www.iwgcr.org). Because there is a statistical proof showing that a decentralized hosting system operated by community under diverse juridictions (and managed by buildout for example....) can achieve higher resiliency and availability than a centralized hosting system operated by a single company under a single juridiction. But maybe afterall, nobody believes anymore in open source merits. Regards, JPS.
On Mon, Aug 20, 2012 at 12:39 PM, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
https://github.com/popular/starred i doubt that github i willing to get into the doghouse by doing really nasty things - and thus getting into risk of loosing projects.
This is pure speculation, or are you privy to board decisions at Github.
Yet again, I point out that the nastiest thing they legally can do is spamming your email address.
I raised a specific objection: that the onus is on anyone with a Github account to demonstrate their code does not violate any patents in the case of a claim feels like a pretty real threat to me.
If you are on Github or not makes no difference. Github has that clause to protect themselves if somebody else hosts copyright or patent protected code. It means, should Zope violate any patents and Github get sued because of this, the Zope Foundation needs to pay any damages. If we host it ourself, the *we* get sued, and need to pay the damages anyway. Hence Github or no Github yet again makes little, if any, difference.
Again, as Jens has repeatedly said we should not conflate the separate items of toolchain and service provider. Zope Foundation has hardware and a proven track record in hosting. Is anyone actually criticising this?
This is not about git vs svn. It's about using external services, with all the benefits this gets us, or not. And the arguments against are so far mostly because of perceived legal problems with using an external service. Problems that in fact either don't exist, or are just as severe with self-hosting of the code. //Lennart
"Charlie Clark" <charlie.clark@clark-consulting.eu> writes:
Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter <rnix@squarewave.at>:
https://github.com/popular/starred i doubt that github i willing to get into the doghouse by doing really nasty things - and thus getting into risk of loosing projects.
This is pure speculation, or are you privy to board decisions at Github.
It is also speculation that the ZF won't become in some form or another a liability to, rather than an asset to, Zope development and community participation. It's also speculation that ZF efforts and the efforts of its volunteers will do better at maintaining security or stability of services. Ross
On 20.08.2012 12:27, Robert Niederreiter wrote:
even the linux kernel guys seem to prefer the benefits of github. ok, this one was obviously a one-timer due to server troubles at kernel.org. anyway...
-- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at
On Sun, Aug 19, 2012 at 7:01 AM, Lennart Regebro <regebro@gmail.com> wrote:
On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens@dataflake.org> wrote:
On Aug 19, 2012, at 10:17 , Lennart Regebro <regebro@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
participants (12)
-
Charlie Clark -
Hanno Schlichting -
Jens Vagelpohl -
Jim Fulton -
jp＠nexedi.com -
Lennart Regebro -
Leonardo Rochael Almeida -
Matthew Wilkes -
Robert Niederreiter -
Ross Patterson -
Wichert Akkerman -
Wolfgang Schnerring