Mailing List Archive: Zope: Dev

We need to change how code ownership works.

1 2

View All

Index | Next | Previous | View Threaded

regebro at gmail

Aug 19, 2012, 4:01 AM

Post #1 of 30 (320 views)
Permalink

We need to change how code ownership works.

On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens [at] dataflake> wrote:
>
> On Aug 19, 2012, at 10:17 , Lennart Regebro <regebro [at] gmail> 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 [at] zope
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 )

rnix at squarewave

Aug 19, 2012, 4:27 AM

Post #2 of 30 (313 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

On 19.08.2012 13:01, Lennart Regebro wrote:
> On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens [at] dataflake> wrote:
>>
>> On Aug 19, 2012, at 10:17 , Lennart Regebro <regebro [at] gmail> 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 [at] zope
> 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 [at] zope
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 )

hanno at hannosch

Aug 19, 2012, 4:38 AM

Post #3 of 30 (308 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

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 <regebro [at] gmail> wrote:
> On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens [at] dataflake> wrote:
>>
>> On Aug 19, 2012, at 10:17 , Lennart Regebro <regebro [at] gmail> 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 [at] zope
> 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 [at] zope
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 )

me at rpatterson

Aug 19, 2012, 10:37 AM

Post #4 of 30 (308 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

Lennart Regebro <regebro [at] gmail> writes:

> On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens [at] dataflake> wrote:
>>
>> On Aug 19, 2012, at 10:17 , Lennart Regebro <regebro [at] gmail> 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 [at] zope
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 )

ws at gocept

Aug 19, 2012, 11:18 PM

Post #5 of 30 (305 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

* Lennart Regebro <regebro [at] gmail> [2012-08-19 13:01]:
> On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens [at] dataflake> 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 [at] zope
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 )

me at rpatterson

Aug 19, 2012, 11:53 PM

Post #6 of 30 (305 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

Wolfgang Schnerring <ws [at] gocept> writes:

> * Lennart Regebro <regebro [at] gmail> [2012-08-19 13:01]:
>> On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens [at] dataflake> 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 [at] zope
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 )

jens at dataflake

Aug 20, 2012, 12:07 AM

Post #7 of 30 (304 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

On Aug 20, 2012, at 8:18 , Wolfgang Schnerring <ws [at] gocept> 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

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

regebro at gmail

Aug 20, 2012, 12:08 AM

Post #8 of 30 (305 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

On Sun, Aug 19, 2012 at 1:38 PM, Hanno Schlichting <hanno [at] hannosch> wrote:
> 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.

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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

regebro at gmail

Aug 20, 2012, 12:19 AM

Post #9 of 30 (304 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

On Mon, Aug 20, 2012 at 9:07 AM, Jens Vagelpohl <jens [at] dataflake> 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

regebro at gmail

Aug 20, 2012, 12:27 AM

Post #10 of 30 (304 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

On Mon, Aug 20, 2012 at 9:19 AM, Lennart Regebro <regebro [at] gmail> 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

jp at nexedi

Aug 20, 2012, 1:28 AM

Post #11 of 30 (304 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

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 [at] gmail> [2012-08-19 13:01]:
> > On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <jens [at] dataflake> 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 [at] zope
> 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 )
>

regebro at gmail

Aug 20, 2012, 2:09 AM

Post #12 of 30 (305 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

On Mon, Aug 20, 2012 at 10:28 AM, <jp [at] nexedi> 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

leorochael at gmail

Aug 20, 2012, 2:58 AM

Post #13 of 30 (304 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

Hi,

On Mon, Aug 20, 2012 at 11:09 AM, Lennart Regebro <regebro [at] gmail> wrote:
> On Mon, Aug 20, 2012 at 10:28 AM, <jp [at] nexedi> 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-mitigation

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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

matthew at matthewwilkes

Aug 20, 2012, 3:01 AM

Post #14 of 30 (305 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

charlie.clark at clark-consulting

Aug 20, 2012, 3:10 AM

Post #15 of 30 (305 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

Am 20.08.2012, 11:09 Uhr, schrieb Lennart Regebro <regebro [at] gmail>:

> 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

regebro at gmail

Aug 20, 2012, 3:24 AM

Post #16 of 30 (305 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

On Mon, Aug 20, 2012 at 11:58 AM, Leonardo Rochael Almeida
<leorochael [at] gmail> wrote:
> Hi,
>
> On Mon, Aug 20, 2012 at 11:09 AM, Lennart Regebro <regebro [at] gmail> wrote:
>> On Mon, Aug 20, 2012 at 10:28 AM, <jp [at] nexedi> 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

rnix at squarewave

Aug 20, 2012, 3:27 AM

Post #17 of 30 (305 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

On 20.08.2012 12:10, Charlie Clark wrote:
> Am 20.08.2012, 11:09 Uhr, schrieb Lennart Regebro <regebro [at] gmail>:
>
>> 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

charlie.clark at clark-consulting

Aug 20, 2012, 3:39 AM

Post #18 of 30 (304 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter <rnix [at] squarewave>:

> 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

rnix at squarewave

Aug 20, 2012, 3:39 AM

Post #19 of 30 (305 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

wichert at wiggy

Aug 20, 2012, 3:49 AM

Post #20 of 30 (304 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

On 08/20/2012 12:39 PM, Charlie Clark wrote:
> Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter
> <rnix [at] squarewave>:
> 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.

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.

_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

rnix at squarewave

Aug 20, 2012, 3:50 AM

Post #21 of 30 (305 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

On 20.08.2012 12:39, Charlie Clark wrote:
> Am 20.08.2012, 12:27 Uhr, schrieb Robert Niederreiter <rnix [at] squarewave>:
>
>> 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

rnix at squarewave

Aug 20, 2012, 3:52 AM

Post #22 of 30 (308 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

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 [at] squarewave>:
>> 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.
>
> 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 [at] zope
> 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 [at] zope
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 )

jim at zope

Aug 20, 2012, 4:07 AM

Post #23 of 30 (305 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

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

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

IIUC, their repositories have CONTRIBUTORS.txt files:

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

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

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

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

Jim

--
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://zo.pe/Kqm
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

rnix at squarewave

Aug 20, 2012, 4:11 AM

Post #24 of 30 (304 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

jim at zope

Aug 20, 2012, 4:25 AM

Post #25 of 30 (304 views)
Permalink

Re: We need to change how code ownership works. [In reply to]

On Mon, Aug 20, 2012 at 6:39 AM, Charlie Clark
<charlie.clark [at] clark-consulting> 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads