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

[Mauro Carvalho Chehab <mchehab+samsung@kernel.org>]

Em Wed, 19 Sep 2018 10:16:21 -0400
James Bottomley <James.Bottomley@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@kernel.org> escreveu:
> >   
> > > Em Wed, 19 Sep 2018 07:28:02 -0400
> > > James Bottomley <James.Bottomley@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@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 ...
> 
> > > IMHO very badly written Contract of Adhesion - as it creates a lot
> > > of new duties to maintainers and establishes punishment measures if
> > > the terms of such contract are violated).  
> 
> I can't disagree with that either.  Unfortunately, most codes of
> conduct are definitely badly written from a legal point of view because
> they're usually constructed by non-lawyers without any legal input. 
> I'm not very keen on this one because, as I said somewhere upthread, it
> doesn't cover a lot of our problem areas.  However, it's not the worst
> I've seen.

Well, we don't need to stick with it. If it has solvable problems,
they should be fixed. Otherwise, better to revert this patch and keep
using the old CoC, where the major ideas are already covered, but with
a language that won't cause too much legal problems.

Every time I read the new CoC I become more convinced that it is
utter crap (can I say it with this new Coc?). The email address
issue is just the tip of the iceberg.

> To your specific concern, run this thought experiment with me: 
> Supposing instead of  "Publishing others’ private information, such as
> a physical or electronic address, without explicit permission", it had
> said "publishing others non-public information ...." (sorry had to
> correct the misplaced apostrophe as well).  I think you can agree with
> me that an email address already sent to the list cannot be non-public, 
> since it's already been disclosed by the sender in a public forum.  So
> with that form of wording it would cover the tags use case, right?
> 
> Now let me point out that from a US legal point of view, "non-public"
> encompasses a broader range of things than "private", so anything
> that's private is also non-public but not everything that's non-public
> is also private.  Thus the original wording is actually a narrower duty
> which is a strict subset of the form of wording I asked you to
> consider.  Thus, I still don't think our use of tags resulting from
> public email exchanges can be in any way construed as a violation of
> the privacy duty imposed by the CoC.

I understand your point, but the concept of "public/non-public",
"private", "personal information", etc actually depends on how it
is defined. It should either be clearly stated or the document, 
or whatever the legislation says would be valid (or judge's mind).

I suspect that, in US, the concept of non-public and private can
even vary from state to state, or even from district to district,
as local legislators may have approved laws defining it for
electronic communications. It is even worse if we consider other
Countries with a different ruleset.

That's why, on most legal contracts there are clauses that specify
what it actually cover, instead of too broader terms like the ones
used on this CoC.

For example LF web site privacy policy - with very likely it was
written by some lawyers[1] states that e-mail addresses are 
Personal information.

[1] https://www.linuxfoundation.org/privacy/

At the "Sharing of Personal Information" chapter, it then defines
a concept of "Publicly Available Information", saying that those
can be disclosed.

-

What I'm trying to say that, while I'm fine with the idea of having
a CoC, it should either be prepared by someone that understands
what legal impacts it will cause (e. g. some lawyers that understands
open source), or it shouldn't be adding stuff that will just cause
more evil than good.

See, the points that this new CoC tries to address (on a very bad
way) were already covered by the past CoC:

-Code of Conflict
-----------------
-
-The Linux kernel development effort is a very personal process compared
-to "traditional" ways of developing software.  Your code and ideas
-behind it will be carefully reviewed, often resulting in critique and
-criticism.  The review will almost always require improvements to the
-code before it can be included in the kernel.  Know that this happens
-because everyone involved wants to see the best possible solution for
-the overall success of Linux.  This development process has been proven
-to create the most robust operating system kernel ever, and we do not
-want to do anything to cause the quality of submission and eventual
-result to ever decrease.
-
-If however, anyone feels personally abused, threatened, or otherwise
-uncomfortable due to this process, that is not acceptable.  If so,
-please contact the Linux Foundation's Technical Advisory Board at
-<tab@lists.linux-foundation.org>, or the individual members, and they
-will work to resolve the issue to the best of their ability.  For more
-information on who is on the Technical Advisory Board and what their
-role is, please see:
-
-	- http://www.linuxfoundation.org/projects/linux/tab
-
-As a reviewer of code, please strive to keep things civil and focused on
-the technical issues involved.  We are all humans, and frustrations can
-be high on both sides of the process.  Try to keep in mind the immortal
-words of Bill and Ted, "Be excellent to each other."

The old one doesn't prevent using Reviewed-by/Acked-by/... tags.

It also doesn't turn maintainers into baby sitters, making them
accountable for any bad behavior on every place where a member
of the community misbehaves.

Thanks,
Mauro