NB: This is a guest article by John Pavolotsky, a practicing legal professional who focuses on technology transactions and other intellectual property matters at Greenberg Traurig.
Mobile apps are pervasive and, in many cases, mobile is becoming the preferred interface to access software applications, especially in the travel sector where the fit is natural between provider and the traveler on-the-go.
But while some time may still pass until vacations are booked primarily via an app, we are certainly much closer today than only a few years ago.
With opportunity, of course, comes some risk. The process of developing an app is still relatively new. That said, in many cases, the issues presented in connection with developing an app are similar to ones associated with developing custom software.
For example, apps may be, and in fact, tend to be, developed by third parties, and without a contractual provision presently assigning the developerâs intellectual property rights in the app to the client, unless the app is a work-made-for-hire, under federal (US) copyright law, the app will be owned by the developer.
To that end, care should be taken to prepare a consulting agreement addressing, among other things, ownership of the app and any related intellectual property.
Likewise, the agreement should have the developer indemnify the client from any claims made by any third party that the app (including any data accessed or presented by it) infringes on any intellectual property or other rights of that third party.
An indemnity is simply a promise to compensate another entity for a loss.
Things to remember
Mobile travel apps, in particular, require access to and presentation of data from a multitude of sources, such as GDSs (Global Distribution Systems), map platforms, and social networking sites, if there is a social component.
As such, it should be understood by both the developer and the client which sources need to be accessed, whether any licenses (API (application programmer interface) or other) are required, and the scope and cost of these licenses.
If, for example, the API license is for internal use only, and the API will be accessed by the app to present data to consumers, a distribution license will need to be procured, even though it is debatable whether APIs are copyrightable, and thus require a license.
Many apps still do not have privacy policies.
In practice, this requirement is universal, because a developer may not be able to prevent California consumers from purchasing the app, or will likely not want to.
The Joint Statement provides, among other things, that in the application submission process there will be included:
Privacy policies generally describe how personal data is collected, used, and shared. Contuining the example outlined arlier, the California Online Privacy Protection Act (2004), which is cited by California Attorney General Harris in the Joint Statement, provides additional details about the contents of such policies.
Of course, the California Department of Justice, and in particular the newly-formed Privacy Enforcement and Protection Unit, may prosecute violations of other data privacy and security laws. For example, if app developers do not abide by the posted policies, there is liability under Californiaâs Unfair Competition Law and/or False Advertising Law.
Further, others, including the (US) Federal Trade Commission, have taken an acute interest in privacy policies and security practices.
Data – lots of it
Data may have tremendous commercial value, especially in the case of free apps, for which the primary revenue source is in-app advertising, which is wholly dependent on the data collected by app.
Many apps, and especially those that are travel-related, feature LBS (Location-Based Services). Some may know that CTIA (Cellular Telecommunications Industry Association) has published a Best Practices and Guidelines (March 23, 2010) (âGuidelinesâ), “intended to promote and protect user privacy as . . . âLBSâ are developed and deployed”.
By way of example, the Guidelines would apply to a developer that makes available through a digital app store an app that requires the user to be located in order to provide roadside assistance or directions to a local travel hot spot.
The Guidelines are premised on notice (of how the location information will be âused, disclosed and protectedâ) and consent (which may be implied if a user requests a service, such as roadside assistance, which cannot be provided without a userâs location). The Guidelines address a number of other topics, including the security and retention of the location information.
The Guidelines, however, do not address, except by reference to illustrative “Location Based Privacy Policies” available via a link in the Guidelines, international LBS issues, such as transfer and processing of data to and in a country other than where the services are being used.
As practical matter, in vetting apps, digital app stores will ask whether or nor the app has LBS capabilities and will want to be assured that, at the very least, the Guidelines are being met.
Lastly, as part of the application submission process, the developer will have the option to include its own mobile EULA to accompany the app, to state the rights and remedies of the consumer and developer with respect to the app.
The distribution or license agreements for each app store are, as one might expect, rather different. One digital app store might require the developer to incorporate certain terms into the mobile EULA. Another might not have any such requirement, but simply provide that if there is conflict between the mobile EULA and the distribution agreement, the latter will govern.
At any rate, each distribution or license agreement with the particular app store should be carefully reviewed.
NB:Â This is a guest article by John Pavolotsky, a practicing legal professional who focuses on technology transactions and other intellectual property matters atÂ Greenberg Traurig.
NB2: Mobile lifeboat image via Shutterstock.