Page MenuHomeVyOS Platform

A review of the use of racist language in VyOS
Closed, ResolvedPublic

Description

Can we please review our codebase for racist language and begin its deprecation? During deprecation, both the racist and anti-racist terms will be supported, but the latter preferred.

Please consider whether this is a worthwhile task for the project. I can put together a patch which would support the deprecation similar to the one[3] I did to change the license of the AllJoyn codebase.

According to [1], work published in academic journals has argued that continuing to use racially-charged terms prolongs racial stereotypes.

From [2], the use of such terms does not merely reflect a racist culture, but also serves to legitimize and perpetuate it.

[1] https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/
[2] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6148600/
[3] https://github.com/alljoyn/extras-automation/blob/master/relicense/bin/do-relicense

Details

Difficulty level
Unknown (require assessment)
Version
1.4
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Config syntax change (migratable)

Event Timeline

cjac created this object in space S1 VyOS Public.

For the record, people of all races are still being held in slavery. Calling it "racist" is an incredibly US-history-centric view.

Anyway, to the point, here's my position on the subject:

  • We will not change any terms that are codified by protocol standards. For example, the term "master" in the VRRP context comes from the RFC (however, there's no master-slave dichotomy there, it's master-backup).
  • There should be a specific task for every place where this kind of terminology exists.

If you find specific instances, please create a task for each one and we can discuss it there.

dmbaturin claimed this task.

I could not find any uses of "slave" in current VyOS versions. If anyone finds any, feel free to start a discussion. VRRP "master" terminology cannot be changed because it's a part of the protocol spec itself, and, as said above, its counterpart is "backup".