Licence compliance

Ilavrita is distributed under the AGPL-3.0 and is scanned by the FOSSA GitHub App on every push and pull request.

This page records what the scanner reports and what we concluded, so a flagged dependency is either fixed or explained — never silently ignored.

It is an engineering determination, not legal advice.

Current state

The License Compliance check on dev is red: 15 issues, read from the commit status at 6da26a9 and again at 8a17b23 on 2026-09-19.

gh api repos/Ilavrita/Ilavrita/commits/<sha>/status \
  --jq '.statuses[] | select(.context=="License Compliance") | .description'

That is a live count, and the breakdown below is not. The groups and verdicts in this page were established against a scan of 28 issues (27 licence, 1 vulnerability) recorded on 2026-09-14. The count has since moved to 15 without this page being re-derived, so:

• The determinations below still hold. They are about what each module contains and whether it reaches a released artefact, and that does not change because a scanner's issue count did.
• The attribution does not. Which of today's 15 belongs to which group has not been checked, and this page should not be read as saying it has.

Re-deriving it means opening the FOSSA project and listing the current issues per package. Until that is done, the honest statement is: 15 open issues, the modernc.org/libc question and CVE-2023-36308 are both still open, and the remainder are believed to be the scanner artefacts described below.

The engineering checks being green says nothing about this. Lint, tests, the container build and the description check all pass at 8a17b23; License Compliance is a separate, still-red work queue.

Evidence from the scan of 2026-09-14

The two self-flags

FOSSA flags AGPL-3.0-only and AGPL-3.0-or-later on Ilavrita itself. The project is deliberately AGPL-3.0; this is the policy reporting our own licence back to us, not a dependency risk.

The dependency flags

Four Go modules are flagged. Three are file-scan artefacts. One is not, and it was misreported in an earlier revision of this page.

golang.org/x/text, golang.org/x/crypto, modernc.org/sqlite — artefacts

None of these contributes licensed material to a released artefact. Concluding each as BSD-3-Clause is well founded.

modernc.org/libc — needs legal review

modernc.org/libc declares BSD-3-Clause, and its LICENSE-3RD-PARTY.md lists only Go (BSD-3-Clause), musl libc (MIT), go-netdb and NixOS/nixpkgs.

That notice is incomplete. The package is generated by ccgo, which transpiles system headers, and the generated Go files carry the licence comments of the headers they came from. Measured at v1.74.4:

The 32 are transpiled from glibc headers and carry the GNU C Library's LGPL-2.1 notice verbatim. They compile into ghcr.io/ilavrita/ilavrita for both published architectures. Examples: pwd, grp, termios, dirent, unistd, fcntl, poll, time, sys/stat, sys/types, wctype, langinfo.

What they contain is the ABI surface rather than glibc's implementation — pwd/pwd_linux_amd64.go, for instance, is 789 lines holding 72 type declarations and 27 constants, and no functions.

Engineering conclusion: LGPL-2.1 is compatible with AGPL-3.0, so the AGPL distribution raises no new obligation. The open question is the commercial licence Ilavrita intends to offer alongside it (PRD risk R-006): relicensing a product that carries LGPL-derived material you do not own is exactly the case that risk describes.

This needs a lawyer, not a scanner. Do not mark modernc.org/libc as BSD-3-Clause to clear the checks — that would record a conclusion this page's own evidence contradicts. Options worth putting to legal review:

1. Accept it. Header-derived type and constant declarations are widely treated as interface facts rather than protectable expression, and glibc's own position is permissive about headers.
2. Avoid it. modernc.org/sqlite is the only reason libc is present. A CGo-backed SQLite driver, or a different storage backend, removes the question — at the cost of the pure-Go single-binary property that ADR 0002 selected embedded-runtime for.
3. Scope it. Offer the commercial licence only for deployments where the obligation does not arise.

Until that review happens, the AGPL distribution is unaffected and these issues should stay open in FOSSA, where they are visible.

Correction

An earlier revision of this page stated that the GPL and APSL text in modernc.org/libc lived only in testdata/ and *_darwin_*.go, and was therefore excluded from Linux builds by build constraints. That was checked for darwin and generalised without checking the Linux files. It was wrong: 52 files that do compile on Linux carry copyleft notices, and 32 of those carry no exception.

The one genuine finding

A crafted TIFF file can crash the decoder. The dependency reaches us through embedded-runtime, which uses it for thumbnail generation, and upstream has published no fixed release.

Reachability was assessed twice, and the first assessment was wrong. /fhir/R4 exposes no image handling, but the process also served embedded-runtime's own /api/files/… thumbnail route, which reaches the decoder directly. That surface is now disabled by default (FR-029) and can only be restored with ILAVRITA_EXPOSE_embedded-runtime=true, so a default deployment does not reach the decoder.

The advisory itself is narrow: AV:L, user interaction required, availability impact only, EPSS 0.4%, and NVD notes it is unclear whether any common use case carries a security consequence. The realistic effect is a panic on one request, not data exposure.

Payloads are now implemented (FR-032), which this page previously named as the point at which the advisory becomes material. Re-checked on 2026-09-19: it does not, because Ilavrita's payload path decodes nothing. Binary bytes are hashed and written to disk and served back verbatim, and DocumentReference refuses inlined bytes altogether. Nothing under /fhir/R4 reaches an image decoder.

It remains a release gate for any build that restores the embedded-runtime thumbnail route, and it would become one again the day Ilavrita itself renders, resizes or inspects an uploaded image.

Clearing them

FOSSA's REST API is read-only for issues. Verified 2026-09-14 against fourteen endpoint variants: every issue read succeeds, every issue write returns 404, and policy writes return 403 User not permissioned. The work below has to be done in the FOSSA dashboard.

It is smaller than the issue count suggests. The ten "Denied by Policy" issues sit on three packages, and FOSSA applies a licence conclusion per package — so that is three actions, not ten.

1. Conclude three dependency licences

For each package below, open it in the project's dependency list, choose Conclude licence, set BSD-3-Clause, and paste the note.

Do not conclude modernc.org/libc. Its flags are not artefacts — see above. Leave those issues open until the commercial-licence question has had legal review.

2. Resolve the two AGPL self-flags

These are on Ilavrita itself, not a dependency. Resolve with: this is the project's own declared licence.

3. Leave CVE-2023-36308 open

It is real, it has no fixed version, and it should stay visible until upstream publishes one or the dependency is replaced.

Why the policy is not being changed

The project is assigned FOSSA's Standard Bundle Distribution policy, which is the right one: Ilavrita ships binaries and container images rather than running as a hosted service, so distribution-mode obligations apply.

Loosening the policy to permit copyleft would clear these checks and would be the wrong fix twice over. It would mask a genuinely GPL-licensed dependency arriving later, and Ilavrita intends to offer a commercial licence alongside the AGPL (PRD risk R-006) — a copyleft dependency we do not own would block exactly that.

Running a scan locally

export FOSSA_API_KEY=...
fossa analyze
fossa test

.fossa.yml scopes this to the two manifests Ilavrita ships. The CLI reports into a different project from the GitHub App, so prefer the App's results as the source of truth; CI does not run the CLI, to avoid two projects disagreeing about the same code.

When a new finding appears

1. Establish the module's declared licence before reacting to a file match.
2. Decide whether the flagged code is compiled into a released artefact.
3. Either remove the dependency, or record the determination here.

A finding that is neither fixed nor written down here is not resolved.