The README says what DCCore is for, and who is responsible for what it shares

README.md

@@ -66,6 +66,14 @@ python3 -m unittest discover -s tests -t .
 
 Thousands of them - the count is kept in [docs/FUTURE.md](docs/FUTURE.md) - stdlib-only, on Linux, Windows and macOS, Python 3.10, 3.12 and 3.14 in CI.
 
+## Responsible use
+
+DCCore is a tool for sharing files **you have the right to share**: your own recordings and creations, public-domain and Creative Commons works, and anything else whose licence allows it to be passed on. It comes with no content, points to none, and is not made for distributing material you have no right to distribute.
+
+As the operator, you decide what goes into your shared folders, and you are responsible for it: the bot offers everything in them to anyone who asks. Before you share a folder, make sure you are allowed to - copyright and related laws differ from country to country, and the ones where you live are the ones that apply to you.
+
+The DCCore contributors do not host, control, monitor or endorse anything any bot shares, and accept no liability for how the software is used. See also the "no warranty" terms of the licence below.
+
 ## License
 
 DCCore - an IRC DCC file-sharing daemon

docs/UPDATES-PUBLIC.md

@@ -2,6 +2,7 @@
 
 ## Unreleased
 
+- **Added: a "Responsible use" note in the README.** DCCore is for sharing files you have the right to share; you decide what your bot offers and are responsible for it; the contributors do not host, control or endorse anything any bot shares.
 - **Added: a bot that keeps failing is paused, and a full disk makes downloads wait.** If DCCore cannot connect to a bot three times in a row, that bot is paused - its downloads stay queued with a **Resume** button on the Downloads page - instead of failing file after file. And when the drive fetched files go to has less than 200 MB free, downloads wait instead of failing, and carry on by themselves once there is space.
 - **Added: the Downloads queue looks after itself.** Files you queue from another bot wait for it if it is offline and are asked for a minute after it comes back; only three are asked of one bot at a time (*Files asked of one bot at once*), the next going when one arrives, so a big selection no longer earns "queue full"; a "busy" answer is asked again later, three times; and unfinished downloads survive a restart. The Downloads page says why each one is waiting.
 - **Changed: searching and downloading keep working while the list rebuilds.** They used to be refused for the whole of `!update` (or a scheduled rebuild) - often a minute or more. The new list is built next to the current one, so the bot now keeps answering from the list people already have and pauses only for the few seconds it takes to swap the new one in; a request that lands in those seconds is asked to try again shortly. *Pause for the whole rebuild* on the Settings page (`PAUSE_FOR_WHOLE_UPDATE`) brings back the old behaviour.

docs/UPDATES.md

@@ -4,6 +4,15 @@ All version changes, optimizations, and bug fixes made over time in the DCCore p
 
 ## 🟨 Unreleased
 
+### ⚖️ The README says what DCCore is for, and who is responsible for what it shares
+
+The only legal text was the GPL, which covers the code and says nothing about use. A **Responsible use** section,
+just above the licence in the README (and so on the GitHub page and in every download), says DCCore is for sharing
+files the operator has the right to share - their own work, public-domain and Creative Commons works, anything whose
+licence allows it - that it comes with no content and points to none, that the operator decides what is shared and
+is responsible for it under the laws where they live, and that the contributors do not host, control, monitor or
+endorse what any bot shares and accept no liability for how it is used. Documentation only.
+
 ### ⏸️ A bot we cannot reach is paused, and a full disk makes fetching wait (#926)
 
 Item 4 of #926, stacked on the queue pacing below.