Mobile App Developer Agreements

Given the breadth of functions and services apps can perform, it is helpful to undertake a needs assessment to establish what purposes the app should serve. Depending upon the app's purpose and how much control, customization and exclusivity the company wants, it may decide that rather than having a custom app developed, the lower cost, ease of scalability and simple approach of white-labeling a generic app made available as a software-as-a-service (SaaS) offering is a better approach. In either case, vendors will be better able to propose the potential solutions that the company may want to consider if they have a clear understanding of purposes and goals. This will also make comparison of proposals from competing vendors more relevant. Further, given the data privacy and security implications inherent in apps, companies should access the privacy and data protection impacts of a potential app and strive to minimize the impact on user privacy and of the potential for harm arising out of a data security breach.

Use the RFP and Scoping Processes Wisely

While RFPs can be time-consuming, the process is an opportunity to pre-establish desired deliverables, including material business and legal expectations, as well as to undertake due diligence on the vendor's track record, quality assurance process, data protection and service continuity programs and controls and its relevant resources and capabilities. Finally, as the standard agreements for app developers are weighted heavily in the vendor's favor, ask for a copy with the RFP response that includes the “gives” that have been agreed to with other clients in comparable transactions and explain that an agreement that is overreaching will be considered against the developer in the vendor selection process. Vendor references should also be checked.

Also, consider simultaneously negotiating with the two top RFP respondents so you are not stuck if the agreement negotiation does not yield commitments to the expectations that were called for in the RFP, or at least have a second choice you can turn to if negotiations with the first choice fall apart. Another approach is to engage one or more vendors for an initial scoping and blueprinting project, essentially a paid consulting arrangement where the vendor conducts the needs assessment discussed above and proposes one or more detailed solutions and the pricing thereof. For SaaS vendors, you can typically obtain a trial license to test out the app.

Think of scoping as the pre-development design process where the user experience is designed and illustrated using wireframes, user flows, data maps and design comps. With all this established, pricing, schedule and deliverables will be more reliable.

Carefully Define Fees

The scope of the services, as well as the deliverables specifications and any third-party platform interoperability (e.g., Apple iOS, Android, Windows mobile, Facebook, etc.), scalability, features, functions and interface requirements, and any permitted dependencies that limit the vendor's responsibilities, are material business points that should have been called out in the RFP or established during scoping. At a minimum, they need to be carefully articulated in the development phase agreement, and the definition of key elements (such as vendor software, third-party software, components, specifications, documentation, and interoperability) are crucial and determine what will be delivered for the contracted price and what the vendor will be responsible for or not.

The fees for the various services and deliverables should also be well defined, advisably payable at milestones, with approval and termination rights at each milestone. Beware of hidden fees and add-ons, such as implementation fees related to “free” enhancements or updates. A change-order process should also be agreed upon to address inevitable changed circumstances, and it is preferable to lock in rates for change orders in advance. Make clear what third-party license fees and other costs (e.g., third-party software, photos and other content, SSL Certificates, app store registrations, etc.) are included or excluded. Clarify who will be responsible for obtaining platforms' and distributors' approval of the app. If the company will be operating the app itself, it will need all developer's manuals and other information necessary to operate, update and revise the app. If the vendor will undertake to operate the app, those obligations need to be included, and a transition process should be established.

Pay Attention to IP

The licenses to any vendor technology should be as broad as justifiable under the circumstances, including permitting future versions of the app (excepting SaaS), even if the developer is no longer involved. The vendor should only have the ability to use the company's materials and marks for purposes of performing its obligations. For custom content and software development, articulate who owns the new creations and what the non-owner can do with the new intellectual property. Where deliverables are owned by the company, the developer will likely want some kind of license back, at least of generic tools and utilities, for use with other clients. Where this is accepted, a company may want to limit the scope of the license, especially for material features and functionality, at least as to its competitors.

