> If they did allow that, and retained no control over the forked copy, now you can ride a coach and horses through the access control to a private repo by simply forking it when you have access.
...which you can still trivially do if you use git to make the copy. And then your github repo will be immune to this kind of deletion.
So common sense says to me this should act similarly.
> ...which you can still trivially do if you use git to make the copy.
If you want to steal code from your former employer it's your business and your legal jeopardy. GitHub can't do anything about that. They can remove access to the copies they're storing for you, though.
GitHub has a weird model where they encourage using the same account for personal and professional work, which causes this kind of ambiguity. From their perspective, there isn't a real difference between forking a private repo and making a private copy of a shared Google doc in your work account.
It's not about wanting to steal anything. It's that making a copy is trivial, so there's no point in worrying about how you can "you can ride a coach and horses through the access control".
Don't worry about the barn door when there is no side on the barn.
My point is that GitHub does not personally want to have a hand on the reins, or whatever metaphor we're doing here. A private fork is a copy of the original code that GitHub is holding onto. A clone on your personal computer or server or printed out on paper tape is a copy that you are holding on to.
...which you can still trivially do if you use git to make the copy. And then your github repo will be immune to this kind of deletion.
So common sense says to me this should act similarly.