alt Hacker News> While I wholeheartedly agree this as a general concept, I find it tricky to accomplish in practice.
The problems you are describing are not actually "problems in practice", as you say. They are theoretical problems.
In practice: You can just do stuff. There is no subroutine on your computer stopping the git push. In practice: Employers just write stuff in their employement contracts. They'll write everything they possibly can, to cover asses in every possible direction. If they're allowed to just write stuff, why aren't you allowed to just do stuff? Nothing matters. In practice: Roughly zero open source projects have had their IP challenged because of this technicality.
Replies
You might be comfortable taking that risk yourself, but if you misrepresent your FOSS contributions as your own copyright you impose that risk on third parties. Tricking people into infringing your employer's copyright is asshole behavior.
when you commit code to a project you are warranting that you have the legal right to do so. the bigger projects will not even accept your contribution done at work without an explicit permission from your employer.
this is not just about you and your risk, but also about the risk for the project.
Have you heard of DCO (Developer Certificate of Origin)?
The rub is if you make something really cool or valuable, your employer may find out about it and want it, and the precautions are to protect yourself and your project. Doing it "on company time", if provable, puts you at a disadvantage.
Parties involved have to decide on their acceptable level of risk, right?