Contracts · Employment law

Are their alternatives to "Company Ownership of Developments" restrictive employment agreements?

Brian Costello Strategy, Product Development, Digital & Investment Professional

February 25th, 2015

In many employment agreements with developers, language such as "Company Ownership of Developments" is placed in.  Most of this language grants the employer any and all ownership to whatever the developer is doing.  These tend to be very restrictive and cause consternation among developers that are very active with projects in their "off hours."  As an entrepreneur, investor and executive I'd prefer to support developers in their curiosity by not forcing them to sign documents that make them feel they are giving it all up .  I'd prefer very active developers that are excited about our products but are also creative and building things in their free time as well -- I want to support that creativity.  

Has anyone seen alternative more developer friendly language that allows developers to keep what they do externally while still making sure that any internal "inventions" are company owned?

Art Yerkes Computer Software Professional

February 25th, 2015

I commend you for taking this kind of attitude toward your engineers.  This might not help, but I'll try to describe my mindset when thinking about these issues from the perspective of an employee.

In my employments, I've seen a pretty wide range of these clauses, from kitchen sink style ones that claim "all works in the field of employment for the duration of this agreement" to forms where you can name specifically excluded projects to very informal agreements like "we own what's on our laptop". 

Although I can't offer advice on the legal language, informally, my opinion is it doesn't have to get deeper than this:

1) Code derived from company code or that interacts with company products in a deep way belongs to the company.
2) I don't work on my code on a work laptop.
3) I don't expect to own what pops out if I take work home.
4) I don't consider working on open source software the company consumes or might consume to be taking work home.

Derek Bereit Startup founder || python neophyte, NY attorney, veteran || general counsel Nimbo || co-founder Symptomly | Techstars

February 25th, 2015

[not legal advice -- just observations of contract language I have seen]

(1) Firstly, in my experience, Investors and potential acquirers will require IP ownership/assignment, and will be one of their top concerns in diligence.

(2) However, I have seen most agreements have a carve-out, language like:

(i)The term Inventions shall not include anything that I develop (i) entirely on my own time (ii) without use of Company assets and (iii) that does not relate to methods, computer programs, designs, products, (etc) used or under consideration or development by Company.

(3) California requires its own carve-out language similar to the above. [check out Section 2870 of the California Labor Code]. I found this in the Orrick (Law Firm) Startup Forms publicly available to startup community (great free resource).

Rob G

February 25th, 2015

Derek is right;  as an entrepreneur and investor you and your investors and your acquirers want to be sure you have air-tight (as is plausible) IP assignment.  I've worked for plenty of tech companies with draconian employment agreements that still have carve-out language that excludes IP you invent on your own time and have room to identify projects you are currently working on or have built in the past that can be listed and explicitly excluded from the IP assignment provisions.  

Karl Schulmeisters Founder ExStreamVR

February 26th, 2015

On source that the company uses....sorry that is too close to home.  there is then a risk of overlapping IP the safer thing is to identify that anything related to the explicit IP of the company then have joint IP

Jake Carlson Software Development Manager at Oracle

February 26th, 2015

This is an issue near and dear to my heart. Any experienced engineer should have a wealth of preferred ways of solving common problems. It is absolutely unreasonable to expect someone to reinvent the wheel, and it's absolutely unreasonable to expect someone who has invented the wheel to reinvent it again to satisfy some kind of clueless legal agreement.

This is why I am a fan of non-compete clauses over strict IP assignment. For example, let's say that while I am working on a social networking application, I create a very clever way of performing searches. When I move on to the next project, is it reasonable (or even possible) for me to 'forget' my idea if it applies to the next situation? No. It is, however, perfectly reasonable for me to avoid applying the same code or concept to a competitor of the original entity the code was written for.

Most code involves solving common problems. The 'secret sauce' business logic that makes software unique to a specific application should be protected from competitors. That's fine and to be expected. But code is not the product; code is a manifestation of an idea. Rearranging code slightly is still using the idea.

I once lost a large sale because of this issue. I had a framework for which I owned the IP. I offered the client a royalty-free, perpetual, transferrable license to any code I had previously written which I incorporated into the work I did for them. They insisted all code must be written from scratch -- and the technical advisor was leading the charge on this. He insisted that I could just 'write it a little differently'. What a load of crap. If you have a piece of code that solves a problem well, what is this nonsense of rewriting it a different way to satisfy a legal loophole of full IP assignment to the client? 

I even offered to open-source my code so that IP assignment would not be an issue, and they still did not relent. They wanted everything written from scratch. The idea of doing so not only bores me to tears, but it is also flat out ridiculous. Where does it end? Your code runs on an operating system. The operating system uses hundreds of packages, most of which are open-source. 

You cannot own all the IP that your code depends on. And you cannot own all the ideas that went into your software. You can try to own the manifestation of those ideas and you can protect yourself from engineers selling secrets to competitors, but not much beyond that. Any engineer that agrees to not use an idea he/she had before applying it to your project, or agrees to never use an idea he/she had while working on your project in the future -- is either a terrible engineer or a liar. You don't want to work with either.