Consider this: You’re an executive at a small proprietary software firm called GoGetter Software. Your only product is GoGetter 1.0, which your employees developed over two and half years. At a trade show, you strike up a conversation with an independent software developer who has a similar product – call it “Shortcut.”
It’s not as mature as your product, but it offers some features that would make GoGetter a lot better.
You agree to hire Shortcut’s developer as a “consultant” and work together to incorporate the useful features of Shortcut into GoGetter Version 2.0. Everyone gets right to work, with your consultant acting as the project manager. As you later learn, he writes 99% of the new code himself.
Fast forward one year. GoGetter Version 2.0 is still in alpha. Progress has been slower than you would have liked. You’re ready to sign up beta customers, begin your marketing campaign and work out some of the bugs after commercial release. But your consultant is a perfectionist and wants to wait.
Against his wishes, you decide to go forward. Without warning, your consultant (apparently with hurt feelings) announces that he is no longer interested in working on the project and has accepted an offer with your main competitor.
But wait: In your haste to get the business done, you never signed an agreement clarifying your rights to the source code formerly known as Shortcut, which now is a critical part of GoGetter 2.0. In fact, it’s not clear to you how much of GoGetter 1.0 is really left in Version 2.0, and you have a feeling that Version 2.0 may include more Shortcut code than the original GoGetter code.
Your consultant tells you that his soon-to-be new employer is interested in some of the features of Shortcut. Suddenly, you’re worried that the last year spent developing the next version of your only product may be at risk, as your consultant believes he has just as much right to the code as you have.
Copyright laws should force every software developer to think carefully before collaborating with another developer to create enhancements to an existing application. Unless you plan ahead, you run the risk that your exclusive rights to develop, adapt and sell modifications to the original product are no longer so exclusive.
The problem
Your risks lie in two areas: the copyright in GoGetter 2.0 and your right to prevent the consultant from modifying 2.0 and competing against you. Your company undoubtedly owns the copyright to Version 1.0, because that version was developed solely by GoGetter employees. But your consultant’s work on GoGetter 2.0, with all its enhancements, may make him a “joint author” of the new version of the software, depending on how different the final product is from Version 1.0.Legally, joint authorship means your consultant is a full and equal co-owner of the copyright. In that case, GoGetter and the consultant own an undivided ownership interest in the software. Both parties can do with it whatever they like, and each has a right to receive a share of the profits the other earns from its sale. Importantly, neither can be barred from using or reproducing it.
Even if the consultant’s contributions were not significant enough to create joint authorship, he may still own the copyright to a “derivative work” of Version 1.0. Although derivative rights are more limited than joint authorship rights, the consultant would still own the copyright to the incremental code he authored, which embodies the bulk of the modifications that make up Version 2.0, meaning you can’t use it without his permission. (For more information about derivative works, see the section below.)
And it could be worse. If Version 2.0 is more Shortcut than GoGetter, then Version 2.0 may be considered more a derivative work of Shortcut than of GoGetter. If so, your consultant may be considered the sole author of that derivative work, and you may not have any rights to it at all.
The law of copyright
The Canada copyright act provides a set of exclusive legal rights to the owner (or “author”) of a copyrightable work (which includes software): 1) the right to reproduce the copyrighted works; 2) the right to prepare “derivative works”; 3) and the right to distribute (sell, license, etc.). This set of “exclusive” rights includes the right to block others from doing the same thing.Normally, copyright law defines the author (or owner) as the actual creator of the work. However, when a company’s employees create the copyrightable work within the scope of their employment, then the work is considered a “work made for hire.” In that case, the employer is considered the author and receives the exclusive rights to the work, while the employee has no ownership rights whatsoever.
We’ll return to the employee/employer consideration in a moment. But there’s another key question here: whether GoGetter 2.0 is a derivative work of GoGetter 1.0 or a derivative work of Shortcut.
Derivative works
Among the key rights enjoyed by an author to a copyrighted work is the exclusive right to prepare or license “derivative works” to that original work. A derivative work is a work based upon a pre-existing work. Courts have found that subsequent versions of computer software programs are, in most cases, considered derivative works of the original underlying version of the program.In many instances, the derivative work is separately copyrightable by its author. Copyrights in derivative works provide protection for the incremental additions of originality contributed by the authors of the derivative works.
So, if your consultant is not an employee, in the absence of a written agreement, the code he wrote may be deemed a derivative work to which he alone owns the copyright. If it’s a derivative work of GoGetter, then you at least own the rights to the original work and can probably keep him from competing against you (although, as noted above, you can’t use it either). But if it’s really a derivative work of Shortcut, you may not own anything.
If there is a dispute, the only way to resolve that dispute is to go to court, hire experts to examine the code and let a jury of six or 12 laypeople try to sort through it all.
Employee vs. independent contractor
So the key question is whether the consultant is an employee or an independent contractor. The U.S. Supreme Court has defined the employee/independent contractor test as follows: “[W]e consider the hiring party’s right to control the manner and means by which the product is accomplished.” CCNV v. Reid, 490 U.S. 730, 751 (1989).In determining “control,” the court considered 1) the skill required; 2) the source of the instrumentalities and tools; 3) the location of the work; 4) the duration of the relationship between the parties; 5) whether the hiring party has the right to assign additional projects to the hired party; 6) the hired party’s discretion over when and how long to work; 7) whether the work is part of the regular business of the hiring party; 8) whether the hiring party is in business for himself; 9) the provision of employee benefits; and 10) the tax treatment of the hired party.
Thus, if GoGetter can show the requisite “control,” as defined by these types of factors, then everything the consultant did belongs to GoGetter, regardless of whether GoGetter 2.0 is more Shortcut than GoGetter 1.0.
But most of the time, a company only has these characteristics of “control” when it is actually in an employer-employee relationship. If you don’t want to add another staff member and really want your consultant to act as an independent contractor (to whom you can issue a 1099, rather than be required to withhold taxes), then you probably won’t have the “control” needed to establish “authorship.”
For GoGetter, if the consultant can show a lack of control, then he was a truly independent contractor, and you’re in a world of hurt. Your company has just spent the last year working on something that it cannot market, does not solely control and may not even own at all.
Making the law work for you
Collaboration on software development may present legal pitfalls, but a company wishing to partner with a secondary developer has a means of protection. In most cases, a written agreement that carefully specifies each party’s rights and ownership will clarify who owns the resulting code.In our GoGetter example, if you had purchased Shortcut outright (with a written agreement), or secured the consultant’s agreement with regard to his development work on GoGetter 2.0 to disclaim all potential copyright interests and assign such interests to GoGetter – often termed a “work made for hire” agreement — then in most circumstances, you would end up as the owner of the code.
Although there is some controversy over whether software code can be the subject of a “work made for hire” agreement under the Copyright Act, an agreement that includes a promised assignment of the resulting code will, at the very least, create a claim for breach of contract against the developer if he ultimately refuses to assign the code as promised.
Tech companies grow and thrive by making strategic partnerships with other players in the industry. To avoid misunderstandings and litigation over the question of who owns the code, however, software companies should take precautions from the earliest stages of development and enter into clear contractual agreements about future legal rights of any product resulting from software development efforts – before development begins.
John P. Hutchins is an attorney in the Atlanta office of Troutman Sanders LLP, which, among other practice areas, specializes in intellectual property issues.
