Github Copilot licensing is silly

[hades200082]

Select Topic Area

Question

Copilot Feature Area

General

Body

I am the Head of Engineering in my organisation and responsible for selection of our developer tooling.

All of the previous posts and discussions I've seen on this subject appear to have been closed/ignored, but here goes anyway.

As an organisation, we have invested heavily in AI tooling and specifically in developer AI assistants.

We have so far avoided Github Copilot, not because it's not good at what it does, but because the license policies and management is rediculous.

If a user with an active Copilot Pro or Copilot Pro+ plan is assigned a seat in a Copilot Business or Copilot Enterprise plan, their personal plan is automatically canceled, and a prorated refund for any remaining portion of their personal billing cycle is issued. The user will now use Copilot under the organization's policies.

This policy is nonsense. For years Github has advised that users have a single user account linked to all of their work and personal repositories. You introduced the concept of organisations to allow orgs to manage permissions and licenses for that very reason.

But you're now telling us that our developers can't have their own individual copilot licenses if we assign them a seat on our organisational license? That's silly - as is requiring them to now have miltiple accounts.

We don't want our developers using up our premium requests on their personal/side projects and the developers themselves don't want to be forced to use the organisation's license when building side projects as that would grant the organisation rights to their IP under their terms of employment.

Additionally, since Github already knows which repositories belong to which organisations/individuals, it should be simple for you to apply the correct license to the correct projects/repositories. Even without that, a simple option to select which seat/license to use per-project in the VSCode extension would solve this issue too.

If a single user receives a seat from multiple organizations within the same enterprise, the enterprise is only billed once per billing cycle for that unique user. One organization that assigned Copilot to the user is chosen at random each month to be billed for the seat.

This is also silly. How is the premium model usage counted across multiple orgs? Or can only one org use premium models each month? What about usage beyond the included allowance for premium models? Are we getting billed for usage that was made against another orgs projects?

Again, since Github already knows which repositories belong to which organisations/individuals, it should be simple for you to apply the correct license to the proper projects/repositories. Even without that, a simple option to select which seat/license to use per-project in the VSCode extension would solve this issue too.

The same would go for the Enterprise vs Business plans.

For now, we've had to exclude Github Copilot from our consideration of tools to use across the organisation.

I'd be happy to revisit Github Copilot if the situation with seats and licensing becomes more sensible.

[SanjarIsmailov]

idk

[sagar-bankar]

No, GitHub Copilot's licensing isn't "silly"—it's intentionally designed this way for enterprise control and compliance.
The Policy (Straight from Official Docs)
When an organization assigns you a Copilot Business or Enterprise seat (linked to your personal GitHub account):

Your existing personal Copilot Pro/Pro+ subscription is automatically canceled.
You get a pro-rated refund for the unused portion of your current personal billing cycle.
From then on, you use Copilot under the organization's policies (e.g., data protection, code suggestions filtering, IP ownership).

This happens because Business/Enterprise plans are built for companies to centrally manage access, billing, and restrictions—preventing employees from bypassing org policies with a personal license.
Why It Makes Sense for Organizations