If the company is expecting to obtain proprietary deliverables that it owns and controls, it also needs to consider how use of open-source software in the creation of those deliverables may result in the derivative software being required to be made available to the open source community. It may want to restrict use of “copyleft” software. Finally, particularly given the many patent “troll” claims associated with the features and functionality of mobile apps, it needs to be specified who is responsible, and to what extent, for claims that the app infringes third-party rights and what the parties' obligations are with respect to clearing and working around conflicts.

Address Data Protection

Apps necessarily collect, generate, process, store and transfer data. The contract needs to specify what data is to be available, and on what basis, which will require consultation with the company's app stakeholders. Establish who owns what data and who can use what data for what purposes. Typically, there will be numerous third parties (e.g., ad networks, social media plug-ins, analytic vendors, etc.) that are integrated into the app and have access to and collect app data. All these data practices have regulatory data privacy and security implications. The company must understand and approve all vendor and third party data practices, as well as its own, as it will ultimately be responsible for regulatory violations, including practices inconsistent with the privacy notice provided to app users, and data security breaches associated with the app.

Where developers and other third parties are permitted to use certain app data for their own purposes, consider appropriate limitations such as limiting use to non-individualized, anonymous, aggregate data, not attributable to the company, and restrictions on providing even that data to certain competitors.

Companies have a host of privacy and data security obligations that will apply to their apps, including regarding personally identifiable information and usage data of consumers, credit card data, use of the app to track user activities or location, accessing users' phone and third-party services account data, app-enabled communications and ad serving. The company is ultimately responsible to data subjects and regulators for its vendors and others that have app data access. The company's overall data risk assessment should be applied to each such third party.

In addition, information governance obligations should be specified, including data segregation, residency, redundancy and backup obligations and response times for providing access to or delivering stored data, and in what formats and cost, and for its retention and destruction and certification of destruction. Residency is particularly important for cloud services and other outsourced processing and storage, since many countries outside of the U.S. prohibit data access from, or transfer to, the U.S. absent commitments to data practices that exceed U.S. legal standards, even if the data originated from the U.S. Address redundancy and backup by permitting the company to periodically back up its data on its own, or another vendor's, servers.

