Scraping vs licensed data: what actually differs

"Is web scraping legal?" is the wrong question, and it is the one every vendor comparison answers. The useful question is narrower: which specific act, in which jurisdiction, creates which specific exposure — and who carries it, you or your supplier?

This article is a map of the actual legal surface, written for the engineer or technical buyer who has to answer a security review. It is not legal advice, and the honest summary up front is that several of these areas are genuinely unsettled. Where that is true, this says so rather than picking the reading that flatters a product.

Five separate legal theories, routinely conflated #

Public web data touches at least five bodies of law. They are independent: winning on one says nothing about the others. Most "scraping is legal, the courts said so" arguments are the result of collapsing all five into the first.

1. Computer misuse (US: the CFAA) #

This is where the famous cases live, and where the news is genuinely favourable to scrapers.

In Van Buren v. United States (Supreme Court, 2021), the CFAA's "exceeds authorized access" was read narrowly: liability attaches to accessing areas of a system you are not entitled to reach, not to misusing information you were entitled to obtain. A gates-up-or-down test, rather than a terms-of-service test.

In hiQ Labs v. LinkedIn, the Ninth Circuit held that scraping data from a public profile — no login, no gate — does not plausibly amount to access "without authorization" under the CFAA.

The part usually left out: hiQ did not ultimately win. On remand the case turned on LinkedIn's User Agreement, hiQ was found to have breached it, and the matter resolved with an injunction against hiQ. So the accurate statement is: scraping public pages is unlikely to be a federal computer-crime problem in the US; it can still be a straightforward breach of contract. Two different theories, two different outcomes, one case.

2. Contract #

If you clicked, signed, or continued past terms that forbid automated collection, that is a contract question, and it survives everything the CFAA cases decided. It is also the theory with the least uncertainty and the least drama — which is precisely why it is where these disputes now land.

3. The EU database right #

This one is European, has no clean US analogue, and is regularly missed by teams reasoning from US case law alone.

The sui generis database right (Directive 96/9/EC) protects a maker who made a substantial investment in obtaining, verifying or presenting the contents of a database — independently of copyright in the contents. Extraction or re-utilisation of a substantial part can infringe, and repeated extraction of insubstantial parts can add up to the same thing.

Large structured collections of results, listings or reviews are exactly the shape this right was written for. If your compliance analysis stops at "the data was publicly visible", it has not addressed this at all.

4. Text and data mining (EU DSM Directive 2019/790) #

Two exceptions, and the difference between them is the one to remember:

• Article 3 covers TDM for scientific research by research organisations and cultural heritage institutions. It cannot be contractually overridden.
• Article 4 is the general one — available to commercial actors — but it applies only where rights have not been expressly reserved in an appropriate machine-readable form for content made publicly available online.

Article 4 is why machine-readable opt-outs matter legally rather than just as etiquette. A site reserving rights in a machine-readable way removes the exception you were relying on. Whether a given signal counts as an effective reservation is still being argued, but "we ignored the opt-out" is not a position you want to defend.

5. Data protection (GDPR) #

The one most likely to actually cost money, and the one most often waved away.

Public data is not exempt data. Reviews carry names, business listings carry contact details, profiles carry a great deal more. Once personal data is in scope, you need a lawful basis — usually legitimate interests under Article 6(1)(f), which requires a documented balancing test, not an assertion. And because you did not collect it from the person, Article 14 requires informing them, subject to a disproportionate-effort exemption whose scope is contested and which regulators have read narrowly.

The enforcement record here is not theoretical: the fines levied on Clearview AI by several European authorities concerned collecting public images at scale.

What the distinction actually is #

Given that map, "scraped vs licensed" is not a moral distinction, it is a distinction about where the risk sits:

Licensing does not make the questions disappear. It moves specific ones to a counterparty who has agreed to carry them, and gives you a document to hand a reviewer. That is the entire substance of the claim, and any vendor implying more is overselling.

