jp at nexedi
Aug 20, 2012, 1:28 AM
Post #11 of 30
Re: We need to change how code ownership works.
[In reply to]
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
> * 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?
> Zope-Dev maillist - Zope-Dev [at] zope
> ** No cross posts or HTML encoding! **
> (Related lists -
> https://mail.zope.org/mailman/listinfo/zope )