What an open-source project owes the people who run it
About this documentUpdated 2026-09-18ShowHide
Sean McDermott, Co-Founder and CEO, UnGovr
Written by Sean McDermott (with AI assistance) using the LexLint law library, which supplied every legal instrument, status and date on these pages.
Every law named here links to its summary page on lexlint.org, translated to English (if needed) and restructured to a standard format for human and code use. Every case links to the court's or the regulator's own record where one could be reached.
© 2026 UnGovr, publishing as LexLint. The text, the figures and the theme-register file are licensed under Creative Commons Attribution-NonCommercial 4.0: share and adapt them for noncommercial purposes with credit to LexLint (UnGovr). Please contact LexLint at hello@ungovr.org to discuss commercial use. Logos and wordmarks belong to their owners.
Corpus figures as of 2026-09-18.
Every open-source licence disclaims liability and the law binds the operator, so an open-source project carries little legal risk. The exposure it creates for the people who deploy it is another matter, and three questions follow for a project that already knows where that exposure is.
1Open-source licences and the law point in opposite directions
Open-source licences differ in almost everything except this: permissive or copyleft, two paragraphs or twenty, each says the software is provided as is, without warranty, and that the authors are not liable for what happens when it is used. The law, read across the LexLint software-law corpus, points the other way. It binds the party that runs the software. The GDPR binds the controller, which is whoever decides why personal data is processed. The AI Act binds the deployer, which is whoever uses a system under its own authority, and the provider, which is whoever places it on the market under its own name. A state privacy act binds the business that conducts business in the state. A computer-misuse statute binds whoever accessed the machine. In each case the party is the OPERATOR, or a party the OPERATOR chose, and the project whose code is running is nowhere in the sentence.
The new law mostly keeps that shape, and says so out loud. The AI Act excludes free and open-source AI systems from most of its scope unless they are placed on the market as high-risk or fall under the prohibitions or the transparency duties, and gives open-source general-purpose models a lighter set of duties under Article 53 unless they carry systemic risk. The EU's product liability directive treats software as a product and then excludes free and open-source software developed or supplied outside a commercial activity. The one horizontal law that writes the MAKER of software into the addressee list, the Cyber Resilience Act (Article 13, from 2027-12-11; Article 14, since 2026-09-11), created a lighter "open-source software steward" role for a foundation that supports a product without placing it on the market, and reaches a project in full only where it is developed in the course of a commercial activity.
A project that runs no software carries little legal risk of its own. The people who run its software carry all of it, under laws that were written with the OPERATOR in mind and never mention the project.
2The exposure a project creates downstream is real, and it is known in advance
The enforcement examples in the last document of this section are all, without exception, actions against the party that ran the software. An airline answered for what its chatbot said. A ride-hailing company answered for the automated decisions its system made about drivers. A companion-app OPERATOR was fined for how it handled its USERs' data, and the model behind the app was not named. Nobody sued the framework. The one place the record reaches people who wrote code, the prosecutions of the developers of two cryptocurrency mixers, it does so on the finding that they also ran the service; the open-source section of that document sets them out.
What makes this a question for a project rather than only for its USERs is that the exposure is often visible from the project's side before any OPERATOR meets it. A project whose feature sends email knows that outbound messages are regulated everywhere. A project whose feature generates images knows that AI Act Article 50, India's intermediary rules and California's AI Transparency Act require a mark on the output. A project whose feature makes decisions about people knows that Article 22 of the GDPR and California's automated decision-making regulations give those people rights. And a project whose feature proxies an AGENT's traffic knows that it sees the facts every one of those laws turns on: who asked, from where, what was sent, to whom, and what came back. These are not obscure. They are the same three properties every time:
- Not obvious to the author. The feature reads as engineering; the duty it triggers is in a statute the author has never opened.
- Unlikely to reach the author. The licence disclaimer, whichever licence the project chose, the exclusions above, and the OPERATOR's role between the code and the harm all point liability elsewhere.
- Known in advance. The risk area is documented law, dated and cited, and it attaches to the feature on the day it ships, not on the day someone is fined.
A project that meets all three has a choice, and the choice is the subject of the rest of this document.
3Is there a duty to say so, or to help?
As a matter of law, for a non-commercial project, mostly not. A licence's liability disclaimer is enforceable in most jurisdictions, the product liability exclusion is explicit, and the Cyber Resilience Act's steward duties are about the project's own security practice (a vulnerability policy, cooperation with authorities), not about warning USERs of the law they will be under. The picture changes for a project developed in the course of a commercial activity, where the Cyber Resilience Act's manufacturer duties apply in full, and it changes again for the party that takes a project's system and places it on the market under its own name, which under the AI Act's Article 25 makes that party the provider with the provider's whole set of duties.
As a matter of practice, the answer has already been given by the projects that came before. Open-source software has met privacy and security law for thirty years, and the pattern is consistent: the duty landed on the deployer, and the project shipped the switch. Registration flows for a children's-privacy statute, a consent banner for a cookie rule, an export tool for a data-protection regulation, a signed bill of materials for a procurement order. None of those projects was the addressee of the law it built for. Each built for it anyway, because its largest deployer base needed the feature, and because a project that knows its USERs will face a duty and says nothing has made a choice it did not have to make.
There is also a plainer argument. A foundation or a maintainer that states a project is "enterprise-ready" or "governed" or "trustworthy" is making a claim, and a claim about software is within reach of consumer-protection law in most places; the examples in the last document include a company fined for what it said its AI could do. Saying less and documenting more is the safer register, and it happens to be the more useful one.
4Three questions for a project that knows where the exposure is
1. Do we want to make it legally safer from the start?
The cheapest time to build for a duty is before the interface exists. The AI law of 2024 to 2026 offers a short list of defaults that cost little at design time and a great deal after launch:
- Preserve a mark you did not create. Where the project carries or transforms generated content, keep the machine-readable provenance metadata intact by default. India's rules require the mark to be permanent; Article 50(2) requires it to be detectable; California's AI Transparency Act penalises its removal. A pipeline that strips metadata as a cleanup step turns every downstream OPERATOR into a violator.
- Say it is a machine, by default. Where the project renders an interface to a person, default to a disclosure the OPERATOR can turn off rather than one it has to remember to turn on. Most of the interaction-disclosure statutes in force accept an obvious-from-context exception; none accepts silence.
- Record events, not just errors. The AI Act's Article 12 asks a high-risk system to log events automatically, and Article 26 asks the deployer to keep those logs for at least six months. A project whose default log is a debug stream has left every high-risk deployer to build the record themselves.
- Make consequential actions interruptible. Human oversight is a duty on the deployer under the AI Act's Article 14 and a prohibition on disabling it under Vietnam's law. An AGENT framework that cannot pause before an irreversible step has decided that question for every OPERATOR.
2. Where the law needs a fact at runtime, whose job is it to make that possible?
Several of the duties in Global AI law turn on facts that exist only at request time: where the person was, which site was read, where the data went, whether a response came from a model. A duty that turns on a fact the system did not record cannot be shown to have been met, and cannot be shown to have been breached either, which is the same problem from the regulator's side. The project cannot know the law. It can make honouring the law possible, in three steps, each of which is a feature rather than an opinion:
| Step | What it looks like in a project | What it makes possible for the OPERATOR |
|---|---|---|
| Carry the fact | A field in the request context and the log schema for a declared principal location, a COUNTERPARTY domain, a destination hostname or full URL (never only an IP address), a provider, and a flag on model-generated content. Empty is allowed; absent is not. | The applicability question can be asked per transaction, and answered later from the record. |
| Ask for it once | A configuration block where the OPERATOR states its own establishment, the jurisdictions it serves, and what it wants recorded, and acknowledges that the defaults were read. | The facts that do not change per request are stated once, by the party that knows them, and the acknowledgment is itself a record. |
| Keep it for long enough | A retention setting with a documented floor, defaulting to the longest one the project's documented use cases attract. | The six-month floor of the AI Act's Article 26, the breach clocks of GDPR Articles 33 and 34, and the record a court will ask for are all served by the same knob. |
Whether the OPERATOR fills those fields, and what the law then says, is the OPERATOR's question. That the fields exist, and that the OPERATOR was shown them, is the project's.
3. What else does a project owe the people who run it?
- A named risk area per feature, in the documentation. Not legal advice, and never a list of statutes, which will be stale in a month. One sentence per feature saying what kind of duty it tends to attract: "this sends messages to people; outreach law applies in most places", "this decides about people; automated-decision rights apply in most places". The parties document gives the vocabulary.
- Configuration that maps to a duty, with the duty named beside it. A retention floor, a disclosure default, a metadata pass-through, an approval step before an irreversible action, each with a comment that says which kind of law it exists for.
- A runbook for the clocks. Breach notification runs on 72 hours under the GDPR and 24 hours for early warning under NIS2; a serious incident under the AI Act has its own clock. A project that ships an incident runbook has given every OPERATOR the shape of the first day.
- A way to get the record out. An export of what the AGENT did, for whom, and under what authority, in a format a person can read, is the one artifact every OVERSEER in the parties document will ask for.
- No claim it cannot support. "Compliant", "certified" and "safe" are claims. "Records these facts, keeps them this long, discloses by default" are features.
5A worked example: a proxy for AGENT traffic
Take an open-source proxy that sits between AGENTs and the tools and models they call, of the kind several foundations now host. It evaluates a policy over every request and can allow, deny, transform, rate-limit and log. It cannot know whether a given request is lawful, because that depends on who is asking, from where, and under which OPERATOR's authority, and it holds none of that as law. It does hold the facts, and that is the point.
| What the proxy sees on the wire | The kind of duty that turns on it | What the project can ship, without becoming a legal engine |
|---|---|---|
| The destination host of every tool call and fetch | Computer-misuse and scraping law on the COUNTERPARTY's machine; cross-border transfer when personal data leaves | Log the destination hostname or the full URL as a first-class field, never only the IP address: a name points at an owner and an owner points at a jurisdiction, while an address behind a content delivery network is usually local to the caller and says nothing about either. Let policy deny by hostname; document that a destination list is a legal boundary as well as a security one |
| The tool arguments, including a URL or a recipient | The COUNTERPARTY's terms; outreach law on the recipient | Record the argument that names the other party; offer a policy hook that can require a claim before a send |
| The payload, and whether a response came from a model | Content marking; disclosure to the person; sensitive-data rules | Pass provenance metadata through untouched; flag model-generated responses in the log; never strip a mark in a transform step |
| Identity claims on the request, and the client's address | Age rules, consent, automated-decision rights, all keyed on where the person is | Carry a declared-location claim and a consent claim as named fields; log them; leave their truth to the OPERATOR that issued them; resolve the client address to a jurisdiction at the edge and store that, not the address |
| Nothing about the OPERATOR's establishment or the jurisdictions it serves | Every duty that keys on the OPERATOR | A configuration block where the OPERATOR states them once, with an acknowledgment; the proxy stamps every record with it |
| Every request, for as long as the log is kept | Record-keeping and audit duties; the six-month floor; breach evidence | A retention setting with a documented floor, an export, and a runbook for the day a regulator asks |
Every agentic workflow ends at one legally accountable party at least, the company running the software, and usually at several. A proxy that records the six facts above has not taken any of that accountability on. It has made it possible to locate.
Where the person is, without collecting where the person is
The jurisdiction facts a proxy needs are coarse: which country, and where the law splits by state or province, which state. The address that arrives with the request is finer than that, and it is personal data on its own. The Court of Justice of the European Union held in Breyer (2016-10-19) that a dynamic IP address a website OPERATOR records is personal data in the OPERATOR's hands where it has lawful means to identify the person, and California's privacy act lists an Internet Protocol address by name among the identifiers that are personal information (section 1798.140(v)(1)(A)). So "log the client address" is a personal-data decision, with a purpose, a retention period and breach duties attached to it.
Coarse location is a different thing. California's sensitive category is precise geolocation, defined as data used to locate a person within a circle of 1,850-foot radius (section 1798.140(w), and (ae)(1)(C) for its place in the sensitive list); a city is many times larger than that circle, so country, state and city fall outside the sensitive category. Under the GDPR, "location data" is one of Article 4(1)'s example identifiers, and Recital 26 makes identifiability the test: a country or a city on its own singles out nobody, and it becomes personal data when it sits in a record beside an account, a device or an address, which is where almost every request record puts it.
That gives the project a rule it can ship. Resolve the address to a jurisdiction at the edge, country plus state or province where the law divides that way, and record the jurisdiction. Keep the address out of the durable log, or hold it apart under a stated security purpose with a short retention. Never store coordinates finer than a city, and prefer a declared-location claim from the OPERATOR over anything derived from the device. A request record tied to an account is personal data whatever else it holds, so the jurisdiction field adds no new category and the retention floor the OPERATOR already carries is the one that applies.
The field is easier to reason about when it holds an identifier rather
than a name, and any stable jurisdiction identifier will do. UnGovr's
Atlas is one example: every government it lists has one of the form
urn:ungovr:<slug>, with the hierarchy in the slug
(urn:ungovr:de is Germany, urn:ungovr:us/ca is
California, urn:ungovr:us/ca/santa-barbara a county in it),
resolvable at ungovr.org/urn; where the
data source is known, the prefix can be dropped and the slug alone
carried. The list does not have to name every government on earth, only
every jurisdiction a known law reaches from, which is what the LexLint
software-law corpus enumerates. A proxy records the coarsest identifier
the law needs, and a reader, or a lint, compares it against a statute's
reach without parsing a place name.
6What this document does not claim
It does not say that any project is liable for anything, and it does not say that any of the practices above is required by law of a project that is not the OPERATOR. It says that the exposure a project creates for its OPERATORs is usually visible from the project's side first, that thirty years of open-source practice have answered the question of whether to build for it, and that the AI law now in force makes the facts an OPERATOR will need unusually easy to name. Nothing here is legal advice.