lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 8 Oct 2018 16:23:57 -0300
From:   Mauro Carvalho Chehab <mchehab+samsung@...nel.org>
To:     James Bottomley <James.Bottomley@...senPartnership.com>
Cc:     Josh Triplett <josh@...htriplett.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        ksummit-discuss@...ts.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the
 ambiguity about collecting email addresses

Em Mon, 08 Oct 2018 08:30:20 -0700
James Bottomley <James.Bottomley@...senPartnership.com> escreveu:

> On Mon, 2018-10-08 at 08:20 -0700, Josh Triplett wrote:
> > On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote:  
> > > The current code of conduct has an ambiguity in the it considers
> > > publishing private information such as email addresses unacceptable
> > > behaviour.  Since the Linux kernel collects and publishes email
> > > addresses as part of the patch process, add an exception clause for
> > > email addresses ordinarily collected by the project to correct this
> > > ambiguity.  
> > 
> > Upstream has now adopted a FAQ, which addresses this and many other
> > questions. See https://www.contributor-covenant.org/faq .
> > 
> > Might I suggest adding that link to the bottom of the document,
> > instead? (And then, optionally, submitting entries for that FAQ.)  
> 
> We can debate that as part of everything else, but my personal opinion
> would be we should never point to an outside document under someone
> else's control for guidance as to how our community would enforce its
> own code of conduct.

Fully agreed on that. The same argument that we use for GPL 2 only
applies here: we should stick with an specific version of this it, in
a way that we won't be automatically bound to whatever new version
of it would say.

Btw, the term "social contract" is there at the FAQ. At least in
Brazil, as far as I can tell, there's no distinction of a "social
contract" and a "contract". From what I understand, both will have
equal legal value.

Thanks,
Mauro

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