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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 8 Oct 2018 12:57:51 -0700
From:   Josh Triplett <josh@...htriplett.org>
To:     Mauro Carvalho Chehab <mchehab+samsung@...nel.org>
Cc:     James Bottomley <James.Bottomley@...senPartnership.com>,
        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

On Mon, Oct 08, 2018 at 04:23:57PM -0300, Mauro Carvalho Chehab wrote:
> 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.

Linking to a FAQ with useful clarifications in it doesn't make those
"binding". This is *not* a legal agreement.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