Cracking the ownership of codes
Many companies possess valuable proprietary software but are not aware that they may not own it. This is particularly true for historical or legacy software or systems that were developed by a consultant, contractor, or part-time employee at a time when business and legal sensitivities about the value of, and need to own and protect, intellectual property, were not as great as they are today.
For example, in the 1990s and early 2000s, many companies did not have in place formal employee and consultant IP assignment agreements, or internal or regular outside IP counsel, to the extent that they do today. A company that received a copy of source code during software development or delivery, developed and upgraded it and then assumed that it owned the software, may in fact never have been assigned the copyright in the code.
A possible misunderstanding regarding software asset ownership is potentially significant because under copyright law ownership confers certain important rights to development and exploitation. Moreover, this lack of understanding can present contractual issues, as a company that later attempts to license or sell such software will typically be required to state that it owns and possesses all rights in the software. This software may have become a significant asset following its use, improvement and customisation over time—perhaps being essential to the company’s operations or providing an appreciable competitive advantage. Frequently, the issue regarding ownership of business software systems may not be discovered until a critical moment in the life cycle of a business—when a company is preparing for, or is going through, the process of being sold.
Determining ownership of such legacy systems may be difficult given the time that has elapsed. There may be no underlying contract directly addressing development of such software, or there may be an underlying contract that addresses the software development but does not define the ownership rights of the parties in the software. In many instances whatever contract may have existed can no longer be located. Company employees who were responsible for commissioning and overseeing the initial development work may no longer be with the business. Even the circumstances, contractual provisions, and parties’ intent concerning the development and ownership of the software may be, at best, unclear.
In its normal internal operations, a company as a practical matter probably has little reason to worry about its rights to legacy proprietary software.
Rather, issues surrounding ownership of proprietary software often arise when a company seeks to engage in a sale of its business or assets, or to license its software. In the deal context, a seller will typically seek to assess rights to its proprietary software, or a prospective buyer or licensee may try to determine the seller’s rights during diligence. Frequently, regardless of the level of diligence conducted, a buyer will require that the seller represents and states that it owns the rights in, or has the right to transfer or license, its software.
It is in these cases that the unclear historical provenance of a system, the company’s implicit assumption that it owns its system, and a buyer’s demand for representations and evidence supporting representations of ownership can potentially collide.
Other than software developed in-house by full-time employees in the course of their employment, a company generally will not own its software unless it has been assigned to the company in writing. Companies that have had software developed for them, particularly a decade or two ago when IP ownership was generally less of a focus, are more likely not to have entered into agreements assigning such rights to them. Rather, many software development efforts were informal exercises undertaken by a particular business unit within a company and were frequently undertaken on an invoice basis or without a contract. Accordingly, in many instances, such software may continue to be owned by the third party developer.
Absent an assignment, the rights of a company to use software developed by a contractor would be through a licence. An exclusive licence would have to be in writing, so assuming there is no written licence, the company’s rights to use such software would be through an implied non-exclusive licence. There is a possibility that a company has no legal right to use such software and therefore would be infringing the third party developer’s rights, but it is unlikely in circumstances where the software and code were delivered to the company for its future use, modification, and enjoyment.
An implied non-exclusive licence may be terminated by the licensor upon reasonable notice, although such a licence is more likely to be irrevocable because it was supported with consideration—payment to the contractor for its creation of the software—and limited in scope to the use generally intended by the parties at the time of creation and delivery. Implied licences are not transferrable without the copyright owner’s consent.
Who has the rights?
The first step for a company to undertake when it identifies material legacy software or systems is to determine the nature of its rights in and to such assets. Below is a brief overview of applicable law for the purpose of making such determinations.
Authors of original software initially own the copyright in the software unless it is a “work made for hire,” either (i) a work made by an employee within the scope of his or employment; or (ii) a work made and commissioned for certain uses, including as a contribution to a collective work or as a compilation, if the parties agree in a written instrument that the work will be made for hire. Unless there is a written agreement between the parties specifying that the software created is a “work made for hire”, the key inquiry is whether the authors are employees.
To determine whether the authors are employees or independent contractors, courts look to federal law, referencing principles from the common law of agency. The principal factor in determining whether a person is an employee is the hiring party’s right to control the manner and means by which the software or other material was created, as well as the skill required, the provision of employee benefits, the tax treatment of the hired party, and whether the hiring party has the right to assign additional projects to the hired party, among other factors. Given the factually intensive nature of the inquiry, the determination of whether an individual acts as an employee for the purpose of his or her software development is understandably difficult to discern in many circumstances.
“TRYING TO TRANSFER SUCH PROPRIETARY SOFTWARE IN AN ASSET SALE, FORWARD MERGER AND, POSSIBLY, REVERSE MERGER, OR TO SUB-LICENSE SUCH SOFTWARE MAY BE DIFFICULT.”
In one case a court found that a graduate student hired to program software used to manage records, inventory, sales, and other information for a swimming pool retail chain was an independent contractor who owned the copyright to the software. The key factors were that the hired programmer was highly skilled in the relevant field, received no employee benefits, was not subject to tax, and performed work that was outside the company’s regular pool-selling business.
In another case, a court held that a programmer hired to create source code for a speech assistance medical device was an employee, despite the fact that the hiring party did not withhold his taxes (initially), provide facilities for his work, provide employee benefits, control the manner and means of the creation of the software code, or determine his hours. The court attributed many of these factors to the small, start-up nature of the business rather than to the programmer being an independent contractor. Accordingly, a determination of whether an author of software is an employee depends not only on the nature of the author’s relationship with the hiring party, but also the nature of the hiring party’s business.
If the company does not own the software under the “work made for hire” doctrine, then it may potentially still own the software as a “joint work”. A joint work must be prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole. As the US Court of Appeals for the Second Circuit held in rejecting a claim of co-authorship of a play, all putative joint authors must (i) make contributions to the work that are independently copyrightable; and (ii) mutually intend, at the time of writing, to be joint authors.
In holding that a company was not a joint author of software written by its contractors under the direction of one of the company’s employees, the US Court of Appeals for the Ninth Circuit stated, a person who merely describes to an author what the commissioned work should do or look like is not a joint author. To be an author, one must supply more than mere direction or ideas: one must “translate an idea into a fixed, tangible expression entitled to copyright protection”.
When a company hires programmers as independent contractors to create proprietary software, generally the company would not contribute enough independently copyrightable material to qualify as a joint author. However, if a company has a team of its own employees working as programmers who collaborate with the contractors in the development, the company can probably establish that the parties intended to share ownership. If a company has joint ownership, it can use such software as an owner and can transfer its rights without the contractor’s consent.
If the creator alone owns the copyright to the software, then the question is whether he or she transferred the copyright to the company. The creator of a copyright can assign his or her copyright only through a signed statement. The requirements for transfer are not stringent, as the ninth circuit has observed: “It doesn’t have to be the Magna Carta; a one-line pro forma statement will do.”
Scope of a licence
Where a company lacks a signed statement from the authors of the code conveying copyright in the code or granting an exclusive licence to the copyright, the company will almost certainly have a non-exclusive licence to use the software for limited purposes. Non-exclusive licences do not need to be in writing, and may be granted orally or by implication. Non-exclusive licences have been found when (i) a person (the licensee) requests the creation of a work; (ii) the creator (the licensor) makes that particular work and delivers it to the licensee who requested it; and (iii) the licensor intends that the licensee-requestor copy and distribute his or her work.
One court found that a company had an implied non-exclusive licence to use the software created by the contractors for the purposes for which it was created—“otherwise, the [hiring party’s] payment of a large sum of money would have been senseless”. Similarly, another court noted that “common sense dictates” that a contractor who developed websites for a company intended for the company would have an implied licence to use them.
A company that has an implied non-exclusive licence also should determine the licence’s scope. The key to determining the scope of an implied licence is the intent of the parties at the time of its creation and delivery. The courts consider the following factors to determine such an intent: (i) whether the parties were engaged in a short-term, discrete transaction rather than a continuing relationship; (ii) whether the authors used written contracts providing that the software could be used only with their future involvement or express permission; and (3) whether the authors’ conduct during the creation or delivery of the software indicated that use of the material without their involvement or consent was permissible.
If a company hires a contractor to develop proprietary software, it is likely that both parties intend that the company may use and modify the software after the contractor’s work is completed. Nonetheless, it is important for a company to assess the scope of its licence based on the circumstances at the software’s time of creation and delivery. For example, if source code is delivered by the contractor to the company or the parties agree that the company, not the contractor, will service and maintain the software, then it can probably be inferred that the licence includes the right to make derivative works over time and to extend the code to new ancillary or related uses. If the scope of the contractor’s initial engagement was narrow, then the licence may be limited to the particular use or application.
As noted, frequently a company will first learn that it may not own certain proprietary systems when it is considering a potential strategic transaction. The absence of such ownership could have a great impact on the transaction because non-exclusive licences generally cannot be transferred or sub-licensed to the buyer without the consent of the licensor
At least one court has held that a reverse subsidiary merger constituted an impermissible assignment by a software licensee. A sale of stock by a company, in contrast, should not present issues concerning an implied software licence. Accordingly, a company that does not own certain key software programs or systems developed for it and that instead has an implied licence will need to consider how best to structure a sale, or licence, of such software, so that it minimises the risk of breaching implied non-assignability and non-sublicensable clauses.
Ultimately, a company very probably has a right to use, retain, and modify its proprietary software, even if that software was written by independent contractors and there is no signed writing regarding the software rights. However, trying to transfer such proprietary software in an asset sale, forward merger and, possibly, reverse merger, or to sub-license such software may be difficult. The significant risk when considering such a transaction is the independent contractor making a reappearance and seeking to hold up the deal, seeking an exorbitant licensing fee, or suing the company or buyer/licensee for copyright infringement on the basis that the buyer/licensee does not have the right to receive an assignment or sub-licence of the software.
Often, however, the contractor probably has since moved on from his or her work for the company, and may think of the company as the owner of the delivered software, so the risks may not be as great in practice. Nonetheless, it is important to consider whether there are key software programs and systems that the company considers itself as owning but in fact may not, and the related potential issues, risks, and consequences, particularly in the context of a potential strategic transaction involving the assets. Conducting an audit of ownership of legacy software systems now may save an unpleasant surprise later.
Bruce Goldner is a partner at Skadden. He can be contacted at: bruce.goldner@skadden.com
Benjamin Howard is an associate at Skadden. He can be contacted at: benjamin.howard@skadden.com
