From a conversation on the gnu-linux-libre mailing list:

http://lists.nongnu.org/archive/html/gnu-linux-libre/2016-04/msg00070.html
http://lists.nongnu.org/archive/html/gnu-linux-libre/2016-04/msg00116.html

A lot of programming languages have own packages managers: npm (CSS/JavaScript), Bower (Web), pip (Python), RubyGems (Ruby), CPAN (Perl), Cargo (Rust), ..."

These things would qualify as "repositories" under the Free System Distribution Guidelines. And they do not limit themselves to only including free software. Until/unless Stallman's ideas of either convincing them to only include free software or develop a free replacement come along I propose disabling such things in Parabola.

known TPPMs:

---
|_.TPPM |_.status |_.converter |_.description | UPDATE 2022-04:
| apm | | | Atom package manager |
| asp | blacklisted | n/a | ArchLinux build source file management tool |
| apper | | | An application and package manager using PackageKit |
| bower | | | A package manager for the web |
| cabal | libre | cblrepo, arch-hs | haskell package manager |
| cargo | not libre | cargo-pkgbuild | rust package manager |
| cpan | not libre | | PERL package manager |
| dub | | | Developer package manager for D programming language |
| fusesoc | | | Package manager and build abstraction tool for FPGA/ASIC development |
| helm | | | The Kubernetes Package Manager |
| nimble | | | Package manager for the Nim programming language |
| npm | | nodejs-npm2arch | A package manager for javascript |
| nuget | | | Package manager for .NET. |
| ocaml-findlib | | | OCaml package manager |
| opam | | | OCaml package manager |
| pecl | not libre | | PHP package manager |
| pip | blacklisted | pipman-git, pip2arch-git, python-pypi2pkgbuild | python package manager |
| rpm-tools | | | RPM Package Manager - RPM.org fork, used in major RPM distros |
| rubygems | blacklisted | gem2arch, pacgem | ruby package manager |
| shards | | | The package manager for the Crystal language |
| sn0int | | | Semi-automatic OSINT framework and package manager |
| pcr/guix | | | A purely functional package manager for the GNU system |
| pcr/nodejs-bower | | | A package manager for the web |

NOTES:
* "not libre" indicates that the repo has no libre licensing policy

summary of the proposed options:
|_.proposal |_.intrusiveness |_.workload |_.effectiveness |_.FSDG-fitness |
| do nothing - ignore it like all other distros do | none | none | none | none |
| remove all TPPMs from the repos - do nothing else | none | negligible | total | full |
| add a pacman hook to warn during install | none | negligible | none | dubious |
| move to a new 'dubious/dangerous' pacman repo | none | medium | partial | dubious |
| disable default TPPM repo, make user-configurable | minimal | medium | total | full |
| disable the search feature | minimal | medium | total | full |
| filter the search feature | minimal | medium | dubious | dubious |
| remove from the repos, accept packaging requests | none | maximal | total | full |
| maintain libre repos as a GNU project | none | maximal | total | full |
| convince the TPPM repos of licensing requirements | none | negligible | dubious | dubious |

NOTES:
* "intrusiveness: minimal" because those proposals entail patching the clients
* "workload: medium" because those proposals entail maintaining blacklist replacements for each TPPM, even if unmodified
* "workload: maximal" because those proposals entail the perpetual burden of package curation
* "effectiveness: total" (even if non-free packages are still installable) because those proposals resolve the conflict with the FSDG - namely: they would no longer recommend/suggest/steer-toward non-free
* "effectiveness: partial" because TPPMs would be inaccessible by default - the user would need to re-configure pacman, in order to access them
* "effectiveness: dubious" because the mechanism would rely entirely on the honor and licensing knowledge of the third-party packager
* "filter the search feature" may not be possible for some of these - it is not yet know which, if any, expose licensing information via API/metadata
* "maintain libre repos as a GNU project" is obviously the ideal option; but it is unlikely to happen
* IMHO, "disable default TPPM repo, make user-configurable" has the best chance of being generally acceptable to all (it is exactly my plan for 'octopi')
* although i would prefer "remove from the repos, accept packaging requests" for the language-specific TPPMs