Hacker News new | ask | show | jobs
Ask HN: Does your company ban GitHub Copilot?
8 points by pqn 1213 days ago
Many of my friends are telling me their companies have banned Copilot since it sends sensitive data externally to GitHub, even in their enterprise offering.

Have you all heard of which companies have bans, for this or other reasons? Any interesting conversations or internal discussions talking about it?

4 comments

I don't think my company even knows Copilot exists, let alone bans it.

I certainly haven't seen any message about it, nor evidence of any coworkers using it. But if they did, it'd probably get banned for that same data issue, since they're very worried about folks transferring data from their machines and tend to restrict things like most companies emails being sent to third party addresses, USB devices being used, etc.

We moved to Gitlab after the acquisition of Github by Microsoft. Copilot is not used here. All devs received a company license for Tabnine.
One of the team here at Tabnine. Thank you for choosing us and please let us know if we can help.
I think the bigger reason it is banned at most companies is because it's nearly impossible to know what kind of license the generated code is available under. Copilot is trained on open source codebases, which carry a number of different licensing agreements to use that code in your own codebase. Companies simply do not want to deal with using software that opens them up to unknown legal risks.
How would it ever be tracked? Is there something that can detect Copilot generated code?
Actually, no need to detect the Copilot code. Just compare the code itself, there are a bunch of tools that can do this.
Didn't it spit out the famous fast inverse square root almost verbatim?
We're a tiny company, but it is basically "banned" for similar reasons.

We're concerned more and more about GitHubs behavior ever since the Microsoft acqusition. Due to this, we've agreed not to use any proprietary GitHub solution, including codespaces, actions, as well as copilot. It feels like new GitHub features go towards a data-hoarder, vendor lock-in oriented solution.

What is the problem with GitHub actions?
There's very little guarantee to where the GitHub-provided runners are executed. There's very little guarantee as to what the auto-updating self-hosted runner binary does. There's very little guarantee as to what the GitHub-provided containers and actions contain.

It is also unsupported - and exceptionally hard - to execute runners without GitHub being available, or to migrate off of the proprietary action descriptor format.

Running GitHub enterprise locally may releive some of these issues, but using GitHub.com with GitHub actions is somewhat of a security and reliability nightmare, unless you trust Microsoft's GutHub with infinite visdom and 100% uptime.

The same thing could be said of any build system unless you run it yourself and invest a lot of effort in locking it down. Then you have to worry a out what is running in your build system... at some point, this all becomes paranoia.
To some extent I agree, but I see a major difference in whether you have the ability to control it or not.

With GitHub actions, you have to trust the platform or migrate away, there are no other options.

With many more open alternatives, you have the ability to control these. factors if you need or want to. Most likely you wont.