Introduction

These pledges are currently a DRAFT, and subject to change.

The following are a set of independent pledges, which can be committed to by web-service providers who value creating high-quality, ethical and sustainable products, over quick profits and acquisitions at the expense of their userbase.

These pledges should be aimed towards the service's end users, to provide them with a level of reassurance about certain key operating principles. Instead of needing to carefully analyse marketing copy, they'll be able to, at a glance, understand that the service is following a set of mutually agreeable guidelines.

A service provider can commit to as many or as few of these pledges as they desire. It's recommended to show commitment to these pages, along with a link to the homepage, somewhere easily visible to new users.

An endemic problem for the users of web-services provided by startups is their volatility - especially in the case of acquisitions. For this reason, part of the conditions of accepting these pledges, is that an acquisition must only go through if the acquiring party agrees to uphold the existing pledges.

There's nothing physically stopping a service provider from expressing that they'll follow these pledges, but going on to breakthe agreement. This system is built on respect and trust, so the main reprecussion would be - rightfully so - a tarnished reputation for inability to stick to one's word.

For this reason, especially with the long-term service agreement, it's recommended to agree to these pledges under the name of an individual (typically the founders of the service), as opposed to using the name of the service itself - because short-lived services have no reputation to maintain.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

1. Long-term service (X years)

• The core value proposition of the service MUST be available for the next X years, for any users who signed up during, or before, the commitment was in place.

• RECOMMENDED values for X are 1, 2, 5 or 10 years.

• The service SHOULD keep enough funds set aside to allow this guaranteed usage period for existing customers (taking into account any revenue from these members), without having to rely on a certain amount of future growth or external investment.

• If this pledge is included, the pledge MUST be presented under specifically named individuals, as opposed to anonymously against the service itself.

• If the pledge is left in place, or the term increased, it SHALL apply retroactively to all existing users of the product. For example, if on 2014-10-20, the pledge on the landing page is increased from 1 to 2 years, every user who signed up on or before 2014-10-20, can expect service until 2016-10-20.

• This pledge MAY be removed, or decreased in length, at any time. This will affect new users, signing up after that point, only.

• Sites offering this pledge MUST keep a publicly accessible history of, as described above, what dates users can expect service until based on the time at which they were a member.

2. Personal data integrity

• Personal data MUST NOT be sold to third parties.

• Personal data MAY be exchanged with third-parties when providing a crucial part of the service (e.g. API integrations).

• Users MUST be provided with an automated, "no questions asked" way to permenantly close their account.

• After closing their account, users MUST NOT receive further contact from the service, apart from a RECOMMENDED final email confirming the deletion.

• After closing their account, users' personal data MUST be removed from the system within 28 days.

• The user MAY be given the option of "undoing" their account closure if they get in contact within a specified timeframe (no more than 28 days).

• Anonymised and non-identifiable data about the user (e.g. for analytical reasons) MAY be kept in the system beyond the 28 day limit.

• In the event of a data breach, affected users MUST be notified by email.

• In the case of wanting to retract this pledge, existing users MUST be given at least 2 months explicit notice, to give them time to optionally close their account, and make sure their data is out of the system before the changes are enacted.

• If this pledge is used in conjunction with the long-term service pledge, it MUST NOT be retracted within the period of that pledge.

3. No data lock-in

• Data MUST be exportable in a human-readable format (e.g. formatted html).

• Data MUST be exportable in a format convenient for machine processing (e.g. JSON).

• There MUST NOT be a delay of longer than 24 hours between the user requesting their data, and it being provided to them.

• In the event of ceasing operations, export formats SHOULD be provided for the most widely recognised competitors.

• In the case of wanting to retract this pledge, existing users MUST be given at least 28 days explicit notice, to give them time to export their data before the change is enacted.

• If this pledge is used in conjunction with the long-term service pledge, it MUST NOT be retracted within the period of that pledge.

4. Transparent subscription pricing

• Users MUST be offered a fair way to evaluate the service - either via a free trial, or a money-back guarantee period.

• If a money-back guarantee is offered, it MUST be automated and with "no questions asked".

• After signing up to a certain subscription level, users MUST NOT ever be automatically transferred to a higher price point.

• Users MAY be transferred to a lower price point.

• If it becomes unsustainable to support a certian subscription level, the user MAY have their subscription terminated, UNLESS this is used in conjunction with the long-term service guarantee, in which case providing the user service, at the same subscription price point or lower, is part of the service guarantee.

• This pledge MAY be retracted at any time, but that MUST only have an impact on new users.

5. Privacy-first

• All personal data entered into the system (including user profiles) MUST be private by default; only becoming accessible by others through opt-in processes.

• Uniquely identifying account information (e.g. username or email address) MAY be revealed as part of the sign-up process (i.e. showing that a username is taken).

• This pledge MAY be retracted at any time, but that MUST only have an impact on new users.