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-next>] [day] [month] [year] [list]
Message-ID: <e223b198-af0e-123d-49bf-fad7e0f9126e@cantab.net>
Date:   Wed, 19 Sep 2018 07:00:26 +0100
From:   Edward Cree <ec429@...tab.net>
To:     linux-kernel@...r.kernel.org
Subject: Re: Code of Conduct: Let's revamp it.

The new Code of Conduct makes me feel threatened and uncomfortable.

No, really.  As a person with (diagnosed) Asperger's, I'm a member of,
  objectively, a marginalised minority.  Effectively (i.e. this is a massive
  oversimplification), I was born without the hard-wired circuitry for 
social
  interactions that is normally a part of the human brain; consequently 
I have
  to run a slow and inaccurate software simulation when interacting with
  'normal' people.

In nearly all the communities I participate in, this is a constantly 
limiting
  factor for me.  But there is one world that is blessedly free of such 
things:
  the world of open-source software.  It is one of the last places where my
  particular neurodiversity does _not_ mark me out as Other, does _not_ 
force
  me to carefully watch what I say and present a falsely constructed 
façade in
  place of my real identity.  For here, we care not for 'feelings'; 
either the
  code is good or it is bad, and in the latter case we say so directly and
  bluntly.  Not only does this mean that I don't have to guard my tongue 
when
  critiquing someone else's patch, far more importantly it means I can
  understand what's being said when _my_ patches are criticised.  
(Almost all
  of my best ideas and patches have been born out of someone telling me I'm
  wrong.)

The Linux kernel community is a place without office politics, without 
subtle
  subtexts, without primate dominance dynamics.  A place where criticism 
_can_
  be gracefully accepted _without_ having to worry that admitting to being
  wrong will lower one's status.  A place where I, and people like me, 
can feel
  at home, and maybe even create something of value.

And the Contributor Covenant looks very much like the camel's nose of an
  attempt to take that place, that community, away from me.  To replace 
it with
  an Orwellian nightmare where I must forever second-guess what is safe 
to say.
  (First they came for "master/slave replication", and I did not speak up
  because I was not a DBA.)

I cannot speak for my employer (hence why I am posting this from my personal
  address), but to the extent that my rôle as a contributor to the 
networking
  subsystem, and as co-maintainer of the sfc driver, gives me any 
standing in a
  _personal_ capacity, I absolutely cannot sign up to this 'Pledge' nor 
accept
  the 'Responsibilities' to police the speech of others that it makes a 
duty of
  maintainership, and I urge the project leadership to revert its adoption.

Some elements of the Code are unobjectionable; sexual advances, for 
instance,
  have no place on the lkml (though they may at, say, a conference, and not
  everyone can reliably predict whether they are unwelcome), and the 
ability of
  kernel developers to accept constructive criticism is one of the strengths
  that has made Linux what it is.  But far too many of its provisions 
rely on
  ill-defined terms, and thus give those charged with interpreting those 
terms
  the power to destroy livelihoods.  By placing a corporate body (the LF) in
  the position of arbiter, an avenue is opened for commercial pressure to be
  applied; and the legalistic phrasing of the Code practically invites 
rules-
  lawyering whereby the most abusive may twist it into a weapon to further
  their abuse.

If the Code were reduced to something more like the old Code of Conflict,
  reminding people to 'be liberal in what they accept and conservative 
in what
  they emit', and clarifying that patch submissions should be judged by the
  _code_ and not by any characteristics or beliefs of the submitter (I don't
  think the enumerated list of protected classes is helpful, as a legalistic
  abuser can always slip into a crack between them), I think the sting 
would be
  drawn.  Probably the CoConflict would make a better base from which to 
draft
  such a document.

(A note for the irony-challenged: where I use Progressive terms-of-art, such
  as 'marginalised', 'Other' and 'identity', in the above, I am 
endeavouring to
  show that this alleged push for 'inclusiveness' fails on its own 
terms; I am
  _not_ accepting the theory behind those terms nor suggesting that, in
  reality, the kernel community owes me any special treatment on account 
of my
  'diversity'.)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