I totally agree with your proposal. (and all the points you made, leading to it)
> As mentioning these rules isn't too much of a fuss, I'd even say that
> bringing them up just to avoid issues in the future is even worth it, as
> notifying the developers and maintainers that their package has been
> added to the archive makes sense with or without these rules.
What has been proposed is not mentioning the rules, but acquiring an
explicit agreement to them in advance, to be noted down in a file, for
each and every package that we add.
I quote what I wrote in private correspondence to Richard and others on
6 January 2021:
The goal is to avoid shipping non-compliant packages. I believe the
technical aspects (while important) are less important than the ethical
considerations here.
Upon further reflection, I don't think an agreement will help much.
- Maintainers change. We only make the agreement with the current
maintainers.
- Any package that will at some point not meet our criteria is likely to
already not do so. Those that already meet them are exceedingly
likely to continue to do so.
- Package developers that don't care enough to meet our criteria will
not care enough to tell us (with or without an agreement).
- Package developers that do care might break our criteria anyways, due
to being unaware of the issues involved.
- We might check a package yet miss an important issue. The same could
hold true for package maintainer themselves. We are only human.
- In reality we will therefore almost always detect any issues the usual
way: someone makes us aware of them.
- We can easily and quickly deal with any violations once we know about
them (e.g. by deleting or forking the package).
There is of course nothing wrong with letting package maintainers know
that we are shipping their package. In fact, it can only help.
But to implement a strict requirement that we must always solicit a
written agreement with the developers of a package before adding it
seems like a very large amount of work for at best only a very minor
benefit. In practice, I don't think it will be of much use.
So I think we should indeed check packages before adding them. This may
or may not include communicating with package developers in advance.
This is the guideline I would propose.