Published `.wasm` files bundle `extension-functions.c`, which carries no license — please offer a build without it

[sxd-nakai-hiroki]

Summary

Every .wasm in the published npm package statically links
extension-functions.c
from the SQLite contrib page. That file carries no copyright notice and no license grant
of any kind, so the published binaries contain third-party code whose redistribution terms
are undetermined.

This is easy to miss: the file is not vendored in this repository. It is downloaded during the
build (Makefile lines 9–11 at cff99da), so source-level license scanning of the repo does
not reveal it. It only shows up when the published artifacts are inspected.

We hit this during a license audit of a downstream product that ships these .wasm files to
end users' browsers via @powersync/web.

Where it comes from

Makefile at cff99da (master):

 9: EXTENSION_FUNCTIONS = extension-functions.c
10: EXTENSION_FUNCTIONS_URL = https://www.sqlite.org/contrib/download/extension-functions.c?get=25
11: EXTENSION_FUNCTIONS_SHA3 = ee39ddf5eaa21e1d0ebcbceeab42822dd0c4f82d8039ce173fd4814807faabfa
16:   extension-functions.c \      # in CFILES
30:   extension-functions.c \      # in MC_CFILES

It is in both CFILES and MC_CFILES, so it ends up in every build variant. The SHA3-256 of
the file we downloaded matches EXTENSION_FUNCTIONS_SHA3, so we are looking at the same bytes
the build uses.

What the file says about its license

Nothing. A case-insensitive search over the 52,188-byte source returns zero occurrences of
copyright, license, licence, public domain, permission, and warranty. The only
attribution is a bare author line, Liam Healy, followed by a change history. There is no
grant of rights and no statement placing it in the public domain.

The contrib page does not help either: the word "license"
does not appear on it, and the only entry that says anything about terms is a different one
(sqlite_fk.tgz: "public domain source code"). So the page's authors do state terms when they
have them, and for extension-functions.c they state none.

SQLite itself being public domain does not extend to contributed files: the core is explicitly
dedicated to the public domain, whereas this file says nothing at all.

What the published packages actually contain

extension-functions.c registers SQL functions that core SQLite does not provide
(strfilter, padc, padl, padr, leftstr, rightstr, proper, charindex,
replicate, reverse, difference, median, variance, lower_quartile,
upper_quartile, …). Their names survive in the .wasm data section, so presence can be
verified directly:

import io, re, tarfile, urllib.request
URL = "https://registry.npmjs.org/@journeyapps/wa-sqlite/-/wa-sqlite-2.0.3.tgz"
MARKERS = [b"strfilter", b"padc", b"lower_quartile", b"upper_quartile", b"proper", b"leftstr"]
with tarfile.open(fileobj=io.BytesIO(urllib.request.urlopen(URL).read())) as tf:
    for m in tf.getmembers():
        if m.name.endswith(".wasm"):
            data = tf.extractfile(m).read()
            hit = [k.decode() for k in MARKERS if re.search(rb"\b" + k + rb"\b", data)]
            print(m.name.split("/")[-1], hit)

Results:

package	.wasm files	contain the markers
@journeyapps/wa-sqlite@2.0.3	8	8
@journeyapps/wa-sqlite@2.0.4 (latest)	8	8
wa-sqlite@1.0.0 (rhashimoto)	2	2

As a control, core-SQLite symbols such as julianday and substr are found in the same files,
confirming the search method works.

Why this matters for the LICENSE file

package/LICENSE in the published tarball is:

MIT License
Copyright (c) 2023 Roy T. Hashimoto

That correctly covers this project's own code, but the published .wasm files also contain
code authored by someone else, under no license. Consumers who comply with the MIT terms are
still left redistributing code they have no demonstrable permission to redistribute.

Is it actually used?

Not by PowerSync, as far as we can tell. We searched the published sources of
@powersync/web@2.2.0 (125 files) and @powersync/common@2.2.0 (150 files) for every function
name that only extension-functions.c provides and found no references. Our own application
does not use them either.

We understand other consumers of this package may rely on these functions, which is why we
are not asking for them to be removed from the default build.

