Some Assistance with Voice Assistants

Amazon, Apple, and Google are focused on growing the use of their voice assistants (Alexa, Siri, and Google Assistant, respectively). Like with more traditional apps, the business model that companies are pursuing is to drive ubiquity of the platform, and allow developers to create the real value by building voice apps (called “voice skills” for Alexa) or adding voice compatibility to their existing products. The expectation is that over time, users will become increasingly comfortable with voice technology, and voice will replace touch as the default means of interacting with technology. It will replace the touch screen, that replaced the mouse, that replaced the keyboard.  The platform owners will benefit by capturing enormous amounts of data that they will find ways to monetize.

Think about it this way – today, when one of your users goes into your app, that’s a black box to the platform. They know the user is in there, but they generally can’t tell what the user is doing. With the addition of a voice layer, every time a user gives a command the device maker gets a peek into the black box, and learns a bit more about your user.

To a large extent, both developers and platform companies are learning on the fly. It’s hard to predict what types of voice skills people will come up with, what will resonate with consumers, what problems they may encounter, and how courts will resolve those issues. As a result, it’s likely that the voice assistant section of each platform’s developer agreement will be an area of frequent change.


Apple DPLA Updates 6/4/18

Apple released an updated version of their Developer Program License Agreement “DPLA” last night (6/4/18). The most interesting changes are the ones that reflect what’s on the mind of Silicon Valley execs. Based on this latest DPLA, privacy is certainly front of mind for Apple’s leadership post-Cambridge Analytica, and a lot of the changes seem intended to create additional disclosure and protections around how end user data is used. Tim Cook doesn’t want to end up testifying in front of Elizabeth Warren.

• Apple placed a bunch of additional user protections in this latest draft, making it clear that any app that captures image, video, or audio needs to make it clear to the user that they’re capturing it. Whether it’s saved to the cloud or on the device. If you previously obtained consent to capture data and decide to expand what you capture, you will need to go back to the user for additional consent. Also, no more linking to your privacy policy; it needs to live in the App description.

• They also expanded the definition of Face Data. I suspect that we’ll see lots of tweaks to this language over time. Apple is likely still trying to figure out how to manage this data contractually since (i) we’re only at the very beginning of figuring out what facial recognition can do, and (ii) people get really touchy when you say you’re going to make a digital map of their grill

• There are additional clarifications and obligations regarding health records, location, and other categories of data that tend to be more sensitive.

Unrelated to privacy concerns, they’re pushing Apple Pay Cash – looks like Apple is trying to make a real business out of it. They’re also trying to maintain a fair and safe environment. No deceiving customers or unfairly competing with other developers. The management of competition between developers is interesting. Does that extend to the companies they represent? Is Apple in a position to manage the competitive landscape of industries. Probably not.

The Amazon Developer Services Agreement

The Amazon Developer Services Agreement (formerly known as the “App Distribution and Services Agreement”) is Amazon’s standard app developer agreement. Below is a rough outline of what is contained by section. Think of this as the section-by-section, condensed, plain-English version; you’ll want to review the actual document in its entirety! Also, there are many other documents that are incorporated into the main document that may be relevant to your business. Read them! I will try to provide plain-English outlines of those documents in later posts.

Amazon Developer Services Agreement

  1. The Agreement that you’re agreeing to includes not just the body of the document, but also any relevant schedules. A schedule is applicable and becomes a part of the agreement if you engage in the schedules covered activity, so it’s worth reading the schedules to see what applies.
  2. Amazon is acting as a middle-man between end users who purchase, download, and access mobile & non-mobile apps, and the developers that create them.
  3. Amazon makes software (such as SDK, API, etc.) available for Developers to use (remember, they want to seed the Amazon app ecosystem). By using them you agree to the related terms and policies
  4. You agree to comply with all laws and protect personally identifiable information. You will get any user consent you need and respond appropriately to security breaches.
  5. You won’t hack them. You have to promise.
  6. Amazon has no obligation to promote your app, and they have sole discretion related to payments, refunds, and customer service, and sole ownership and control of all sales and other data they get.
  7. You agree to provide Amazon with any app info, logos, images, etc. that they request, and what you provide will be accurate.
  8. You keep all of your rights to your content, Amazon keeps its rights to its own technology and content. Basically, Amazon doesn’t get your IP because you have your app in their App store. You don’t own their SDK or IP because it was used to create your app. If you provide them feedback they can use it for free.
  9. The agreement begins when you click “accept,” and continues until either party terminates. You can terminate after giving Amazon 10-days prior notice. They can terminate the agreement or suspend you at any time. Be careful, your obligation to keep things confidential continues after the agreement is terminated (same with sections 1-6, 8-16).
  10. Representations & Warranties – these are things that you are agreeing are true, and Amazon is basically saying they would not have entered this agreement with you were they not. If they get sued over your app and one of these things turns out to be untrue there will be serious consequences. Some of these are standard, but be sure that you have any rights, copyright, or IP that your app needs (if you don’t know, hire an attorney), that there is no malware in your code.
  11. You agree that if Amazon gets sued over your app, you’ll hire an expensive attorney to defend them, and if you lose, you’ll cover their cost. When larger companies negotiate these they typically indemnify each other. In this case it’s one-sided in Amazon’s favor.
  12. You agree to keep everything confidential. Notice there are no corresponding obligations for Amazon to keep your information confidential (although it’s probably bad business for them to leak a bunch of their developers’ IP).
  13. Trademarks – they’ll let you use their logo etc. but you have to do it according to their guidelines.
  14. Limitation of liability – Amazon is doing the best they can and they won’t be responsible if something they do destroys your app or gets you sued. The max they will pay you is $100. Seriously. Don’t be alarmed by the all-caps, these things are always written that way so they’re “conspicuous.”  
  15. Amazon reserves the right to change the agreement unilaterally. This is one of the tricky things about these agreements; you agree to a set of terms, and down the road Amazon may change those terms. They don’t really have to give you any notice except to post the new terms on the website. The only thing you can do is give them notice that you want to terminate the agreement (remember, 10 days notice from section 9, above).
  16. General – this section is a catch-all containing a bunch of pretty standard legal provisions. Among other things it explains a bit about the relationship between you and Amazon (independent contractors) and says you’re going to pay your taxes. It says that any disputes will be settled using Washington state law. If you need to give official notice of something (for instance, that you’re terminating the agreement, or selling your company).

