Alternatively, you're a project manager at a successful corporation. Next thing you know, two of your top engineers quit to form a new company. Their new project looks suspiciously familiar, however. In fact, you think they may have adapted the idea from work they completed under your direction. Can you claim their new project as company property before they gain significant market share?
Issues like these often arise in the context of software development. While every situation is unique and requires careful consideration, a review of the basic, background law will help you—either as a startup or an existing corporation—flag these issues as they arise.
THE BASIC LAW
In the U.S., federal copyright law protects both the software code itself and, in some circumstances, the nonliteral elements of the code (the structure, sequence, and organization). The copyright is generally owned by the author of the work, unless the work is a "work for hire." This article assumes that U.S. law applies. The laws of other countries may vary, but the below discussion may still be useful.
A "work for hire" (also referred to as a "work made for hire" or "WFH") is a work made by an employee within the scope of his or her employment. If you are considered an "employee" and your work was "within the scope of your employment," your company owns your work—not you.
It should be no surprise that the main points of dispute are over (1) who can be considered an "employee" and (2) what types of activities are considered "within the scope of your employment."
FOUR POINTS v. BOHNERT – A RECENT CASE
A U.S. federal court in Missouri is dealing with a software ownership dispute in a case filed by Four Points Communications against its former vice president, Bryan Bohnert. Four Points designs and installs military communication systems. While working for Four Points, Bohnert developed a piece of software, SSAM, that digitizes forms, including the survey forms used by Four Points.
Bohnert claims he developed the SSAM software in his own time, using his own money. But Four Points argued that the software was created within the scope of his employment with Four Points using company resources. The case ended up in litigation over who owns the software. Recently, the judge hearing the case ruled that there was enough evidence on both sides of the ownership issue so that the case would have to be decided at trial. Filings in the court indicate that the parties may have reached an undisclosed settlement on the eve of the scheduled trial. Regardless, the case provides guidance for both employees and employers on how to handle intellectual property ownership issues so that protracted and costly litigation does not ensue.
ISSUES AND PRACTICAL CONSIDERATIONS
1. Who is an employee / independent contractor?
The relationship between a corporation and its employees is often quite clear. There will generally be an employment agreement that defines Johnny Engineer as an employee. In cases concerning employees, the argument typically centers around the "scope of the employment," which is discussed below. Even if there is no employment agreement, a work can still be a work for hire if you are not officially an employee, but you are treated as one. This is a fact-specific inquiry.
In cases involving independent contractors, an employer cannot claim that it is the owner of the copyright unless there is a written agreement saying that it owns the work. If an independent contractor is doing freelance work, there is typically a development agreement that will include some boilerplate language that makes the deliverable a "work for hire." Examine this language, because it may also make future modified versions of the deliverable ("derivative works") a "work for hire." If base code is used to create the work, parts of the base code could be signed away to the employer. Both sides should make sure the statement of work (SOW) is carefully drafted to clearly define the scope of the project and how created works will be owned.
It is important for both sides—the employer and the employee/contractor—to clearly define their relationship at the outset. This leaves less room for debate over the employee's or contractor's employment status.
2. Scope of employment
Once the employment relationship is determined, attention turns to whether the work was performed "within the scope" of employment. The three main considerations are: (a) was the work the kind that you were employed to perform, (b) did the work occur within the time and space limits of your job, and (c) was the work done at least in part to serve your employer. These considerations are discussed below.
3. What does the agreement say?
The employment agreement is a key document that defines what work an employee is supposed to be doing while at work.
In the Four Points case, Bohnert was not a software developer or engineer. Instead, he was the vice president of business development. Bohnert claimed that development of software programming was not part of his job description, but Four Points countered that his job included developing new business ideas and doing any tasks assigned to him. The description of Bohnert's job in his employment agreement was so vague that it did not provide a definitive answer.
Again, both sides should make sure the scope of employment and/or statement of work (SOW) are carefully drafted to clearly define job duties. If the stated job duties are clearly defined, there is less likely to be a dispute.
Engineers and programmers should make sure their jobs are sufficiently described so that there is not an overlap with any side projects that they have already started. Employers should make sure to define the job such that if there are any side projects, they will be company owned or far enough away from the company's core business such that they are not assisting their next competitor.
4. Was any work done during work hours or in work space?
This point is fairly obvious. While not determinative on the issue of whether a work was done "within the scope of employment," work done at work or using work property could become the property of the employer. Even if you are working in bed on your personal laptop at 2AM, that work is more likely to be viewed as being within the scope of your employment if it is related to your job duties.
Here's a (perhaps) less obvious point. For those looking to draw a line between a side project and their day job: keep a record. Save receipts and keep track of your hours. Just as importantly, do not use your company email address and resist the temptation to put some extra time in during your lunch hour. If your company wants a piece of your idea, they will be trawling through electronic evidence to try to establish that you used company resources. In the Four Points case, Bohnert hired an outside developer directly, he purchased separate equipment (computers, iPads, FileMaker Pro), and refused to talk SSAM business with potential customers during work hours.
Again, while this is not determinative on the issue, it is a relevant factor. Companies should monitor their employees for suspicious activity, and employees should be respectful of their commitment to their current employer.
5. How similar is the side project to the work duties?
The closer a side project is to a day job, the more likely it will be considered a work for hire. In the Four Points case, part of Bohnert's job was developing paper survey forms. SSAM was basically a digital version of a pen-and-paper system that Bohnert put in place at the company. This similarity allowed Four Points to argue that the software was an extension of Bohnert's other projects.
Employees looking to go on their own should consider whether their side project truly overlaps with their work duties. Before getting pie-in-the-sky dreams, an idea that is related to your work duties is probably best left as a "non-starter," or should instead be presented and used at work to boost your reputation within the office. After all, going it alone can be risky. The idea of impressing the higher-ups without risking your 401(k) doesn't sound so bad after all.
6. Has the new, side project been shared with the employer?
When defining job duties, courts consider whether a particular work was done to serve an employer. However, keep in mind that the work does not have to exclusively serve the employer, it just has to serve the employer in part.
In the Four Points case, Bohnert allowed Four Points to use SSAM for what he described as beta testing. This allowed Four Points to argue that SSAM was developed to serve Four Points. Bohnert argued that SSAM was actually used by other companies in completely different fields. However, the fact that it was used as a survey tool by Four Points strengthens Four Points' case that it was created as part of Bohnert's employment.
CONCLUSION—AVOID A MESS BY BEING PROACTIVE
While Four Points case was (likely) settled out of court, it still provides valuable lessons. If you don't define the relationship, you risk a few years of costly litigation. So be proactive. And if you see a software ownership issue brewing, protect yourself before matters worsen. This article is being written by two lawyers, so it should be no surprise that the final tip is to call an attorney. As each situation is unique and fact-specific, the very best way to protect your rights before they are violated (or to get compensation after they are violated) is to speak to an experienced and knowledgeable lawyer.
Brian Brown and Tim Murphy are intellectual property attorneys with the law firm of Carlson, Gaskey & Olds, P.C. The firm specializes in all areas of intellectual property law, and is located in Birmingham, MI. Brian is a trial lawyer practicing in a variety of intellectual property and commercial fields. Tim is a registered patent attorney who focuses his practice on the preparation and prosecution of patent applications in various areas including mechanical, electro-mechanical, and aerospace technologies.
The judge's decision in its entirety can be viewed here: http://www.scribd.com/doc/238679701/Four-Points-Communicaitons-Svcs-v-Bohnert-SSAM-Software-Copyright