Works for Hire and the No Moonlighting Clause
If you write an app on the side, does your boss own it anyway?
by Britton Payne @brittonpayne
Developers (and coders and programmers) dream of creating the next Facebook, the next Uber, the next Spotify. But dreaming doesn’t pay the bills, so these developers probably work for someone else in the meantime. When dreaming turns into coding on nights and weekends, things start to get tricky with regards to employment agreements. Developers are a very smart class of people, and often rely on their own judgment when looking over their employment paperwork when they start a new job. Unfortunately for both employee and employer, this often leads to adversarial consequences. When the programmer wants to leave the job to work on the dream, and the legal meaning of language in a contract doesn’t line up with the developer’s understanding, both the job and the dream can go up in smoke. This problem doesn’t affect just tech companies — many large companies hire developers in one capacity or another. There are many ways an employment agreement can trip up a dreaming developer and employer, often wrapped up in the No Moonlighting and Work for Hire clauses.
“No Moonlighting” Clauses can Turn “Personal Time Developing” into Breach of Contract
With or without a traditional 9 to 5 in an office, most developers feel like they have a pretty good understanding of what their jobs are: If you do your assignments for the benefit of the company, you’re doing your job. Unfortunately, a developer’s obligations to the employer may also include the things they don’t do in addition to the things they do. Employment agreements often include limitations on what the employee can do with their non-work time — the “No Moonlighting” clause. The idea is that some jobs want you to put all of your creativity and effort into helping your employer, not someone else (including yourself). Sometimes this is limited to work related to the job, but sometimes it is for any work at all. Some sample No Moonlighting clauses that I’ve seen in my practice:
- …The Employee shall devote substantially all of his business time and attention to the performance of his duties hereunder…
- You agree that you will not engage in any other business activities or render services of a business or commercial nature on your own behalf or on behalf of any other person, corporation or any other entity, whether for compensation or otherwise, without [Company]’s prior written approval.
A narrow No Moonlighting clause might restrict you from freelance developing on your own time; a broad No Moonlighting clause might restrict you from tending bar on your own time.
As you can see, the devil is in the details, and your particular clause (if you can find it in the agreement) may not be that easy to understand without the help of an attorney. A client of mine went to quit his job to work full time on his personal time project, and an amicable employer became suddenly aggressive. His employer claimed that not only did it own his project under the Work for Hire clause, but the (now former) employee was in breach of contract under the No Moonlighting clause. Naturally he panicked. We got him through it, but he would have been much better able to manage his project, or even change his employment agreement, if he had consulted with an attorney before he signed his employment agreement.
“Work for Hire” Clauses can Easily Capture Personal Time Programming
Even without a No Moonlighting clause, most developers realize that a Work for Hire clause is standard, and that it limits their ability to own the programs and code they create for their employer. (The copyright statute uses the term “Works Made for Hire,” but it is commonly referred to as “Work for Hire.”) Developers generally understand that there is some rule about creating outside programs on work computers, or during work time or at the office or something. Unfortunately for developers, the “or something” could mean the difference between owning the intellectual property in outside work, or having to give it over to the employer. Some sample Work for Hire clauses I’ve seen in my practice:
- I hereby assign to the Company… all my right, title, and interest in and to any and all inventions, original works of authorship… which I may solely or jointly conceive or develop… during the period of time I am in the employ of the Company… except an Invention that (i) I develop outside of the Company’s normal working business hours and (ii) does not relate to the Company’s business as currently conducted, or as conducted in the future. I further acknowledge that all original works of authorship which are made by me (solely or jointly with others) within the scope of and during the period of my employment with the Company and which are protectable by copyright are “works made for hire,” as that term is defined in the United States Copyright Act.
- You acknowledge and agree that [Company] is the owner of the copyright in any work which it or you produce in connection with your employment…
- All inventions, innovations, improvements, methods, designs, drawings, characters, props, molds and all similar or related information (whether or not patentable) that relate to the Company’s or its Affiliates’ actual or planned business, research and development or existing or planned products or services and that the Employee conceived, developed, or made while an employee of, or a consultant to, the Company (collectively, the “Work Product”) … consisting of copyrightable subject matter is “work made for hire” as defined in 17 U.S.C. § 101 and such copyrights are therefore owned by the Company.
The terms of these clauses vary, as does the intellectual property they intend to capture. A more narrow clause would only capture personal time programming that is in connection with the “employment.” But a broader clause captures personal time programming that relates to the company’s “actual or planned business,” whether or not that relates to the developer’s particular job. One developer client of mine used a database program at work that he felt was inadequate. On his own time, he built a better database program for the purpose. He hoped to quit his job and have his employer become his first client. He knew he had a Work for Hire clause, but because his job did not involve making database programs, he thought his project was outside the scope of the Work for Hire clause. When the employer got wind of his plan, they disagreed, and it led to some tense and adversarial negotiations that were unfortunate for both sides. A similar case from the pre-internet era showed a court’s thinking on how broadly “scope of employment” can be construed:
Miller’s job description did not specifically state that he was to develop computer programs. Miller was not assisted by others in the development of the computer programs. Finally, Miller did not receive any type of additional compensation for the work done on his own time. However, the driving force behind the creation of the computer programs was to benefit CP by making the quality control laboratory more efficient. Furthermore, the development of the computer programs was clearly incidental to the other work performed by Miller. . . . [T]he court concludes that the development of the computer programs by Miller was within the scope of his employment.
Miller v. CP Chemicals, Inc., 808 F. Supp. 1238, 1244 (D.S.C. 1992). Neither side must have been pleased that they were stuck in a lengthy litigation.
Counseling before Signing the Employment Agreement is Good for the Employer and the Employee
Several of my pre-employment counseling clients have been referrals from the employer itself. Developers are generally very smart and quite comfortable acting independently, but employers have seen relationships with developers go bad over the intellectual property terms of their employment agreements, even when both sides initially think the terms are reasonable. Many employers of developers want to employ the kind of talented and enthusiastic developers who would build apps on their own time, and have no interest in owning or slowing down their truly outside projects. It may be better to have a special employee like that for only two years than a less motivated employee for ten. At the same time, employers (and their contract drafters) have an obligation to nurture and protect their company’s intellectual property. As friendly as an employer and a new employee may be, the employee is at a disadvantage when understanding the meaning and application of No Moonlighting and Work for Hire clauses. And there are several other standard clauses peppered throughout a developer’s employment agreement (and even the company policy documents) that might affect a developer’s ownership of personal time programming. A developer may have things they don’t want to share with a prospective employer for fear of scaring them away, which makes it even harder for the employer to help a new employee what they’re getting into. An employer can refer a potential employee to a particular attorney, as long as all parties understand that the attorney remains independent from the employer and is only an advocate for the potential employee. Counseling with an independent attorney can preemptively solve problems like that for both sides while everyone is still feeling good about each other.
Don’t Give Up Hope: The Terms are Often Just the Starting Point for Negotiations
No one wants to go to court, no matter how much bluster one side or the other might display. And it may not even be in either side’s interest to strictly enforce the No Moonlighting/Work for Hire clauses of an employment agreement. Further, overreaching or poorly written No Moonlighting restrictions or Work for Hire grabs may not be enforceable in court. When employment ends, the terms of the employment agreement may dictate strict adherence. But in practice, they often serve as simply the basis for negotiations, especially once the developer leaving the job has representation. One client of mine had created a proof of concept app that was unrelated to his assignments, but would help his employer. When he quit the job to develop it fully, the employer claimed that they owned his app. But because it was only at an early stage of development, it was practically useless without further development from the ex-employee. The sides came to a negotiated agreement involving joint ownership of the new company formed to develop the app that adequately incentivized the developer while giving the employer some benefit of the bargain set forth in the employment agreement.
Mattel, Inc. v. MGA Entm’t, Inc., 616 F.3d 904, 912–13 (9th Cir. 2010), as amended on denial of reh’g (Oct. 21, 2010) (exploring the ambiguity of the phrase “at any time during my employment”)
Advanced Tech. Servs., Inc. v. KM Docs, LLC, 330 Ga. App. 188, 196, 767 S.E.2d 821, 828 (2014), reconsideration denied (Dec. 4, 2014) (finding a developer employment agreement for personal time programming to be ambiguous)
J & K Computer Sys., Inc. v. Parrish, 642 P.2d 732 (Utah 1982) (finding that elements of computer programs are trade secrets that can be protected from use by former employees, even though a few customers had access)
Jumping Ship: Legal Issues Relating to Employee Mobility in High Technology Industries, 17 Lab. Law. 25, 106 (2001)
The Moonlighting Survival Guide
Do You Need an Employee Moonlighting Policy to Protect Your Business?