Ensures company data/IP stays protected (org can block public code matches, enforce policies).
Avoids double-billing (you don't pay personally while the company covers you).
Companies want devs using Copilot on work-related repos under their rules, not unrestricted personal access.

The Frustrating Part (Your Point)
Many devs want both:

Org seat for work repos.
Personal seat for side projects/open-source (without org restrictions).

But GitHub doesn't allow overlapping active licenses on the same account. You can't "split" them—it's all or nothing per account. This forces multiple accounts if you want separation (which GitHub discourages for other reasons).
It's a common complaint in discussions, but it's by design to prioritize enterprise needs. If your org won't grant seats for personal use, the workaround is a separate GitHub account (though not ideal).

[hades200082]

But it doesn't NEED to be this way.

Github knows which repos belong to which orgs. Why can't it auto-apply the relevant policies/rules based on that? Where it can't (like when starting a new project locally in VS Code) it could pop up and ask you "Which org is this project related to?" and could even have the option to select "none - personal project".

That's why I say it's a silly policy.

Avoids double-billing (you don't pay personally while the company covers you).

No it doesn't - because if you follow the advice given, you'd have a separate account that you still pay for separately.

Claude Code, Google and pretty much every other AI coding assistant out there manages to handle this in a way that allows different licenses for different organisations.

[danr-cova]

I am really struggling with the license setup as well. We have an Enterprise with a number of organisations on a business plan. Generally people get Co-Pilot Pro licenses but we want to be able to give selected heavy users Pro+ plans. The only way this apparently was possible was to create a skeleton org for premium users which is then given the Pro+ plan as default and assign the users to that but even that clunky workaround doesn't look like it will work as I'm tripping over the Enterprise just being a "business plan". I'm sure it will work if I change 150 people to all have Pro+ plans and double the cost for people that don't need it. There must be a simpler way to manage this. Please help GitHub support if you are reading this...

[krishparmar22242]

You don't have to upgrade all 150 people. The 'proper' way to handle this in 2025 is to use Enterprise Mixed Licensing:

1. Change the Enterprise Policy: Go to Enterprise Settings > Copilot > Settings and make sure you aren’t forcing a single plan on all orgs. You want the setting that allows Org-level selection**.
2. Use the Skeleton Org:It feels hacky, but it’s actually the way to go. Set that specific org to the Copilot Enterprise plan ($39/mo).
3. The 'Magic' Billing: When you add a 'heavy user' to that premium org, GitHub recognizes they have two seats. It will automatically give them the higher 'Enterprise' features and only bill you for that one $39 seat—it won't affect the $19 billing for the other 150 devs in your other orgs.
   It’s definitely clunky, but it avoids the $3,000+ price jump you were worried about! If you're still stuck in the UI, it might be because the Enterprise account itself needs to be 'unlocked' for mixed tiers by your account manager. Hope that helps!

[danr-cova]

thanks for that. I will look into this. I have ownership at the Orgnization level but not the Enterprise so cannot see everything on that side with what's possible to set up and it's been pretty difficult to determine from the documentation what it should look like on support requests internally. I will check to see whether we have that sort of granuality in our Enterprise GH settings. Thanks for the tips though, definitely opened a new possible path to resolution 😵‍💫

[danr-cova]

I really hope this works for us... Thanks for so much. I'm just waiting for the next gotcha tbh :/

[danr-cova]

GitHub Support seem to have a different view...

The most straightforward and easiest method for increasing the premium allowances of a small number of users within an org / enterprise would be to enable Premium Request overages, and assign budgets to these users to allow them to go over the default allowance.

Their suggested solution to manage it via overage costs in Pro plans on per individual basis is not really an acceptable path in this case. It will add too much administrative overhead and then almost fosters league table of api usage vs results charts... "He was able to do this amount of work and only needed $15 in overage fees, whereas this person spent $100 and has barely merged a PR" ... All this admin and thinking about the nuances gets in the way of the actual task of using the tooling. To maxmimise developer workflow they shouldn't need think about this sort of thing. We want most users on one plan. Heavy Premium users can pay double and make more requests... It should be simple, but its GH licensing so it isn't.

I get that Pro+ licenses are for an individual so that wouldn't be possible so then the "Enterprise" license is pretty much the same as Pro+ so I will go with that.

So now I need to find out, can I enable Enterprise licensing for one organisation whilst the rest of the Enterprise / Org structure is on the "Business" Plan.

If I can do that then the co-pilot licenses for that organisation will effectively be the "Enterprise" ones rather than regular Pro licenses. I am sure there will be another stumbling block to tell me that you cannot do that without either doubliing the cost of everything or creating a standalone organisation that's not connected to hold licences..

[krishparmar22242]

Hey! I saw your point about the Copilot licensing mess. Honestly, you hit the nail on the head—GitHub’s 'one account' rule is crashing into their 'Enterprise billing' logic, and it’s a nightmare for IP protection.
Right now, since there’s no 'per-project' license toggle in the IDE, here is the only 'safe' way to handle it for your team:
Force Separate Accounts: It’s annoying, but tell devs to use a dedicated work-only GitHub account. This keeps the Enterprise seat off their personal account so their personal $10/mo plan doesn't get nuked.
VS Code Profiles: They can set up a 'Work' profile in VS Code signed into the company account. It creates a clean legal break for IP.
The Billing 'Randomness': GitHub does that to prevent double-billing, but it makes departmental budgeting impossible. Using separate accounts for each Org is the only way to ensure the 'right' Org gets billed for the right usage.
It’s crazy that we have to work around the tool like this, but until they add a 'Select License Source' button in the settings, the 'Dual Account' approach is the only way to keep the lawyers happy!

[hades200082]

That's my point though. We don't have to work around it.

All of the other AI code assistants can handle having multiple licenses. Just use one of them instead and GitHub will get the message.

[krishparmar22242]

need more help about anything if it was helpful please accept the answer