Yes, I mean entirely an ethical obligation.
At a fundamental level, the consensus of registry maintainers is that the General registry is a “community resource”. There is no list of obligations that this entails, just common sense and the general community code of conduct, which boils down to “don’t be an asshole”.
At the most immediate level, the General registry being a community resource means that new registrations are subject to community review (anyone can flag concerns about a package during the mandatory three-day waiting period). As a consequence of the naming guidelines, “descriptive” package names are the norm. This makes good package names scarce: there can only be one authoritative package for a particular domain (by name), and that creates the continuous concerns about appropriately named packages, as well as expectations for the continuing maintenance of those packages. A package like DifferentialEquations advertises an extremely broad scope and has the corresponding expectations (which SciML can meet) while the equally descriptive but much more narrow GroundHeatExchanger (random recently submitted package) would receive much less scrutiny.
Post-registration, the responsibilities of a maintainer a more nebulous, and there really isn’t much (if any) of an enforcement mechanism. So, whatever common-sense ethical obligations you can think of. Basically: maintainers should maintain their registered packages in good faith and to the best of their abilities. What it means to me is that I expect maintainers to accept reasonable contributions that are within the scope of the package (the more general the package name, the more important), and keep up with basic maintenance to make sure the package keeps functioning. If a maintainer can’t or doesn’t want to keep working on a package, they have an obligation to pass the package to a new maintainer, if and when someone else wants to step in.
The AI in the “version 1” of your post was spot on when it said “commitment to maintain”, in addition to the expectations and requirements laid out in the General registry README.
When maintainers just disappear and package thus become abandoned, registry maintainers can and do step in to assign the package to a new maintainer, by switching the package URL to a fork (which we’ll typically insist will have to be owned by an organization, not an individual account). This is a last resort, and will never happen over the objection of a maintainer. If at all possible, we try to have the existing maintainer facilitate the handover to a new maintainer.
Deleting a registered package is not possible, and deliberately deleting the underlying repo feels to me like a violation of ethical responsibilities (but maybe that’s just me). At a technical level, the registry is robust against this sort of deletion: the package servers cache all versions of all registered packages. Indeed, this robustness and reproducibility guarantee is what distinguishes the General registry from other registries. What should happen in such a case, in the long term, would have to be figured out by consensus of the registry maintainers. I could see a fork being allowed to register. Under normal circumstances, the registration of forks receives a lot of scrutiny, and generally will not happen without the consent of the forked package maintainer.
As a most extreme hypothetical ethical violation, if a maintainer started pushing malware through their package, I could see the registry maintainers stepping in to lock them out of the registered package. So far, this has never happened. In general, any issue with registered packages will be decided on a case-by-case basis, and with a light touch: we want package maintainers to maintain their packages as they see fit.