Program Agreements

Read first: OAuth Activation | Read next: Payments

Program agreements are a must-have for any app marketplace. They set clear expectations for users and app developers, and provide a point of reference in case of any disputes.

Like any other legal document, program agreements should be created on a case-by-case basis, under the guidance of a team of lawyers. Nevertheless, this page provides an overview of the two types of program agreement:

  • User Agreements

  • Developer Agreements

User Agreements

User agreements for an app marketplace, more commonly known just as Terms and Conditions, Terms of Use, or Terms of Service, outline what the user should expect from an app marketplace.

Platform owners should already have an existing user agreement that governs their platform before launching an app marketplace. Additional terms that relate specifically to the use of the app marketplace can be added to this user agreement, or collected in a separate app marketplace user agreement.

In either case, terms in the existing user agreement may need to be expanded or modified with the launch of an app marketplace. For example, information and terms about what, how, and why data will be shared with apps created by third-party developers should be added.

Common Terms

  • App responsibility. Users should know that some apps are created by third-party developers. They should know that the platform owner does not take responsibility for these apps, but may still promote, share data with, and enforce agreements relating to them.

  • Payment terms. Users should know how — and especially by whom — payments for first- and third-party apps will be handled.

  • Cancellation disclaimers. Users should know that the platform owner retains the right to close, cancel, or deactivate any apps, user accounts, developer accounts, or even the marketplace as a whole.

Format

Like elsewhere on the web, user agreements are often formatted as browsewrap or clickwrap agreements. They can be presented to the user when first accessing the marketplace, or when signing up to the platform. They may also be linked to in the footer section of the marketplace.

Examples

Developer Agreements

Developer agreements, also known as Partner Agreements, Developer Terms, or Marketplace Terms, outline what the developer should expect from an app marketplace and what they are responsible for.

Platform owners rarely have an existing developer agreement before launching an app marketplace, so the marketplace developer agreement is usually a standalone document.

Common Terms

  • Brand/marketing guidelines. Developers should know how they can and cannot market themselves and their apps. They should know how they can represent themselves in relation to the platform, and what platform names and assets (such as logos) they can use.

  • App responsibility. Developers should know that they will be held responsible for the content of their apps, as well as their apps' security, privacy, and other traits.

  • Payment terms. Developers should know what, how, and when they will be paid for their paid apps, including how taxes will be handled. They should know what to expect in case of any refunds, upgrades, or other events or changes.

  • Cancellation disclaimers. Like users, developers should know that the platform owner retains the right to close, cancel, or deactivate any apps, user accounts, developer accounts, or even the marketplace as a whole.

  • Cancellation terms. Developers should know what to expect if their marketplace account is cancelled.

Format

Like user agreements, developer agreements can be formatted as browsewrap or clickwrap agreements, which are displayed when signing up to the marketplace or submitting an app.

Alternatively, platform owners may require developers to sign a developer agreement when signing up to the marketplace, often using an eSignature solution like DocuSign.

Examples

What's Next?

We've discussed what program agreements usually include and how they are formatted. On the next page — Payments — we'll look at how to handle payments.