eRFC: Crate name transfer

[dtolnay]

[RENDERED VIEW]

Summary: This experimental RFC proposes a process by which a designated Rust team member or members could reassign ownership of a crate name on crates.io. The aim is to identify the absolute smallest, most conservative step we can feasibly make from the status quo of crate names that can only be transferred by a current owner. The proposal is intended to address only the absolute most clear-cut situations in which a crate name would need to be transferred. It is not intended to address the situation of name squatting on crates.io, nor as a gateway to eventual more aggressive forced exchange of crate names.

References

• Pre-rfc discussion

[Centril]

The @rfcbot does not have a team T-crates-io on record and this isn't exactly about the operation of cargo so I have added T-core in the interim. We might want to fix this before a team triages this RFC.

[burdges]

I do think this RFC makes sense. I'll point out that crate namespaces can address roughly the same problem, with less manual intervention even than this RFC, but this RFC sounds "more conservative". A namespace approach might go:

• In some future edition, all existing top-level crate names become deprecated, except for compiler provided crates like std, core, etc. as well as a few crates like futures that integrate tightly with compiler crates. We might extend this to really solid canonical crates like serde and rand, but that creates the same problem, so likely not happening.

• In this edition, all newly available top-level names become available for maintainers, both organizations or individuals, who must first demonstrate control over some relatively limited name resource utilizing roughly sane name, so a DNS name, github or gitlab user or organization name, stackoverflow name with reputation over 1000, or similar. We’d verify these conditions automatically to minimize the cargo team’s workload. If you cannot satisfy such an automatic condition then you may request a top-level maintainer name manually with a pull request on some cargo-requests repository, which provides a forum for objections.

• We expose only the lower level crate names to rustc, not the maintainer name. As a result, we should only need to edit Cargo.toml files for the new edition, meaning no changes to actual rust code.

[fbstj]

is it worth explicitly mentioning in the Experiment section that "burnout"/etc of the Responsible Party is a totally valid reason for closing the experiment? similarly is there an upper limit to the length of time of this experiment, or is it worth stating somehow that if the experiment is successful (in that "not too many" renames happen or w/e) then a more formal RFC will be written to solidify the practices afterwards?

may be worth writing down what happens to the RFC itself after the experiment is concluded? I can't remember seeing or hearing of what happens when eRFCs are done, do they stay published but somehow marked as "complete" or "replaced" by their resulting things?

[newpavlov]

Earlier I've published a less conservative proposal, which is similar in spirit to PEP 541. I hope we will move in this direction eventually.

[carols10cents]

I have added T-core in the interim. We might want to fix this before a team triages this RFC.

Because the libs and moderation teams are mentioned in the rfc implementation, I think they should sign off too. I forget, does rfcbot support multiple team sign off?

[Centril]

I have added T-core in the interim. We might want to fix this before a team triages this RFC.

Because the libs and moderation teams are mentioned in the rfc implementation, I think they should sign off too. I forget, does rfcbot support multiple team sign off?

@carols10cents It does; you just add more labels and the bot will request sign-off from all members in the union of all the teams.

[dtolnay]

@burdges regarding namespacing: Thanks! I know many people are excited about pursuing a namespacing scheme. I added a note that I think it should be pursued in a different RFC by someone willing to spearhead a namespacing proposal. I acknowledge that namespacing touches on an overlapping set of concerns and conflicts, but I consider the actual proposal to be orthogonal to this RFC in that we may opt to do neither, one or the other, or both.

---

@fbstj

is it worth explicitly mentioning in the Experiment section that "burnout"/etc of the Responsible Party is a totally valid reason for closing the experiment?

Absolutely, if at any point it seems that a qualified volunteer is not forthcoming, a team could choose to terminate the experiment. I added a note about staffing under Drawbacks. Note that a gap in coverage does not automatically terminate the experiment -- termination would be a team decision based on the negatives of having the process continue to exist without a person behind it, as well as the perceived likelihood of a qualified candidate turning up in time.

similarly is there an upper limit to the length of time of this experiment, or is it worth stating somehow that if the experiment is successful (in that "not too many" renames happen or w/e) then a more formal RFC will be written to solidify the practices afterwards?

