A well-conducted beta test takes a great deal of planning and effort to ensure that you receive valuable feedback and insights and, often, small mistakes or oversights can make the difference between a resounding success and a big flop.
When planning for a beta test, a common mistake made by app developers is not considering the legalities of the test. Just because the app is still in the pre-release phase doesn’t mean that it’s OK to forego the formalities. In fact, it is doubly important for a beta test specifically because it isn’t out of development yet and has not been released to the public.
Beta Test Legal Agreements
The legal agreements used for beta testing are usually combined into one legal document or agreement. While there isn’t a standard naming for this agreement, it is usually called “Beta Participation Agreement” (BPA), “Beta Tester Agreement”, “Pre-release Software Agreement”, or something along those lines.
Besides the legal aspects, getting your beta testers to sign a BPA has many indirect perks. To begin with, it will set your testers’ expectations regarding what to expect from the program and what is required of them. Moreover, formalizing the agreement will help your testers’ appreciate the importance of the roles they are assuming and make them more likely to provide useful feedback.
The non-disclosure agreement (NDA) or clause is imperative for a closed beta to make sure your trade secrets are not revealed to the market before you have validated and perfected your app. In the beta stage, your app will still have some annoying bugs and stability issues to work through. Discussions about these issues should remain private to avoid having them affect how your release version is received; especially since these issues should be resolved by the time you release.
Additionally, even if your app is fairly bug-free and well received, keeping the beta private will give you more control over your marketing message upon release. This lets you control how and when your app is revealed and the messages you are trying to convey through your marketing efforts.
Finally, the NDA establishes the confidentiality of the test and its data. This is where you specify what your testers can talk about and what they should keep to themselves and for how long.
Now let’s take a closer look at the clauses most commonly included in a beta test agreement, their meanings, and importance.
Arrangement and Definitions
This clause introduces the parties involved in the agreement and the arrangement’s desired outcome. It also provides a definition of any special terms used in the agreement. Terms like “beta test”, “beta feedback”, etc. are explained in detail to specify what they refer to throughout the agreement. Here is an example from Paragon Software:
“Scope of this Agreement
The Software-Product accompanying this Agreement as a pre-release copy and all affiliated materials, including documentation and information (collectively the “Product”), is copyrighted. Scope of this agreement is the licensing (not selling) of the “Product” to You, as the ‘user’ (either an individual or an entity). PARAGON reserves all rights not expressly granted.”
Eligibility and Enrollment
You will definitely have some criteria defining who will be eligible to participate in your beta test, and this is where you specify them. A “no-conflict” provision should be included to keep your competitors out of your beta test. You will also want to mention the enrollment channels and process through which your testers can join the program. This clause is often skipped for closed betas since the participating testers have been reviewed and selected by the developer beforehand. However, for an open beta agreement, these rules and mechanisms must be clearly stated and specified. Here is an example from Square Enix:
“Please read and agree to the following terms and conditions, if you wish to be eligible to participate in the Closed Beta Testing. However, we do not guarantee that you will be selected to participate in the Beta Testing.
All applicants are required to have a Square Enix ID prior to submitting their application.
BY SELECTING THE “ACCEPT” BUTTON, YOU ACKNOWLEDGE THAT: (1) YOU ARE 13 YEARS OF AGE OR OLDER, AND IF YOU ARE BETWEEN AGE 13 and 18, YOU HAVE OBTAINED CONSENT FROM YOUR PARENT OR GUARDIAN; AND (2) YOU HAVE READ, UNDERSTOOD, AND ACCEPTED THE TERMS AND CONDITIONS OF THIS AGREEMENT.”
Copyrights and Ownership
Here you will want to establish your ownership of the app, its code, design, trademarks, and any intellectual properties associated with it. You will also want to make it clear that testers are not granted any rights unless they are expressly mentioned in the agreement. Here is an example from Parallels Software:
License and Acceptable Use
Under this clause, you indicate what type of license is granted to the tester and any restrictions that may be put on it. Additionally, this is where the developer needs to specify what constitutes “acceptable use” of the product. For a beta test, a non-exclusive, non-transferable, non-sublicensable, revocable, limited license is a common choice, with the usual restrictions on copying, reverse engineering, and redistribution. As for the use of the product, it should be tied to its documentation and restricted from live data and environments. Here is an example from Atari:
Disclaimer of Liability and Warranties
Also called “Beta Disclaimer”, this clause expressly states that the provided app is licensed “AS IS” and is known to contain bugs and stability issues. Testing is the only purpose behind using the application and the developer disclaims any liability for data loss, damages, or loss of profits incurred through the use of the beta app. Likewise, the developer disclaims all express and implied warranties for the application under test and the tester uses the app at their own risk. Furthermore, since you will be sending beta updates, explicitly stating that they are subject to the same terms is a good idea. Here is an example from Paragoni Apps:
Term and Termination
This is just legal-speak for “duration of beta test”. Here you will want to specify the initial intended duration of your beta test after which the granted license will be terminated. If your beta test is not time-boxed, you will also want to mention extensions to the test and how they will be announced. Moreover, this is where you should establish both parties’ right to terminate this agreement and on what grounds. Generally, in beta test agreements, both parties are granted the right to terminate the agreement for any or no reason upon providing a notice. Here is an example from Talend:
“TERM AND TERMINATION
Unless otherwise terminated as specified under this Agreement. Licensee’s rights with respect to the Beta Software will terminate upon the earlier of (a) the initial commercial release by Talend of a generally available version of the Beta Software or (b) automatic expiration of the Beta Software based on the system date. Either party may terminate this Agreement at any time for any reason or no reason by providing the other party advance written notice thereof. Talend shall immediately terminate this Agreement and any Licensee rights with respect to the Beta Software without notice in the event of improper disclosure of Talend’s Beta Software as specified under Section 6 (Confidentiality) below. Upon any expiration or termination of this Agreement, the rights and licenses granted to Licensee under this Agreement shall immediately terminate, and Licensee shall immediately cease using, and will return to Talend (or, at Talend’s request, destroy), the Beta Software, Documentation, and all other tangible items in Licensee’s possession or control that are proprietary to or contain Confidential Information. The rights and obligations of the parties set forth in Sections 2, 3, 4, 5, 6, 7, 8 9 and 10 shall survive termination or expiration of this Agreement for any reason.”
Feedback is what beta testing is all about, and in this clause, the testers’ feedback responsibilities are specified. In most cases, feedback is explicitly stated to be a responsibility of the tester and mentions some of the expected types of feedback (bug reports, feature requests, etc.). Less often, the clause will include the feedback and reporting channels to be used by the testers. More importantly, developers need to use this clause to acquire the needed licensing over the feedback provided. This is necessary as a legal safeguard before using the feedback in development or marketing. Here is an example from Slitherine:
“BETA TESTERS DUTIES
Beta Tester agrees to report any flaws, errors or imperfections discovered in any software or other materials where Beta Tester has been granted access to the Beta Test. Beta Tester understands that prompt and accurate reporting is the purpose of the Beta Tests and undertakes to use best efforts to provide frequent reports on all aspects of the product both positive and negative and acknowledges that any improvements, modifications and changes arising from or in connection with the Beta Testers contribution to the Project, remain or become the exclusive property of the Disclosing Party”
Confidentiality and Non-Disclosure
Obviously, this clause is only used in closed beta test agreements and is used to maintain its confidentiality. Here, the testers agree to not disclose any information related to the app (features, code, architecture, etc.), or its testing (bugs, crashes, performance, etc.) without prior written consent from the developer. Often, testers also acknowledge that any breach of this clause can cause irreparable damage to which the developer is entitled to injunctive and/or equitable relief. Some provisions are made for information that might be publicly available and the duration through which the NDA remains effective. Additionally, you will want to specify the duration throughout which the NDA will remain in effect and whether it will survive the termination of the agreement and for how long. Here is an example from Syngli:
The Tester will not disclose Software or any comments regarding Software to any third party without the prior written approval of Syngli. The Tester will maintain the confidentiality of Software with at least the same degree of care that you use to protect your own confidential and proprietary information, but not less than a reasonable degree of care under the circumstances. The Tester will not be liable for the disclosure of any confidential information which is:
(a.) in the public domain other than by a breach of this Agreement on Tester’s part; or (b.) rightfully received from a third party without any obligation of confidentiality; or (c.) rightfully known to Tester without any limitation on use or disclosure prior to its receipt from Syngli; or (d.) generally made available to third parties by Syngli without restriction on disclosure.”
You may or may not be providing support for your app to your testers, either way, this is where you list your support terms. Regardless of what level of support you decide to provide, you want to state that it is provided at your sole discretion to assist them in their testing activities. Here is an example from Apple:
“No Support and Maintenance; Future Products.
During your participation in the Beta Program or in a particular seed. Apple is not obligated to provide you with any maintenance, technical or other support for the Pre-Release Software. If. at Apple’s option, such support is provided. it will be provided in addition to your normal warranty coverage for your computer and/or device. You agree to abide by any support rules and policies that Apple provides to you in order to receive such support. You acknowledge that Apple has no express or implied obligation to announce or make available a commercial version of the Pre-Release Software to anyone in the future. Should a commercial version be made available, it may have features or functionality that are different from those found in the Pre-Release Software licensed hereunder.”
Fees and Payment
In case you are not providing the beta app free of charge, this is where you set your payment terms. Specify the price you will be charging and the methods of payment you prefer or accept. On the other hand, paid testers are usually handled by a third-party service. Here is an example from Kony App Playground:
“Fees and Costs
There are no license fees for Licensee’s use of the Beta Product under this Agreement.
Licensee is responsible for all costs and expenses associated with the use of the Beta Product and the performance of all testing and evaluation activities.”
In this clause, the developer establishes his right to modify the terms of the beta agreement and whether that requires the tester’s consent. It should also include the developer’s responsibility, if any, to notify the testers of these changes and the accepted channels for this notification. Generally speaking, the more beta testers you include, the more flexibility you will want to have for modifications. Here is another example from Talend:
This is the entire agreement between the parties relating to the subject matter hereof and all other terms are rejected. No waiver or modification of this Agreement shall be valid unless in writing signed by each party. The waiver of a breach of any term hereof shall in no way be construed as a waiver of any term or other breach hereof. If any provision of this Agreement is held by a court of competent jurisdiction to be contrary to law the remaining provisions of this Agreement shall remain in full force and effect.”
Assignment refers to a party’s right to assign or delegate any of their responsibilities or obligations to other entities. Developers will want to restrict testers from assigning their obligations as it is uncalled for in beta testing. On the other hand, occasionally, the developer might need to delegate some of their responsibility to a third party. In that case, you should establish that in this clause, detailing the obligations you may assign and whether prior consent is required from the tester. Here is an example from Kidizen:
This Agreement is personal to Tester. Tester shall not assign or otherwise transfer any rights or obligations under this Agreement.”
In the event that a court finds any clause or provision in the agreement illegal or unenforceable, severability ensures that only that clause is voided with the rest of the agreement remaining in effect. It can also be drafted to enable a revision of the clause to make it enforceable rather than nullifying it altogether. Here is an example from Ampetronic:
Governing Law and Jurisdiction / Arbitration
Parties entering the beta test agreement can specify their preferred dispute resolution method in this clause. You can specify a venue and jurisdiction where any disputes will be resolved, according to that jurisdiction’s laws. Alternatively, both parties can agree to submit to binding arbitration, where they settle their disputes away from courts through mutually chosen arbitrators. Furthermore, a mix of both approaches can be used, if you specify the arbitration to be non-binding. Here is an example from Splunk:
“CHOICE OF LAW AND DISPUTES
For other than the U.S. Government as a party, this Agreement shall be governed by and construed in accordance with the laws of the State of California. as If performed wholly within the state and without giving effect to the principles of conflict of law rules of any jurisdiction or the United Nations Convention on Contracts for the International Sale of Goods, the application of which is expressly excluded. Any legal action or proceeding arising under this Agreement will be brought exclusively in the federal or state courts located in San Francisco. California and the parties hereby consent to personal Jurisdiction and venue therein.”
Communicating the Beta Participation Agreement
After drafting your Beta Participation Agreement, you need to communicate it to your users and get their legal consent. Generally speaking, you will want to make your BPA available for your users on your website and/or in-app to better track the users’ consent. There are two main approaches you can take:
Conversely, click-wrap agreements use explicit consent and require the user to indicate their consent by clicking a button or checking a box. In this case, users cannot claim that they were unaware of the agreement and are bound by its terms.
While both approaches have their merits, click-wrap agreements offer a legal and a strategic advantage that make them preferable for betas. First, the explicit consent provided by your users prevents situations where they may claim to have not been aware of the agreement notice. In legal precedents, browse-wrap agreements have a much longer record of being found unenforceable since it is up to the court to determine if your notice was conspicuous enough. Second, as we have mentioned before, formalizing the agreement with your testers helps them appreciate the importance of their roles. Click-wrap agreements, by requiring explicit consent, makes your testers more likely to actually read the agreement and comply with it.