Shifting from a full time tech employee to a small business owner has been a mindset shift. I've had to get very acquainted with negotiation, sales, business law, IP issues, what rights I have, and much more.
One of the biggest realizations I've had is how little programmers I knew in my full time career have done to protect their rights. It's quite baffling, actually. I say this in the context of knowing many companies, especially in the game industry, could be much better places to work.
I heard over and over passive statements like "The game industry really should have more unions!" or "Our management is so poorly run" when problems came up, while all kinds of actions individuals can take go undone, while a poor culture is actively supported. Maybe before we complain about management or lack of unions-- both extremely valid concerns-- we should look inward, and make sure we're doing everything we can too.
Disclaimer: See a lawyer before taking any action. This advice is probably pretty US-centric, and software-developer-centric. This is just advice I've learned, a mix of from personal experience and speaking with my lawyers.
1. Editing contracts is not a big deal, and you should feel free to do it all the time.
When you see a clause you don't like, politely cross it out, replace it with something you do like, and send it back. It's not a big deal. Lawyers deal with this all the time, and it's in everyone's best interest to minimize friction in the process so your changes have a good chance of being accepted.
Because I'm good at negotiation, my friends have sent me many, many software contracts to review. And it is astounding how many downright illegal clauses companies try to get away with, just because they know most people won't notice or complain.
2. Companies can't own all your work.
Look at a three part test: 1) on company property 2) on company time 3) in that company's specific field. All three must be true. And the third may be more narrow than you think. I heard of a case where a UI designer was allowed to continue making UI designs that he owned, on company property and time, because they were not specifically related enough to the work he did for the company.
An addendum to this-- don't sign non-compete clauses that control who you can do work for in the future. They don't have to be in contracts, and I've seen many companies that don't include them. At the least, be very careful of their wording, time limits, and conditions.
3. Don't let companies control your speech.
And if this is true, companies should not be able to restrict your speech as much as I've seen some try to. Don't sign non-disparagement clauses, ever-- those are terrible and illegal. And make sure you can still blog, write, speak, etc. on your own time, freely.
4. Uncompensated overtime should not be allowed.
This is one I don't have lots of legal experience in, but I know it well from a culture perspective.
My favorite analogy that works with a lot of overtime scenarios is the angry customer at the bar, and you're the bartender. He wants his drink and he wants it now. If you apologize to him profusely, he's very likely to scream louder. If you firmly say he's in line but there are several drinks ahead of his, so he needs to wait-- he's more likely to calm down.
We wish our managers could do this people relations work for us, but often in a bad culture that work is left up to us. Whenever possible, stand your ground. Tell the angry customer (your company) that you are prioritizing their work, but it'll have to wait. Really think about how necessary your fear is-- it's difficult to find developers especially, and probably unlikely you'll be fired. In fact, standing up for yourself can make you less likely to get fired-- you won't just follow through on promises better, but you'll also look more confident in your ability and capable.
But more than anything-- talk about it. Talk about mental health issues surrounding working too much. Be open with your coworkers, with other developers.
This is worth investigating from a legal angle. I know cases have been brought against companies related to this, and companies have backed down when challenged. I wish I had done this when it was an active problem for me.
5) Protect your work.
For closed source work, why need patents-- isn't it illegal to steal someone's work? Well, often it is, even without a patent. But what about the case of reverse engineering software? Patents are the best way to make sure you are protected, especially against larger companies.
With patents, it typically takes 2 years to process the paperwork, and you can't make any changes to the paperwork during those two years. For that reason, provisional patents are a great option-- a provisional patent allows you to make changes to your patent for up to a year before officially submitting.
A pending patent isn't as protective as an approved patent, but having one submitted "first in line" is a strong protective case.
Keep in mind that if you are patenting your work, be wary of invitations to read other patented work or code related to yours. If you are infringing on a patent, you'll have to pay either way if you lose the battle, but if you are "knowingly infringing," expect over three times the damages. You don't want that.
Why use NDAs? NDAs help provide evidence that your code is a "trade secret," and give you extra ammo if someone comes after you. Trade secrets are something you inherently have, but only if you take measures to keep the information secret. Be wary of the NDA's you sign, too-- make sure they are reasonably worded, and don't have any nasty extra clauses added.
For free and open source work, copyrights should be good enough.
A business adds another layer of protection. If the code is owned by a business and someone comes after you, they can only seize the business' assets. Your personal assets are more protected this way.
For employee contracts, you should legally be able to work on your own code, but an extra protection can be listing that code specifically in your employee contract and something the employer can not attack you over or own.
6) Don't be afraid to challenge companies.
"You would be surprised how many scary issues go away with a simple letter from us saying that we don't think this is legal," a lawyer told me. Do what you need to do to protect yourself, but don't shy too much away from bringing up these issues and making your workplace a better place to be at.
We have a perhaps surprising amount of power as developers. Use it.