* Lennart Regebro <rege...@gmail.com> [2012-08-19 13:01]:
> On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl <j...@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?


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to