blacklist/whitelist、master/slave という単語は相応しくないという意見に OSS がどの様に対応すべきかを自身で考える為の情報集めです。見つけ次第、逐次更新していきます。

僕(mattn) 自身は black lives matter に同意をしています。blacklist/whitelist、master/slave という単語を廃止する事が、歴史的背景を持たない文化圏では特定の意味を持たなかった為、個人的には若干思う所はありますが、廃止自身に反対するつもりはありません。

昔から、主副を表す物には master/slave という単語が使われてきました。ハードディスクの IDE、仮想端末(pty)、色々あります。またネットワークの IP フィルタリングに関しては blacklist/whitelist と表記した物が今でも沢山あります。

我々日本人が意識せずに使っていた blacklist/whitelist、master/slave という単語が、人々にどの様に影響しうるのか、今後 OSS としてどの様に関わっていけば良いかを理解する上で、自分なりの情報集めをしたいと思っています。

この Gist で個人的な偏りを出すつもりはありません。ただ、1つだけ言っておきたいです。これらの単語が過去に特定の文化圏で差別的な意味を持っていたのを知らずに使った他の文化圏の人達や、その前提知識を得ずに議論に参加しょうとする人達に対して無知だ無関心だ素人だと攻撃する様な事は建設的ではないと思っています。決してそれらを招く為の情報集めではない事をご理解下さい。

https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%E3%82%B9%E3%83%AC%E3%83%BC%E3%83%96

マスター（主人）とスレーブ（奴隷）という用語はしばしば論争の的となることがある。

2003年11月、ロサンゼルス郡は電子メールで出入り業者に対してこれらの用語を使った製品を納入しないよう要求した[5][6][7]。これに対してIT業界ではばかげた主張だとして取り合わない動きが大勢を占めた[8]。マスタースレーブという用語はデバイス内部で起きていることを正確に表した技術用語であり、かつて存在した奴隷制度とは何の関係もないというのがその理由であった（ポリティカル・コレクトネスも参照）。

一方で、こうした論争を避けるため、データベースの分野ではマスタースレーブの代替語として「プライマリー」や「レプリカ」といった語句を採用するケースもある。2018年には、プログラミング言語Pythonが論争の末、マスタースレーブを「ペアレント」や「ワーカー」「ヘルパー」といった語句に置き換えている。

• leader/follower
• builder/worker
• leader/replica
• primary/replica

https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1

https://en.wikipedia.org/wiki/Blacklisting

A blacklist can list people to be discriminated against and cannot be employed. As a verb, blacklist can mean to put an individual or entity on such a list.

https://en.wikipedia.org/wiki/Blacklist_(employment)

各国や地域で行われた雇用拒否のリスト化

https://en.wikipedia.org/wiki/Hollywood_blacklist

初めてブラックリストに登録されたとされる「ハリウッド・テン」というグループについて。エンタテインメント業界で流通したレッドチャネルと呼ばれる雇用拒否リストがあった。

• blocklist/allowlist
• blocklist/safelist
• blocklist/passlist
• denylist/allowlist
• stoplist/golist
• redlist/greenlist

https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.2.1

django/django#2692

The docs and some tests contain references to a master/slave db configuration. While this terminology has been used for a long time, those terms may carry racially charged meanings to users. This patch replaces all occurrences of master and slave with 'leader' and 'follower'

https://issues.apache.org/jira/browse/COUCHDB-2248

Inspired by the comments on this PR:

django/django#2692

Summary is: master and slave are racially charged terms, and it would be good to avoid them. Django have gone for primary and replica. But we also have to deal with what we now call multi-master setups. I propose "peer to peer" as a replacement, or just "peer" if you're describing one node.

As far as I can tell, the primary work here is the docs. The wiki and any supporting material can be updated after.

https://www.drupal.org/node/2275877

Replace master/slave with primary/secondary. The reasons include:

1. This change has also already been evaluated and made by the Django community,
2. The word "slave" has negative connotations (although this might or might not be relevant in the naming of a technical term) including multi-century history of slavery to benefit European colonial powers, prison laborers today forced to work in conditions at times resembling that slavery, young girls sold into sex slavery in many parts of the world today
3. Somehow even this has a sexist angle: in the Django issue a devops person (presumedly female) complains about others making dominatrix jokes at her because of master/slave terminology

https://github.com/antirez/redis/issues/3185

Inspired by django/django/pull/2692, Redis should replace its "master" and "slave" terminology.

The summary is: master and slave have racial meanings (especially in North America, but also more generally) and it would be good to avoid them. Django went for primary and replica. I am not sure what makes the most sense for Redis.

Worth noting, CouchDB made a similar change. As did Drupal.

rails/rails#33677

Per https://twitter.com/dhh/status/1032050325513940992, I'd like for Rails to set a good example and tone by using better terminology when we can. An easy fix would be to replace our use of whitelist with allowlist and blacklist with denylist.

We can even just use them as verbs directly, as we do with the former terms. So something is allowlisted or denylisted.

I took a quick look and it seems like this change is mostly about docs. We only have one piece of the code that I could find on a search that uses the term whitelist with enforce_raw_sql_whitelist. Need to consider whether we need an alias and a deprecation for that.

https://bugs.python.org/issue34605

For diversity reasons, it would be nice to try to avoid "master" and "slave" terminology which can be associated to slavery.

For more context, see:

• https://github.com/antirez/redis/issues/3185
• https://www.drupal.org/node/2275877
• https://issues.apache.org/jira/browse/COUCHDB-2248
• django/django#2692

https://developers.srad.jp/story/18/09/14/0935201/

https://bugs.chromium.org/p/chromium/issues/detail?id=981129

This will be the parent issue for all the potential words we find in the codebase.

The effort here would be just putting up small CLs grouped by area/directory (for reviewer's sake). Hopefully uncontroversial to land quickly.

For anything with potential non-trivial compact impact (command line parameter names, enterprise policy keys, etc), the suggestion would be doing them in one-offs (or very small related groups) so we can ask experts on a case-by-case basis whether some mitigation is necessary.

https://go-review.googlesource.com/c/go/+/236857/

all: replace usages of whitelist/blacklist and master/slave

There's been plenty of discussion on the usage of these terms in tech. I'm not trying to have yet another debate. It's clear that there are people who are hurt by them and who are made to feel unwelcome by their use due not to technical reasons but to their historical and social context. That's simply enough reason to replace them.

Anyway, allowlist and blocklist are more self-explanatory than whitelist and blacklist, so this change has negative cost.

Didn't change vendored, bundled, and minified files. Nearly all changes are tests or comments, with a couple renames in cmd/link and cmd/oldlink which are extremely safe. This should be fine to land during the freeze without even asking for an exception.

https://news.ycombinator.com/item?id=23445987

https://www.reddit.com/r/golang/comments/gy9ylr/go_has_removed_all_uses_of_blacklistwhitelist_and/