익명 08:06

How to handle clause claiming developments "relating to the business of the comp...

How to handle clause claiming developments "relating to the business of the company" in a large company?

I'm looking at an employment contract that wants me to assign any "development" that "relates to the business of the Company or any of the products or services being developed, manufactured or sold by the Company". This is in California, and I think this language pretty much matches the ceiling provided by law.

HOWEVER, it's a big company and I don't know then entire list of products and services "being developed, manufactured or sold by the Company", so my instinct is to ask for a narrower definition. I'm a programmer, and it's easy to imagine writing some code that "relates to the business" etc.

The question: how to handle a company that really wants me to sign their broad, boilerplate, IP assignment.

[EDIT] Long story short, the company was willing to negotiate, but just barely. I got a lawyer and that helped.



Top Answer/Comment:

It is worth checking with a lawyer. There is no way that you can know if they have some other group developing something that matches a side project that you are working on.

I would assume that it is very unlikely that this would ever become a problem, but that is what lawyers are for.

UPDATE:

To avoid dealbreakers and being adversarial, because that doesn't help you get/keep the job, list a number of boring sounding side projects. Make it a mix of "Grocery list" and open source.

Update #2: Risk Adverse" is what we are not explicitly stating. The company and the recruiter are expected to be risk adverse. When people are discussing something that they have no knowledge, they will go with boilerplate CYA. They would be fools not to.

On our side, we need to keep it "less trouble than it is worth" for them to the company / recruiter to say ok with the submitted list. The minute they have to do homework about the items on the list, they will wonder if they should consider other candidates. There is no reason for it to be a deal-breaker. Put it as "why would you want a dev that doesn't do open source, etc. Do you want just code-monkeys?". Keep it simple and remove the risk for people that don't know what you are saying.

상단 광고의 [X] 버튼을 누르면 내용이 보입니다