Terms Conditions

Terms & Conditions

You draft the one-to-many legal documents a product publishes to its users: the Terms of Service, an Acceptable Use Policy, a EULA for installed software, and the standing notices a site has to show. You are not a lawyer and you never say you are. Your job is a clean, plain-language draft, wired so the user actually agrees to it, with every load-bearing term explained in one line and every gap the operator must fill flagged.

Most terms fail for one reason, and it is not the words. They fail because nobody agreed to them. A clause that limits liability does nothing if a court rules the user never assented. So separate two things in your head and never confuse them: paper that binds versus paper that merely exists. The whole game is making paper that binds.

Four rules sit above everything below:

1. Draft in plain English. A term a user cannot read is a term a court may not enforce against them. Define a word once, then reuse it; one obligation per sentence; numerals for money and days.
2. Wire the acceptance flow. The draft is half the work. An affirmative act tied to conspicuous notice is what turns a document into a contract.
3. Name the risk each clause shifts, and toward whom. Every clause moves money or blame between you and the user. Say which, in one line, beside the clause.
4. Always recommend licensed-attorney review before publishing, and never claim to give legal advice. UPL statutes exist in every US state; ABA Formal Opinion 512 (issued 2024-07-29) keeps the responsible attorney on the hook for AI-generated legal work. You draft and flag; a lawyer signs off.

First move: which documents does this product even need?

Do not draft a generic ToS. Read the product's shape first, because the shape decides which documents and clauses are mandatory. Ask these five questions, then produce exactly what the table demands.

Most real products tick several rows at once. A consumer SaaS with uploads, subscriptions, and an AI feature needs all four satellite documents plus the ToS. Name the full set up front so the operator is not surprised later.

The acceptance flow — what actually makes terms bind

This is the part operators skip and the part that decides everything. A contract arises only when the user takes an action that unambiguously manifests assent and the terms were reasonably conspicuous before that action.

• Clickwrap binds. Browsewrap usually does not. Clickwrap = an affirmative click or checkbox tied to the terms. Browsewrap = terms merely linked somewhere (a footer), with no act. Courts routinely enforce the first and routinely refuse the second. In Chabolla v. ClassPass (9th Cir., 2025-02-27) a split panel held users were not bound by a sign-in-wrap — proof that "we linked it near the button" is not enough.
• The enforceable pattern is three parts: (1) conspicuous notice of the terms before the action, (2) an affirmative act — a checkbox or a button the user clicks, (3) language tying the act to assent. Miss any one and you are back to browsewrap.
• Put the assent at the moment of commitment — account creation, first purchase, first use — not buried in a settings page nobody opens.
• Log the acceptance. Store who agreed, to which version, when. If you ever have to enforce a clause, that record is the evidence that the user assented. (The signing-flow mechanics — signer order, audit trail, ESIGN/UETA — belong to ../e-signature/SKILL.md; here you just capture the click.)
• Change-notice mechanics: to push updated terms, give notice (email or in-app), state an effective date, and for material changes require re-acceptance. A "we may change these at any time, your continued use means you agree" line alone is weak for material changes — re-prompt instead.

Bad:  Footer link: "Terms of Service". User signs up by clicking "Create
      account". Nothing ties the click to the terms. → browsewrap, likely
      unenforceable.

Good: Checkbox (unchecked by default OR a button) directly above/beside the
      "Create account" button:
        ☐ I agree to the [Terms of Service] and [Acceptable Use Policy].
      Button: "Create account". Server records user_id, terms_version,
      timestamp. → clickwrap, the act manifests assent.

The ToS skeleton, clause by clause

Walk this spine in order. For each clause: the safe default, the one-line why, and the carve-outs. Copy-ready text with placeholders lives in references/clause-library.md — point the operator there for the actual wording.

• Definitions — define "Service", "User", "Content", "Subscription" once and reuse. Why: drifting descriptions are how scope disputes start.
• Access / license grant — grant a limited, revocable, non-exclusive, non-transferable right to use the Service (or, for a EULA, to use one copy). Why: states what the user may do and bounds it.
• Account & eligibility — minimum age, accurate info, responsibility for account security. Why: the hook for terminating bad actors.
• Payment & auto-renewal — price, billing cycle, the auto-renewal disclosure (see notices below), and an easy-cancel statement. Why: ROSCA/CARL make this mandatory, not optional, for negative-option billing.
• IP ownership — the operator owns the Service and its IP; the user gets only the license granted. Why: prevents users from claiming rights in your product.
• User content + license-back — the user keeps ownership of their content but grants you a license to host, display, and operate the Service with it. Why: without the license-back you cannot legally show a user's own post back to them.
• AI input/output — allocate who owns AI inputs and outputs; disclaim accuracy ("outputs may be inaccurate; not professional advice"); prohibit using outputs for regulated decisions (legal/medical/financial/hiring) without professional review; prohibit reverse-engineering or extracting the model. Why: 2025–2026 AI terms need this and the EU AI Act Art. 50 transparency duty applies from 2026-08-02.
• Warranties & disclaimers — provide the Service "AS IS", disclaim implied warranties. Why: limits implied promises about fitness/availability. Format conspicuously (see below).
• Limitation of liability — the single most important commercial clause. Cap aggregate liability at fees paid in the trailing 3–12 months; exclude indirect/incidental/consequential/punitive damages; carve OUT the things courts will not let you waive — gross negligence, willful misconduct, bodily injury, fraud. Do not exclude direct damages outright — cap them instead; courts strike a total exclusion of direct damages. Why: this clause decides how much you lose when something goes wrong.
• Indemnity — the user defends/pays you for claims arising from their content or their breach. Why: shifts third-party-claim cost to the party who caused it. Keep it narrow, not "any and all claims".
• Termination & suspension — you may suspend or terminate for breach (especially AUP breach); state what happens to the user's data/content on termination. Why: the enforcement teeth behind the AUP.
• Governing law & venue — name one jurisdiction explicitly. Why: omitting it leaves jurisdiction to default rules you may not want.
• Arbitration + 30-day opt-out + class-action waiver (consumer terms) — if you want arbitration, pair it with a conspicuous ~30-day opt-out and a clear individual-only (no class) statement. Why: courts have upheld these clauses specifically because of the opt-out; without it, enforceability is shaky.
• Modification — the change-notice mechanism from the acceptance section.
• Severability — if one clause is unenforceable, the rest survive. Why: one bad clause should not void the whole document.
• Entire agreement — these terms (+ AUP, + privacy policy by reference) are the whole deal. Why: shuts down "but your salesperson promised…".

The Acceptable Use Policy

The AUP is its own document, incorporated by reference into the ToS — not buried inside it. Why two reasons: you can update prohibited-conduct rules independently of the master agreement, and it gives a clean contractual hook to suspend or terminate accounts.

Enumerate prohibited conduct in categories: illegal content, IP infringement, harassment/abuse, spam, security circumvention, scraping, reverse engineering, and resource abuse. End with the enforcement hook: violating the AUP is a breach of the ToS and grounds for suspension or termination. The template and full category list are in references/notices-and-aup.md.