> I don't think even Microsoft/Github actually believes this to be the case because they choose to train on public Github repos and did not include their own pr

> I don't think even Microsoft/Github actually believes this to be the case because they choose to train on public Github repos and did not include their own proprietary codebase. There are good reasons they would not include proprietary codebases aside from this, so I don't see this as a smoking gun. Large codebases often involve elements that don't make sense outside of their immediate environment. Projects the size of Linux have this same issue, but large open source projects tend to have significant cross-pollination with the broader community so it's less of an issue. For example, one large corporate codebase I worked in had a library of ~20, strangely named, short utility functions that were called from many thousands of places. People in the broader community would not find such ubiquitous use of these functions idiomatic at all, but it formed a "dialect" within the company that was often useful given that everyone knew it. These functions caused a lot of signatures/code to be structured in ways that assumed their existence - they were painful to extract when we open sourced internal things. There also tends to be a lot of business logic in corporate code (e.g., `max_space = 100 if has_excel_license else 10`) that would make zero sense in other codebases. A real example in this case... I'd bet that many millions of lines of Microsoft's internal code still use Hungarian notation. Few users would want Copilot generating such names. I could see interest in a version of Copilot that augments the standard Copilot model with your own codebase if you have millions of lines of code in your GitHub Enterprise account.