The one axis that is not shades of grey: anti-bot evasion. Rotating residential proxies to look like consumer traffic, solving CAPTCHAs, and fingerprint spoofing are affirmative steps to defeat an access control the operator deliberately put up. That is the fact pattern that moves a case from "reading public pages" toward the theories in section 1, and it is the one your security reviewer will ask about by name. It is also the reason a category of tooling is simply unusable at some companies, regardless of price or quality.

Dataswap's position: data comes from licensed upstream providers under contract, no anti-bot protections are bypassed and no CAPTCHAs are solved, processing happens in the EU, and request payloads are not forwarded to third-party model providers. The security page and the DPA are the documents behind that, and the privacy policy covers personal data handling.

Provenance receipts, and their honest limits #

Claims in marketing copy are not evidence. So every intelligence-layer response carries a signed receipt describing how the data was obtained:

{
  "v": 1,
  "source_class": "licensed_provider",
  "bot_evasion": false,
  "inference": "eu-only",
  "operation": "context_pack",
  "request_id": "req_…",
  "retrieved_at": "2026-08-04T10:12:44.201Z",
  "payload_sha256": "…",
  "signature": "…",
  "key_id": "…"
}

payload_sha256 is what ties the receipt to specific content, and the Ed25519 signature is what ties it to us. Verification is a public, free endpoint — whoever checks a receipt is a legal or audit team, not a customer, and requiring credentials from them would defeat the purpose:

const card = await dataswap.entity({ domain: 'example.com' });

// The receipt signs the body without itself, so separate them before verifying.
const { provenance, ...payload } = card;
const check = await dataswap.provenance.verify({ receipt: provenance, payload });

console.log(check.valid, check.signature_valid, check.payload_matches);

# The signing key and the sourcing policy, for offline verification.
curl https://api.dataswap.io/v1/provenance/public-key

GET /v1/provenance/public-key returns the SPKI public key so you can verify signatures yourself without calling us at all, plus the stated sourcing policy. key_id derives from the key, so rotating the key rotates the id and an old receipt stays verifiable against the key that signed it.

What a receipt does not do, stated plainly because this is where similar features are oversold:

• It is a signed self-attestation, not a third-party audit or certification. It proves we said this, consistently and unforgeably. It is not SOC 2, and it is not an independent verification of our supply chain.
• Verifying a signature without sending the payload only proves that some response of ours was signed. Send the payload if you want the receipt tied to that exact content.
• It says nothing about whether your use of the data is lawful. Sourcing and use are separate questions, and the second one is yours.

Used for what it is, it is useful: a durable, machine-checkable record attached to each response, instead of a sentence on a website that can be edited later.

Limits and open questions #

Jurisdiction changes the answers. This map is US computer-misuse law plus EU database, TDM and data protection law. The UK diverges post-Brexit; other jurisdictions differ more.

The TDM opt-out mechanism is unsettled. What constitutes an effective machine-readable reservation is still being worked out in litigation and standards work. Anyone claiming certainty is guessing.

Article 14 exemption scope is contested. Do not build a programme whose GDPR compliance depends entirely on disproportionate effort without your DPO signing off.

Licensing is not laundering. If a supplier obtained data unlawfully, a contract with them does not cure that for you — it gives you recourse. Diligence on the supplier is part of the work.

None of this is legal advice. It is a map of where to point your counsel so the conversation starts somewhere useful. The facts of your use case decide the outcome.

The takeaway #

There is no single answer to "is this legal". There are five questions, and the honest comparison between sourcing approaches is about which of them you keep and which you contract away — plus the one bright line, anti-bot evasion, that decides whether a tool clears a security review at all.

Ask any data vendor: where does the data come from, are access controls ever bypassed, where is it processed, does my payload reach a third-party model provider, and will you sign a DPA. The answers are comparable across vendors, and they matter more than the feature grid. Ours are on the security page and on EU-compliant search data, and the routes above are in the API reference.