While Calibre being GPL v3 (with some code vendored in from a variety of different other GPL-compatible licenses) constrains much of Arcalibre to be GPL v3 as well, there is the question of what license should be used for all new code going forward, such as the spellsnake wrapper in arcalibre!14. I lean heavily towards copyleft licenses, after seeing how much "permissive" licenses have facilitated an undermining of labor rights, but even there, is GPL v3 the right answer? Are there other copyleft licenses worth considering, or other GPL variants like AGPL v3?

Background

Currently, Arcalibre has about 27k lines of code inherited from Calibre written in RapydScript-NG (ext *.pyj), a compile-to-JavaScript language intended to be close enough to Python to allow for copying and pasting some code between the two.

RapydScript-NG itself is Kovid Goyal's fork of RapydScript, and as far as I am able to tell, is used exclusively in Calibre and its forks. The original Calibre build includes a snapshot of the RapydScript-NG compile as an xz-archive, itself minified from the compiler by the bin/web-repl-export script in the RapydScript-NG repo as called by calibre.utils.rapydscript.update_rapydscript.

Calls into RapydScript-NG language code currently use the QtWebEngine set of Qt components backed by the "headless" QPA plugin bundled with Calibre, which adds a significant additional chain of dependencies above and beyond the RapydScript-NG compiler itself. Notably, this chain of dependencies is responsible for some Arcalibre failures and other failures downstream of the original Calibre codebase wherein QtWebEngine fails to initialize a Vulkan context.

Moving Forward

Given that RapydScript-NG is a large additional dependency and is less needed given the state of modern JavaScript (it's a much nicer language now than it was in 2012, when version 0.1.0 of RapydScript was first released!), if Arcalibre is going to be a maintainable fork of Calibre and not only an archival (see https://forums.rereading.space/post/6), we'll likely need to rewrite RapydScript-NG code in pure JavaScript, or at most some well-established compile-to-JS language like TypeScript. That in turn raises a question: how do we do that? The contents of src/pyj currently contain a number of interdependent module imports, making it difficult to switch to more conventional JavaScript.

Footnote about TypeScript

While I don't necessarily advocate for TypeScript, it's worth noting that that would still reduce the weight of external dependencies, as it can be obtained and executed using npx rather than via a bespoke compiler and a toolchain that includes an implicit Vulkan dependency. Pure JavaScript requires even less in the way of dependencies, and may be better on that basis, to be sure.

Questions

• Should we remove RapydScript-NG code?
• What should replace it? Pure JavaScript, TypeScript, or something else?
• If we do remove RapydScript-NG code, how should we go about doing so?

The initial goal of the Arcalibre fork of Calibre was to create an "archival fork" of Calibre, locking in the state of Calibre as of 5 December 2025, with AI antifeatures removed and a reproducible build added.

That turns out, with several days of looking at Calibre's build system in more detail, to be a bit more difficult than I expected. Calibre is a 500k or so line project, about 10k of which is build support — much of that comes in the form of implicit dependencies on the host environment, such as expecting tools like podofo to be installed, and much comes in the form of C/C++ code like SQLlite and Qt extensions.

Given all that, a natural question is then whether making an archival fork still makes sense, or whether Arcalibre should pivot to deprecating or removing features that impose too high a maintenance version and rearchitecting some of Calibre's internals to be more easily maintainable. As an example of the latter, it could be worthwhile to extract Calibre's database model into its own wheel that could then be depended on from either Arcalibre or other tools that want to read from Calibre-style databases.

If we do decide to pivot away from being an archival fork, what features should we keep and which ones should we deprecate or remove? For example, one of the libraries with an implicit host dependency at the moment is pychm, a small Python wrapper around chmlib, itself a library for reading Windows *.chm help files. chmlib hasn't seen an update since 2009; that's not a bad thing per se, but does raise the question if it should continue being a dependency. On the other hand, Calibre also depends on html5-parser, which creates libxml trees from trees produced by Gumbo, an HTML5 parsing library by Google. Unfortunately, Gumbo has been deprecated since 2016, and is not recommended for production use. Unlike chmib, though, an HTML parser is very clearly in scope; should html5-parser be kept as-is, or replaced with something like html5ever? More to the point, what criteria should we use in making these decisions?

One option for hosting governance discussions that's been brought up a few times is to spin up a Loomio instance. That seems to me to be a good approach, but I wanted to ask if folks here had any thoughts on that before pulling the trigger.