may be worth writing down what happens to the RFC itself after the experiment is concluded? I can't remember seeing or hearing of what happens when eRFCs are done, do they stay published but somehow marked as "complete" or "replaced" by their resulting things?

Interesting question! This does need to be agreed upon. I added a note that the experiment will continue indefinitely until terminated or until amended by another RFC.

[withoutboats]

My concern with this RFC is that it will create a lot of work and stress for project members in the future, despite the RFC's best intentions and clear effort to isolate that work and stress to the "Responsible Parties." I think that inevitably, a decision will be made that will cause conflict, and intervention and moderation will be necessary by project contributors other than the "Responsible Party." And we can't close the experiment in advance of this happening, because we can't predict when it will happen.

[dtolnay]

Thanks @withoutboats, that is an important drawback.

Do any of the following characterize your perspective?

1. We can potentially make this proposal work as long as the responsibility for oversight is not spread out across so many people; maybe it should be 1-2 teams only.

2. It will never be possible for the Rust team to arbitrate crate name situations because the potential for conflict will always exist.

3. It may be possible in the future but we would need to dedicate paid employees to the problem.

4. It may be possible in the future but this RFC would be counterproductive / not a step in the right direction.

5. This RFC is a step in the right direction but its scope is so conservative that the problems it addresses are not worth solving like this.

6. The primary reason that conflict would arise is from decisions being too conservative.

7. The primary reason that conflict would arise is from decisions being too cavalier.

8. We can potentially make this proposal work but it needs to lay down concrete guidelines to ensure that decisions are sufficiently conservative.

9. We can potentially make this proposal work but we would need a well-defined way to escalate conflicts in a way that isolates most of the Rust team from them.

[withoutboats]

It is not currently worth the cost in moderation of bad feelings and conflict to transfer crate names without the consent of their holder, because crate names are not scarce enough right now. I don't see a process solution to the problem of conflict, so from my perspective its a constant cost and the benefits needs to outweigh it.

[dtolnay]

@withoutboats ah that makes sense. At the same time don't forget the other half of the story which is bad feelings arising from our current policy. Some more questions to understand your perspective better:

• Are you referring primarily to bad feelings of community members regarding decisions made about their crates, bad feelings of community members when the experiment is terminated, or bad feelings between members of the Rust team when the experiment is terminated? Since you mentioned constant cost, I suspect it may be the last one.

• What might tip the scales in favor of benefits that outweigh the constant cost? Especially, what do you think it is about the npm or PyPI ecosystems by which their policies are preferable to inaction? Are they running out of names in a way that we are not yet? Would their users be more vocally upset than ours if clear-cut cases were not addressed? Are their teams better adapted to conflict than our team?

• Do you fundamentally disagree that there is such a thing as a clear-cut situation, like the one (which I claim is) in the Motivation section? Or is it more about borderline cases which may be substantially less clear-cut than that one?

[jonhoo]

I love this proposal.

@withoutboats there have already been cases where the crates.io team has transferred ownership of crates. For example, this happened recently with the imap crate where the previous owner disappeared after creating https://github.com/mattnenterprise/rust-imap/issues/69 in which they specifically said they were willing to transfer ownership. I would argue that it falls under the clear-cut case outlined in this eRFC, and the crates.io team acted on it (after trying unsuccessfully to contact the crate author). That suggests to me that formalizing that process that already exists is a good idea. Maybe @sgrif can comment on this?

One change I'd like to see to the eRFC is a logging clause. Whenever ownership is transferred, I think that action should be logged, along with who the Responsible Party was, who the original author was, and a short description of why the RP decided that the case was clear cut (should be short, because it's supposed to be clear cut!).

And finally, I would be happy to volunteer as a RP. Though don't know if the Rust team would prefer for the initial RPs to be more core people?

[withoutboats]

@jonhoo In the case you cite, the consent of a current owner is very clearly documented (they had made you a comaintainer of the source repo and written that they wanted to make you a coowner of the package), making it very unlikely to cause conflict. The case I am concerned about is one in which the original owner has not clearly consented to letting someone take over the package, which is what this proposal is about.

If the standard for "clear cut" is "a current owner of the package indicated that they want this person to become an owner of the package," then I think this RFC is fine. But I don't think that's the kind of case @dtolnay is considering "clear cut," and its those cases where the owner has not consented that are the new policy change.

Our current policy is that we will not transfer packages without their owners' consent unless they have violated our policies or we are legally required to. Changing this policy to say that we will transfer packages when someone we have designated considers it a clear cut good idea to do so is, in my opinion, an imprudent policy change that would only be justified by name scarcity presenting a real and immediate problem, and I don't think that's the case right now.

[joshtriplett]

The crates.io team plans to discuss this after the first of the year. One item we did have consensus on, though: this should definitely be a small team, not an individual.

[pyfisch]

I wondered what the crates.io team has discussed so far and found a draft for a reply to this RFC. The draft was discussed on January 17 so I am not sure if there was a disagreement or if the reply will be posted soon.

[sgrif]

Hey everyone! Thank you so much for this RFC and the thoughtful discussion it has caused.

Sorry for the delay in posting this response, the team has had a lot on its plate lately.

The crates.io team met and had a voice call about reaching consensus within the team. This is not the full extent of team members opinions, nor does it represent a final decision of any sort, simply the consensus we have at the moment. Team members with views beyond what I’ll include here are encouraged to comment further.

The folks who would take on the work proposed in this RFC:

The team has strong consensus that this should be a group of people. We would suggest that it be 3-5 people, and not grow beyond or below that for the sake of consensus seeking, scheduling, and consistency. We feel that this group should be considered a sub team of the crates.io team, and that its members be considered members of the crates.io team. We’d like to do this to build comradery within the group and show that we are all working together- there’s likely lots of things we’ll learn from each other’s experience. One person from the group should be available to attend crates.io team meetings regularly to give updates on the sub team’s activity. It does not need to be the same person, and I can’t imagine it would need to be weekly, but this is something we can sort out as the group gets up and running and we get a sense of the scale and frequency of requests we are dealing with.

Decision making strategy:

To make a decision to act or not on a particular request, we’d like to see the group follow the consensus protocol that the Rust project follows, largely: a majority of the team must approve and there should be zero objections. This gives flexibility if some team members are not available for all decisions. The team should seek to all enthusiastically approve, but that’s not always feasible with folks’ schedules, particularly volunteers.

The “experimental” portion of this RFC:

The authors have given great thought and effort to how this work could be immediately cancelled, but the crates.io team also wanted to account for if the team is successful! In 6 months, if this work has not been cancelled, the crates.io team would like to have a review meeting with this team, just to check in on things and talk about how things can be altered or improved.

How the team works:

We’d like to see the team strive to be as transparent as possible, though in a way that doesn’t interfere with their ability to get work done. The team should feel comfortable working privately, but give a public report of how many requests were made, how many were rejected, and then provide a discussion/announcement of the accepted requests and the rationale in the decision. The frequency of this can be determined as we get a better sense for load of requests.

When a request is accepted, we’d ask the team to reach out to an operations person on crates.io, who will then perform the transfer. There’s a possibility that this could be automated and delegated at some point but that will require further development on the crates.io team’s part and that will require design and implementation and policy.

Crates.io work:

Lastly, in our discussion, we wanted to let you know that we super appreciate the efforts made by the authors of this RFC to try to eliminate the burden on the crates.io team! However, after discussion, we think there will be some technical work required of us to make this a reality. In large strokes, we would expect to need to build features that:

• restrict the publishing of semver compatible versions of the transferred crate
• display a banner on the package page indicating that the crate was recently transferred

We can talk more about those in detail, but their design and implementation is largely something for the crates.io team to handle.

Thanks again and hopefully these comments help us to continue to drive this RFC to consensus- I look forward to reading your replies! If there’s anything that seems like I haven’t provided a rationale for- please do ask- I am not trying to hide anything but certainly could have made an error where I omitted details!

[sgrif]

The previous comment reflected what has consensus among the team. The following are my personal opinions, and should not be taken as indication of consensus among the rest of the team, or an indication of how other members of the team feel.

I generally agree with the points raised earlier about crate names not being a scarce enough resource to justify this amount of effort to re-use them. I think the majority of cases that are "clear cut" are typically cases where folks would opt into "I'm fine with transferring this crate to someone else if they want it" if given the option. Giving folks that option would be a much simpler option, that streamlines how we operate today rather than substantially changing things.

One thing that I do think should be clarified in the text and the discussion around this is the status quo. We're happy to attempt to reach out to the owner of a crate for you, and if we receive consent to transfer the crate, we will do so. The only thing that changes here is what happens without the consent of the existing owner.

From my point of view there's a substantial split in the cases that this might handle, which essentially boils down to crates with a lot of code/users, and names that were abandoned. For the former, I think we cannot transfer a name without restricting the version range the new owner is allowed to publish to, lest we end up in a similar situation as the event-stream incident (again, this is only without the consent of the owner. If the owner wants to transfer the name to whoever, we can't stop them). For names that are just abandoned, having a way for someone to pre-emptively say "I'm fine with transferring this name" would be less risky, and I suspect would handle the overwhelming majority of cases.

One last concern I have here is a legal one. Publishing a crate absolutely can grant you a common law trademark on that name. I'm not a lawyer, and I'm not going to claim that I can tell you which crate authors have a reasonable claim to a trademark on that name, but I'm not confident the team responsible for deciding this will be able to either. I'm really uncomfortable with this RFC without at least having some guidelines given by legal counsel here. The RFC jokingly mentions "file lawsuit" as an option if folks get mad about a decision that is made, but that's a real thing that could happen. There's no discussion in here of who we retain for legal issues, or how that gets paid for.

Again, these are my personal opinions, and should not be taken as consensus from the rest of the team, or an indication of the opinions of other members of the team.

[mahkoh]

• Please do not take my package names away without my consent.

• This RFC seems to be partially motivated by me not giving away package names such as audio and math on demand. If I had given them away when I received the first request respectively, they would now be abandoned (no commits in 2018 or 2019).

• None of the popular libraries on https://mvnrepository.com/popular have general names such as audio, math, crypto, etc.

• When you search for math on https://mvnrepository.com you will not see a library called math even though there are such libraries. Instead you see highly relevant libraries.

  On the other hand: https://crates.io/search?q=math shows a completely useless library at the top just because it is called math. The second one is about transforming text?!. The vecmath package is tagged with math, has 120,000 downloads and is highly relevant, yet it is hidden halfway down the page.

  If the crates.io interface were to be improved, much of the justified concern of @dtolnay might be alleviated. Ideally, my package would not even show up on the first or second or third page.

[joshtriplett]

On Sun, Jan 27, 2019 at 10:09:01AM -0800, mahkoh wrote:

• Please do not take my package names away without my consent.

Please do not mischaracterize this RFC. This RFC exists to handle cases where the crate owner has vanished into the ether, not cases where the crate owner is around to say "no". The RFC directly refers to cases where "Reasonable efforts to contact the author are unsuccessful.".

• This RFC seems to be partially motivated by me not giving away package names such as audio and math on demand.

No, this RFC is not about your mass-squatting of names, or about squatting in general.

On the other hand: https://crates.io/search?q=math shows a completely useless library at the top just because it is called math.

"Exact Match" was intentionally added to ensure that people searching for a package always see that package at the top, rather than a more popular package that happens to use the same keyword.

If the crates.io interface were to be improved, much of the justified concern of @dtolnay might be alleviated. Ideally, my package would not even show up on the first or second or third page.

It's not the domain of this RFC to say what should "ideally" happen to your giant pile of empty packages.

[jonhoo]

This is somewhat related to the discussion in https://github.com/rust-lang/crates.io/issues/166. Figured it'd be useful to have them be cross-linked.

[newpavlov]

@mahkoh Honestly you sound to me like the dog in the manger. You have zero recent activity in Rust community, you haven't left any contact info neither in your github profile, or in any of the squatted crates, and you go as far as to actively guard squatted names without any plans for them. Also I've tried to contact you via email you use for commits you haven't even replied.

None of the popular libraries on https://mvnrepository.com/popular have general names such as audio, math, crypto, etc.

