|
|
|
|
|
|
by Hobadee
392 days ago
|
|
|
Since you already work as an automation engineer, it might be a bit harder since programming is probably part of your job, but this is what I did at a previous company:
I wrote up a contract basically saying that since programming large programs was outside the scope of my normal work, any such programs I wrote would not be considered "works for hire" (a legal term in the US) and not property of the company, but instead my own property that I could sell elsewhere if I wanted. I was specifically allowed to use company resources to develop the software (including reasonable time my manager signed off on) and in return the company would get a non-exclusive perpetual right to use and modify the software as they saw fit. This contract was a win-win. My company got the features they wanted as part of my normal employment, but I also got to keep the idea and monetize it outside the company if I wanted to. The company didn't need to worry about licensing if I left since I granted a perpetual right to use/modify. Unfortunately for various reasons the project never got completed and I never monotized it, so I can't tell you the real-world outcome, but I do know we were all happy with the terms going into it. |
|
|
It can definitely be a win/win for the company as well as for an enterprising engineer. The general idea is simply to go outside the scope of your contract and do something the company didn't ask for, in exchange for a bit of money and the right to reuse whatever code you developed for them.
Avoiding works for hire contracts is how I built a 25 year war chest of reusable components and frameworks, each piece commissioned to an individual task but each used and modified in my next jobs for my next clients, until many versions later I would update my original clients with them.
My advice to OP is to always present your ideas to owners or managers with open ears, and explain how it will help the company. Secondly, never do the work for free. Thirdly, always retain your rights to your ideas and your code when you're working on something creative. If they have a problem with that you can also explain that it's unlikely anyone else will either fill this niche to save them money or that any competitor will ever actually know about or use what you will build for them, but that having it at your disposal is a way for you to continue increasing their efficiency (which is true). It's also a way to make them beholden to you at very little initial cost.