2013 Corporate Cuisine Awards
Your Health, Your Choice
Return to Health
Who Owns the Software?
Back to Basics
The Travel Vet: At Your Pet’s Beck and Call
Are You an Entrepreneur?
Around Utah Facts
Startups usually operate on a shoestring budget with few employees and minimal resources. Many, if not most, of the formalities of a Fortune 500 company simply don’t exist in startups. Even basic formalities often don’t exist. So, how does a startup determine who owns software developed by a developer engaged by the fledgling company?
The rules of ownership for software are fairly straightforward. Software created by a developer who is employed by a company is owned by that company. But software created by a developer who is an independent contractor is owned by that independent contractor/developer. Under federal copyright law, creative works, which include software, created by an employee within the scope of his or her employment are owned by the employer. This is referred to as a “work made for hire.” The relevant issue, then, is whether the software developer is an employee or an independent contractor.
When it is clear whether the developer is an employee or independent contractor, it is also generally clear whether the software is owned by the company or the developer. But in a startup where formalities surrounding employees are often fuzzy at best, the answer to the ownership question is not always clear.
Cutting Some Slack
In a recent case heard by the Ninth Circuit Court of Appeals, the court considered whether a startup software company owned software being developed by a developer associated with the company, or whether the developer individually owned the software. To the disappointment and frustration of the developer, the court found in this case that, although the startup company did not follow many of the formalities it should have followed to treat the developer as an employee, the developer was still found to be an employee. Consequently, the court ruled that the startup, rather than the developer, owned the software.
To reach its conclusion that the developer was an employee of the startup software company rather than an independent contractor, the court looked at several factors. Perhaps the most important factor was that the company was a startup, and the failure to follow certain legal formalities did not weigh as heavily in favor of finding that the developer was an independent contractor as it may have in the case of a more established business enterprise. In other words, the court essentially recognized the reality of entrepreneurship and cut some slack to the entrepreneurs struggling to work through the startup phase.
In finding that the developer was an employee and not an independent contractor, the court looked at several specific factors and found that (a) the developer did more for the entrepreneurial enterprise than just work on the software, (b) the developer was paid a regular salary, although some of the compensation was in the form of stock and (c) the developer’s work at the company was integral to the success of the business in general.
The court considered, but ultimately rejected, the developer’s arguments that the developer should have been treated as an independent contractor because (x) his hours were flexible, (y) the company did not exercise much control over the developer and (z) the company failed to treat the developer as an employee when it came to forms and the payment of taxes. Instead, the court gave the startup great latitude and said that the company conducted its business more informally than an established business might have done, and the expectation for formalizing the employment relationship was not high.
Fast and Loose
The relationships among participants in a startup business venture are by nature loose. Decisions are often made quickly without taking time to document them. Frequently, formalities are left to be handled another day. But there are some decisions that should be made and documented, and some formalities that should be followed, because the risk of overlooking them or not following up on them can be significant and the consequences costly. Not only is there a risk of litigation, relationships can be compromised, critical momentum in the startup can be lost and valuable assets can be lost.
Any software developer and company should reach a decision at the beginning of their relationship whether the developer is an independent contractor or an employee, and then appropriately document that relationship and the ownership of the fruits of the developer’s labors. The parties should clearly document their intent regarding ownership of software and any other copyrighted works.
In this case, the company was lucky, and the developer was left to negotiate for additional rights or additional compensation based on the company-owned software. But there is no need to leave the determination of ownership to chance and expensive litigation. The court stretched to find that the company owned the software in this case, but another startup, or a more mature business, might not be nearly as fortunate.
John H. Rees is a business lawyer at Callister Nebeker & McCullough.