Saturday, September 17, 2011

What is my client's/employer's IP?

This topic has boiled up recently on Ayende's blog here and here relating to providing samples from pet projects. Several people have commented on how some contracts are laid out to state that any work an employee does, whether at work or at home is automatically the IP of the company.

Disclaimer: I am not a lawyer. This subject has intrigued me over the years and I have studied what information I could find applicable to Canada and Australia on the subject.

The answer to this question depends entirely on the country and/or state/province the contract was formed. Generally, any unresolvable IP dispute between employer and employee/ex-employee will need to be brought up in court because there are a large number of factors to consider beyond terms in the original contract. Generally, most edge-cases would rarely ever see a courtroom unless there was a clear breach of proprietary code (such as making similar code available to competitors or a developer choosing to become a competitor) or other breaches of contract. (Such as employees that try to keep the cream of their work to themselves, and deliver crap to their employer or try to extort employers for more money for "better" solutions they claim to have developed on their own time.)

Things that a court will factor in: The history of the development of the IP. Specific terms within the contract relating to IP. The seniority or responsibilities of the employee. How the IP relates to the core business of the employer.

 A sticky point between employees and employers is often the contract. I've often seen IP ownership clauses that state something as broad as "all IP created by the employee during the course of employment is unconditionally transferred to the employer." This is a very broad statement that can be interpreted a number of ways. (Hence the need to involve lawyers & case history) "during the course of employment" could be considered to mean "during work hours", or it could be considered to mean "from the moment you sign the contract until the contract ends." The best course of action an employee can take is to *not* sign such a contract until the terms are clarified and the clause is amended. In my experience I have seen broad clauses like this in most contracts I have been presented. As someone that works on a number of side projects this is the first section I look at when presented with a new contract. Usually the client has no problems clarifying the contract as the clause is a common part of the contract boilerplate that their lawyer provides. Own its own, a clause like this is generally unenforceable as a court will likely decide that the role of the employee, and the compensation awarded to the employee, form a restraint of trade on the employee.

Two hypothetical scenarios to consider these factors:
A junior software employee signs on with a company, and gets delegated minor tasks such as commenting code, testing, and some trivial work in a .Net shop. He have an interest in learning technologies  such as ASP.Net MVC and developing websites on their own and while tinkering on their own time and development license, come up with an interesting website/service that he hosts himself. If his contract had such a general IP ownership and their employer attempted to seize the copyright / IP for that website it would likely be defeated in court. The employee's level of responsibility and the distinct difference in function between what the employee contributes in the course of employment would show that the employer would have no grounds to claim the IP. An employer cannot claim copyright over a fiction book you write on your own time, or that wicked recipe for Chili Con Carne. They cannot claim IP you work on that is unrelated to the type of work and technologies they employ you for.

A senior software employee signs on to work with a company building a workflow engine and designer interface for the company's line of products. After a couple years of working on the system he decides that he can build a better workflow engine and/or designer himself and sets out to write one on from scratch on his own time and resources. Under a similar IP agreement an employer challenge to the IP would likely be upheld in court. The employee has applied intellectual property in the form of design and implementation that was created or learned in the course of their employment into a product that directly falls in line with their employer's line of work. Another similar example which would likely fall under the same sort of principles would be if an employer chose to scrap a project and an employee decided it still had merit and began developing it on their own.


But the contract alone is not the only consideration. The history of the IP is considered, as in who came up with the idea and when. How much of the idea was developed at work or using company resources. (Technically this can include discussing the IP with other employees.) Generally it is a good idea to keep a log of when you are working on IP and avoid involving any company equipment / software licenses, or discussing the project features with other employees during work hours. Using company equipment or doing work on the IP during paid company hours is a strong determining factor into IP settlements in the company's favour. However, in cases where the contract does not state the company is entitled to IP of employees, this often doesn't automatically grant IP to the employer.

Cases where a contract is quite explicit that creations outside of work hours are considered the IP of the company would be enforceable in court. However, the other mitigating considerations would still apply, and these would generally be reserved for very high-level roles such as application architects. Companies attempting to use conditions such as these on relatively low responsibility and low paying jobs can find these contract clauses unenforceable.

What about scenarios where your contract allows you to keep IP on stuff you do on your own time, and you come up with something that would be of use to the company? This would be a scenario where you need to tread carefully. If the project is something not directly related to the work you are doing (such as a timesheet tracker, or maybe a simple queuing system for the integration environment, etc.) then the best thing to do before utilizing it at work is requesting permission and granting a license to the company to use your product. (whether you grant it for free, or they agree to a price.) This way it is clearly defined that they have no entitlement to the IP. You're better off not attempting to build something related to the business on your own time without prior explicit written permission from the company that you can spend your own time on a given complimentary application. (I.e. an add-on, diagnostic tool, etc.)

Regarding specifically to some of the comments on Ayende's blog around people that don't have time or energy outside of work, but do build plenty of spikes and such while at work. These generally always fall under company IP and the availability of using this code for your own benefit will depend entirely on your employer. Many employers will grant you permission to use spike code for your own work or to submit on something like CodeProject if you ask, as long as it's not business-specific. If you do intend to use such code as samples for securing a new contract or role with another company, then it would be a good idea to think ahead and obtain permission for interesting bits as they come up, not the week you're expecting to be going in for interviews. :) Resources like CodeProject are fantastic for this sort of thing because it gives you a valid, innocent reason to ask to use the code, and you can point potential employers at your CodeProject profile for examples of your work. (Which is kudos if you can get some complimentary comments associated with it.)

No comments:

Post a Comment