This is for anyone building a product that takes public legal/court data and turns it into something structured, searchable, or scored — case outcome trackers, lawyer directories, litigation analytics, judge/bench insight tools, anything in that space.
None of this is legal advice. It’s a map of where other people have already hit trouble, built from real court cases and real laws, so you can make informed product decisions instead of finding out the hard way.
Public court data is genuinely public — you’re usually allowed to use it. The trouble doesn’t come from having the data. It comes from three specific things you do to it: attributing it to a named individual, scoring/ranking that individual, and making the tool commercial and queryable rather than a one-off publication. Every real-world legal fight in this space has been about one or more of those three things, not about the underlying data being off-limits.
Any feature in this space falls into one of four tiers. This is the single most useful mental model for the whole playbook — use it every time you’re deciding whether to ship a feature.
Stats about a court, forum, or case type as a whole. “32.8% of commercial cases in this jurisdiction settle.” “Average time to disposal: 3.1 years.” No individual — lawyer, litigant, or judge — is named or identifiable.
This is close to what courts and government bodies already publish themselves (India’s National Judicial Data Grid is a working example). It’s the safest place to build, and it’s still useful — most “how long will my case take” or “what’s typical here” questions can be answered at this level without ever naming anyone.
A named professional’s public record, presented as facts: “has appeared in 243 matters in this court since 2018, primarily commercial disputes.” No score, no grade, no ranking — just a factual summary sourced from the public record.
This is the “Avvo” model (a real US legal-directory company): they show credentials, case history, and disciplinary record, but explicitly do not score actual case outcomes. That one design choice is most of what keeps them out of the legal trouble their more aggressive competitors ran into.
“Lawyer X — 77% success rate.” A real professional, publicly named, assigned an evaluative grade built from their case history, sold as a product feature — without their input or consent.
This is the exact model that got a real US company (Lawyer.com) hit with a privacy class-action lawsuit. The complaint wasn’t about the accuracy of the underlying case data — it was about a company building and monetizing an unconsented public grade of someone’s professional reputation. Non-paying subscribers reportedly scored worse than paying ones, which made it worse, but the core objection stands even without that.
Any feature that lets a user infer how a specific judge tends to rule — grant rates, favorability by case type, patterns by category of party or petitioner — even if you never show a number next to the judge’s name directly.
This is the one real, documented case of an outright ban. France made this a criminal offense in 2019, specifically in response to a legal-tech tool that had surfaced uncomfortable patterns in how certain judges ruled on asylum cases. The reasoning the French courts gave when upholding the ban: this kind of tool lets lawyers “judge-shop,” and that undermines the fairness of the system itself.
Important nuance on Tier 4: the ban wasn’t really about the display of a judge’s name next to a score. It was about the capability to reconstruct that pattern at all. If a user can filter lawyer win-rates by judge, and flip through a few judges comparing the numbers, they’ve built the judge’s profile themselves — you don’t need to have rendered it directly for the underlying problem to exist. This is the subtlest and most important thing to get right in this entire playbook.
This is a real trap: the exact same underlying capability can be low-risk or high-risk purely based on how it’s used, not what data is behind it.
A one-off, editorially-authored, non-monetized published article that says “this court has been notably fast and favorable toward a certain category of petitioner” is Tier 1 — a forum-level finding, made once, for public-interest reasons, not sold as a product. Journalism and research get treated differently from commercial products under most privacy frameworks, precisely because of this distinction.
The same underlying dataset, sitting inside a persistent, paid, filterable product that lets any subscriber run that same query against any judge on demand, indefinitely — that’s Tier 4. The data didn’t change. The delivery mechanism did, and that’s what moved the risk.
Practical takeaway: don’t assume that because a similar-sounding analysis has been published somewhere safely, your product version of it is equally safe. Ask what made the safe version safe — usually it’s one-time-ness, non-commercial framing, and aggregation level, not the topic itself.
These are the actual cases and laws behind the tiers above. Useful to know by name if this ever comes up with a lawyer, investor, or regulator.
A person wanted an old article about them de-listed from search results for their name. The court agreed: search engines have to stop surfacing certain links on name searches if asked, even though the original article stays published and legal. Critically — this is about hiding a search result, not deleting the underlying record. That “de-index, don’t delete” distinction is now the standard remedy almost everywhere this issue comes up, including in newer rulings outside the EU.
France’s regulator wanted Google to de-list globally, not just in the EU. The EU’s top court said no — de-listing only has to apply within the EU, though individual countries can still push for wider removal under their own laws if they choose to. The lesson: “right to be forgotten” remedies tend to stay geographically and technically narrow (name search only) even when the underlying privacy right is treated seriously.
Explained above. The specific trigger was a legal-tech tool exposing a pattern in one category of judicial decisions that became publicly uncomfortable. The government responded with a criminal ban on reusing judge-identifiable data to evaluate, compare, or predict judicial behavior. This remains the single most direct precedent for anything resembling “search by judge” or “compare outcomes across judges” in a legal-tech product.
If data was made public for one reason (court transparency, accountability), reusing it for an unrelated reason (a commercial ranking product) isn’t automatically fine just because the data itself is public. There has to be a reasonable link between the original purpose and the new one. This is a general principle, not a single case, but it’s the doctrinal backbone behind a lot of the more specific rulings above — and it shows up in most modern data protection laws in some form, not just the EU’s.
Covered under Tier 3 above. Worth remembering as a pair: Lawyer.com scored outcomes and got sued; Avvo stuck to credentials/background and didn’t. If you’re building a lawyer directory or ranking feature, this pair is the cleanest real-world A/B test of where the line tends to sit.
Many data protection laws (India’s DPDP Act is one clear example) exempt data that’s already legally public from most of the law’s requirements. This can look, at first read, like a green light for any product built on public court records. The gap: these exemptions are usually about the original publisher’s obligation to make the data public — they don’t automatically say anything about what a third party can then build on top of it commercially. Whether the exemption “travels downstream” to a commercial repackaging product is often untested and unresolved. Don’t treat a public-data exemption as a blanket license — treat it as covering your sourcing, not necessarily your product.
Use this when you’re deciding whether to ship a feature, not just when you’re worried about it.
Aggregate data is safe. Named-but-descriptive is mostly fine. Named-and-scored is a real, litigated risk category. Judge-specific inference — even indirect, even unintentional — is the one thing that has already gotten an entire category of tool banned somewhere in the world.
Design your data model and your UI filters with that gradient in mind from day one. It’s much cheaper to build the boundary in now than to retrofit it after a judge, a bar council, or a regulator notices.
This was written in context w.r.t #August 2026
A founder’s guide to building on public court data without walking into a wall
…ing close to one of my previous works. It produced A founder's guide to building on public court data without walking into a wall (more on that below).