My original Don't Sweat the Small Print post back in 2011 consistently sees the highest traffic of anything I have written on this blog, which I guess means that people are still thinking about the End User Licence Agreement issue for mobile apps.
I have also had quite a few specific questions and comments about how to deal with EULAs.
I have tried to pick these up in the comments section, but there is one issue which I think is big enough to merit a follow-up post:-
how do you make sure your EULA is binding on the user?
The original post was Apple-centric (and so is this one), but the general contract law bits apply to Google Play, Android apps and other platforms just as they do to the iOS App Store.
There are a lot of ways you can bring your EULA to the user's attention. These are the ones I can think of, in (roughly) ascending order of how effective they are:-
- A link in the app to the terms
- A link in the App Store description to the terms
- Including your EULA in the bespoke EULA field in iTunes Connect
- Including the text of your EULA in the app description
- One or other of 1-4 plus forcing acceptance of the EULA when the app is first launched
- One or other of 1-4 plus forcing a scroll-through of the EULA followed by acceptance when the app is first launched
Items 2 and 3 above are pretty similar. There aren't that many apps which use the EULA field in the App Store, but an example is Candy Crush for iOS. If you look at the description for this on the App Store, you will see the following link to the terms and conditions of use.
Clicking on the Licence Agreement tab takes you to the set of terms and conditions.
I actually think this is stronger than just including a link, because it takes advantage of a specific process within the App Store which is aimed at drawing attention to EULA terms.
There isn't any specific legal authority on this, but using a specific process provided by the App Store may be more robust than simply including a link in the app description to terms which are hosted on your own site. The argument is that users should be aware that an entry in the EULA field means that additional terms apply (whether this is true or not is anyone's guess though).
In an ideal world, the Apple standard Licensed Application End User Licence Agreement would have a clause which stated that any clauses in the EULA field in iTunes automatically formed part of your licence agreement; however, I can't see that this is covered anywhere.
Instead, is states that the standard agreement will be displaced by any "valid end user licence agreement" formed between the publisher and the user.
This all matters because your EULA won't be "valid" unless it actually forms part of your contract with the user.
Some of the case law on this dates from well before the internet, but the basic principles haven't changed that much since 1949 and the case of Olley v Marlborough Court Hotel.
The judgement in that case lists the three ways in which you can prove that a user (or a hotel guest in this case) has agreed to be bound by terms and conditions:-
A written document signed by the party to be bound
Handing [the party] before or at the time of the contract a written notice specifying its terms and making it clear to him that the contract is on those terms.
A prominent public notice which is plain for [the party] to see when he makes the contract.
It isn't hard to map the list of methods for accepting a mobile app EULA at the start of this post onto these options.
For some more recent guidance from the Courts, you can look at Spreadex v Cochrane from 2012.
The best lesson from this case is actually not to leave your kids with unsupervised access to your spread betting account. However, these is also some useful comment on how (and how not) to get users to agree to terms.
The Spreadex site had a statement telling the user that the "Customer Agreement" could be viewed via a link and that the user should only click Agree once they had read and understood it.
The Customer Agreement was 49 pages of small print and the Court commented that this was
"...an entirely inadequate"
way of bringing important terms to the user's attention and that it would have been "close to a miracle" if the user had actually read the entire agreement.
One factor here was that the terms which Spreadex sought to rely on were very onerous for the user (in effect seeking to make him liable for £50,000 in unauthorised trades).
The more painful the term for the user, the more effort the developer will need to make to bring it to their attention. It could be that less important terms could be validly incorporated into a contract using the process adopted by Spreadex.
Without delving too deep into the case law, it is worth looking at the judgement in Interfoto Picture Library Ltd v Stiletto Visual Programmes Ltd where Lord Justice Bingham pointed out that where the contract term is:
"[not] usual in that class of contract, a defendant must show that his intention to attach an unusual condition of that particular nature was fairly brought to the notice of the other party..."
This case is from 1987 (in the days where you ordered photos from a picture library and they were delivered to you by hand in a jiffy bag), but the principle still applies.
There is clearly a risk vs reward equation here.
The safest thing would be to force the user to scroll through your whole EULA line by line and click to accept each one (maybe followed by a multiple choice quiz to confirm they understood it). However, the impact on the user experience will probably mean that nobody ever uses the app.
For high risk apps where you are seeking to impose important terms and conditions (like the Spreadex example) it would be appropriate to compromise by presenting the user with the EULA onscreen and requiring them to accept it before they can use the app.
For paid apps, this raises the question of what happens if users refuse to accept the terms after they download the app.
Strictly speaking, the App Store terms state that all sales are final other than in very limited circumstances. In practice, the ability to obtain a refund is wider provided there is a genuine reason, but it isn't clear whether an App seeking to impose unacceptable terms and conditions would be covered.
Even if users can obtain a refund via the App store, this is likely to involve them in some time and effort and leave you with unhappy users and bad publicity.
So why not also include any important or unusual terms in the App Store itself before the download takes place? The official EULA field seems like the best way to do this, but setting the terms out in the description should also have the same legal effect.
There is a second reason to do this, which relates to timing. As in the Olley v Malborough Court Hotel case, any terms you want to include need to be made available to the user before the contract with them is formed. If you don't make them available until after they have downloaded (and paid for) the app, then there is a risk that this could be too late.
In the worst case, this could mean that refusing to allow the customer to use the app unless they accept further terms and conditions which are only put forward once they have paid and downloaded could put you, as the publisher, in breach of contract.
To cut this all down to something manageable, there are three main principles:-
- Risk assessment: How important and unusual are your terms? How much does it matter if they bind the user? Where the risk is high, consider using both the methods below.
- Make the terms available before the contract is formed (ideally via the official EULA field in the App store).
- Require the user to read the terms and click to accept before they can use the app.
This post is already long enough, but one more thing to think about. Even if you do all of this, some terms will always be invalid anyway (for example if they seek to exclude liability for personal injury or death caused by your negligence) and some may be invalid because they are unreasonable... particularly where the user is a consumer.
I will cover this in more detail in another post, but for now it is enough to be aware that just because you validly incorporate terms doesn't mean that you can impose anything you like on the user.