open-bibles: Bible translations as XML files with a licence attached

A flat data repository, one file per translation

open-bibles is a repository of public domain and freely licensed Bible translations in some standard XML formats. The shape of it is as simple as a data repository can be. There is no server, no application and no build step in the top level listing, which contains a .github directory, the README, a utils directory and one XML file per translation.

The file names encode the metadata. Each one starts with a three letter language code, then an optional abbreviation for the version, then a suffix naming the XML dialect, so eng-kjv.osis.xml is the King James Version in OSIS and eng-bbe.usfx.xml is the Bible in Basic English in USFX, while eng-ylt.zefania.xml is Young's Literal Translation in the Zefania format. A file with no abbreviation in the middle, such as fin-biblia.osis.xml or kor-korean.osis.xml, is the default translation for that language.

The repository is a Python project by the language classification, which points at the utils directory as the place where any tooling lives, and the topic tags mention a bible API alongside XML, which is what this repository is the data half of.

What you get is a directory of documents with a predictable naming scheme, and nothing else. That is a feature for a consumer who wants to vendor a text into their own pipeline, and a limitation for a consumer who expected a service, since there is no endpoint here to call.

Three XML dialects, and a consumer that has to know which is which

The Format column of the translation table has three values, and they are the structural decision in this repository.

OSIS is the Open Source Initiative XML Schema for scholarly text, and it is the most structured of the three. USFX is a simpler USFM-based format, and Zefania is the third. The table mixes them freely across languages and versions, so the same translation is not necessarily available in the same format as its neighbour, and a consumer that only knows one dialect gets access to part of the catalogue.

The practical consequence is that parsing code is not portable across the repository, only across the files that share a suffix. A tool that reads OSIS cannot read USFX without a second parser, and a corpus project that wants a single schema across many languages has to pick the files carefully or normalise them. The suffix in the file name is the only signal, so any index you build should key on it rather than on the extension, since every file in the repository is an .xml.

The naming also tells you the version when the version is not the default for the language. The abbreviation column in the table matches the middle part of the file name, with CUV for the Chinese Union Version, KJV for the King James Version, ASV for the American Standard Version, WEB for the World English Bible, OEB-CW and OEB-US for the two regional editions of the Open English Bible, and RV1909 for Reina Valera 1909, among others. For a consumer building a verse index, that abbreviation is the key that stays stable as the underlying text is revised.

The licence column is the part to read carefully

Almost every entry in the table is marked Public Domain. The exceptions are worth reading one by one, because they change what you may do with the file.

Three Spanish editions are not public domain. La Biblia en Español Sencillo, the file spa-bes.usfx.xml, is marked CC BY 4.0, which requires attribution. Palabra de Dios para ti, spa-pddpt.usfx.xml, and Versión Biblia Libre, spa-vbl.usfx.xml, are both marked CC BY-SA 4.0, which requires attribution and, more importantly, requires that derivative works are shared under the same terms. If you redistribute a modified version of either of those files, or bundle them into a corpus that you publish, the share alike clause follows the derivative.

One entry is not a licence at all. The Hebrew Leningrad Codex, heb-leningrad.usfx.xml, is marked with a pointer to a note below the table, which means the terms for that file are somewhere else in the documentation and have to be found. It is the one row in the table where you cannot make a decision from the table alone, and it is exactly the kind of entry that gets overlooked because it looks like the others.

The repository itself has no detected licence, and the top level listing contains no LICENSE file, so there is no repository-wide grant to rely on. What governs each file is what the table says about that file, which is the right model for a collection of texts with different origins, but it does mean the table is a legal document and should be treated as one. For a project that needs a single clean answer across every language, the two share alike files and the Hebrew entry are the obstacles, not the forty public domain ones.

A catalogue that spans four centuries and twenty languages

The breadth of the collection is the other thing that makes it useful. The table runs from Albanian, Bulgarian and Chinese through Cherokee, Czech, Croatian and Danish, to Dutch, English in several editions, Finnish, French, German, Hebrew, Hungarian, Italian, Japanese, Korean, Latin, Latvian, Maori, Norwegian, Polish, Portuguese, Romanian, Russian, Spanish, Swedish, Swahili, Tagalog, Thai, Turkish and Vietnamese.

The versions are historically spread rather than uniformly modern. The Statenvertaling is dated 1637 and the Luther Bible to 1912, the American Standard Version to 1901, the Douay-Rheims to the 1899 American edition, the Riveduta to 1927, the Ostervald to 1996, and Reina Valera to 1909, alongside the World English Bible, the Open English Bible in its Commonwealth and US editions, and the Chinese Union Version. A record is marked NT only, which tells you that a text covers the NT alone rather than the whole Bible.

Two practical notes follow from that spread. First, a project that needs the same canon across languages will find the file names disagree about scope, and the NT only annotation is the visible part of that. Second, versions differ in translation tradition, which matters for anything that indexes or compares verses across translations, and the abbreviation column is the only thing that makes two files comparable.

For an application that displays text, this is a gift. For an application that counts verses or aligns them across translations, the divergences between these traditions are the hard part, and no tooling in the repository is advertised as solving them.

A maintained data set with no release cadence

The repository is not archived and the last push was on 2026-07-21. It publishes no GitHub releases, so there is no version to depend on and no changelog to diff, and the default branch is master. For a data repository that is a mild inconvenience rather than a serious one, since the content is stable by nature and the licences change rarely, but it does mean a consumer who cares about reproducibility has to pin a commit.

The two areas to watch are the licence column and the file list. A translation can be added, and a licence can be corrected, and neither change is visible in a release note because there is no release note. The README table is the changelog, which means a tool that indexes the table rather than the directory would be following the licensing changes, and a tool that only globs the XML files would not.

The utils directory is where any scripts live, and the Python language classification of the repository comes from there. Nothing in the listing suggests a service, a schema validation step or a continuous integration job beyond the .github directory, so the repository is best treated as a source of files with a table attached rather than as a maintained package.

The reasonable way to adopt it is to vendor the specific translations you need, keep the licence table alongside them, and treat the commit you took them from as part of your own release notes. The data does not change often, the terms do occasionally, and both facts are easier to manage in a copied file than in a live dependency.

Editorial conclusion

open-bibles fits a developer who needs a machine readable Bible text with a licence they can act on, in particular because the per file table means you can tell at a glance which entries require attribution and which impose share alike obligations, and because the files are flat XML with no service to run. It is the wrong tool if you need a single canonical text, since the catalogue deliberately spans historic and modern versions with different canons and different verse traditions, and it is the wrong tool if you need an API rather than data, since there is no service in the repository, only files and a utils directory. Before you build on it, read the licence column for the specific file you intend to use, check the Hebrew Leningrad entry, whose licence is marked as a see below note rather than a standard term, and decide how you will attribute the CC BY and CC BY-SA editions if you ship them.

Frequently asked questions

Official sources

1. Issues
2. README
3. seven1m/open-bibles on GitHub