ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)
Date: Wed, 19 Sep 2018 16:55:52 -0300	[thread overview]
Message-ID: <20180919165552.0f30bbef@coco.lan> (raw)
In-Reply-To: <1537366581.6816.1.camel@HansenPartnership.com>

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.
> 
> 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.

After re-reading it, I'm pretty sure that, the way it is, publishing
e-mails violate this CoC.

The thing is that, when it uses the commas there:

	"private information, such as a physical or electronic address," 

The commas actually defines what "private information" is. Even if
this would be changed by "foo information", what we have here is actually two
English sentences that were merged together:

First sentence:
	"Private information, such as a physical or electronic address."

Second sentence:
	"Publishing others’ private information without explicit permission"

See, replace it by foo at the original text:
	"Publishing others’ *foo* information, such as a physical 
	 or electronic address, without explicit permission"

You'll see that "*foo* information" becomes defined.


Thanks,
Mauro

  parent reply	other threads:[~2018-09-19 19:55 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-18  5:55 Dave Airlie
2018-09-18 13:43 ` Steven Rostedt
2018-09-18 14:34   ` Daniel Vetter
2018-09-18 14:58     ` Geert Uytterhoeven
2018-09-20  9:12   ` Rafael J. Wysocki
2018-09-20  9:53     ` Daniel Vetter
2018-09-20 10:05       ` Daniel Vetter
2018-09-20 15:57       ` Mark Brown
2018-09-18 14:02 ` James Bottomley
2018-09-18 14:41   ` Daniel Vetter
2018-09-18 19:29   ` Mauro Carvalho Chehab
2018-09-18 19:36     ` Josh Triplett
2018-09-18 19:52       ` Mauro Carvalho Chehab
2018-09-18 20:52         ` Takashi Iwai
2018-09-18 21:15         ` Josh Triplett
2018-09-18 23:06       ` Steven Rostedt
2018-09-18 23:38         ` Laurent Pinchart
2018-09-18 19:58     ` Arnaldo Carvalho de Melo
2018-09-19 11:28     ` James Bottomley
2018-09-19 11:37       ` Mauro Carvalho Chehab
2018-09-19 12:03         ` Mauro Carvalho Chehab
2018-09-19 14:16           ` James Bottomley
2018-09-19 16:06             ` Mauro Carvalho Chehab
2018-09-19 19:55             ` Mauro Carvalho Chehab [this message]
2018-09-19 20:10               ` Luck, Tony
2018-09-19 23:28                 ` Mauro Carvalho Chehab
2018-09-19 23:45                   ` Tim.Bird
2018-09-19 20:23               ` Dave Airlie
2018-09-20  0:01                 ` Mauro Carvalho Chehab
2018-09-20  0:22                   ` Tim.Bird
2018-09-20  6:33                     ` Jani Nikula
2018-09-20  7:01                       ` Josh Triplett
2018-09-20  7:11                         ` Daniel Vetter
2018-09-20  7:04                       ` David Woodhouse
2018-09-24 13:53                         ` Mel Gorman
2018-09-25  5:45                           ` Leon Romanovsky
2018-09-20 10:19                       ` Laurent Pinchart
2018-09-20 10:23                       ` Mauro Carvalho Chehab
2018-09-20 12:31                         ` Jani Nikula
2018-09-20 13:04                           ` Mauro Carvalho Chehab
2018-09-20 13:49                         ` Tim.Bird
2018-09-20 13:55                           ` Laurent Pinchart
2018-09-20 19:14                             ` Tim.Bird
2018-09-20 19:55                               ` Laurent Pinchart
2018-09-20 20:11                                 ` Dmitry Torokhov
2018-09-20 20:14                                 ` Jonathan Corbet
2018-09-20 20:52                           ` Mauro Carvalho Chehab
2018-09-20  2:44                   ` Joe Perches
2018-09-20 11:11                     ` Laurent Pinchart
2018-09-20 13:35                       ` Joe Perches
2018-09-20  3:38                   ` Stephen Hemminger
2018-09-20 12:28 ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180919165552.0f30bbef@coco.lan \
    --to=mchehab+samsung@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox