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

[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.

[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 mattnenterprise/rust-imap#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.

[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.

[mahkoh]

@mark-i-m "Crate transfer should not require consent" and "silence implies consent" are different topics.

[BurntSushi]

Moderation note: Before responding, please consider whether your comment meaningfully advances this particular RFC discussion forward. The moderators will be watching this thread carefully and will remove comments that veer too far off topic. Thanks.

[joshtriplett]

@joshtriplett

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.".

I hope you know that consent is an active process. Not replying to contact attempts is the same as not consenting. This kind of misunderstanding is exactly why I felt the need to comment.

(I assume you meant to say "is not the same".)

This eRFC does not directly define the process by which the Responsible Party would decide to transfer a crate. See the section "Alternative: provide a checklist of criteria", which mentions "here is a non-exhaustive list of factors that one might expect could influence the decision"; there's also a section "Alternative: transfers by consent of the owner only". I believe your comments are already represented within the eRFC, and in particular that the eRFC and potential folks who might serve as the Responsible Party are aware of the distinction between someone being unreachable and someone explicitly responding and agreeing/disagreeing. The same section "Alternative: provide a checklist of criteria" that same section also states that debating the specific transfer criteria is off-topic, since the eRFC does not establish specific criteria.

this RFC is not about your mass-squatting of names

your giant pile of empty packages.

I'm feeling attacked by your formulation of these statements. (Though the underlying facts are true.) I assume this was intentional. Please be more considerate in the future.

For the sake of clarity: no, this was not intended as an attack, this was an expression of disapproval. I will continue to express general disapproval of mass package squatting in the future. But nonetheless, this eRFC does not specifically address that problem, and thus that is off-topic for this thread. I'd prefer to simply let this off-topic branch of discussion end.

[mahkoh]

@joshtriplett

Not replying to contact attempts is the same as not consenting.

(I assume you meant to say "is not the same".)

No that was no typo. Let me rephrase: If someone does not make an explicit statement one way or the other, then the default assumption should be that they do not consent to having their crates transferred.

I believe your comments are already represented within the eRFC

My interests are represented in the text in the alternatives section. However, the main text gives the responsible team the power to transfer crates at their discretion as long as they respect the spirit of the text. As a potential target of such actions I believe that this is the right place to express my concerns.

I think I've made my position clear now.

[withoutboats]

I still hold to my previous comments on this this thread: the amount of controversy this will cause is not worth it. Moderators are already doing work just from this RFC being opened at all, demonstrating the point. If we start reassigning crates without users consent, users will continue to demand more and more intervention, creating more and more work for the project to moderate conflict and justify our position on why such and such transfer is or is not appropriate. This endeavor is a poor use of peoples' finite time that could be spent far more productively on behalf of themselves or the project, and the proper solution is for users to choose a different name for their projects if the name they want is taken.

[QEDK]

I think this experiment is a good move towards discouraging name squatters and albeit the eRFC aims to disassociate from the issue, it's very likely that the experiment is quite important. Having come across a few name squatters it's quite apparent that this is a mild issue at the very least and given that there is team willing to be responsible to carry out the functions necessary, it only makes sense to go ahead with this.
The largest package registries have policies against name-squatting for a reason and I think it becomes important for crates.io to do the same as a rapidly-evolving language and with that, a growing registry.

[jafioti]

Has any progress been made recently on this? I understand that this RFC doesn't directly pertain to name squatting, but it the first step toward dealing with the issue.

And it is an issue that will have to be dealt with at some point, so I'd assume the sooner the better, as it really is a big issue for the future of the ecosystem.

[carols10cents]

Any progress would have been posted here.

[chevdor]

It should be possible for a github account foo to claim back a crate bar published by whoever and still mentioning the the repo as github.com/foo/bar. That can be a fully automatic (optional) process the user foo should be able to trigger.

There is no benefit and it makes no sense to authorize a disconnect between the code itself (foo/bar) and the crate bar mentioning a repo at github.com/foo/bar if the original author foo decides it.

I understand this is only a sub portion of the real issue but would already easily alleviate some pain for many cases.

[jhpratt]

A fork could mistakenly forget to update the repository URL, which could lead to a hostile takeover. Plus I don't think the crates.io team wants further reliance on GitHub.

[chevdor]

Fair point @jhpratt.

There are surely lots of edge cases. If a fork forgets to update... well bad luck or bad start as this is a very basic change. That means the original author could claim the crate which is the whole idea. I don't think that qualify as hostile takeover.

How many time would that happen vs how many of the current issues would this option solve? It sounds like a good trade off.

As far as the reliance on github, I am actually happy to hear the direction you have in mind but the number of crates currently not using github is probably very limited. Still I understand the will to avoid sticking with the past. My example was what it is: an example. The example would work just the same with any other source hosting solution so feel free to read git<your_pick>.com/foo/bar.

[ShadowJonathan]

Reading the eRFC, I am concerned with how much a carte blanche is given to the RP to decide on crate transfer decisions.

While I agree (to a point) that the RP can and should privately reach conclusions, create a log, and provide optional rationalisations, this eRFC does not provide any minimum time limits and/or failsafes for an owner to decline the transfer.

More specifically, I'd like to see;

• A defined minimum time window (let's say, 4 months) where at the start first the decision to transfer a crate is published, the author is (tried to be) contacted every other month about this decision, and only then after this window does the transfer actually take place.
  • The RP could only freeze or resume this process, and not speed it up.
  • If the original author reappears and gives explicit permission, this period is finished immediately.
• When the crate is widely used, a process by which the community can get involved in accepting the new owner for the crate or not, and that the RP has a way of measuring that acceptance.
• A way for the original author, after they reappear in the community, to start a trialogue process between the them, the RP, and the new author, and gain consensus or receive a final decision on the way forward.

These measures could help the community to gain a reasonable time and right to respond to potentially unwanted crate changes, and could make claiming a crate less of a "oh let me do this quickly", and more of a serious slow decision that will have weight behind it, both for the RP, the community, and the new owner.

Maintaining a crate can be arduous, and this policy should not only apply today, where we might have lots of claimed abandoned names, but also for in 10-20 years, where we have to recognise the possibility that valid crates' authors can disappear over the course for various reasons, and that transferring ownership in those cases isn't a decision that's limited to the RP, the new owner, and the old one, but also to the wider community, and it's trust. I can only hope that the PR can keep a good judgement of character.

---

Also, while this is probably implicit in the proposal, I'd like to see this added as well;

Under no circumstance where the original owner is responsive and objects to the transferral, should a transferral happen.

While this would probably disable some "uses" this proposal would give to the RP, I think it is important to state this, as as I stated above, this eRFC gives the RP too much power, and there is too much potential of them becoming an arbitrary decision-making power on crate names, instead of a custodian.

---

My specific motivation to "cut down" the RPs power like this is pretty simple; Better some crate transferral options rather than none at all, even if it's slow, bureaucratic, and informed. I'd take that over quick and controversial. (This RFC is experimental for a reason.)

---

PS; if me putting a comment like down isn't the proper feedback procedure for an RFC, please poke me and I'll try to fix it.

[jaredgorski]

At the very least, a crate should contain code. If it doesn't, there's no justification for the crate. I think this is a baseline case.

My anecdotal experience with finding crate names to use on crates.io is this:

The problem is not often that a crate name I want to use is occupied by a project, however unmaintained. The problem IS often that a crate name I want to use is occupied by a completely empty project, and installing the crate doesn't download any crate-specific code.

This is anecdotal; take with salt. YMMV.

Someone may try to interpret this experience I described as fundamentally being a problem with squatting, which is out of scope. However, for the purposes of this eRFC, I think it's reasonable to consider empty crates a starting point for a workable category that the RP can use to justify their decisions.

As to the technical details of how decisions are carried out, I think it should vary case by case, which justifies the existence of the RP. At the least, it's good to post a notice on the crate site for some buffer period to give opportunity for the original crate owner to re-stake their claim.

Anyway, I hope to stir discussion on this that leads to some sort of solution. By the looks of this issue/thread right now, we risk stagnation.

---

E.g. of my anecdote: consider this case, where the crate has absolutely zero code associated as far as I can tell. Or this case, where the relevant code is the "It works!" (Rust's version of Hello World). In my opinion, this is more common on crates.io than it "should be", and provides a reasonable zero for some internal categorization by RP.

[nacaclanga]

I belive the general problem boils down to this:
a) This policy shouldn't enable people to steal crate names of legitimate projects.
b) It is hard to define, what constitutes a legitimate codebase and if you put in place any definition, malicious name squatters will find their way around the definition, making the outcome potentially worse.

Because of b) I still belive that the general process described by this eRFC is the right way to go. What should be a rule here, is that crate names can only be reclaimed if they are squattered, not because the crate has been just abandomed.

Maybe one can add a rule, that once the Responsibly Party recommends name transfer, there should be a public comment period of e.g. 2 weeks, where the plan to transfer crate is posted and a wide audiance can raise their concerns and objections.

[ShadowJonathan]

For the sake of people's (limited) time and attention budgets, I suggest that period be a month instead of 2 weeks, this should be enough to research and turnaround a discussion regarding it, if its controversial.

Alternatively, imo, it could be the 2 weeks, but the time can be extended if the period contains extensive/intensive discussion on the matter.

[programmerjake]

@jaredgorski

At the least, it's good to post a notice on the crate site for some buffer period to give opportunity for the original crate owner to re-stake their claim.

imho it should be more than just a message that pops up on that crate on crates.io, email if possible.

If I was writing a project and it wasn't yet ready for release, I might publish a placeholder crate until I was ready to start releasing it -- I'd probably end up publishing a crate stating that it's a placeholder and linking to the git repo of my project, and then I'd keep developing my project and not bother to check the placeholder crate since I'd assume it's fine until notified.

As an example, see the placeholder I published before I was ready to publish a fully working crate:
https://docs.rs/crate/algebraics/0.0.2/source/README.md

[jaredgorski]

@programmerjake

Fair point. When publishing a crate, it should be clear from the start (whether via docs, CLI warnings, web forms, etc.) that crate maintainers 1) must provide reliable contact info, 2) be aware of the nature of crate disputes, and 3) be clear about their intent with the crate. We're trying to conceive a system which eradicates situations where maintainers disappear and can't be contacted and/or are caught by surprise when their crate is taken away.

Thinking outside the box a bit... we could have crate maintainers select a "crate type" when they publish, and one of these options could be "Placeholder". The "Placeholder" option would do 2 things:

1. protect the crate from the same RP scrutiny that other crate types might get
2. open up a second dropdown/dialogue which requires the maintainer to input a timeframe/deadline at which point, if the crate has not been promoted from "Placeholder" status, the crate name becomes eligible for disputes and RP scrutiny

I know this doesn't fix the ex post facto situation (emails, banners, etc. might be all we can do there). Thoughts on anything I said?

[dtolnay]

Superseded in part by #3463. It sounds like the crates.io team will be directly picking up some of the responsibilities described here in regard to mediating ownership transfers.