Back in the late 1990s, no self-respecting company, no matter how stodgy and old-fashioned, wanted to be without a website.
Today, the same is true with mobile apps. It doesn’t matter what industry a company is in—it needs to have an app that customers and potential customers can download to their smartphones. Even big, tradition-bound law firms are developing and distributing mobile apps, for crying out loud.
Here at Socially Aware, we have been known to spend our free time downloading and examining mobile apps owned by companies that are new to the software distribution business (after all, a mobile app is just that — distributed software). In doing so, we’ve noticed a number of common missteps by app distributors in connection with the legal terms—or End User License Agreements (EULAs)—governing such apps. Accordingly, here is our list of key issues to address in adopting a EULA for a mobile app.
1. Adopt Your Own EULA. A EULA is an important part of any company’s strategy to mitigate risks and protect its intellectual property in connection with its mobile apps. Hardly any company would release desktop software without a EULA, and mobile apps—which, as noted above, are software products—warrant the same protection. While a number of other app providers such as Google provide a “default” EULA to govern mobile apps downloaded from their respective app stores, they also permit developers to adopt their own custom EULAs instead—subject to a few caveats, as mentioned in our fifth item below. Because the default EULAs can be quite limited, and can’t possibly address the unique issues that any particular app is likely to raise, a company should ideally adopt its own EULA to best protect its interests in its apps.
2. Is Your EULA Binding? The best EULA is a binding EULA. U.S. courts have consistently made clear that a “clickwrap”-style agreement has the best chance of being enforceable; although whether an agreement is enforceable in any particular case may depend on how the agreement is actually presented to users, and how users indicate their assent. Having adopted customized EULAs, companies have several opportunities to present their EULAs to users. In most app stores, for example, a dedicated link called “License Agreement” lets companies link to their EULAs. In addition, companies should ideally include language in their apps’ “Description” field making clear to users that, by downloading and using the app, they are accepting the EULA. But it’s still possible in most app stores for users to purchase and download an app without seeing the EULA; accordingly, for apps that may present significant risk issues—such as banking or e-commerce apps—the most conservative approach is to require an affirmative “click-accept” of the EULA when the app is first opened by a user on his or her device.
3. Which Parties Will Your EULA Bind? If an app is targeted toward businesses, or toward individuals who will use the app in their business capacities, then the EULA should ideally bind both the individual who uses the app and the individual’s employer. Similarly, if minors will be permitted to use the app, then the EULA should require that a parent or guardian consent on the minor’s behalf. (Of course, if minors under 13 will be allowed to use the app, or if the app will be directed toward such minors, you will need to address Children’s Online Privacy Protection Act issues in connection with the app.)
4. Where Will Your EULA Reside? As a technical matter, a EULA can reside in one of two places: it can be “hard-coded” into the app itself, so that the EULA is downloaded together with the app, or it can reside on a separate web server maintained by the developer. The former approach ensures that the EULA is always accessible to the user, even if the user’s device is offline. Some users may decide not to download the latest updates, however, and, as a result, those users may not be bound by the updated terms. In contrast, under the latter approach, companies can update their EULAs at any time by simply updating the document on their own web servers, although the EULAs won’t available to the user offline. Companies should think about which approach works best for their specific apps and their associated risk issues.
5. Does Your EULA Incorporate Terms Required by Third Parties? Some app stores, such as the Apple App Store, understandably require that, if a company adopts a custom EULA for its app, such customized EULA must include terms protecting the applicable app store owner. (Other app stores may place such protective terms in their own user-facing agreements, and require developers to acknowledge that such protective terms will govern.) Other third-party terms may also apply, depending on any third-party functionalities or open-source code incorporated into the app. For example, if a company integrates Google Maps into its app, Google requires the integrating company to pass certain terms on to its end users. The licensors of any open-source code used by an app may also require the company to include certain disclaimers, attributions, usage restrictions or other terms in the EULA.
6. Is your EULA clearly written and reasonable? Traditionally, EULAs have been overlong, filled with impenetrable legal jargon and, frankly, hard to read, sometimes even for lawyers. An emerging best practice, especially for B2C apps, is to draft app EULAs that are understandable to consumers, and to minimize unnecessary legalisms such as “null and void,” “including without limitation” and the reflexive prefacing of sentences with “we hereby reserve the right” or “you hereby acknowledge and agree.” Moreover, because space on a mobile device screen can be limited, thought should be given to eliminating repetition in app EULAs wherever possible. Of course, even if a EULA is written in plain English, extremely one-sided provisions—such as a disclaimer of direct damages (rather than a cap on such damages)—may raise concerns with a court in any subsequent litigation involving the EULA. At the same time, the EULA is ultimately a legal document, and an app developer will want to make sure that any slimmed-down or simplified EULA still provides adequate protection for the developer.