Having two free accounts as an enterprise employee

[bugale]

Select Topic Area

Question

Body

My enterprise employer uses GitHub.com, and recently, as part of a security hardening program, requires all employees that already have a private free GitHub.com account, to create a second free GitHub.com account for work purposes.
For example, in my case, I would have a private free account with my private email (bug****@gmail.com), and a second free account for work, using my work email (bug****@sentinelone.com).

I believed this is against GitHub.com's ToS, specifically this part: "One person or legal entity may maintain no more than one free Account".
However, my employer dismissed this, claiming I misunderstand the ToS, and that since we are an enterprise, our employees are allowed to have two FREE accounts. As a result, around 500 of our employees created two such accounts, but although I am in minority here I feel uncomfortable doing what in my eyes is obviously a violation of the ToS. Before I join them and open a second free account, I would like to verify it with GitHub:

Assuming I work for an enterprise, am I allowed to create myself a second FREE account that will use my enterprise email?

Thank you.

[ossanna16]

Hi there @bugale and thanks for the great question!

Do you know if your organisation assigns Enterprise Managed Users (EMUs)?

I flagged your post to our Product Manager for EMUs to get his take on this and hopefully provide you with guidance.

Thank you!
Anna

[gpadak]

Hello 👋 Creating multiple personal accounts for a single individual is not in the spirit of our general terms, machine accounts notwithstanding. There is also no inherent benefit to creating net new github.com personal accounts for an enterprise customer outside of enforcing naming standards. Those concerns aside, there are a couple different strategies I'd recommend based on what you've written.

• If your employer wants to enforce account management standards and to fully own the accounts that are being used for business purposes then the solution we offer is enterprise managed users. It does have limitations, which may be desirable, as to how these account can interact with public GitHub.
  • That would still result in users like yourself operating 2 accounts, though the EMU account is fully owned by your business where your personal account belongs to you. Content developed within an enterprise always belongs to that enterprise regardless of account type.
• If your employer does not wish to use EMUs and is a GitHub Enterprise Cloud customer today, I'd recommend using a combination of verified domains and verified emails to guarantee notification flow goes to a corporate email address. I also always recommend the use of SSO and requiring 2FA to add a layer of security around access to the enterprise and its organizations. This best practices guide is always helpful as well in setting an enterprise up for success on GitHub.

[eemil]

Ping @gpadak

Please confirm whether or not creating a second free GitHub account for work, which is a member of a paid organization (Team or Enterprise) will lead to the account getting banned under the current ToS.

[eemil]

I escalated this to our account manager at GitHub, and got this response from their legal team:

"The purpose of the TOS language is to deter abuse, so we can't just get rid of it. But having one dotcom account for your own stuff and another for your work stuff is not abuse as far as we're concerned"

Secondhand information, so take it with a grain of salt...

[nasri-othman-ihpc]

Thanks @eemil. I'm also interested in this matter. Do you know how I can contact GitHub to confirm this information?

A liberal interpretation of the clause is to distinguish that an individual in their personal capacity and an employee in their official capacity can be considered two distinct legal entities. Therefore, having one account for personal, and another for account should be fine.

But I'm not sure if that will pass the smell test. Furthermore, I am unsure if this will apply if my organisation is a free organisation (non-paid).

[conioh]

Thanks @eemil.

I consider this to be basically a "no" and I would suggest everyone to consider it so as well.

Even if we believe you account manager completely, while their original intent in the ToS was to deter abuse, they are aware that it includes broader prohibitions than simply abuse, and they are willfully and intentionally leaving this broader proscription.

This means that regardless of the original intention behind this clause, they might still block someone for violating it. Perhaps because their intentions would change, or perhaps because they want to block him for some other reason, but this will give them a valid cause, or perhaps just for fun. It doesn't matter. They would have a valid cause that every free user agreed to when they signed up. At that point telling them "but you said that wasn't the purpose of this clause" won't help.

I wouldn't take the chance.

---

It is true that the text of the ToS also allows GitHub to terminate accounts at any point for any reason or without reason per section L.3:

GitHub has the right to suspend or terminate your access to all or any part of the Website at any time, with or without cause, with or without notice, effective immediately. GitHub reserves the right to refuse service to anyone for any reason at any time.

However, this clause might not be enforceable or legal in many jurisdictions. In the US the ToS might be considered a contract of adhesion and such terms in it might be voided. In EU law this is likely (IMO, IANAL) to be regarded as unfair terms in and possibly also in UK law. Many other countries have similar provisions.

An EU directive on this matter (that is non-binding, but is a guidance on the issue) specifically lists as part of the unfair terms:

• enabling the seller or supplier to terminate a contract of indeterminate duration without reasonable notice except where there are serious grounds for doing so;

Even in the US, where some people think it's allowed to refuse service to any person for any reason, there are legal limits and there are reasons that are illegal to refuse to provide service.

If, however, a person violates a specific clause that's reasonable enough, it would be much harder to argue than "someone told me that despite what the ToS says I can do it and they would look the other way". Sure, you can play lawyer and fight in out in court with their lawyers. I prefer not to. The ToS say no more than one free account and that's that.

[timtucker-dte]

While there may have been no benefit in the past, the addition of Copilot subscriptions with a limit of 1 per account changes things.

In other discussions Github is openly recommending that people split accounts between if they want to use Copilot individual for personal projects but are assigned Copilot business by their organization:
https://github.com/orgs/community/discussions/64920

Presumably the same issue would also apply if someone is part of multiple organizations that each want to keep Copilot data from bleeding in between them.

If that's really the new way forward, it seems like a revision to the recommendations to merge accounts and the accompanying rules in the TOS are in order.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