Developing Programmers .com

Local Search:



This site is optimized for standards so you can use any standards compliant browser:

Valid XHTML 1.0 Transitional
Valid CSS!
(RSS) RSS Feed

Web Search:
Google


Thursday, 19 January, 2006

Employment Contracts: What Did I Just Sign?  

Jamie Wodetzki is a technology lawyer. Most of his career has been as a technology / copyright lawyer; and now he works on a software company he started, Exari Systems (previously SpeedLegal). Exari Systems is a Java house which writes their own proprietary document assembly software, uses and contributes to some open source tools, and even hosts an open source Java based XML editor project (Xerlin).

As Jamie happens to be part of the family, I had the opportunity to ask him some questions over breakfast. The meal is significant because Jamie also happens to run a popular Breakfast Blog and said the eggs Benedict at the café were “definitely well above average,” which is impressive given his standards for a good breakfast.

I asked Jamie about two different topics:

  • Mixing open source and proprietary software licenses.

  • Two particularly scary clauses that seem to be typical in employment contracts.

This article is about the worrisome clauses in employment contracts.

I asked Jamie about the clause that says you can’t use what you have learnt in this job in your next job. One friend is concerned that because he works in a specialized area of the software industry he will be unable to work in that area again if he leaves his current employer.

Jamie said:

Using knowledge from a previous job is generally fine: skills like languages, tools and widely known technologies like XML are not really trade secrets, but sections of code and specific algorithms can be. What most employers are most keen to protect is any valuable copyright and trade secrets. There’s not much point stopping people from using knowledge and skills that are widely available in the market.

Saying you can’t work in the same part of the industry again? This issue is about what’s known as “restraint”. It is common for employment contracts to have a period of restraint. These absolutely have to time out or they won’t stand up. The legal position is that restraints have to be “reasonable.” Forever isn’t often considered reasonable. Restraints should be limited, usually in time, geography and market.

For employers, the main purpose of restraint clauses is to stop previous employees from stealing their customers or from running off to work for one of their competitors. This is where your friend’s problem comes in.

It is possible to limit him working in that area of industry for a while. But it will be much harder for an employer to stop someone working for a different kind of company that doesn’t compete. To pass the “reasonable” test, a restraint should only say that he can’t work for a direct competitor or a potential competitor for some limited period of time (maybe 12 months).

In America these restraints are very common and are very commonly challenged. The most famous recent example was Google poaching Dr Kai-Fu Lee from Microsoft to set up its China business. The courts initially decided that Google could employ him, but there was a temporary restraining order preventing Dr Lee from working in any area that was competitive with Microsoft, which had a 12 month restraint or non-compete clause in its contract with Lee. The case was eventually settled, although not before many heated exchanges between everyone involved.

So, even if a restraint clause sounds impressive (or scary, depending on your point of view), the full extent of it generally won’t be enforceable. In most cases anything over a year is difficult to enforce, but there’s no hard and fast rule.

I also asked Jamie about the clause that says any software or patentable idea you produce while employed is owned by your employer.

Some of my friends are worried about this because they contribute to (or have started) open source projects, others because they do a little business on the side.

Jamie:

A typical contract should say that anything created in the course of your work is owned by the company. Even if the contract is silent on this, by default, your work as an employee is owned by the company, but what you do in your free time is yours.

The problem is that most contracts will go further and say anything you create while an employee is owned by the company, even if you happen to do it outside of normal work hours. So most people would need to change or at least review their contract to work on a side project.

The main thing is to be up front about wanting to do your own projects and reach an understanding that clearly divides what’s for the company and what’s yours. If your “side project” happens to be competitive with your main work then you’ll have problems getting away with that.

Also, the company might want an option to commercialize side projects.

Google give their employees a day a week to do side projects. I don’t know what IP ownership is like on those side projects.

Sarah: But employers will generally have some standard contract a lawyer has given them and will be reluctant to spend money getting a lawyer to help change it.

Jamie:

Perhaps employees could encourage the employer to come up with a standard extra clause that all employees can use to allow side projects. It should make a clear distinction between the definition of work projects, side projects, and side projects that are deemed competitive.

Sarah: Perhaps it could have a place to list each side project by name.

Jamie:

That could work. A good employer should listen but there’s no way to persuade them if they won’t.

Sarah: I agree… Any programmer that really enjoys programming is never going to be happy working somewhere that doesn’t allow side projects.

Jamie:

If you want your employees happy this is a good way to do it. Happy programmers are less likely to ask for pay rises etc. This is a cost effective way to keep happy programmers who like their job. Side projects are an easy way to keep people interested. Not allowing them risks losing good programmers.

Thanks, Jamie!

Jamie works in Australia and that is where this article is most relevant. According to him, American, United Kingdom, Canadian, New Zealand and Singaporean law follows similar principles so this article is relevant in those places too. Please note that this article contains only general principles and that you can not know about law in your specific circumstances without getting personalized legal advice.

Posted by sarah at 11:09 am in: Employment , Legal (7460 views)

2 Comments

  1. Thanks Sarah and Jamie. This clarifies issues that come up in contracts for a wide range of industries - not just IT.

    Comment by Ian George — On 22-1-2006 at 9:47:19 AM

  2. Some of theses concepts apply to non-employees, as well. I do contract work and have been asked to sign documents concerning IP rights of what I develop. Generally, I am okay with assigning the rights of the work - if they pay for my time, they own the work; if they want to license a piece of software, I own the work. The problem comes when the contractee wants to affix some language to the extent that they also own “any ideas, inventions, extensions of any kind” as a result of the work that is problematic. I can share results from when I consulted a lawyer from here in the US, if you wish.

    Comment by Alan Halsey — On 16-11-2006 at 3:34:29 AM

Please use the DP Forums for further discussion of this topic.