Table of contents
11 February 2013
Are you developing an app? If you are, by taking a few simple precautions early in the development cycle—ideally before you start development—to make sure that you own the app, you could avoid major headaches later.
For example, you could find yourself in the situation where someone whom you don't expect to have ownership rights in the app claims that they have rights to the app or an interest in your company. This person could be someone who claims that they were involved in the founding of your company and therefore should be entitled to share in its success (the so-called "phantom founder" issue). Or they could be someone who claims that they own some, or even the entire, app by virtue of somehow having been involved in its development. Or it could be your or your colleague's current or former employer who claims ownership of some or all of the app because it was developed while you or your colleague were employed by the company. Or it could be someone who claims that you included some of their code or other intellectual property (IP) in your app without their permission. You'll often hear from one of these people once the app or your company is a success, the way someone who wins the lottery suddenly hears from a "long-lost relative."
Also, if you're fortunate enough to find an investor in your app or your company or a publisher or distributor of your app, they will probably require you to make "representations and warranties" (basically, assurances on which they can rely) that you own the app free and clear, and to indemnify them (that is, cover their losses and damage claims) should it turn out that you don't own the app free and clear. It could be very risky to give these representations, warranties, and indemnities if you haven't taken the proper precautions, especially if you already received one of the claims described above. So if you failed to take the appropriate precautions in advance, you could find yourself having to go back to others involved in developing the app to obtain all of the rights you need to comfortably give these representations, warranties, and indemnities in order to save the deal. To put it mildly, your bargaining power at that point would be much less than before development started.
So what are these precautions? Some examples follow. But as you read them, keep in mind that the information contained in this article is intended only for general informational and educational purposes. It is not offered as and does not constitute legal advice or legal opinions. For that, you should consult your own lawyer.
It's often the case that more than one person is involved in the conception, design, or development of an app, or in the business that will own the app. For example, perhaps you conceived the idea for the app and have been working on it with friends or schoolmates. Or maybe you obtained the assistance of others with coding or architecture because you don't have the expertise or the bandwidth to do it all yourself. If the expectation is that some or all of the people involved would be a part of the business that would develop and monetize the app, then you should memorialize the arrangement with them in a signed written agreement which describes, among other things, the understanding of the parties regarding ownership, the sharing of revenue, and decision making.
As you may know (and as will be discussed in a separate article), it is a good idea to form a legal entity, such as a corporation or a limited liability company, to help shield the personal assets of the individuals involved from the liabilities of the company. A side benefit of forming a legal entity is that it often involves the creation of a founders' agreement and other organizational documents that describe the agreed-upon arrangement among the founders, so you can obtain two important legal benefits at the same time. When the company is formed, each of the founders would assign to the company whatever rights to the app he or she may have, and would receive shares of ownership in the company in exchange, and each founder would agree that all future work that he or she did on the app would be the property of the company.
And if it's the parties' intent that some of the people involved would not be treated as owners of the company, then you should memorialize this understanding with these people in a signed written agreement, which would include their assignment to the company of all of their rights to the app. Essentially, these people would be treated as independent contractors, as discussed below.
By taking the above steps you can help minimize the likelihood of a "phantom founder" claim.
Generally, the person who actually creates a copyrightable work (an app, for example) is the legally recognized author of that work for copyright purposes. However, there is an exception to this general rule when a work is created by an employee within the scope of his or her employment. These employee-created works are known as "works made for hire." Under the copyright laws of the United States and certain other jurisdictions, if a work is "made for hire," you, the employer—not the employee—is considered the legal author.
However, keep in mind that the work-for-hire doctrine only applies to copyrights. In the course of their employment with you, your employees could conceive of or develop ideas or materials that are protected by other forms of intellectual property. (I'll discuss the differences among the various forms of intellectual property in a separate article.) So, before each employee begins work for you, you should have him or her sign an agreement that assigns to you ownership of all intellectual property that he or she creates in the course of their employment. (There are other reasons to have your employees sign an employee agreement, including binding them to confidentiality obligations and, if appropriate, prohibitions against competing against you or soliciting your other employees or business partners. This will also be addressed in a separate article.)
Assignment in writing
If you do not have the in-house resources or expertise necessary to develop the app according to your desired timeline, you may decide to engage an independent contractor or a development services organization to help develop your app.
If you do, it's crucial that you enter into a written agreement with the developer that, among other things, assigns ownership of the app to you. This is because in the absence of a written transfer of ownership, the developer, not you, will own the portion of the app that the developer developed. Let me repeat that: if the developer doesn't assign to you ownership of the copyright in the work product it develops in writing, you don't own the copyright. Instead, what you'd get is an implied license to use the work product, which the developer might be able to revoke, meaning that it's possible that the developer could demand additional compensation as a condition to your further use of the developer's work product that is included in your app.
Not only does the assignment need to be in writing, but it also needs to be phrased a certain way. Courts have interpreted statements like "developer agrees to assign ownership of the work product to client" as a mere promise to assign ownership at some future date, rather than an actual assignment of ownership. So instead of phrasing the assignment of ownership this way, the agreement should say something like "developer hereby assigns ownership of the work product to client."
Also, the provision should specifically state that ownership is assigned. It is not sufficient to merely say something like "client shall have the right to use the work product." There is a big distinction between having the right to use something and actually owning it. If you own it, unless you give someone else permission to do so, only you have the right to reproduce, prepare derivative works of (modify), distribute, or publicly display the work product. If you merely have the right to use the work product, you will not have the ability to stop the developer from doing any of these things or allowing others to do them.
If the developer is a company, rather than an individual freelancer, make sure that all of the company's personnel who are involved in developing your app are required by the company to sign similar assignments of ownership, whether directly to you or to the company to in turn assign to you, so that ownership is properly assigned all the way through the entire chain of development.
In certain cases, the developer may ask to retain ownership of certain code or other IP that is incorporated into the work product. For example, the developer may wish to utilize some of its pre-existing code or IP (a game engine, for example) in developing your app. Make sure that, before including any pre-existing code or IP into your app, the developer identifies it in writing and gets your permission in each instance.
Sometimes the developer will ask to retain ownership of some of the newly-developed code or IP that it creates in the course of developing your app—usually code or IP which is not specific to your app and that could be repurposed by the developer to develop its own apps or to develop apps for others (sometimes referred to as "generic code"). Again, the developer should provide you with a description of what this code consists of so that there is a clear understanding of who owns what. But determining and agreeing upon what is and what isn't generic code is usually easier said than done, so from your perspective it would be best to avoid agreeing to this.
In either case, if the developer includes any of its own code in the deliverable, the developer should grant to you a broad, irrevocable license with few, if any, limitations, so that you can fully exploit your app with the code included in it to the same degree that you would be able to if the developer's code was not included.
You should also make sure that the developer doesn't include in the work product any code or other IP that belongs to a third party (that is, someone other than you or the developer). Occasionally there may be a compelling reason to make an exception to this rule. If that's the case, make sure that, before including any third-party IP in the work product, the developer gives you a description, obtains your permission, and obtains the permission of the third party (all in writing, of course). This permission, or license, should give you broad enough rights so that your ability to fully exploit your app is not limited—you should be able to exploit that app including the third-party IP to the same degree as you would be able to if the third-party IP was not included.
Similarly, you should prohibit, or at least severely limit, the developer's ability to incorporate open-source code into your app. This is because under certain open-source code licenses, by including open-source code into an app that is distributed to others (like a mobile app) or provided to others online (like a social network app), you could be making your entire app open-source. So it's best to outright prohibit the use of open-source code in your app, and if you are to make an exception to this you should make sure that before including any open source the developer describes the open-source code, you review the open-source license, and you approve of the open source terms.
Work for hire
By the way, although such arrangements are often commonly referred to as "work for hire" agreements, it is not sufficient to simply say that the development is being done on a "work for hire" basis and not specifically state that ownership of the work product is being assigned to you. This is because, in many cases in which development is being done by a non-employee, the term "work for hire" is a misnomer: the term is defined in the U.S. Copyright Act, and under this definition, if the work is created by a non-employee, the work may be considered a work for hire only if the work comes within one of nine specific limited categories of works. So it's always best to operate under the assumption that the work product is not truly a work made for hire and to include a provision in the agreement that specifically assigns ownership of the work product to you.
 The United States Copyright Act of 1976 defines a work made for hire as being either (1) a work prepared by an employee within the scope of his or her employment; or (2) a work specially ordered or commissioned for use as a contribution to a collective work, as a part of a motion picture or other audiovisual work, as a translation, as a supplementary work, as a compilation, as an instructional text, as a test, as answer material for a test, or as an atlas, if the parties expressly agree in a written instrument signed by them that the work shall be considered a work made for hire. (17 U.S.C. § 101).
Often an app is developed "in a garage" on evenings and weekends by people with full-time jobs. If you or anyone whom you intend to involve in the development of the app is also employed by another company, be they your founders, employees, or freelancers, you should review their agreements with their employers before allowing them to do any development to make sure that these employers can't lay claim to the work done for you. Most employee agreements include a provision assigning to the employer rights to intellectual property created by the employee. Many of these assignment of rights provisions are written very broadly, to encompass all work product created by the employee during the time he or she is employed, whether or not it was created during work hours or using the employer's resources. And even with more narrowly drafted employee assignment-of-rights provisions, if the work product created for you relates to the employer's business or actual or anticipated research or development of the employer, the employer could claim that it is owned by them, not you. So be especially careful if the employer's business is competitive with or related to yours.
After reading this article, you should have a better sense of how others could claim ownership of your app or an interest in your company, as well as some of the steps you could take to reduce your chances of getting such a claim. Of course, this article isn't meant to be a definitive list of all ownership issues that could arise, and there are several nuances to each of the issues addressed here. In short, as stated previously, the information contained in this article is intended only for general informational and educational purposes. It is not offered as and does not constitute legal advice or legal opinions. So, if you are developing an app, you should seek legal counsel from an attorney familiar with game or other application development and the issues faced by startup companies.