4 ms·

I admire the poster's idealism, but the advice is poor and the title is pure linkbait. The problem is this: it is difficult bordering on impossible to get a co

I admire the poster's idealism, but the advice is poor and the title is pure linkbait. The problem is this: it is difficult bordering on impossible to get a company funded or acquired without IP assignment in place. It's the first check in due diligence. That means you'd be a fool to work at a company like the one the poster describes, since it is clearly run by amateurs and has grave, self-inflicted problems in its future. There are always exceptions - maybe an idealistic consulting firm could pull this off - but this is very dangerous stuff. If you're dubious, ask your favorite startup attorney what the #1 killer in due diligence is - it's nearly always IP assignment. Someone wrote some code without having it in place, and you have to either excise the contribution (not always possible) or try to buy the IP retroactively - and since the entire company is likely on the line, you won't be paying market rates. It's more like extortion at that point than a purchase. Long story short: if you're not assigning your IP, then you're not working for the company; you're working at the company. Don't try this one at home.

psykotic 15y ago
I think you're misreading him. He's not saying the company shouldn't own inventions developed by the employee for the company on company time. He's talking about the all-encompassing agreements that make employees sign over all rights to anything conceived by them in their professional field for the duration of their employment.
netaustin 15y ago
As the owner of [what I believe to be] an idealistic consulting firm, I tend to agree with both the rule and the exception. IP ownership isn't really a good business practice for us because it comes with its own liabilities and could put us at odds with our clients. Our rule for our devs is that if you develop it for a client, it belongs to a client. If you develop it to serve a process we use for multiple clients, it belongs to us. If you develop it in your spare time, it's all yours.
ghshephard 15y ago
In reality, reasonable companies and people can come to an agreement regardless of what the template language in the employment contract states. I had a network engineer write some clever code that allowed us to write our firewall filtering in either OpenBSD PF or Cisco ASA format, and convert it back and forth seamlessly. It had absolutely nothing to do with what our company did, and he wanted to publish his work publicly so I simply asked our CTO if we could Open Source it - he had no problem with it as long as it didn't mention our company name anywhere. In general, reasonable people usually come to an agreement despite employment contract language, and if people aren't reasonable, no contract language will make it a good place to work.

psykotic 15y ago

I think you're misreading him. He's not saying the company shouldn't own inventions developed by the employee for the company on company time. He's talking about the all-encompassing agreements that make employees sign over all rights to anything conceived by them in their professional field for the duration of their employment.

netaustin 15y ago

As the owner of [what I believe to be] an idealistic consulting firm, I tend to agree with both the rule and the exception. IP ownership isn't really a good business practice for us because it comes with its own liabilities and could put us at odds with our clients. Our rule for our devs is that if you develop it for a client, it belongs to a client. If you develop it to serve a process we use for multiple clients, it belongs to us. If you develop it in your spare time, it's all yours.

ghshephard 15y ago

In reality, reasonable companies and people can come to an agreement regardless of what the template language in the employment contract states. I had a network engineer write some clever code that allowed us to write our firewall filtering in either OpenBSD PF or Cisco ASA format, and convert it back and forth seamlessly. It had absolutely nothing to do with what our company did, and he wanted to publish his work publicly so I simply asked our CTO if we could Open Source it - he had no problem with it as long as it didn't mention our company name anywhere. In general, reasonable people usually come to an agreement despite employment contract language, and if people aren't reasonable, no contract language will make it a good place to work.