This page is a draft under review on legal-discuss. It is not yet ASF guidance.
The other pages in this set deal with one question: whether a tool's terms restrict the generated output in ways inconsistent with open-source licensing. A tool's terms also cover things that have nothing to do with that question but still matter to contributors and projects. This page lists the ones to watch for. None of these, on its own, makes a tool's output unsuitable for contribution, and none of them makes it suitable either. They are separate decisions about whether and how to use the tool.
Many services use your prompts, uploaded files, and the generated responses to train or improve their models, especially on free tiers. Some allow human reviewers to read them. Paid and enterprise tiers often have better promises, and some vendors offer an opt-out, but you have to check.
Treat anything you paste into a hosted AI service as potentially retained and read. Do not put unreleased security fixes, private list discussion, credentials, personal data, or other non-public ASF material into a service unless its terms and your project are comfortable with where that material goes. Some services also store and process data in jurisdictions that may matter for a given project or employer.
This is a confidentiality question, not a licensing one. A service that trains on your prompts can still produce output you are free to contribute, and a service that never trains on them can still have restrictive output terms.
Some vendors offer to defend paying customers against third party IP claims arising from generated output. Where offered, it is usually limited to specific paid tiers or listed services, and often conditional on using the vendor's required mitigations. Free tiers are commonly excluded.
Indemnity is worth knowing about, but it does not answer the terms question either way. A tool with no indemnity can have perfectly acceptable output terms, and an indemnified tool can still restrict its output.
Some contributors are not free to use a particular tool at all, for reasons that have nothing to do with its terms: sanctions or export-control law, government or procurement rules that prohibit particular vendors, an employer's policy, or an institution's security review. Data-jurisdiction concerns fall in the same bucket: where a service stores and processes data can matter to an employer, or under privacy and data-protection law, even when the terms are otherwise fine.
These restrictions bind the contributor, and contributors must comply with them when generating contributions. But they are not output-rights findings: a tool someone's employer prohibits can still have terms that place no restriction on output, and the ASF does not turn third-party prohibition lists into conclusions about a tool's terms. If you are subject to such a rule, follow it; it just isn't part of the terms question these pages cover.
A growing number of tools ask, in one form or another, for AI generated content to be identified as such. Some require it outright: verify output and clearly indicate it was generated by AI before publishing it, disclose that output is AI generated in applications built on the service, or include a machine generation disclaimer in publicly distributed generated code. Others put it negatively, barring you from presenting generated content as written by a human where that would mislead. The negative form amounts to much the same thing, because the practical way to avoid misrepresenting output is to say where it came from.
None of this is a burden if you are already following the Generative Tooling Guidance, which recommends identifying the tool in the commit message with a Generated-by line. That satisfies these requirements for a code contribution, and the guidance's own rule for published text, review it before you publish it or label it, covers the rest. Treat the vendor requirements as one more reason to do what the guidance already asks, rather than as a separate obligation to track per tool.
The exception is where the requirement is written to bind whoever receives the code rather than you. A notice you must apply is a handling condition; a notice your downstream recipients must preserve is a restriction that travels with the output, and those rows are Category X.
All of these tools disclaim warranties and accuracy. Responsibility for what a contribution does remains with the contributor who submits it, which is one more reason generated code needs the same human review as any other code.
Some features attach citations, content credentials, or provenance data to what they produce, and some terms ask you to display or preserve such notices. Whether that is a problem depends on whether the obligation follows the output into contributed code; that case is covered on the What to Look For page, and the Review results page records which tools it has been found in. The mere presence of citations or credentials in a tool's ordinary operation is not, by itself, an issue.
