SweetSub: fansub subtitle sources with a reuse policy written out in full

The repository holds subtitle sources, not videos

SweetSub is a fansub group, and its GitHub repository is described in one line: subtitle source files from SweetSub. The tree is small. Besides the README there is an Archive directory, image assets for the logo, a .gitattributes file and the GitHub configuration directory. Nothing in the repository distributes video. What it distributes is the timing and text of translations, which is why the reuse rules take up so much more space than a typical open source licence would. The catalogue of what exists is not in the repository either. The README points to a Google Sheets spreadsheet titled as a works list, and that sheet is where a reader is meant to see which titles are covered and in what state. The group also runs a Telegram channel that the README asks readers to follow. So the practical shape of the project is three pieces: a git history of subtitle files, a spreadsheet index maintained outside git, and a chat channel for announcements.

Screen text is aligned to frames, so audio based retiming does not work

The most technically interesting detail in the policy is about timing rather than licensing. SweetSub subtitles contain a lot of on screen text, and that text is aligned to the picture frame by frame. The README warns against using sushi, an audio based subtitle timing tool, on these files, because sushi works from the audio track and therefore cannot keep screen text lined up with the image. Manual adjustment is needed, and the project acknowledges that this is a chore. Its answer is that when an animation gets a BD release, the group publishes a BD version of the subtitles, aligned to the new source. For a reuser, that has a clear consequence. A subtitle file retimed against one source will not line up against another, and the difference is not a small offset that a global shift fixes. The policy therefore grants permission to adjust the timeline as part of reuse, with attribution and non-commercial use, which is exactly the operation that frame aligned screen text makes hard.

Traditional Chinese versions are machine converted and labelled as such

The repository also addresses a section of readers beyond the original language, and it does so honestly. Except for Flip Flappers and the Madoka Magica side story, the Traditional Chinese subtitles are produced with the zhconvert program for automatic Taiwan localisation, and the README states plainly that they have not been manually checked. Readers who want to help are invited to open an issue or send a pull request. There is a second layer of unfinished work here. Entries in the works list that are not marked as a BD collection are described as half finished, and the note says they may still receive various corrections during careful proofreading, so the guidance is to wait until the status changes to BD collection before doing a manual Traditional Chinese conversion. In other words the project tells you which of its own outputs are provisional and which are final. That is a small thing, but it is the difference between a file you can build on and one that will move under you.

Reuse terms are attribution, non-commercial, and no derivatives

The subtitles default to the Creative Commons Attribution NonCommercial NoDerivatives 4.0 licence, which the README links and summarises. Within those conditions the README says the subtitles can be reposted and used freely. It also grants a named exception, which is unusual and practical: adjusting the timeline to match a different source of the same video is allowed under attribution and non-commercial use, as is cropping to match black bars. Attribution has a definition here, and it is stricter than a footnote. When reposting, you must state clearly and legibly that the subtitles come from SweetSub, in a font no smaller than the one used in the post itself, and you must keep the credits that are inside the subtitle file. Two example phrasings are given, one for a plain repost and one for subtitles retimed and then embedded in a video. What is strictly forbidden is stated just as plainly: using the subtitles for commercial or profit purposes, reposting without attribution, and claiming that another person or group made them, including misleading viewers into believing that.

Format conversion and burn in need permission first

Between the allowed list and the forbidden list sits a third category that anyone shipping video needs to read carefully. Sharing modified subtitle files that go beyond retiming and cropping is listed as something to ask about first. So is converting the subtitles into another format, for example turning them into SRT, turning them into image based subtitles, or building external subtitle structures. So is hardcoding the subtitles into the picture and releasing the result as an embedded version. The reason is visible in the licence itself: a no derivatives licence does not permit format translation, and the group treats these cases as negotiable rather than prohibited. The README gives a channel for that negotiation, a Telegram contact and an issue tracker. The instruction for anyone who has already modified the subtitles beyond what the licence allows is blunt: do not publish them, keep them for private use. The rules are dated. They have applied since 2024-08-25, so any older summary of the policy circulating elsewhere is out of date.

The archive and the spreadsheet drift apart on purpose

The README explains that the group re-proofreads subtitles when a series finishes, when a collection is assembled, or after a BD release, and that the files will be corrected at those moments. Anyone reposting or using a subtitle file taken from an uncollected state has to take that into account, because the version they hold is not the version that will remain. This is the practical reason for the Archive directory in the repository, and for the issue tracker, which the README links at the path SweetSub/SweetSub/Archive/issues for people who want to help with the Traditional Chinese work. The catalogue spreadsheet records the state of each title, so the sheet is the authority on whether a given file has been finalised, and the git history is the authority on the text itself. The gap between the two is the risk: a title can be marked as a BD collection in the sheet while an older copy of its subtitles is still sitting in someone's download folder, unchanged.

The licence GitHub shows is not the licence the subtitles use

A few repository level details are worth knowing before you plan around this project. GitHub lists the primary language as unknown and the licence as unknown as well, and the repository has no GitHub releases, so there is no tagged version to pin a build to. The default branch is master, and the last push was on 2026-10-09, which means the subtitle files are still being revised even though the visible catalogue and the legal rules have not changed. The actual licence lives in the README, not in a LICENSE file, and it covers the subtitles rather than any software in the repository. That distinction matters for organisations that run licence scanners over their dependencies: this repository will scan as unlicensed and unlicensed by default, and the terms a reuser must comply with are the ones written in the README and dated 2024-08-25. There is also no build, no package and no runtime, which is the point. The artefact is a text file with timing, and the governance around it is the real content of the project.

Editorial conclusion

SweetSub suits someone who needs subtitle files for a specific release and can meet the attribution and non-commercial conditions, and who has the patience to work with frame aligned screen text rather than assume a timing tool will do it. It does not suit a commercial release, a project that needs subtitles in another format without asking first, or anyone who wants a machine readable catalogue, because the index lives in a spreadsheet outside the repository. Before using a file, check the catalogue entry for that title against the policy rules dated 2024-08-25, and confirm whether the entry is marked as a BD collection, since earlier files are semi-finished and are corrected later.

Frequently asked questions

Official sources

1. Issues
2. README
3. SweetSub/SweetSub on GitHub