Inactive username can't be claimed?

Lately, I’ve been little sensitive about the usernames across the websites I hold an account and started to use the same username everywhere possible. There is this guy who is blocking the username I wanted on github, from over a decade with no public activates and repositories.

To claim this username I have reached out to github support and requested to release it so that I can claim. But github support rejected my request, stating it can’t be release to me. I still don’t know why I can’t claim this username and it is very disappointing to know that github is choosing an inactive user (who has been violating github policy by reserving the username from more than a decade) over a active user who is getting started with open-source world.

Here is a link to the username policy
https://docs.github.com/en/github/site-policy/github-username-policy

As per our policies,

GitHub prohibits account name squatting, and account names may not be reserved or inactively held for future use. Accounts violating this name squatting policy may be removed or renamed without notice. Attempts to sell, buy, or solicit other forms of payment in exchange for account names are prohibited and may result in permanent account suspension.

Based on this policy, I believe the username can be removed and allow it for me to claim.

I hope github staff look into this and help me out to get the username I desire so badly.

2 Likes

I’m just a user, like you, but I’m surprised that your request was denied, because this question has already surfaced in other posts and the user-name squatting policy was mentioned in this regard as a legitimate claim for overtaking similar inactive accounts.

I’m not sure whether “squatting” refers to opening multiple such accounts, or even a single one. But the “inactively held” policy does cover the case you mention.

The problem is that some users create GH account in order to access various GH services, e.g. being able to download Zip archives of repositories, so not all their activities do show up in their user profile. So, yes, there are some legitimate GH users who don’t create repositories, and maybe not even participate to third party repositories or Issues discussions, but still regularly log into GH, which means their are not “inactively holding the account”.

So my guess is that if your request was turned down it might be due to some inside knowledge about this specific user being active in some way.

But I’m really interested in this discussion, and hope that when the holiday period is over, and the Community will enjoy full-fledged presence of GH staff, we’ll be reading more on this delicate topic of users names.

1 Like

@tajmone - thanks for expressing your thoughts on this matter.

I agree with you - not all activates are publicly visible. But rather than giving a reply like “We cannot release the name to you” it would be nice to hear the reason, why it can’t be release to me or anyone.

I also believe, users who use only the github services might not be that sensitive about username (I could wrong though). But when I reach “gitlab” support to claim a taken username, they have a policy, which they will notify the current user about being inactive and risk of loosing the username, with one to two weeks notice to respond. I think something like that should be in place to keep inactive user from taking usernames for future purpose.

However, I was expecting a more human friendly reply from the support rather than copy pasting a standard message for tickets like this. As a last hope I have reached here, lets see how it goes.

1 Like

There’s a users’ forum for a commercial product which I purchased that has a policy of sending an email after one (or two, not sure) years of inactivity (i.e. not logging in), the email warns that unless the user logs into the forum within so many weeks his/her account will be terminated. I have engaged in a rather hot confrontation with the admins about this; they claim this is both required and justified by UK laws, but I counter argued that it would be a violation of my copy-rights, since it will remove my name from posts that I’ve authored (which include code), thus stripping my work of my paternity and exposing it to misuses, and that merely keeping my work on their website without mentioning my authorship would be a violation of my author- and copy-rights.

Shutting down an account to which published author’s works (text and code) are associated is always problematic, especially if the previous contents are preserved under a placeholder pseudo username (on GitHub, deleted accounts become “Ghost User”). Different countries have different legal interpretations regarding this, and it might not be a simple issue to tackle.

Deleting all the user contents when the account is shut down is also problematic — in a forum this would disrupt threads, leaving holes in conversations, and for threads which were initiated by the user it would mean taking the whole thread down. This is technically unpractical and will most likely enrage other users. With Git repositories, disrupting consequences might have stronger ramifications, both in terms of breaking dependencies and affecting their authorship.

On the other hand, renaming the deleted account to a predefined placeholder account (“ghost”, “deleted”, etc.) while preserving the original material is not exempt from side effects either — paternity is lost, copyright becomes unclear, possibility of interactions are disrupted.

Another potential problem with taking over a user account that was initially active but then went stale is that the new account owner could be mistake for the original one — i.e. attempts to contact the former will result in reaching the latter, which could potentially lead to misrepresentation issues. This is a frequent problem with email accounts, especially those associated to subscription domains which expire and become available on the market again, which leads to old contacts writing to the account ignoring that a new owner has taken it over.