And how exactly does it justify squatting those names and doing nothing with them?

If I had given them away when I received the first request respectively, they would now be abandoned

With a policy to transfer crates in cases of maintainer abandons crate or vanishes altogether, someone else would've taken this crate name sooner or later. Such policy has higher chance of resulting in a healthy circulation of ownership, compared to fossilization to which the current status quo leads in the long-term.

UPD: Sorry for derailing, but I think that it's actions (and inaction) of individuals which lead us to the current situation and which in turn many find unsatisfactory. Also it was rare chance to understand position of @mahkoh, which is quite hard to contact. Initially I thought that his actions were done in good faith, that he is ready to transfer crate ownership to suitable projects (and IIRC there were such cases!), but after his message... Honestly I am not sure anymore.

[sgrif]

Folks, this RFC is not about the actions of any individual and I'd like to ask that we avoid derailing the discussion of this RFC by trying to frame it that way

[sgrif]

Hey folks, since this hasn't seen much activity lately I just wanted to make sure it's clear where the crates.io team is at. While we haven't made a final decision right now, we're generally feeling positive about this RFC. That said, we don't think it's ready for FCP yet. We'd like to see some updates with the clarifications we requested in our previous response.

I personally would also like to see my concerns about the legality of this addressed, or have the text of the RFC say why that isn't an issue.

[dtolnay]

Thanks Sean -- this is waiting on me to update the RFC text for another round of discussion. Will get to it ASAP.

[joshtriplett]

@dtolnay Still interested in pursuing this?

[spacekookie]

Heya,

@dtolnay https://github.com/dtolnay Still interested in pursuing this?

I had a chat with @sgrif at CoGoldRust about this and, considering that a crate I wrote would qualify for this, I am interested in being involved in pushing this RFC forward. I'm missing a lot of context, just now having joined the conversation, but would be happy to help out in any way possible.

[pyfisch]

:memo: Rendered :heavy_plus_sign: Changes

Hi, this RFC hasn't seen much progress in the last few months but people are still interested in transferring crate names. Therefore I have updated the eRFC text with the changes requested by the crates.io team.

@dtolnay Feel free to copy my changes to the main proposal.

This raised a few questions:

we’d like to see the group follow the consensus protocol that the Rust project follows, largely: a majority of the team must approve and there should be zero objections.

Is this process described in detail anywhere so I can link it from the RFC text? A related question is whether the discussion and votes within the team should be public or private. Having a public discussion increases transparency but may also lead to haggling and may put pressure on individual team members to vote in a certain way. (This also applies to the decisions of all other teams, people can get pretty emotional about programming language features.)

We feel that this group should be considered a sub team of the crates.io team, and that its members be considered members of the crates.io team. We’d like to do this to build comradery within the group and show that we are all working together- there’s likely lots of things we’ll learn from each other’s experience.

I like the idea but what are the consequences of being considered members of the crates.io team? Do they get to vote on all decisions made by the team and are they allowed to register concerns? I think the members of the crates.io crate name transfer team should be considered members of the crates.io team and be invited to join discussions and meetings but they should not vote decisions made by the team. This is mainly to limit the workload of the crate name transfer team.

One more question about governance: The current draft says: "The library team and/or moderation team will designate a Responsible Party." I think if the crates.io team reviews their work they also should appoint the team.

I hope this helps to move the discussion forward.

[pietroalbini]

One more question about governance: The current draft says: "The library team and/or moderation team will designate a Responsible Party." I think if the crates.io team reviews their work they also should appoint the team.

Honestly, I'm not sure why the libs team is involved in this.

[dtolnay]

@pietroalbini this was written before a crates.io team existed and there wasn't any team whose jurisdiction this best fit.

Which team(s) would you prefer to put in charge of the nominations?

[dtolnay]

I am coming back to this RFC after a bit of time to sort out some other project ideas that had piled up waiting for my time (syn 1.0, case studies, proc macro workshop, request-for-implementation, anyhow, thiserror, watt, async-trait, get a new job, ...).

But I feel better than ever about this RFC and still think we should do this. I expect to go through the discussion again and update the text in the next 1-2 weeks.