According to the GNU FSDG (, emphasis are mine):
Toggle quote (2 lines)
> A free system distribution must not steer users towards obtaining any nonfree information for practical use, or encourage them to do so. The system should have no repositories for nonfree software and no specific recipes for installation of particular nonfree programs. *Nor should the distribution refer to third-party repositories that are not committed to only including free software; even if they only have free software today, that may not be true tomorrow.* Programs in the system should not suggest installing nonfree plugins, documentation, and so on.
However, at least on the case of the rust package, in the following example one can see that cargo is also included:
> synopsis: Compiler for the Rust programming language
> description: Rust is a systems programming language that provides memory
> + safety and thread safety guarantees.
In continuation, as can be seen on , the installed cargo has it's default repository enabled.
Furthermore, neither  nor  have expressed commitment to the GNU FSDG.
Here are some suggestions, probably not tested nor researched for viability:
a) make the importer activate a flag of its own in order to use that package. This would render a plain install of the package a version with cargo absent while still having the possibility to do the imports;
b) coordinate with the head of the cargo community (and possibily other free/libre system distributions or free/libre software activism groups) an agreement so that they express commitment to the GNU FSDG on  and , and of course make them setup a bug/issue/task tag/section for GNU FSDG issues. This must be done together with either (a), (d) or (e);
c) coordinate with other free/libre system distributions or free/libre software activism groups a project to provide a common repository that such groups could refer to by default by patching their copy of cargo. This must be done together with either (a), (d) or (e);
d) find a way to provide cargo but without any repository. This would require a way for the importer to specify the repositories at run-time;
e) despite not being desirable by some people, there is also the possibility of removing cargo.
As a side-note, as the original subject stated, I think we should address this issue in other packages too, if any, and also document the decision on the manual or on guideline.