Email accounts usually fall in the same category of phone numbers and are regulated by a State’s laws on telecommunications, which makes the issue legally blurred in those countries which consider phone numbers and vehicles registration plates as uniquely associated with the individual (i.e. you can change as many cars or phone contracts you want, but you’ll keep the same registration plate or telephone number). In many EU countries, when change phone provider you have now the right to keep your old phone number, which has to be relinquished by the previous service’s company to the new one (it’s a clear case of user rights over company rights). With emails this is currently not possible, but it’s being discussed.

Your desire to keep a same user name across different third party services reflects this felt desire and need to obtain personal ID uniqueness and portability of user name across services, and beyond services migration. I believe in the future this is going to become the norm, as many new Internet protocols are moving in that direction, and many states are trying to provide officially sanctioned digital identities to their citizens, which ultimately means one account for everything (of course, many people are unhappy about this, since it means less anonymity and a stronger state grip on our communications and transactions).

As you can see, there are many consequences to shutting down an account which was active for some period and then went stale, some of which are technically complicate to handle without disrupting services, others which are legally obscure in nature, and ethically complex (to say the least). Also, user accounts fall in the broader scenario of personal identity in the Internet age, and the struggle between obtaining a strong identification while also preserving our privacy.

My best guess is that when it comes to legal matters, staff members have their hand tights — clamped between privacy protection laws that prevent disclosing personal information, and the fact that emails have legal value and being employees their replies reflect responsibility on the company.

But this is definitely an important issue to be publicly discussed, and I’m sure that users have a lot to say on this in terms of expectations and service improvements. So I too hope that this thread will develop into a constructive conversation with strong participation from both the community members and staff — without leading to flame wars. GitHub is attentive to its user base needs, and similar discussions can play a role in shaping the future of its services.

My personal opinion is that digital technologies and services have evolved too fast in the past decade, leaving much of their legal and ethical grounds as undiscussed matters. Laws in this field are usually introduced very late, when any remedy is hard to enforce, and widespread adoption of these services has led to the introduction of strong privacy protection laws which often differ from country to country, making it hard to understand how their legal jurisdiction unfolds in services which are consumed across different states (a general problem with any digital legal matter related to the Internet).

1 Like

A similar question was posted a few weeks ago. You haven’t provided the username you’re trying to claim, so I can’t check myself, but here’s an explanation of how to check if the username is actually abandoned:

That said, it’s worth noting that GitHub’s policy may have changed, according to @Vasile-Peste

I sympathise with your situation: there’s an abandoned username I’d like for my organisation because I am publishing a lot of GitHub Actions, unfortunately the owner does not want to release it – even though it has not been used for more than a decade and they have no intention of using it. Ultimately, a username is first come first serve and it’s very difficult for companies to fairly reclaim and reallocate usernames, someone will lose out, and it introduces security concerns when GitHub usernames are so often part of a dependency ecosystem. We can’t begrudge them, we should have been a decade earlier :slight_smile:

1 Like

I find it hard to keep up with all the policies and free-account features changes — I’ve seen so many of them in the past 7 years, but recently they seem to be changing faster than before. This can easily be confusing, so much so that I start to wonder whether the policies pages should have their own version history (just like APIs) so users can easily track their changes in time.

Honestly, I rather prefer this situation than seeing what happened with NPM, when they complied to a company taking over a package name due to patent rights:

the username that I was trying to claim is “ckpro” and I just did a curl and found the following info

  "created_at": "2011-05-27T18:59:54Z",
  "updated_at": "2015-04-07T14:49:19Z"

It appears he/she is inactive since 2015 (please correct me, If I read curl output wrong).

I’m not familiar with the legal terms as I’m new to this line of work (online accounts, policies & stuff) and I will certainly consider this as a opportunity to get my hands dirty and I thank you for sharing your experience with me here.

However, from a user point of view, I can say that, user satisfaction is most important. Be it a free or paid service. I’m sure gitHub has been on top of the list in providing many number of services for free and I always admire github for this. But, if we look at the other side of the coin. Getting hold of the users with strategies that make him/her to come back for goodies and rewards is the most important factor. In case of gitHub, I think the open source “community” (users like you and me) itself is the reward that everyone are coming back for and this is what might have stopped many of the users moving from github to githlab after ms acquired github. So, I personally think, github must keep good hold on the “community” by providing quality support in the subscription range.

Again, I’m a big fan of github and my identify on github means a lot to me, that is the reason I’ve been trying my luck here as a last resort.

Having versions for the policy pages would certainly comes very handy to track and also clears a lot of confusion for the users. True.

The support said that the policy has changed as one has mentioned. But still I would love to have one username which is inactive.

Can someone from the staff/support look into this request and allow to change/claim the username for one last time?

Hello @lazydeveloper,

