Many companies engage outsourced developers to assist with writing software code, whether for mobile apps, SaaS products, or websites. However, many template MSAs, Service Agreements, or Development Agreements have IP ownership clauses that may not actually transfer ownership of the code to the customer. This article discusses why certain clauses may not be sufficient to convey ownership and describes the “magic words” that are the best practice to transfer ownership to code developed by an independent contractor.
Who owns code written by an independent contractor?
Outsourced development arrangements are common for companies in all industries. Companies such as manufacturers and banks that don’t distribute software to customers may engage developers to assist with automating back-office functions or creating ERP systems, and digital-native companies with in-house developers may engage outsourced developers to assist with tackling large projects or obtain unique expertise without having to incur the cost of hiring additional employees. The agreement between the outsourced developer and the customer may be called a “Master Services Agreement” or “MSA”, a “Development Agreement”, a “Consulting Agreement”, or something similar, but the content and purpose of these agreements are generally fairly similar.
One of the most important clauses in the agreement governs ownership of the “deliverable” or “work product” resulting from the arrangement, occasionally captioned “Intellectual Property”, “Ownership”, or “Work Product”. Many parties simply assume that this clause provides for the customer to own the code created by the developer under the agreement. However, a number of forms circulating in the marketplace contain ownership clauses that are poorly written and may not actually transfer ownership to the customer.
This article considers a few (unfortunately) common variations of the ownership clause that may not, on their own, convey ownership of code created by an outsourced developer to the customer. This article then describes the better wording represents a best practice for ensuring that the customer receives ownership of the code.
Work Made for Hire
To help understand the first problematic variation addressed in this article, it will be helpful to discuss a few terms in the United States Copyright Law to provide context. Because software code is generally considered to be a “work of authorship” that is copyrightable under the Copyright Law, it’s critical to be familiar with this law when reviewing the development agreement.
Section 17 U.S.C. 201(a) of the Copyright Law states the general rule that ownership of a copyright in a work vests initially in the author(s), which would be the developer in outsourced development agreements. Section 17 U.S.C. 201(b) of the Copyright Law provides an exception to the general rule for “works made for hire.” If a work qualifies as a work made for hire, “the employer or other person for whom the work was prepared is considered the author” and “owns all of the rights comprised in the copyright.” Section 17 U.S.C. 101 of the Copyright Law defines a “work made for hire” as a work that fits into one of two categories: either (1) a “work prepared by an employee within the scope of his or her employment”, or (2) a “specially ordered or commissioned” work that both (A) falls within one of nine enumerated categories, and (B) is designated by the parties as a work made for hire in a written agreement.
The above provides the background for one problematic clause that keeps popping up in development agreements. The clause in question provides that all deliverables produced by the developer under the agreement “shall be considered works made for hire.” An outsourced developer is generally treated as an independent contractor, not an employee, of the customer, and therefore the first category above will not cover software developed under an outsourced development contract. A clause stating that all of the developer’s work product is “considered works made for hire” is therefore aimed at slotting the deliverables into the second category, which can apply to works produced by independent contractors.
The problem with fitting software code into the second category of work made for hire is that the Copyright Law limits the definition of work made for hire to works that are both designated as works made for hire in a written agreement as a work made for hire AND fall within one of nine specifically enumerated categories. The nine enumerated categories are: (1) a contribution to a collective work, (2) a part of a motion picture or other audiovisual work, (3) a translation, (4) a supplementary work, (5) a compilation, (6) an instructional text, (7) a test, (8) answer material for a test, or (9) an atlas. Many software programs may not be covered by any of those categories. Therefore, merely designating code as a work made for hire in the development agreement is likely not sufficient to cause the code to be treated as a work made for hire by the courts.
“Agree to Assign”
The second problematic variation appears very similar to the best practices approach. Development agreements will often state that the developer “agrees to assign” or “will assign” to the customer all rights in the code. Although this wording is often prudent for a customer to include in a development agreement and may seem sufficient at first blush, it implies that the actual transfer will occur in the future via a subsequent action. If that subsequent action never occurs, then ownership may never convey to the customer.
In Advanced Video Techs. LLC v. HTC Corp., 879 F.3d 1314 (Fed. Cir. 2018), the Federal Circuit Court of Appeals held that a contract clause providing that a developer “"will assign to the Company" all her right, title, and interest in any inventions … invoked a promise to do something in the future and did not effect a present assignment.” In Omni MedSci, Inc. v. Apple Inc., 7 F.4th 1148 (Fed. Cir. 2021), the Federal Circuit Court of Appeals held that a clause providing that intellectual property “shall be the property” of a party was an agreement to assign, and not a present assignment.
The distinction between a present assignment and an agreement to assign is significant. If the developer “agrees to assign” the code in a development agreement but then later refuses to assign ownership to the customer, the customer may be able to bring a breach of contract claim against the developer and win a damages award. However, the customer would not have ownership of the code. As any litigator can attest, lawsuits and trials are costly, lengthy, and time-consuming, and the outcome is often inherently uncertain. Moreover, without ownership of the code, the customer may not be able to bring actions against other parties that are infringing the code.
The analogy that I often give to clients is to pretend that you’re buying a house. Having the seller agree in the purchase contract to sell you the house at closing is great. However, the purchase contract doesn’t give you the house; you still need the seller to sign and deliver the deed at closing.
The Magic Words
This brings us to the best practices approach for obtaining ownership of code produced by outsourced developers. Although a good, comprehensive intellectual property clause will often contain additional elements such as a perpetual license to pre-existing intellectual property, a waiver of moral rights, a requirement for the developer to assist with the customer’s actions to enforce and register the intellectual property, and even an “agreement to assign” described above, the key phrase to transfer ownership is a present grant of assignment. A present grant of assignment may read as follows: “The Developer agrees to assign, and hereby does assign, to the Customer any and all right, title and interest in and to the code, deliverables, and all inventions and work product developed, made, conceived, invented, created, reduced to practice, or produced by Developer under this Agreement.”[1]
The underlined words stated above are what I often call the “magic words.” They constitute a “present grant of assignment” that actually carries out the transfer of ownership in the code to the customer. These words are, in effect, the “deed” in my analogy of a house purchase from above. If there is a future dispute over ownership of the code or if the customer needs to prove ownership as part of a proceeding against an alleged infringer, the customer can point to these words to show that it received ownership of the code and that no further action is necessary for the customer to own the code.
Takeaways
Although the provisions discussed above may seem similar and aimed at the same result, the outcome of each provision can be very different. This reinforces the need for parties to engage experienced legal counsel when negotiating outsourced development agreements. Intellectual property provisions can be densely written, and many form agreements in circulation may have been compiled by non-attorneys who, hoping to avoid legal fees, pulled together clauses from several agreements that the individual previously saw without a full understanding of the meaning of each clause. Review and input from an experienced attorney before signature is therefore critical to ensure that the development agreement works as intended.
[1] It’s often best practice to create a defined term such as “Work Product” that is defined broadly to include everything that the developer creates while performing under the Agreement or using the customer’s confidential information or property. The assignment clause can then convey to the customer all right, title, and interest in and to that Work Product.
About Joseph B. Allen
Joe is a corporate transactional attorney who concentrates his practice on M&A transactions, private placement transactions (both as issuer’s counsel and as counsel to venture capital firms, family offices, and angel investors), corporate and LLC governance and reorganizations, joint venture transactions, and complex commercial transactions in the areas of software licensing, industrial equipment sales, and significant supply, reseller, and distribution agreements.