What we are asking for

Please offer a build of the artifacts that does not include extension-functions.c, alongside
the existing ones. Existing consumers keep exactly what they have today; consumers with a
license-compliance requirement can opt in.

Two shapes would work for us, and we would defer to whichever fits your release process better:

1. Additional dist/ artifacts in the same package — e.g. dist/wa-sqlite-noext.*,
   dist/mc-wa-sqlite-async-noext.* (naming is yours), built from a CFILES / MC_CFILES
   list without extension-functions.c. No new version line, no new package. Downstream
   consumers of @powersync/web would alias the fixed import paths in vfs.js to the
   -noext files.
2. A separate version line or dist-tag of @journeyapps/wa-sqlite built without the file.
   Downstream consumers would pin it via npm overrides (since @powersync/web depends on an
   exact version).

The change to the sources is small as far as we can see (static inspection only, not yet
built): drop extension-functions.c from CFILES (line 16) and MC_CFILES (line 30), drop
"_RegisterExtensionFunctions" from src/exported_functions.json (line 2), and skip the
Module.ccall('RegisterExtensionFunctions', …) call in sqlite3.open_v2 (src/sqlite-api.js
line 526) for the variant. RegisterExtensionFunctions is referenced nowhere else in the
sources.

Alternatives, for completeness:

• Remove extension-functions.c from the default build outright (breaking for consumers who
  call these functions; presumably a major).
• Obtain an explicit license from the author and record it in the repository, if the functions
  are considered worth keeping in the default build.

We are happy to open a PR for option 1 or 2 above if you tell us which shape you prefer.

The parent repository rhashimoto/wa-sqlite has the same file in its CFILES; we will
cross-reference an issue there.

[rkistner]

The code is published in the public domain over here: https://gitlab.com/liamh/extension-functions. Liam Healy is the contributer of that code to the SQLite project, so I think we can safely assume the file we're using here is in the public domain.

That said, I'm not opposed to trimming down the default build, sticking to standard SQLite as far as possible. Most projects won't need the additional functions provided by this extension. That would be a breaking change though, so would need a major version bump.

[simolus3]

It looks like the scalar version of the extension functions are also available in a default build under a define, so we wouldn't have to download them from elsewhere.

That would be a breaking change though, so would need a major version bump.

With versions 2.x of @powersync/web, wa-sqlite is no longer a dependency users have to add manually. So a breaking change here is also not a huge deal.

[sxd-nakai-hiroki]

Thank you both, that is very helpful — we had not found the GitLab repository.

We checked it: LICENSE there is the Unlicense text (public-domain dedication), added by Liam Healy on 2017-12-19. The extension-functions.c in that repository is one revision newer than the copy on sqlite.org (?get=25, 2010-02-06): the diff is 19 lines (a 2010-06-03 warnings patch and three variable initialisations), so the two are clearly the same work.

Two small caveats for the record, not objections:

• The dedication lives in the repository's LICENSE file, not in the .c file itself, and the sqlite.org copy is fetched without it. So anyone auditing the published .wasm or the sqlite.org download still finds no licence statement.
• The file header says "I have basically packaged up someone else's code", so the dedication covers Liam Healy's own interest; the original author is not named.

From our side, the public-domain dedication answers the substantive question. What it does not change on its own is the state of the published artifacts: they still link code that carries no licence statement anywhere a consumer can see, and a licence review of the .wasm reaches the same dead end we did. So we would like the provenance recorded in this repository, where a consumer will actually find it. Would you be open to either of these, both non-breaking?

1. Point EXTENSION_FUNCTIONS_URL at the GitLab copy (which ships with the LICENSE) and mention extension-functions.c / public domain in this repository's LICENSE or a NOTICE, or
2. Keep the sqlite.org URL and just add the provenance note (GitLab link + Unlicense) to the repository.

Either would let downstream licence registers cite something concrete. We would be glad to send that as a small PR.

Separately, if you do decide to trim the default build to standard SQLite (plus SQLITE_ENABLE_MATH_FUNCTIONS) in the next major, we would be happy to help with that too — but we would not want to block on a major for the licensing question alone.