⚠️ Caveats and legal disclaimers
I am not a lawyer
I am not a lawyer and this site is not legal advice. It is a political and ethical argument; not advice about your contract, your employer, your immigration status, your licence obligations or your specific situation. If your stakes are high, talk to someone qualified before acting.
As per almost all open source licences: no warranties are provided. This is supplied “as is”, without warranty of any kind, express or implied. If you lose your job: it is not my fault, but please let me know so I can publicly shame your employer here!
Contracts, policies and ownership
Employment contracts, handbook policies and invention assignment clauses can claim work created during employment, on employer equipment or within assigned duties. Some states limit those claims for work done on personal time and equipment, but the details matter.
Read your employment contract before doing this. Make sure your employer does not own the open source IP you intend to publish. If the machine, network or account changes ownership risk, use your own.
Negotiate your IP agreement
IP assignment is often negotiable. When you accept a job offer, ask for an open source carve-out in writing before you sign; read your employee IP agreement first so you know what to push back on. I have negotiated contract changes away from the standard at almost every employer I have worked for; most pushed back far less than you’d expect.
Point your prospective employer at GitHub’s Balanced Employee IP Agreement , it is open sourced under CC0, already used in production by a large public company and designed so the employer keeps what it pays for while the employee keeps the open source work that does not compete with the business. Ask for the same, or for the relevant clauses, by name.
Confidentiality and security
Do not disclose private repositories, credentials, incidents, customer data, roadmaps, unreleased vulnerabilities or internal discussions. Do not use access you would not otherwise be allowed to use. Do not route around security controls.
Direct action is not an excuse for making private company information public. It is a reason to keep public work public and clearly separate from commercial secrets.
Quiet does not mean careless
Undisclosed does not mean reckless. Use your own judgement when a policy, contract, client obligation or safety rule changes the risk. You may need to do this work on your own machines, accounts and networks. The point is not to “steal” from work. The point is to balance what your work takes from open source with what you can give to it.
You may get worse performance reviews than co-workers who spend every visible hour feeding the company machine. This is fine! A sustainable B grade is healthier than burning your life for an A grade at a company that can still fire you tomorrow and claim AI has replaced you.
Honesty about the limits
This argument is weakest where your time is billed to a specific client, grant, government body, defence project or regulated environment. It is weakest for junior or precarious engineers without the leverage to absorb the downside. It is strongest for senior maintainers fixing the public dependencies their employers already use.
The cleanest version is not “do whatever you want during work hours”. It is “treat maintenance of open source as part of engineering work”. Maintain projects you already maintain. Improve shared tools your job touches. Skip anything unrelated, anything proprietary and anything that would make you miss a real commitment.