[Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Dave Airlie]

On Thu, 20 Sep 2018 at 05:56, Mauro Carvalho Chehab
<mchehab+samsung at kernel.org> wrote:
>
> Em Wed, 19 Sep 2018 10:16:21 -0400
> James Bottomley <James.Bottomley at HansenPartnership.com> escreveu:
>
> > On Wed, 2018-09-19 at 09:03 -0300, Mauro Carvalho Chehab wrote:
> > > Em Wed, 19 Sep 2018 08:37:49 -0300
> > > Mauro Carvalho Chehab <mchehab+samsung at kernel.org> escreveu:
> > >
> > > > Em Wed, 19 Sep 2018 07:28:02 -0400
> > > > James Bottomley <James.Bottomley at HansenPartnership.com> escreveu:
> > > >
> > > > > On Tue, 2018-09-18 at 16:29 -0300, Mauro Carvalho Chehab wrote:
> > > > > > Em Tue, 18 Sep 2018 10:02:08 -0400
> > > > > > James Bottomley <James.Bottomley at HansenPartnership.com>
> > > > > > escreveu:
> > > > > >
> > > > > > > > After the past 2-3 days I get the feeling there are
> > > > > > > > maintainers unsure about how this affects them and I think
> > > > > > > > assuaging those fears might be a good thing.
> > > > > > > >
> > > > > > >
> > > > > > > From my perspective, which is probably fairly widespread:
> > > > > > > we're already pretty much policing the lists using a set of
> > > > > > > rules which match fairly closely to the new CoC, so there
> > > > > > > should really be no huge impact.
> > > > > >
> > > > > > After carefully reading it a couple of times, I think it has a
> > > > > > huge impact.
> > > > > >
> > > > > > The more immediate impact is with regards to this wording:
> > > > > >
> > > > > >       "Examples of unacceptable behavior by participants
> > > > > > include:
> > > > > >       ...
> > > > > >       * Publishing others’ private information, such as a
> > > > > > physical or electronic
> > > > > >         address, without explicit permission"
> > > > > >
> > > > > > When we publish a patch with a Signed-off-by, Reviewed-by,
> > > > > > Acked-by, Requested-by, Suggested-by, etc, we are actually
> > > > > > publishing an electronic address.
> > > > > >
> > > > > > The DCO 1.1 has an explicit clause that would allow to publish
> > > > > > the email address from the SOB's, together to its
> > > > > > redistribution:
> > > > > >
> > > > > > "       (d) I understand and agree that this project and the
> > > > > > contribution
> > > > > >             are public and that a record of the contribution
> > > > > > (including all
> > > > > >             personal information I submit with it, including my
> > > > > > sign-off) is
> > > > > >             maintained indefinitely and may be redistributed
> > > > > > consistent with
> > > > > >             this project or the open source license(s)
> > > > > > involved."
> > > > > >
> > > > > > But that doesn't cover the other tags.
> > > > >
> > > > > I disagree with the strictness of the interpretation: "including
> > > > > all personal information I submit with it" covers all the other
> > > > > tags. Although the expectation is the permission was obtained by
> > > > > one of the people adding the sign off because that's how the DCO
> > > > > flows, which might be a bit wishful thinking, we've always
> > > > > thought that it covers the additional tags for the use case
> > > > > section (d) was created for: national data protection acts and if
> > > > > it covers that case, it surely covers the CoC permission case.
> > > >
> > > > I see your point. Yes, that places the SOB signer's as^W backs
> > > > responsible for such thing.
> > > >
> > > > > Additionally, as others have said, if the tag was added from
> > > > > information in the public mailing list, it's not private within
> > > > > the meaning of the CoC.  I think the electronic mail example in
> > > > > the CoC is simply because it's more used in a github type
> > > > > environment where email addresses are private and not necessarily
> > > > > part of the workflow.
> > > >
> > > > If it doesn't apply, it should be removed. Legal documents with
> > > > unneeded terms only cause confusion (and this *is* a legal document
> > > > - a
> > >
> > > In time:
> > >     and this *is* a legal document -> I believe that this is a
> > > legal document
> > >
> > > I'm actually waiting for a legal advice about this under US laws.
> > > Under Brazilian laws (and probably other civil law system), I'm
> > > almost sure it is a contract - if this is a valid or a void one has
> > > yet to be seen.
> >
> > OK, I can't disagree with this.  It does definitely impose obligations
> > that are legally meaningful.  However ...

A legal document would mean there were legal repercussions for
violating it, like violating copyright laws or getting fired for
violating your employment contract.

This doesn't seem to stand on that, this is a set of guidelines for
how a community should act. The people interpreting the document are
members of the community that we in theory trust (via TAB elections).
These are examples of things that cause problems, and guidelines to
follow to avoid bad behaviours, but the intent still matters at the
end of the day. If someone complains you accidentally tagged their
email, the people on the complaints review will figure that out.

It's funny we don't really have this problem with the drm so far, due
to mainly group maintainership. If someone sends me a private email
unless it's a security issue, I ask them to resend it to the public
lists and/or use a public bugzilla, before I action it. This ensures
that members of group teams can engage as a group instead of one
maintainer having the primary inbox load.

I've no objections to clarifying this sort of thing and I think it's
important that we do, but trying to turn this document into something
like an legal employment contract isn't going to be helpful.

Dave.