The company has a legal obligation to post a complete and accurate description of its data practices related to app data on the app and in the app store, an obligation that mobile platform providers such as Apple and Google/Android additionally require. Specific disclosures and consumer choices may be applicable under privacy laws (e.g., California and international consumer privacy laws and federal e-mail and text communications laws and the federal children's privacy law). A thorough understanding of the data practices is necessary to meet these obligations. It is also a good idea to have an end user agreement for app users, which will include terms protective of the company and licenses and consents from the user. Privacy policies and Terms of Use are not cookie-cutter, and companies should engage their own lawyers to develop these documents rather than rely on example forms the developer may provide. SaaS vendors may want app users to also accept the vendor's privacy policy and terms of use, and the impact of that should be considered.

Companies have a legal duty to maintain reasonable security of user data, a contractual obligation to secure credit card data, and have notification obligations to data subjects and regulators under state laws in the event of a breach of security of certain types of personal information. Accordingly, the vendor agreements need to provide for vendors to give the company immediate notice of suspected incidents, and spell out the vendors' cooperation and remediation obligations.

Establish Milestone, Testing, Approval and Revision Terms

Performance can be broken out based on deliverable obligations at various milestones. Each milestone can have detailed deliverable specifications and a submission, testing and acceptance process. Consider outside vendors if you lack the internal competency to undertake the testing and acceptance, and to perform a security assessment in-house. The company should have the right to request revisions until acceptance is obtained, and the ability to terminate for cause if acceptance cannot be timely obtained with minimal revisions. Penalties can also be provided for in the event of schedule delays. Consider also an ability to terminate without cause at each milestone, which can sometimes come with a kill fee.

Obtain Guarantees and Warranties

The agreement should establish minimum acceptable levels of performance, consistent with detailed specifications and free of material errors or downtime other than during established scheduled maintenance. Following a typically limited warranty period, a maintenance contract will likely be required to continue the service warranty and/or a service-level commitment. Beware of exclusions to maintenance obligations. Maintenance should include doing everything necessary to maintain compatibility with crucial third-party equipment and software, as such may change or be updated or enhanced. Maintenance contracts can also include app enhancements and improvements, especially up to a certain time allotment not otherwise used to perform routine maintenance.

A service level guaranty through a Service Level Agreement should spell out how acceptable service and downtime will be measured, ways the vendor will minimize service outages, how problems are reported and managed, a communications escalation procedure, the minimum time for the vendor to respond, and how it will solve problems of differing severity level issues. Vendors should also provide for credits for failures and a termination right for chronic failures. The more critical the system, the higher the service level commitment should be and the more severe the remedies for failing to meet it. Dedicated contact persons or numbers available 24/7/365 are recommended, as is a ticketing system and regular reporting on ticket status while issues are being remedied.

The company should seek the service warranty to include compliance with functional, performance, and compatibility specifications, virus and malware protection, and prevention of unauthorized access or use. Additional warranties related to legal and self-regulatory compliance obligations, non-infringement, confidentiality and interoperability should be sought.

Negotiate the Liability, Remedies, Insurance and Indemnity Terms

Contracts should clarify which party is responsible under what circumstances with respect to compliance with law, third-party infringement claims and data protection. Remedies limited to fees paid to the vendor (often for a partial look-back such as six months) offer inadequate protection for continuity, data protection and integrity, compliance with law and intellectual property infringement risks, and for failure to fulfill confidentiality obligations. Damages arising out the vendor's breach of representations, warranties and obligations related to such matters should ideally not be capped or subject to other damages limitations. This is often one of the most hotly negotiated points, with the vendor arguing that the pricing assumes that it will have limited liability and the company countering that the vendor must be stand behind its core obligations. Where these lines are drawn will depend on leverage. Accordingly, setting expectations on these issues as part of the RFP can help minimize the negotiations.

Some intellectual property infringement and errors and omissions risk, and increasingly data privacy and security incident risk, may be insured by vendors, and agreements can require certain specified types and levels of coverage be maintained with the company added as a named additional insured. The company can itself insure against these risks, but policy terms need to be carefully checked as exclusions and limitations can affect the practical value of such coverage. It is recommended that company policies pre-qualify the company's law firm of choice (and its rates) as acceptable under defense and incident response coverage.

Plan for Changes, Transitions and Termination

Obtain termination rights for material breaches, chronic service failures, undesired vendor changes and changes in your own circumstances and legal obligations. Understand that the mobile space is fast-moving ' only a few years ago, BlackBerry, now essentially gone, was a dominant platform and Android, now on par with Apple, was just getting started. SaaS vendors will not want to commit to particular interoperability long term, but should permit a termination if the company is not satisfied with how the SaaS app changes over time. Owned apps are likely to be in need of constant updating and revision, and the company needs the documentation and other know-how to be able to do that even without the vendor. Consider a termination for convenience right, even if it includes a reasonable kill fee, especially for SaaS engagements where milestones are less important. Provide for an orderly exit process on termination, including appropriate transition support and data delivery or destruction.

Conclusion

Taking these considerations into account will help a company appropriately set and codify the parties' respective obligations. Thereafter, IT vendor management should be employed to ensure that vendors perform and comply and that changes in the vendor's or the company's business or legal obligations are evaluated and mitigated as necessary. A strong and flexible agreement will make doing so easier.

Alan Friel, CIPP and CIPM, is a partner at Baker Hostetler in its Los Angeles office and a member of this newsletter's Board of Editors. He may be reached at [email protected].

Many companies that have had disputes with developers have been surprised to discover that the agreements signed, often without input from legal, failed to hold developers to measurable standards, give the company ongoing interest in deliverables, or provide meaningful remedies to problems that arise.

Company legal counsel and information technology (IT) professionals can take steps to protect the company. Before a vendor is even selected, the company should develop needs and privacy impact assessments to guide procurement in a manner that is consistent with business goals and its legal compliance obligations. These may include accessibility alternatives for the disabled (http://bit.ly/1VOqGh6), notice and choice for sharing certain app or device data with third parties, including for interest-based advertising (http://bit.ly/1N8XTle), and other requirements. A request for proposal (RFP) process based on the assessments can help in the selection of a vendor, development of specifications and deliverables, and clarify which party is responsible for what. It is crucial, then, to carefully scrutinize and negotiate the boilerplate of the developer's agreement and its ancillary documentation in order to assure that the company's expectations are reflected and can be enforced.

Assess Needs and Privacy

Given the breadth of functions and services apps can perform, it is helpful to undertake a needs assessment to establish what purposes the app should serve. Depending upon the app's purpose and how much control, customization and exclusivity the company wants, it may decide that rather than having a custom app developed, the lower cost, ease of scalability and simple approach of white-labeling a generic app made available as a software-as-a-service (SaaS) offering is a better approach. In either case, vendors will be better able to propose the potential solutions that the company may want to consider if they have a clear understanding of purposes and goals. This will also make comparison of proposals from competing vendors more relevant. Further, given the data privacy and security implications inherent in apps, companies should access the privacy and data protection impacts of a potential app and strive to minimize the impact on user privacy and of the potential for harm arising out of a data security breach.

Use the RFP and Scoping Processes Wisely

While RFPs can be time-consuming, the process is an opportunity to pre-establish desired deliverables, including material business and legal expectations, as well as to undertake due diligence on the vendor's track record, quality assurance process, data protection and service continuity programs and controls and its relevant resources and capabilities. Finally, as the standard agreements for app developers are weighted heavily in the vendor's favor, ask for a copy with the RFP response that includes the “gives” that have been agreed to with other clients in comparable transactions and explain that an agreement that is overreaching will be considered against the developer in the vendor selection process. Vendor references should also be checked.

Also, consider simultaneously negotiating with the two top RFP respondents so you are not stuck if the agreement negotiation does not yield commitments to the expectations that were called for in the RFP, or at least have a second choice you can turn to if negotiations with the first choice fall apart. Another approach is to engage one or more vendors for an initial scoping and blueprinting project, essentially a paid consulting arrangement where the vendor conducts the needs assessment discussed above and proposes one or more detailed solutions and the pricing thereof. For SaaS vendors, you can typically obtain a trial license to test out the app.

Think of scoping as the pre-development design process where the user experience is designed and illustrated using wireframes, user flows, data maps and design comps. With all this established, pricing, schedule and deliverables will be more reliable.

Carefully Define Fees

The scope of the services, as well as the deliverables specifications and any third-party platform interoperability (e.g., Apple iOS, Android, Windows mobile, Facebook, etc.), scalability, features, functions and interface requirements, and any permitted dependencies that limit the vendor's responsibilities, are material business points that should have been called out in the RFP or established during scoping. At a minimum, they need to be carefully articulated in the development phase agreement, and the definition of key elements (such as vendor software, third-party software, components, specifications, documentation, and interoperability) are crucial and determine what will be delivered for the contracted price and what the vendor will be responsible for or not.

The fees for the various services and deliverables should also be well defined, advisably payable at milestones, with approval and termination rights at each milestone. Beware of hidden fees and add-ons, such as implementation fees related to “free” enhancements or updates. A change-order process should also be agreed upon to address inevitable changed circumstances, and it is preferable to lock in rates for change orders in advance. Make clear what third-party license fees and other costs (e.g., third-party software, photos and other content, SSL Certificates, app store registrations, etc.) are included or excluded. Clarify who will be responsible for obtaining platforms' and distributors' approval of the app. If the company will be operating the app itself, it will need all developer's manuals and other information necessary to operate, update and revise the app. If the vendor will undertake to operate the app, those obligations need to be included, and a transition process should be established.

Pay Attention to IP

The licenses to any vendor technology should be as broad as justifiable under the circumstances, including permitting future versions of the app (excepting SaaS), even if the developer is no longer involved. The vendor should only have the ability to use the company's materials and marks for purposes of performing its obligations. For custom content and software development, articulate who owns the new creations and what the non-owner can do with the new intellectual property. Where deliverables are owned by the company, the developer will likely want some kind of license back, at least of generic tools and utilities, for use with other clients. Where this is accepted, a company may want to limit the scope of the license, especially for material features and functionality, at least as to its competitors.

If the company is expecting to obtain proprietary deliverables that it owns and controls, it also needs to consider how use of open-source software in the creation of those deliverables may result in the derivative software being required to be made available to the open source community. It may want to restrict use of “copyleft” software. Finally, particularly given the many patent “troll” claims associated with the features and functionality of mobile apps, it needs to be specified who is responsible, and to what extent, for claims that the app infringes third-party rights and what the parties' obligations are with respect to clearing and working around conflicts.

Address Data Protection

Apps necessarily collect, generate, process, store and transfer data. The contract needs to specify what data is to be available, and on what basis, which will require consultation with the company's app stakeholders. Establish who owns what data and who can use what data for what purposes. Typically, there will be numerous third parties (e.g., ad networks, social media plug-ins, analytic vendors, etc.) that are integrated into the app and have access to and collect app data. All these data practices have regulatory data privacy and security implications. The company must understand and approve all vendor and third party data practices, as well as its own, as it will ultimately be responsible for regulatory violations, including practices inconsistent with the privacy notice provided to app users, and data security breaches associated with the app.

Where developers and other third parties are permitted to use certain app data for their own purposes, consider appropriate limitations such as limiting use to non-individualized, anonymous, aggregate data, not attributable to the company, and restrictions on providing even that data to certain competitors.

Companies have a host of privacy and data security obligations that will apply to their apps, including regarding personally identifiable information and usage data of consumers, credit card data, use of the app to track user activities or location, accessing users' phone and third-party services account data, app-enabled communications and ad serving. The company is ultimately responsible to data subjects and regulators for its vendors and others that have app data access. The company's overall data risk assessment should be applied to each such third party.

In addition, information governance obligations should be specified, including data segregation, residency, redundancy and backup obligations and response times for providing access to or delivering stored data, and in what formats and cost, and for its retention and destruction and certification of destruction. Residency is particularly important for cloud services and other outsourced processing and storage, since many countries outside of the U.S. prohibit data access from, or transfer to, the U.S. absent commitments to data practices that exceed U.S. legal standards, even if the data originated from the U.S. Address redundancy and backup by permitting the company to periodically back up its data on its own, or another vendor's, servers.

The company has a legal obligation to post a complete and accurate description of its data practices related to app data on the app and in the app store, an obligation that mobile platform providers such as Apple and Google/Android additionally require. Specific disclosures and consumer choices may be applicable under privacy laws (e.g., California and international consumer privacy laws and federal e-mail and text communications laws and the federal children's privacy law). A thorough understanding of the data practices is necessary to meet these obligations. It is also a good idea to have an end user agreement for app users, which will include terms protective of the company and licenses and consents from the user. Privacy policies and Terms of Use are not cookie-cutter, and companies should engage their own lawyers to develop these documents rather than rely on example forms the developer may provide. SaaS vendors may want app users to also accept the vendor's privacy policy and terms of use, and the impact of that should be considered.

Companies have a legal duty to maintain reasonable security of user data, a contractual obligation to secure credit card data, and have notification obligations to data subjects and regulators under state laws in the event of a breach of security of certain types of personal information. Accordingly, the vendor agreements need to provide for vendors to give the company immediate notice of suspected incidents, and spell out the vendors' cooperation and remediation obligations.

Establish Milestone, Testing, Approval and Revision Terms

Performance can be broken out based on deliverable obligations at various milestones. Each milestone can have detailed deliverable specifications and a submission, testing and acceptance process. Consider outside vendors if you lack the internal competency to undertake the testing and acceptance, and to perform a security assessment in-house. The company should have the right to request revisions until acceptance is obtained, and the ability to terminate for cause if acceptance cannot be timely obtained with minimal revisions. Penalties can also be provided for in the event of schedule delays. Consider also an ability to terminate without cause at each milestone, which can sometimes come with a kill fee.

Obtain Guarantees and Warranties

The agreement should establish minimum acceptable levels of performance, consistent with detailed specifications and free of material errors or downtime other than during established scheduled maintenance. Following a typically limited warranty period, a maintenance contract will likely be required to continue the service warranty and/or a service-level commitment. Beware of exclusions to maintenance obligations. Maintenance should include doing everything necessary to maintain compatibility with crucial third-party equipment and software, as such may change or be updated or enhanced. Maintenance contracts can also include app enhancements and improvements, especially up to a certain time allotment not otherwise used to perform routine maintenance.

A service level guaranty through a Service Level Agreement should spell out how acceptable service and downtime will be measured, ways the vendor will minimize service outages, how problems are reported and managed, a communications escalation procedure, the minimum time for the vendor to respond, and how it will solve problems of differing severity level issues. Vendors should also provide for credits for failures and a termination right for chronic failures. The more critical the system, the higher the service level commitment should be and the more severe the remedies for failing to meet it. Dedicated contact persons or numbers available 24/7/365 are recommended, as is a ticketing system and regular reporting on ticket status while issues are being remedied.

The company should seek the service warranty to include compliance with functional, performance, and compatibility specifications, virus and malware protection, and prevention of unauthorized access or use. Additional warranties related to legal and self-regulatory compliance obligations, non-infringement, confidentiality and interoperability should be sought.

Negotiate the Liability, Remedies, Insurance and Indemnity Terms

Contracts should clarify which party is responsible under what circumstances with respect to compliance with law, third-party infringement claims and data protection. Remedies limited to fees paid to the vendor (often for a partial look-back such as six months) offer inadequate protection for continuity, data protection and integrity, compliance with law and intellectual property infringement risks, and for failure to fulfill confidentiality obligations. Damages arising out the vendor's breach of representations, warranties and obligations related to such matters should ideally not be capped or subject to other damages limitations. This is often one of the most hotly negotiated points, with the vendor arguing that the pricing assumes that it will have limited liability and the company countering that the vendor must be stand behind its core obligations. Where these lines are drawn will depend on leverage. Accordingly, setting expectations on these issues as part of the RFP can help minimize the negotiations.

Some intellectual property infringement and errors and omissions risk, and increasingly data privacy and security incident risk, may be insured by vendors, and agreements can require certain specified types and levels of coverage be maintained with the company added as a named additional insured. The company can itself insure against these risks, but policy terms need to be carefully checked as exclusions and limitations can affect the practical value of such coverage. It is recommended that company policies pre-qualify the company's law firm of choice (and its rates) as acceptable under defense and incident response coverage.

Plan for Changes, Transitions and Termination

Obtain termination rights for material breaches, chronic service failures, undesired vendor changes and changes in your own circumstances and legal obligations. Understand that the mobile space is fast-moving ' only a few years ago, BlackBerry, now essentially gone, was a dominant platform and Android, now on par with Apple, was just getting started. SaaS vendors will not want to commit to particular interoperability long term, but should permit a termination if the company is not satisfied with how the SaaS app changes over time. Owned apps are likely to be in need of constant updating and revision, and the company needs the documentation and other know-how to be able to do that even without the vendor. Consider a termination for convenience right, even if it includes a reasonable kill fee, especially for SaaS engagements where milestones are less important. Provide for an orderly exit process on termination, including appropriate transition support and data delivery or destruction.

Conclusion

Taking these considerations into account will help a company appropriately set and codify the parties' respective obligations. Thereafter, IT vendor management should be employed to ensure that vendors perform and comply and that changes in the vendor's or the company's business or legal obligations are evaluated and mitigated as necessary. A strong and flexible agreement will make doing so easier.

Alan Friel, CIPP and CIPM, is a partner at Baker Hostetler in its Los Angeles office and a member of this newsletter's Board of Editors. He may be reached at [email protected].