> The criterion we apply to GNU ELPA is not to refer users (lead or
> steer them) to a nonfree program.  A service is a different issue.  We
> don't have a rule against packages that communicate with problematical
> services.

This is interesting.  Does this mean an ELPA package that communicates with
a service to, say, convert a document, is fine?  Would that mean that MELPA
could be made FSF-compatible by splitting it up into a free and non-free
section, similar how Debian uses split package repositories, with the
non-free being opt-in?  Or is that not an option either as soon as even the
existence of a non-free repository is mentioned?

If this is indeed an option, please let me know about the specific criteria
necessary to address and I'll initiate conversation with the MELPA
maintainers.  While their first and foremost idea is enabling greater
convenience for users, they've been receptive to enforcing free licenses and
the LibreJS restrictions for their website.

Vasilij