Status This document represents the final deliverable of the TOS/EULA task force, and was accepted by the Steering Committee on December 15, 2009.  At that point, the group decided that our goal was to help companies develop a Portability Policy.  The "EULA & TOS Task Force" ended, considered a success, and was replaced by the Portability Policy Working Group.

Introduction

The model we use for agreements between people and products comes from a time when the average person didn't need to deal with very many of them.  Developing software was complex and expensive so there weren't that many choices.  Online, the place where you got your email was generally where you spent most of your time, and companies added ever more features and services to keep you from going anywhere else.  Offline, you used whatever word processor or spreadsheet that your company chose and, in general, everyone you dealt with used the same one.  The practical outcome of this was that you didn't need agreements with a lot of companies and your data wasn't moving around very much. Until four or five years ago, this was the accepted model of how software was used, but it no longer matches how we use our computers.

New designs, faster chips, and cheap networking changed all that.  Only a few years ago, we purchased software for a task and expected the basic program to provide all of the features we wanted.  Today, we routinely use things that are cobbled together with bits and features from many providers, extended with plugins, and automated with scripts.   A dozen of companies might be involved in even the simplest operations.  Every Facebook application is from a different company.  Any page you look at might have ads, features, or tracking codes from a host of sources.   Data is whizzing all over the place without you even realizing it. You've made an agreement with each of those companies but do you know what you've agreed to?  Do you even know who they all are?

The existing TOS / EULA model assumes that you've made an informed decision to use all of these products.  The ad servers, the tracking codes, the plugins, all of it.  In the days when we dealt with three or four companies, this might have been a reasonable expectation but today it's not.  It's no longer reasonable to assume that a person has read and understood the terms of every component included with every product they use - and can follow all of the ways that they change - because there are simply too many.  Each is different.  Almost all are written in complex, legal language.

The goal of the ToS/EULA task force of the DataPortability Project is to create a range of standard portability terms and license clauses that improve communication between people and service providers. We plan to provide standard marks and icons so people can determine at a glance whether the product meets their needs, and product owners can be confident that customers really understand and agree to the terms.

We do not seek to enforce any particular business practice or technology. Rather, we want to open and simplify communication so people make informed choices, enabling market forces to help products meet demand more effectively.

Following the example of the Creative Commons, the goal of this task force is to identify and provide standard names for key concepts that help people and service providers understand what each expects from the other. These will be supported by legal documents that can be referenced or included as additional modules in existing ToS, EULA and Privacy agreements. A tool will help the product or site owner choose among the options, and will provide appropriate icons and language after they have answered a few questions.

By providing people with standard terms and concepts, we give them something to ask for. We give them specific requests that they can make of the product providers, rather than negotiating separately with each.  Portability policy gives products another way to compete for customers and offers people a new basis for comparing and choosing services.

We encourage providers to adopt standard, plain language policies determining how data and digital objects can be moved from product to product. We believe people wish to know what they can do with their data and who can access it. By following the approach we outline below, we create a way to communicate in a way that benefits all parties involved.

Why this is needed: what happened?

Until recently, an application could be relatively sure that it was the only program that would be modifying the data it cared about.  Developing software was complicated and distribution was expensive so, to justify the overhead, the programmers made each program do as much as it could.  Networks and data communication were slow and expensive, and programs didn't expect to be able to talk to one another.  There was a clear line between what lived on the desktop and what was online.  It was generally understood that if a person wanted to move data from one program to another there would be an export and an import. 

But an unexpected thing happened. Moore's law has been around since the 60s so hardly anyone was surprised that chips got cheaper, but only a few people predicted what would happen when processing, memory, disk, and networking all got cheap at the same time.  The result has been a fundamental change in the way that software is built and deployed.  We didn't just get us the same things, cheaper.  Whole new classes of product were created because one or two people could have a good idea and ship it.  Advances in networking also meant that programs could get smaller. You don't need one program to do everything, you extend with features and plugins.

The Problem

The relationship between a person and a product are set out in contracts. The most common are Terms of Service (ToS), End Use License Agreement (EULA), and Privacy Policy. In theory, everyone using a product has read and agreed to these, but that's rarely true. These documents are long, complex, and written in language that is difficult for a general audience to understand. In practice, few have read these contracts and even fewer understood them.

This is bad for everyone. It not only leaves questions in the person's mind about what they've agreed to, but also calls into question the service's ability to enforce the agreement. The global nature of the Internet makes this even more complicated, as the user can rarely be sure what is enforceable where they live and what isn't.

This issue is important for all sorts of software products.  When data portability is mentioned, people's thoughts naturally go to address book and social network products. This makes sense, as these are very popular and address book portability shows up in the news from time to time. Social networks are only part of the story, though. Desktop applications, online games, and all kinds of services create data that might be desirable in other places. Will this service share changes I make with other services that I use? Can you get a copy of the photos you've uploaded to a service? Can you move a playlist from one music manager to another – even if all of your music files are in a standard format?  Is that plugin broadcasting a copy of your data somewhere?  Can you take your character items from one game to another?

Note that we're not insisting that all providers agree on common formats for every bit of data. This would be counter productive, and we believe that companies should be allowed to innovate with their products however they see fit.

Home is Where the Data Is

Because the capabilities of the software have outpaced our business models, people have been left in an unexpected position. Most products behave as though they are the authoritative version of the data. Each acts as though is the center of our data universe, that it is the home source of any data it knows about, and any other products have copies. There are a few ways to keep them all synchronized, but companies were known to do everything in their power to prevent this from happening. This has left users in the position where they were expected to enter the same data over and over again, and where all but the most recently used product were out of date.

