5 Free Legal Contracts That Every Mobile Developer Needs

So, your job is designing and developing mobile apps. But, there is a difference between simply making apps and being a professional developer. If you are serious about a career in mobile apps, you will need to step up your game and adopt professional best practices, starting with proper business contracts. A written contract protects you and the people you work with. A well-drafted contract can make sure you get paid for your work and save you from painful and expensive legal headaches. We will go through five core documents that any app developer will encounter sooner or later in his or her profession, and help you understand the legalese with some tips and examples you can use as a starting point.

Technology Assignment Agreement

According to Copyright Law, the developer owns the code in the very moment it is “fixed in tangible form.” In other words, you own the copyright as soon as you press “Save,” even if you haven’t released anything yet. This is also counts, of course, for the design and creative content that goes on the app. In the vast majority of cases, you will also use the work of others to build your app. You had better make sure you own it, or you might be exposed to third parties’ claims to revenues. This is what the Technology Assignment Agreement is for. It’s a simple contract where someone will assign to you (or to your company, if you are incorporated) the intellectual property of the work. Here’s a very basic example to give you an idea. As with every contract, it needs consideration to be valid. Consideration is simply the value exchanged to have the IP (intellectual property) rights. It’s usually money (any value will do, but symbolic amounts like $1 may be contested), but can also be equity in the company, like in this example. It can also be a promise, such as a certain percent of future sales or revenues. The important things are the representations and warranties of the person who assigns the copyright. For example this section will state that:

• [developer] is the sole owner of all IP rights and title.
• [developer] has not assigned such rights to anybody else.
• [developer] is not aware of any violation, infringement or misappropriation of any third party’s rights by the IP .
• [developer] was not acting within the scope of employment by any third party when conceiving or creating IP (because, if that is the case, the IP belongs to the third party employer).

Note that there’s often a non-disclosure provision included within this type of agreement. It’s pretty standard and shouldn’t be a negotiated point!

Work for Hire

Working with others; there’s a contract for that. If you’re using contractors to build any part your app, you need a document that goes by many names: Independent Contractor Agreement, Work for Hire agreement, or even Contract for Mobile Application Development Services. They’re all essentially the same, as long as they have a “work for hire” clause like:

Work for Hire. The Developer expressly acknowledges and agrees that any all proprietary materials prepared by the Developer under this Agreement shall be considered “works for hire” and the exclusive property of the Company unless otherwise specified. These items shall include, but shall not be limited to, any and all deliverables resulting from the Developer’s Services or contemplated by this Agreement, all tangible results and proceeds of the Services, works in progress, records, diagrams, notes, drawings, specifications, schematics, documents, designs, improvements, inventions, discoveries, developments, trademarks, trade secrets, customer lists, databases, software, programs, middleware, applications, and solutions conceived, made, or discovered by the Developer, solely or in collaboration with others, during the Term of this Agreement relating in any manner to the Developer’s Services.

The great thing about a work-for-hire agreement is that it takes care of the IP assignment for you. So, if you sign it in a timely fashion with your contractor, i.e. before any work is done, you don’t need a separate assignment agreement: all the code and design that the contractor will do for you is automatically assigned to your company. If you are a freelance developer, you can expect that your clients will always want to sign a work for hire agreement, as they want to be the full owners of the app source code as soon as possible. The flip-side of this is that they can do whatever they want with your creation. If you want to limit the way your code (or design) is used, you should avoid work for hire agreements (see more about this below). If you don’t have the leverage to avoid a work-for-hire, try to retain the so-called “portfolio rights” so you can at least show your work to future clients or employers.

License Agreement

Very frequently called “service agreement” or some variation of it, this contract is radically different from the one above in the IP provisions; the copyright is not automatically assigned, but instead it is licensed to the client or commissioner for a fee (fixed or periodical). Licensing allows freelance developers to customize their offering in great length, for example:

• they can limit the scope of the license to a particular project or product, geographic area or time period;
• they can make the client pay a premium for exclusive use of the code;
• they can define a different IP treatment for the so-called “tools” (i.e. those snippets of code or fonts that you incorporate into multiple projects. Just because they are in some client’s project doesn’t mean that client owns the tools. Instead, you only give the client permission to continue using the tools.)

Most of the time your best bet is a good compromise between licensing and work for hire. A comprehensive service agreement is usually the best of both worlds, see for example:

• Website + Identity Design Contract
• AIGA Standard Agreement for Interactive Works

These documents expressly exclude that the final product (in this case, the app) will be a work for hire, to be able to condition the assignment upon payment of full price. That’s the greatest tool you have to avoid getting stiffed, so make sure it’s in your contract! “Pure” Licensing Agreements come handy for when you have to get proper permission for the use of third party’s media in the app, like images and sounds. A great example is this Music License Agreement specific to mobile apps’ usage

Privacy Policy

As for now, you are not violating the law if you don’t have a privacy policy in place, provided that you don’t collect “sensitive” data like children’s information, financial data, or health-related data. Nevertheless, the European Union has stricter privacy policies in place and you might get caught in that regulatory net. Furthermore, both Apple’s App Store and the Android Market have terms in place that asks for updated and “legally adequate” privacy policy for all apps that collect usernames and passwords. So, there is a very good chance that your app needs a privacy policy. Here are a couple of open-source examples that might be a good starting point:

• Mobile privacy Policy
• Mobile Privacy Policy (for apps that use geolocation)
• Mobile Privacy Policy (for apps that use ads)

There are also some free privacy policy generators out there, with the only mobile-centric one at the time of writing from Privacy Choice. In any case, the point is not to have a chunk of text called “privacy policy” in your app, but rather to make sure that the text is truthful and updated. For example, if you add a tracking service like Google Analytics to your app (even if just to aggregate anonymous data for internal purposes), you have to update your privacy policy. Reading FTC’s new guidelines for app developers can definitely help you figure out what should go in to the privacy policy. While blindly copying and pasting your biggest competitor’s policy is not a good idea, comparing your policy with others’ is the best way to make sure you didn’t forget anything.

NDA

Last but not least, the infamous NDA! As much as everybody hates non-disclosure agreements, they are still pretty common in tech business. So, don’t be surprised if somebody you are dealing with asks you to sign one. It is one of those contracts that rarely gets triggered, but if the work or the relationship goes south, it can be a real lifesaver, and that’s why people still (ab)use it. If you are sent an NDA to sign, check the following three things very carefully:

• If the NDA is mutual or unilateral: i.e. if only one party is disclosing information. Unless you are a contractor or an employee, try to sign only mutual NDAs.
• If the NDA contains a non-compete: this is usually a nasty provision, so nasty that it’s not enforceable in California. Make sure this clause is not super-broad, both in duration and scope.
• If the NDA contains other off-market provisions. How do you check that? Well, compare it with standard NDAs in the industry, like this, this or this.

Conclusion

Because app development is still a relatively new business, a lot of the legal stuff has been treated fairly loosely by developers, employers, and even the app stores themselves. But don’t get left behind, the above issues will become increasingly important as you advance in your career, and as mobile apps become an even larger industry. Disclaimer: This article wants to be useful and informational, but keep in mind it is not legal advice and all the legal documents cited are only to be used as a starting point. The author, BuildMobile, Docracy, and the original authors of the legal documents cited disclaim any liability connected to the use of these material without a licensed attorney.

Frequently Asked Questions (FAQs) on Mobile App Development Contracts