Unfortunately, we are no longer accepting requests to release usernames. While some of these usernames may appear dormant, it’s important to remember that not all activity on GitHub is publicly visible. If you are the owner of a relevant trademark and you believe someone’s account is violating your trademark rights, you can explore your options on our Trademark Policy page:* GitHub Trademark Policy - GitHub Docs *. Otherwise, you will need to choose a username that is currently available.

@tuves no offence, but the whole point of creating this discussion in our community is not see “this” message here as well, but to reconsider the name change policy or at least help a very few of us to have the username changed as an exclusive case.

Thanks!

This username I’m trying “ckpro” - the account holder might be also violating our rules by holding this username for future purpose as from this simple command it appears that he didn’t login to github since 2015.

$ curl https://api.github.com/users/ckpro

Please take a look at the last line (“updated_at”) of the result in the screen shot above.

This is incredibly frustrating, as they still list their Name Squatting Policy in their public site policy. Now, when you attempt to contact GitHub support regarding this, they prompt you with this message (which is at least better than nothing):

In my opinion, this is a seriously poor choice by GitHub. Namespaces will always become crowded over time if not maintained, and this creates a poor user experience for new users the longer the service is available. It was GitHub’s choice to tie the username to a unique identifier, like the URL/repo path. They could have utilized a UUID system for URLs that would maintain unique addresses without making public user/organization names unique. That would have solved the problem.

As far as I’m concerned, if this is going to be GitHub’s long-term policy, people should switch to other platforms like GitLab. GitHub is CHOOSING a dormant, free user over me, an active user that WOULD buy a subscription, if my organization name was available.

There’s an interesting twitter thread about this which I am confident is related, given npm is owned by GitHub.

1 Like

And this makes perfect sense to me. I wouldn’t be creating a stink if the organization had any public (or private) repos associated with it. I totally understand and agree that in that circumstance, the name should not be released unless the owner of the name agrees to release it voluntarily.

But if an account is dormant and has no public repositories, as far as I’m concerned, there is no issue with compromising supply chains. If the account is actively being used privately, of course I have no way of knowing that unless Support says that the account is being actively used, and isn’t abandoned/squatting. If an account has no active public OR private repos, there really shouldn’t be any issue releasing the username IMO.

To compound the issue, at least in my case, the organization has no public repos, nor any public members/contact information. So I can’t even contact them to ask them to voluntarily release the username if they aren’t using the account. This is incredibly frustrating.

1 Like

This is my email that’s being hacked I keep changing my email to avoid this. Itsgetting old

I see these as two different things. The name squatting policy is really more about warning end users that such a practice may result in account deletion, at GitHub discretion. It’s more of a “you’ve been warned” thing, whereas requests to free dormant usernames are quite different, for here we have a third party claiming someone else’s account based on the assumption that it’s not being used, or that it’s name-squatting, etc. This requires stuff members to actively look into that account, which is time consuming.

My best guess is that time-consumption might be one of the major issues at play here. In fact, they’re still accepting complaints about usernames violating trademarks, etc.

Interesting thread, thanks for the link. I’m not sure how much the fact that NPM is owned by GitHub might imply relevancy here — after all, we could say that GitHub is owned by Microsoft too.

The way NPM has handled username reclaiming in the past has been quite disastrous, and has also lifted up quite an ethical storm in the opens source community.

With NPM, the problem is that packages have just their names associated with them, unlike a repository which has also a username. This (as your link shows) can easily become a problem when a package being delivered via multiple platforms discovers that its unique name has been already taken on one or more such platforms.

This problem of unique usernames and packages/apps conflicts across different platforms is becoming increasingly apparent, especially with all these different services being integrated into wider ecosystems that interact with each other. There will always be a user name clashing with a company name or another username already taken up.

Giving priority to registered businesses and trademarks is far from an ideal solution in my opinion. Trademark squatting is also a growing phenomenon (believe it or not, someone here in Italy even tried to register the anarchy symbol as trademark), just like domain names squatting (i.e. buying up all alternative domains for a company website, in an attempt to resell them to the latter).

What we really need is a new third way to differentiate between same-named users across the ecosystem, e.g. like an independent and neutral service which could use a unique auto-generated ID to distinguish between same named accounts — a bit like a DNS server mapping IPs to domain names, except that this service would map UUIDs to usernames that might look alike, although by further inspecting their credentials details you’d know they belong to different people, orgs or entities.

Other than that, we could you use emails accounts, which are unique, but we all know that (1) this would be inviting spammers to feast, (2) not everyone is willing to publish so openly an email account.

on top everything - GitHub is being less human for name change requests.
I’ve created 2 support tickets for the same purpose. 1 requesting name change, 2. user violating GitHub policy by holding username. for both my requests, I got same reply stating dormmate usernames can’t be changed.