From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6F5F2BAC for ; Wed, 19 Sep 2018 12:03:37 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 50F177D2 for ; Wed, 19 Sep 2018 12:03:36 +0000 (UTC) Date: Wed, 19 Sep 2018 09:03:32 -0300 From: Mauro Carvalho Chehab To: James Bottomley Message-ID: <20180919090332.723c1b75@coco.lan> In-Reply-To: <20180919083749.49268562@coco.lan> References: <1537279328.3424.6.camel@HansenPartnership.com> <20180918162948.769dda1d@coco.lan> <1537356482.4640.7.camel@HansenPartnership.com> <20180919083749.49268562@coco.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ksummit Subject: Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Em Wed, 19 Sep 2018 08:37:49 -0300 Mauro Carvalho Chehab escreveu: > Em Wed, 19 Sep 2018 07:28:02 -0400 > James Bottomley escreveu: >=20 > > On Tue, 2018-09-18 at 16:29 -0300, Mauro Carvalho Chehab wrote: > > > Em Tue, 18 Sep 2018 10:02:08 -0400 > > > James Bottomley escreveu: > > > =20 > > > > > 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. > > > > > =20 > > > >=20 > > > > 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. =20 > > >=20 > > > After carefully reading it a couple of times, I think it has a huge > > > impact. > > >=20 > > > The more immediate impact is with regards to this wording: > > >=20 > > > "Examples of unacceptable behavior by participants include: > > > ... > > > * Publishing others=E2=80=99 private information, such as a physical= or > > > electronic > > > =C2=A0=C2=A0address, without explicit permission" > > >=20 > > > 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. > > >=20 > > > The DCO 1.1 has an explicit clause that would allow to publish the > > > email address from the SOB's, together to its redistribution: > > >=20 > > > "=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(d) I understand and agree= that this project and the > > > contribution > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0are public and that a record of the contribution > > > (including all > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0personal information I submit with it, including my sign- > > > off) is > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0maintained indefinitely and may be redistributed > > > consistent with > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0this project or the open source license(s) involved." > > >=20 > > > But that doesn't cover the other tags. =20 > >=20 > > 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. >=20 > I see your point. Yes, that places the SOB signer's as^W backs=20 > responsible for such thing. >=20 > > 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.=C2=A0=C2=A0I think the electronic mail example in t= he 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. >=20 > 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. > 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). >=20 > Thanks, > Mauro Thanks, Mauro