• Will this product share changes with other products?
• Will it accept data updates from another product?
• Will it delete data if the data is deleted on another product?
• If I don't use this product in a certain amount of time, will my data expire?

When a user provides a bit of data:

• Does the user get it back exactly as it was provided?
• Can the user get the "improved" (normalized/tagged/contextualized) version?
• Can the user get data to which it refers?
• Can the user get data which refers to it?

The data in scope of this policy is classified into three buckets:

• Identity: Representations of a person
• Media and content: Expressions of a person
• Structure and metadata: Relationships between data

For each of those, we attempt to give it a value of:

• None: This product stores a copy of the data, but does not provide standard export tools.
• Home: The product stores a copy of the data. The person can export data from this product, but the product does not provide an automated way to accept changes made elsewhere.
• Sync: The product stores a copy of the person's data. It treats other services as peers. It can export data and also accept changes from other products.
• Remote: This product does not attempt to store a copy of the data. It requests the data it needs in order to do its work, but returns updates to the authoritative home for storage.

Data has characteristics that need to be understood for its portability:

• Identity: How does the user identify themselves to the product?
• Authority: Does this product believe that it has the authoritative copy of this data, and all others are copies?
• Freshness: Is this data up to date?
• Flexibility: Does the person have access to data in a way that it can be re-used?

A set of questions have been developed, which we require as a minimum set of disclosure. We believe answering our questions is only part of the solution. The product owner is also expected to provide details of their answers.

The Solution

Our goal is to create a tool that complies with our Vision & mission, asking the site creator a set of questions (detailed below) and provides appropriate TOS and EULA clauses in return.

The questions are, necessarily, generic and the product owner will be prompted to provide a link where the user can go to learn more detailed information about the product's approach to the question. The product creator will also be provided with a set of marks and icons that can be used on their site to display their choices.

Questions for the Product Owner

• Are your export APIs and formats documented?
  • Yes or No
• Do people need to create a new identity for this site, or can they use an existing one?
  • New Identity - The person is expected to create a fresh identity that is used on this site. This site does not trust a third party to authenticate identity.
  • Existing Identity - The person can register an account that is accessed using an identity authenticated by some third party. This product assumes that, by selecting a third party to authenticate their identity, the person accepts that third party as trustworthy.
• Must people import things into this product, or can the product refer to things stored someplace else? Can this product work with objects and information whose "authoritative home" is another product, or can this product only work with things that it hosts directly?
  • Must Host - In order for this product to work with a thing, it must be hosted directly.
  • Can Refer - This product has the ability to access and work with things that are hosted by third parties, assuming that the third party allows this.
• Can this site accept updates that users make on other sites? In cases where the product tracks or manages things that the person has stored on some third party product, can this product watch the third party for updates?
  • One Time Import - This product only sees the remote thing at import time, and does not watch for changes.
  • Watch For Updates - This product watches the third party for changes, and updates its own view of the remote thing to match.
• If person updates something here, is that change stored only by this product or can the person ask this product to store it elsewhere? Can this product accept some other site as being the authoritative home of a thing it knows about?
  • Must Be Authoritative - This product assumes that it is the authoritative home of all things it manages, and does not update third parties.
  • Can Update Remote - This product can work with a third party that is assumed to be authoritative. All updates made by the person using this product are also forwarded to the third party.
• Can the person allow other sites to use the things they've created or updated here? Does this product provide a way for third parties to authenticate a person and read or write?
  • No Access - The person must use this product to read or access whatever it manages.
  • Third Parties Can Read - The person can provide the third party with authentication credentials, and can read data managed by this product.
  • Third Parties Can Write - The person can provide the third party with authentication credentials, and can write data managed by this product.
• Can the person download or remotely access a copy of everything they've provided to this service? As part of their standard use of most products, people import or create things. Does this product provide an open, DRM-free way for people to retrieve or access via third party all of the things they've created or provided?
  • No Access - This product does not offer the person the ability to download the things they've provided.
  • Remote Access - The product provides an open, DRM-free way for people to download all of the things they've provided to the product, or remotely access it using a third party product.
• Can the person download or remotely access information that others have provided to the product? In cases where the product allows download or remote access, can the person export or access all of the data to which they have access, or only data which they have directly created?
  • Provider Only - This person may only export or access data which they have directly provided.
  • Full Access - The person may export or download any data to which they have access on this product, subject to reasonable usage and abuse rules.
• Will this site delete an account and all associated data upon a user's request? If the user creates a password or account for use with this product, does the product provide a way to cancel the account and erase all data associated with it?
  • Immortal Accounts - Accounts or passwords, once created, are assumed to live for as long as the product is available. Desktop applications and other stand-alone products that do not have host services may have no way to remotely revoke accounts or passwords.
  • Data Expires - If this product acts as a hub, the data it copies from other sites will expire in a set amount of time. This product must be linked to a place where it can refresh or synchronize data in order to stay current.
  • Accounts Deleted Upon Request - This product has the ability to remove a person's account and all relevant data, and will do so when requested by the person or third party with appropriate legal standing.

The tool will return a document containing appropriate language to reflect how the site owner answered.

The metaphors

A set of standard marks will be created to reflect the above agreements between a service-provider and service-user. This work is ongoing by the task force.

Taskforce Notes

The end result of this task force should be a set of freely available documents that are suitable for use by web sites.

Workpapers and information about the EULA & ToS Task Force