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つだけ言っておきたいです。これらの単語が過去に特定の文化圏で差別的な意味を持っていたのを知らずに使った他の文化圏の人達や、その前提知識を得ずに議論に参加しょうとする人達に対して無知だ無関心だ素人だと攻撃する様な事は建設的ではないと思っています。決してそれらを招く為の情報集めではない事をご理解下さい。
マスター（主人）とスレーブ（奴隷）という用語はしばしば論争の的となることがある。
2003年11月、ロサンゼルス郡は電子メールで出入り業者に対してこれらの用語を使った製品を納入しないよう要求した[5][6][7]。これに対してIT業界ではばかげた主張だとして取り合わない動きが大勢を占めた[8]。マスタースレーブという用語はデバイス内部で起きていることを正確に表した技術用語であり、かつて存在した奴隷制度とは何の関係もないというのがその理由であった（ポリティカル・コレクトネスも参照）。
一方で、こうした論争を避けるため、データベースの分野ではマスタースレーブの代替語として「プライマリー」や「レプリカ」といった語句を採用するケースもある。2018年には、プログラミング言語Pythonが論争の末、マスタースレーブを「ペアレント」や「ワーカー」「ヘルパー」といった語句に置き換えている。
https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1
master/slave の意味は不適切で難解である。それに加えて master と slave の比喩は技術的にも歴史的にも不正確である。例えば、DNSでは「スレーブ」はゾーン転送を拒否することもできる。
- leader/follower
- builder/worker
- leader/replica
- primary/replica
- primary/second (DNS)
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
初めてブラックリストに登録されたとされる「ハリウッド・テン」というグループについて。エンタテインメント業界で流通したレッドチャネルと呼ばれる雇用拒否リストがあった。
http://www.kenkyusha.co.jp/uploads/lingua/prt/18/gendai1806.html
言ってはいけない！ 現代アメリカのタブーな英語 3 | 研究社 WEB マガジン Lingua リンガ
- 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
Google は代替を用意せず、文脈から正しい単語を選ぶ事を推奨している。
https://developers.google.com/style/word-list#blacklist
https://security.srad.jp/story/20/05/04/067221/
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:
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:
- This change has also already been evaluated and made by the Django community,
- 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
- 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
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.
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.
ほか Ruby 関連だとここに多くまとまっている。
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:
- redis/redis#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=842296
Chromium's source code uses "blacklist" and "whitelist" a lot. Ideally we wouldn't do that since it unnecessarily reinforces the notion that black==bad and white==good. https://mcwriting11.blogspot.com/2014/06/that-word-black-by-langston-hughes.html illustrates this problem in a lighthearted, if somewhat pointed way.
These terms can usually be replaced by "blocklist" and "allowlist" without changing their meanings, but particular instances may need other replacements. (Defining an exhaustive set of replacements is not within the scope of this bug - let's focus on improving instead of perfection.)
Places that are visible to users affect more people and so are higher priority than instances internal to the code, but both should be fixed eventually. New code should definitely not use the terms.
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://chromium-review.googlesource.com/c/chromium/src/+/2234793
Rename classes in components/blacklist to use more inclusive names.
This is the first of 2 changes to rename components/blacklist to components/blocklist. This contains all the class/method/member/variable renaming. There should be no functional differences here. This patch will be followed by another patch that renames the directory/files and updates the necessary build system rules. The vast majority of the changes here are simply replacing an 'a' with an 'o'.
- Replaced blacklist references with blocklist in components/blacklist
- Replaced whitelist references with allowlist in components/blacklist
- Updated all code that depends on components/blacklist to use new names and updated the names of any callers that may have been influenced by the original names.
- Filed bugs and left TODOs for code that interacts with backend services that may depend on the old name.
- Replaced some empty method bodies with '= default;' and added default member assignments to make ClangTidy happy. These should not cause any behavior changes.
https://go-review.googlesource.com/c/go/+/236857/
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.
master/slave terminology is offensive and should be replaced with something more appropriate, such as primary/replica.
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/
master/slave terminology is offensive and should be replaced with something more appropriate, such as primary/replica. (2020-06-08)
Some technology vendors have already done so. See wikipedia page here: https://en.wikipedia.org/wiki/Master/slave_(technology)
How to repeat: View any documentation page about replication in general, for example: https://dev.mysql.com/doc/refman/8.0/en/replication-options-slave.html
Or, view documentation for command line operations, ie. 'start slave', etc: https://dev.mysql.com/doc/refman/5.7/en/replication-administration-pausing.html#:~:text=mysql%3E%20START%20SLAVE%3B,a%20backup%20or%20other%20task
Suggested fix: I would suggest starting with changing documentation such that 'master' is replaced with 'primary' and 'slave' is replaced with 'replica'.
sql commands and configuration settings should be changed accordingly. ie. 'start slave' should be replaced with 'start replica', etc. existing variables, commands, etc can continue to be honored for backward compatibility to facilitate migration to the new terminology over time.
So I don't mind master/slave terminology, but if you're going to fix it, at least end up with something others chose too. See django which ended up with Primary/Replica (after first adopting Leader/Follower in django/django#2692) in django/django#2694 (which was just closed, but still changed in django/django@beec056 )
The only thing I personally have against Leader/Follower is that it is a bit odd as a german (and seems I'm not alone in that feeling). Though I wouldn't mind that had it not already been changed from master/slave anyway. Just want it changed "properly" if it gets changed at all. It also seems to be used in literature already from what I was told.
The change was inspired by https://go-review.googlesource.com/c/go/+/236857/ and replaces all occurrences of whitelist/blacklist with allowlist/blocklist.
Most of the changes are internal only with two exceptions for which this patch requires RFC:
- opcache.blacklist_filename INI directive
- opcache_get_configuration()["blacklist"] key in returned array value
Above INI directive and value returned by opcache_get_configuration() will be marked as deprecated and superseded by (respectively):
- opcache.blocklist_filename INI directive
- opcache_get_configuration()["blocklist"] key in returned array value
Old INI directive and value returned by opcache_get_configuration() will remain the same for BC purposes till next minor version for removal.
→ issue はオーバーヒートし過ぎて lock されている。
Our team would prefer to change our default branch name away from "master", since "master" is a generally problematic term due to its association with slavery in some contexts. (We are aware that "master" as used in git does not necessarily have that connotation, but we do not want to nitpick about etymology here.)
We are considering one of these names for the default branch name: trunk, development, or main.
- check our scripts/automation for whether master is hardcoded anywhere
- run the branch migration script (below)
- move branch protections from master to new branch
- modify docs to reference the new branch instead of master
- delete master branch
- instruct devs to update their local clones:
git fetch origin --prune
git checkout trunk
git remote set-head origin trunk
git branch -D master
→ デフォルトブランチが trunk に変更された
A thread on the Git mailing list made the cautious attempt at bringing this issue to attention: enough names in Git are non-inclusive to cause unintended consequences. Most prominently, the default name of the default branch.
I create this ticket to track the progress of fixing this.
While I want to fix it rather sooner than later, I want to abide by the saying "If you want to go fast, go alone, if you want to go far, go together". I want to go far on this.
Any constructive comments are welcome!
Remove some offensive/archaic terminology from OpenSSL.
I would like us to use the term "blocklist" instead of "blacklist". I've updated all the internal uses I could find. There are no BC breaks.
We still use some "blacklist" when we relate to PHPUnit\Util\Blacklist
ありがとうございます。著名な物をいくらかピックアップします。