{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreih7xmbkhy6hxpbrq2vqobbdkglfbgtduqyu4kvfm5ptrwbgtu76xi",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3mm52wqikm2d2"
  },
  "path": "/viewtopic.php?t=33451&p=274270#p274270",
  "publishedAt": "2026-05-18T13:42:20.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "> What are some examples of GPL code that would potentially need to be bundled to make a working AppImage? I'm having a hard time coming up with specific examples.\n>\n> For example, GTK is under LGPL so bundling GTK isn't a concern since the LGPL states that if a user can replace the bundled copy of LGPL with their own copy it is allowed to be bundled. glibc can be bundled (although it isn't recommended) because although glibc itself is GPL it has an exception so that non-GPL software can link against it without being required to relicensed under GPL.\n\nWell, with LGPL there is less of an issue, but the problem is that still makes us a distributor of an LGPL library. LGPL would require us under such circumstances to allow unconditional relinking and essentially we would lose control of our branding. The reason Mozilla didn't have an issue in lgpllibs.so (or whatever it was called) is because nothing that links against that library is touching the user interface. But since GTK touches the interface code and is linked into major libraries like libxul.so that touch our branding and UX, this potentially means we could lose rights over our branding under MPL. Granted, this really is assuming the strictest possible interpretation of the LGPL, but without a lawyer ruling it out, I think the implication is that we're better safe than sorry.\n\nIn all honesty, it we could bundle GTK without losing control of the branding, I suspect we would, for much the same reason we don't like relying on system libs in general.\n\n* * *",
  "title": "Contributed 3rd Party Builds • Re: AppImage of Pale Moon available",
  "updatedAt": "2026-05-18T13:42:20.000Z"
}