{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihtlqq5qgs4ywxipf252oljg6llubyooc7ski7mcrhovnjo6bhjym",
    "uri": "at://did:plc:yrn4rbgwenb6lfhhzjegbtnc/app.bsky.feed.post/3mnxo5xqorxy2"
  },
  "path": "/t/introducing-flutpak-automating-flathub-submission-for-flutter-apps/12294#post_6",
  "publishedAt": "2026-06-10T15:58:29.000Z",
  "site": "https://discourse.flathub.org",
  "tags": [
    "@bbhtt",
    "pdfium-binaries",
    "flatpak-flutter README",
    "@hfiguiere"
  ],
  "textContent": "> @hfiguiere / @bbhtt — a clarification question before I close this out\n\nRegarding the `objectbox-c` rejection: I want to make sure I understand the\npolicy correctly, because I’m seeing something inconsistent.\n\n`flatpak-flutter`’s `foreign_deps.json` — which @bbhtt recommended — ships\nprebuilt native binaries for at least two packages: `pdfium_flutter`\n(prebuilt PDFium from pdfium-binaries,\nApache 2.0) and `audiotags` (prebuilt `linux.tar.gz` from the audiotags GitHub\nreleases). Several apps listed in the\nflatpak-flutter README\nas successfully published on Flathub use those entries.\n\n`objectbox-c` is not in `flatpak-flutter`’s registry, so I’m not claiming\nexact equivalence — but the broader pattern is the same: prebuilt native\nbinaries distributed under permissive licenses, bundled via Flatpak sources.\n\nOn reflection I’m also dropping the “Mere Aggregation” argument I made in the\nPR — the GPL FAQ is clear that modules running linked together in a shared\naddress space “almost surely means combining them into one program”, and the\nFAQ explicitly states that containers do not change this analysis. So\ndynamically linking `libobjectbox.so` into a GPL-3.0 app does constitute a\ncombined work, and the GPL’s source-availability requirement applies to the\nwhole. Since `objectbox-c` has no source available, that requirement can’t be\nsatisfied. The license conflict is real.\n\nThat said, the question about `pdfium_flutter` and `audiotags` still stands —\nboth ship prebuilt binaries (Apache 2.0) via `flatpak-flutter` and those apps\npass review. Is the difference simply that those libraries are also dynamically\nlinked but their permissive license doesn’t create a conflict with the app’s\nlicense? Or is there something else I’m missing about how Flathub evaluates\nprebuilt binary dependencies?\n\nKnowing the answer would help anyone packaging a Flutter app that uses\nObjectBox and trying to understand what’s actually allowed on Flathub.",
  "title": "Introducing flutpak - automating Flathub submission for Flutter apps"
}