linux-kernel - Re: [Ksummit-discuss] [PATCH] code-of-conduct: Remove explicit list of discrimination factors

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 10:55:50 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Josh Triplett <josh@...htriplett.org>
Cc:     ksummit-discuss@...ts.linuxfoundation.org,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-discuss] [PATCH] code-of-conduct: Remove explicit list
 of discrimination factors

Hi Josh,

On Sun, Oct 7, 2018 at 1:35 PM Josh Triplett <josh@...htriplett.org> wrote:
> On Sun, Oct 07, 2018 at 10:51:02AM +0200, Geert Uytterhoeven wrote:
> > Providing an explicit list of discrimination factors may give the false
> > impression that discrimination based on other unlisted factors would be
> > allowed.
> >
> > Avoid any ambiguity by removing the list, to ensure "a harassment-free
> > experience for everyone", period.
>
> I would suggest reading the commit message that added this in the first
> place. "Explicit guidelines have demonstrated success in other projects
> and other areas of the kernel." See also various comparisons of codes of

The first paragraph of the commit message (the "why" part) is exactly the
part we've been waiting for a clarification since the inception of the
commit...

> conduct, which make the same point. The point of this list is precisely
> to serve as one such explicit guideline; removing it would rather defeat
> the purpose.

Then (at least) the list should be marked containing examples, cfr. the other
examples in the document.

> In any case, this is not the appropriate place for such patches, any
> more than it's the place for patches to the GPL.

There are precedents:

Until recent, the file named "COPYING" (which you referred to in another
email related to patching the CoC), was a verbatim copy of the GPL, with
clarifications added at the top.

Documentation/process/code-of-conduct.rst is already a slightly modified
version of the original.

Now, if amending the CoC locally is not an option, I'm afraid a plain revert
is the only option, like for any other commit that breaks the userspace ABI
(Linux kernel developers are also users ;-), until the raised issues have
been resolved upstream.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds