Are there publishing rules on crates.io?

For example, is it allowed to post some crate named v*****? Is it allowed to show sexual pictures in the crate's README? The Cargo "publishing" documentation doesn't prohibit any of this, so I can use whatever name and whatever README, right?

Overworked volunteers of crates.io only take action on edge cases. There's no moderation (even if little), so you've right to do anything.

Your hypotheticals sound like they would violate the Rust code of conduct, but I can't speak for the crates.io moderators. Compare the pypi policy with the Rust policy. I think the Python policies are more straightforward.

Sure; but even if crate name or README breaks the policies, there are no moderators. I've been told that some folks that manage crates.io only take action on very specific cases. So these folks won't do even little. So what I understand is that I can finely break that code of conduct.

For example, if they add a feature of namespaces, but not as the crates as namespaces proposal, if someone illegally takes ownership of a namespace that shouldn't belong to them, no little will do the few folks that manage crates.io. Plus, this illegal "ownership" thing doesn't happen "frequently"; it's very, very, very rare; so no need of frequent moderators.

I think it would largely depend on context. There is a whole ecosystem of crates for teledildonics centered around https://crates.io/crates/buttplug (may be NSFW depending on your specific SFW policies).

Personally I don't find the pypi policy that much more straightforward

We do not allow content or activity on PyPI that:

  • is sexually obscene or relates to sexual exploitation or abuse, including of minors;

What is the level that causes content to become "obscene" (which culture's values are used to derive this level)?

6 Likes

The pypi policy goes into much greater detail later in the document.

I think you've misunderstood something, I'm sure breaking the rules is one of such specific cases.

1 Like

Quote:

Is there some context for your question?

It's due to a recent proposal of mine about supporting crate domains on crates.io. Someone told any user could take illegal ownership over a domain, which is a rare edge case, even though which is also a legality issue?

My proposal of domains and URI crates has a goal similiar to the proposal: Pre-RFC: Packages as Optional Namespaces

I don't think they were intending on enumerating all possible cases that the moderation team will take action on. I'm not aware of any cases where rule-breaking crates have been reported and the reports have been ignored.

5 Likes

To be honest, I don't think hypothetical questions like this pose any value. There is obviously a level of common sense used when a crate is reported.

10 Likes

Yes, but like said before, there's no one getting paid for this and they said... there's no one to work on resolving even edge problems like illegal package name ownership.

So... it means I can do whatever. Once I take a name that doesn't belong to me, there will be no moderator to take over me if I'm using it illegally. Right?

For example, if I publish an empty stub crate with the name azure, it's gone; it belongs to me. azure would normally belong to Microsoft, but they didn't use crates.io at the moment. What if I lose access to my crates.io account and can't pass ownership to anyone else? Or what if I don't want to pass ownership and be a bad person? That's just an example (not concrete).

And so, after all, my crate domain proposal was taken down because of something like this explained above.

If crates.io is self-service at extreme, then I can create a crate ***** and *.

No, as you said earlier crates.io operators will respond to legal orders. If you for example commit trademark infringement and the trademark owner gets a legal order for crates.io to remove the crate they will.

2 Likes

Then why was my domain proposal underrated for that? The moderators would just remove the domain.

Then nothing. It's not against the rules of crates.io let alone illegal, Microsoft can use microsoft-azure, azure-rs or whatever.

If your actual intent is to just talk about your proposal again (which had many good reasons to be rejected) I suspect this thread will get locked just like the previous ones.

2 Likes

This should change, otherwise Rust will have a complicated future in crates.io.

As far as I recall the discussion this wasn't a reason anyone had against your proposal. Someone using a "crates.io domain" which overlapped with an Internet domain name (since you explicitly rejected validation of the domains back to Internet domain names) isn't in itself a trademark infringement. There is a wide gray area in which there's no illegality involved but the names are ambiguous and the domain name form of them gives a stronger chance for mistaken identity (someone is more likely to think microsoft.com/azure is owned by Microsoft than microsoft-azure).

Yes, I thought of this ambiguity. I was mostly inspired by XML namespaces, which use URIs, but not "HTTP" URIs...

I'm still up for the other proposal using packages as optional namespaces, but the issue of crates.io moderation still sucks. They said the minor team of crates.io won't do anything regarding unused crates... This kind of moderation I'm talking about isn't simply deleting unused crates, too; it involves author contact etc.

By the discussion in my previous proposal, what I understand is that they'll never do anything about an unreachable crate.

Unrelated comment, but I think namespaces over "packages as namespaces" are better as it distinguishes crates from crates.io namespaces. For example, you distinguish microsoft namespace from microsoft crate.