Why Standardize?

From the platform’s perspective, the two most critical features of the app developer agreement are its one-sidedness and its standardization. The platform companies that draft these agreements understand that few developers will have the size, know-how, or resources to effectively negotiate a fair agreement. Most won’t even know that it’s possible. In addition to the favorable terms that they’re able to secure, it’s important for the platform to have consistency in its agreements with the thousands and thousands of developers. If each of these contracts were unique, the challenge of administering them would quickly become a nightmare.

Take for instance choice of law, a common provision covered in nearly every app developer agreement. Each state in the US has it’s own courts and set of laws. If Google didn’t insist that developers waive their right to sue except in Google’s home state, Google would have to employ teams of lawyers around the country. Does Google have the money to do that? Of course, but it’s very inefficient. At any one time Google might find itself in 50 different courts applying 50 different sets of laws.

Instead, companies like Google just include a paragraph in their app developer agreement that saying that if you want to sue about something related to your app, you have to do it on their home turf. If you’re from South Dakota you’re going to have to say goodbye to the family, hire some expensive Silicon Valley attorneys, and check in to an extended stay hotel. Often this is enough of a pain in the ass that, even if you have a legitimate gripe, you might not sue. If you do, you’ll be facing an attorney who is an expert on California law and probably goes cycling with the judge on the weekends.

Unless you’re Netflix or Uber, choice of law and many other provisions will likely fall into the category of “non-negotiable.” Other standard terms are more often negotiated. The way to secure the best deal is by knowing which terms these are, knowing what to ask for, and having a true understanding of your value to the platform.

The “Apple-Tax”

The Apple App Store is the second largest app store globally, but for developers of apps in the United States, maybe the most important. The agreement that governs the App Store, Apple’s Developer Program License Agreement (or “DPLA”), is high-profile in it’s own right because of the way it impacts corporate decision-making, customer experiences, and the economics of the internet.

Of the nearly 100 pages worth of provisions that make up the DPLA, the only one that has gained public notoriety is the provision outlining the 30% share that Apple retains on any sale made in-app. The Google Play Store and other platforms have similar provisions, and these commissions should be a key strategic consideration. Will you simply sacrifice 30% as the cost of doing business with giants like Apple and Google? Do your margins allow it? Will you charge your customers 30% more for the convenience of purchasing through your app? Is there a demand for your product at that price? There’s no right or wrong answer to these questions, only what’s right for each app developer, CEO, or strategist.

In 2015 Spotify famously decided that it would charge its customers a premium for the convenience of being able to subscribe to its music streaming service on an Apple device. They were very open about it, going so far as to provide instructions on how to sign up at a lower price, or switch a more expensive subscription to a less expensive one. Generally it’s not a good idea to answer the question “how much does your service cost?” with, “it depends what device you buy it on,” but Spotify had already established a loyal fan base of millions, and could afford to muddy its marketing message a bit.

Spotify also has real costs. If you sell additional features in your dating app, or virtual currency in your game, the 30% commission probably won’t kill your business. If you sell subscriptions to a music service, and have to pay music labels for their artists’ most popular content, 30% might put your business underwater. An alternative to consider is building a companion website where your customers can transact and manage their accounts. While a companion website is great for avoiding the Apple tax, it adds a considerable amount of friction to any purchase flow. Attention spans are short, and if your slot machine gamer just spent his last virtual dollar and is jonesing for another pull, taking him out of your app to enter credit card information on a website will result in less money spent.

The moral of the story is to carefully consider your app’s user experience, margins, and brand loyalty before deciding whether to accept in-app purchases and pay the “Apple tax,” or not.

Screen shot 2018-06-03 at 7.39.55 PM