Introducing flutpak - automating Flathub submission for Flutter apps

@hfiguiere / @bbhtt — a clarification question before I close this out

Regarding the objectbox-c rejection: I want to make sure I understand the policy correctly, because I’m seeing something inconsistent.

flatpak-flutter’s foreign_deps.json — which @bbhtt recommended — ships prebuilt native binaries for at least two packages: pdfium_flutter (prebuilt PDFium from pdfium-binaries, Apache 2.0) and audiotags (prebuilt linux.tar.gz from the audiotags GitHub releases). Several apps listed in the flatpak-flutter README as successfully published on Flathub use those entries.

objectbox-c is not in flatpak-flutter’s registry, so I’m not claiming exact equivalence — but the broader pattern is the same: prebuilt native binaries distributed under permissive licenses, bundled via Flatpak sources.

On reflection I’m also dropping the “Mere Aggregation” argument I made in the PR — the GPL FAQ is clear that modules running linked together in a shared address space “almost surely means combining them into one program”, and the FAQ explicitly states that containers do not change this analysis. So dynamically linking libobjectbox.so into a GPL-3.0 app does constitute a combined work, and the GPL’s source-availability requirement applies to the whole. Since objectbox-c has no source available, that requirement can’t be satisfied. The license conflict is real.

That said, the question about pdfium_flutter and audiotags still stands — both ship prebuilt binaries (Apache 2.0) via flatpak-flutter and those apps pass review. Is the difference simply that those libraries are also dynamically linked but their permissive license doesn’t create a conflict with the app’s license? Or is there something else I’m missing about how Flathub evaluates prebuilt binary dependencies?

Knowing the answer would help anyone packaging a Flutter app that uses ObjectBox and trying to understand what’s actually allowed on Flathub.