exec packages for linux (appimage, snap, flatpak)

[dapgo]

I like the apple approach of having an app on a single binary package, so I would like to have Basilisk for linux and I think it is a must to have for at least these reasons:

• very portable

• easier for basic users ( quite similar to the images used on MacOS)

• not distro dependant (all dependencies included)

Of course including all the files is a waste of storage but i think it is not a problem anymore


Unfortunately Basilisk is not on
https://flathub.org/apps/search?q=basilisk
https://snapcraft.io/search?q=basilisk
https://appimage.github.io/apps/

[Moonchild]

From previous analysis of this question we've come to the conclusion that it's not legally possible to create any of these bundled formats of any UXP application because it will invariably bundle GPL-licensed libs as an essential part of the bundled format. The GPL prohibits this kind of creation of a "larger work" with differently-licensed software and the MPL is incompatible with the GPL for that purpose. Not to mention other included licensed modules in our UXP source code under other licenses.
It is a problem with the "absorbing" nature of the GPL which basically demands everything it touches also be GPL licensed.

Since Basilisk is built on UXP and Goanna, the same problems occur when suggesting bundling with GPL libs.

[Lucio Chiappetti]

I ignore completely the legal aspects of the matter, and I suspect that my information on snap for developers is incorrect. As a Linux user I had only one experience with snap, and that was for the installation of the old image viewer "xv". As far as I understood (but most likely I understood incorrectly) xv could not be distributed in the distro repositories because of some copyrighted libraries, but it could be distributed as a snap since it is sort of statically linked. But the point is that the snap version (of xv) is built with some inconvenient limitations (for one, it assumes that the user home is /home/user, while on our machines it is usually /machinename/user (non standard but convenient for us), and it forbids access to filesystems outside /home.
Since then I carefully avoided using snap. And as a plain user I would not endorse it for any package.

Off-topic:
(and incidentally, the old xv binary I had works perfectly moved on the new machine)

[Basilisk-Dev]

I like the apple approach of having an app on a single binary package, so I would like to have Basilisk for linux and I think it is a must to have

While I do fully understand why you feel the way you do, and I'm not against this, it isn't on our roadmap at this time.

If we were to release any of these it would be an AppImage. I would accept a PR if someone were to implement this.

From previous analysis of this question we've come to the conclusion that it's not legally possible to create any of these bundled formats of any UXP application because it will invariably bundle GPL-licensed libs as an essential part of the bundled format. The GPL prohibits this kind of creation of a "larger work" with differently-licensed software and the MPL is incompatible with the GPL for that purpose. Not to mention other included licensed modules in our UXP source code under other licenses.

I haven't done any research into this, but I'm not sure if your assessment is correct or not. There are Flatpak and Snap packages for other MPL licensed software such as Firefox. I feel like Mozilla would not have released a Snap nor a Flatpak if this were a concern.

[dapgo]

I've been using Firefox on appimage and Snap format without problems.
So I suppose that other webbrowser should work in a similar way

I ignore completely the legal aspects of the matter, and I suspect that my information on snap for developers is incorrect. As a Linux user I had only one experience with snap, and that was for the installation of the old image viewer "xv". As far as I understood (but most likely I understood incorrectly) xv could not be distributed in the distro repositories because of some copyrighted libraries, but it could be distributed as a snap since it is sort of statically linked. But the point is that the snap version (of xv) is built with some inconvenient limitations (for one, it assumes that the user home is /home/user, while on our machines it is usually /machinename/user (non standard but convenient for us), and it forbids access to filesystems outside /home.
Since then I carefully avoided using snap. And as a plain user I would not endorse it for any package.

Off-topic:
(and incidentally, the old xv binary I had works perfectly moved on the new machine)

[Moonchild]

I haven't done any research into this, but I'm not sure if your assessment is correct or not. There are Flatpak and Snap packages for other MPL licensed software such as Firefox.

As far as I was able to determine it's not allowed according to the licenses involved (specifically the GPL) if you strictly follow them (which one should). If you want I can take some time to break my understanding of it down for you. I just wanted to make sure you're aware of potential licensing issues here before putting time into creating these app packages.
From what i understood they can't be made without at least including some GPL libs in the packages. I don't know if Firefox app packages include or exclude them (if excluded they would have to draw on system libs in which case it'd be less portable/compatible with different distros).

[vannilla]

According to https://www.gnu.org/licenses/license-list.html.en the MPL version 2.0 is compatible with the GPL.

Section 3.3 provides indirect compatibility between this license and the GNU GPL version 2.0, the GNU LGPL version 2.1, the GNU AGPL version 3, and all later versions of those licenses.

When you do, section 3.3 gives you permission to distribute the MPL-covered work under the terms of the same GNU licenses, with one condition: you must make sure that the files that were originally under the MPL are still available under the MPL's terms as well. In other words, when you make a combination this way, the files that were originally under the MPL will be dual licensed under the MPL and the GNU license(s). The end result is that the Larger Work, as a whole, will be covered under the GNU license(s).

From what I can gather the issue is not that they can't be bundled, but that the bundled result ends up being licensed under the GPL license, which is something that might be unwanted. In case of Pale Moon and Basilisk it probably interferes with the branding redist rules, so a bundle would still be a no-go but for different reasons.

[Moonchild]

the bundled result ends up being licensed under the GPL license,

You aren't allowed to re-license software like that. That is the problem.

[Basilisk-Dev]

According to https://www.gnu.org/licenses/license-list.html.en the MPL version 2.0 is compatible with the GPL.

Off-topic:
Being GPL incompatible is a desired trait. See also: https://repo.palemoon.org/Basilisk-Dev/ ... er/LICENSE

[dapgo]

What about the .dmg /apple.image package formats used on MacOS?
As far as i know they are a soft bundle too. It eases things but u can access as it were a folder to all its content files

I don't know much about snap but i would swear that appimage was quite similar to the apple one.

Also seeing the number of available packaged apps, I assume that many apps should be also impacted by same potential infringements.

From previous analysis of this question we've come to the conclusion that it's not legally possible to create any of these bundled formats of any UXP application because it will invariably bundle GPL-licensed libs as an essential part of the bundled format. The GPL prohibits this kind of creation of a "larger work" with differently-licensed software and the MPL is incompatible with the GPL for that purpose. Not to mention other included licensed modules in our UXP source code under other licenses.
It is a problem with the "absorbing" nature of the GPL which basically demands everything it touches also be GPL licensed.

Since Basilisk is built on UXP and Goanna, the same problems occur when suggesting bundling with GPL libs.

[mrnhmath]

AppImage would be your best match for Apple-like software distribution. I find it great for small projects and applications with minimum dependencies like AzPainter, but I can't see how one could handle something like Basilisk without verging on illegality.

I don't know if Firefox app packages include or exclude them (if excluded they would have to draw on system libs in which case it'd be less portable/compatible with different distros).

I would bet on the former, it's just that nobody cares because Mozilla.

[athenian200]

The only way I could imagine this working out is if you could create it without any GPL libraries at all. That is, it would have to ship with an alternate libc (glibc would be out of the question), probably be compiled with Clang, and I don't think you could even use GTK... we'd have to find a toolkit with licensing that was compatible and wire that in as a replacement for GTK.

Probably if you really wanted to work at replacing everything in the stack that depends on GPL with something less restrictively licensed so you could ship the whole shebang as pretty much a miniature Linux distro (that's basically what a flatpak is, it ships with almost everything your OS would need to come with to run the application), but you'd have to almost totally change the way you build the application and make sure it doesn't need anything GPL-licensed at runtime.

The most frustrating thing about this whole situation, is that glibc version compatibility and GTK2 support are sticking points that make the concept attractive, but because of licensing it can't be done for us. It would be really nice to be able to basically ship everything in the build environment with the browser and not rely on any system libraries at all, but GPL, especially GPLv3, makes that idea more or less a pipe dream.

[Basilisk-Dev]

The only way I could imagine this working out is if you could create it without any GPL libraries at all. That is, it would have to ship with an alternate libc (glibc would be out of the question), probably be compiled with Clang, and I don't think you could even use GTK... we'd have to find a toolkit with licensing that was compatible and wire that in as a replacement for GTK.

GCC has an exception where binaries compiled with it do not have to be released under the GPL.: https://en.wikipedia.org/wiki/GPL_linking_exception

GTK is under the LGPL, not the GPL. LGPL basically says that if you modify GTK itself you have to release your modifications to GTK, but you can do whatever you want in terms of licensing your own application that links against GTK.: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/COPYING

glibc is also under the LGPL.

There aren't any issues from a licensing perspective with these three specific components. I'm not sure what other GPL libraries we link against.

[athenian200]

GCC has an exception where binaries compiled with it do not have to be released under the GPL.: https://en.wikipedia.org/wiki/GPL_linking_exception

To my understanding, that's fine for UXP applications themselves, but it would become a problem for flatpaks because they ship with the version of libstdc++ they are compiled against. And the libstdc++.so files are GPLv3, so if they are included in a flatpak, that would constitute a larger work, right?

GTK is under the LGPL, not the GPL. LGPL basically says that if you modify GTK itself you have to release your modifications to GTK, but you can do whatever you want in terms of licensing your own application that links against GTK.: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/COPYING

Right, linking against GTK/glibc isn't where the issue comes in, if it were then we couldn't build against those libraries at all. The issue comes in when we include a bundled copy of glibc or GTK with the application, because then the flatpak is potentially considered a larger work that includes GTK.

There aren't any issues from a licensing perspective with these three specific components. I'm not sure what other GPL libraries we link against.

That is a good question, I am only aware of those three myself, but UXP is pretty huge and depends on a lot of stuff... it's definitely a reason to be careful when it comes to stuff like this. What's really noteworthy is that I think for the most part, the GPL-licensed stuff we rely on is the only real exception to our policy of not relying on system libs. I think on Windows, we actually do ship the MSVC runtime libraries we use with the application because the license isn't viral and is permissive about letting you make sure the application has what it needs to run on computers that don't have MSVC installed, but this is all AFAIK and I am not really the expert on this.

[Basilisk-Dev]

It might be worth our time to email someone at the FSF or GNU project and ask

[Moonchild]

Of note, where we use LGPL licensed libraries in our tree (we do use some), they are dropped in a separate dynamically-linked lib (lgpllibs) to satisfy LGPL requirements of including them in our applications. Even just packing those together in an opaque binary container would be against the LGPL as it won't satisfy the exception under §6 (LGPL 2.1 is what I looked at), so even LGPL libs would need to be handled specially IIUC, let alone full GPL v3 where this is simply out of the question.

[cheriedavy]

Thank you for sharing your perspective on having Basilisk available in a single binary package for Linux. I agree that this approach offers several advantages, including portability and ease of use, especially for basic users. It's also beneficial for avoiding dependency issues across different distributions. While it's not currently available on the mentioned platforms, your input underscores the potential value of such an addition. Hopefully, this idea gains traction in the future.

[andyprough]

Someone could just create a bash shell script that downloads and installs the official Pale Moon tarball (or Basilisk or Epyrus or whatnot) on a typical GNU/Linux system. It would be easy - link the binary, link the icon files, link or create a .desktop file. I find that linking the binary to /usr/local/bin works well and keeps the system nice and tidy.

There's a lot of software that's provided that way - I know that Virtualbox has a shell script installer, the Guix package manager, Bedrock Linux to name a few. The Arkenfox user.js updater is a simple shell script.

[Basilisk-Dev]

Someone could just create a bash shell script that downloads and installs the official Pale Moon tarball (or Basilisk or Epyrus or whatnot) on a typical GNU/Linux system.

This is basically what I do on my machines now. I could release the script if people want it but I'd need to clean it up and test it on several different distros first since it's catered specifically to the distros I use. I don't want to break anything on anyone else's system because it's different than mine.

[jobbautista9]

Someone could just create a bash shell script that downloads and installs the official Pale Moon tarball (or Basilisk or Epyrus or whatnot) on a typical GNU/Linux system. It would be easy - link the binary, link the icon files, link or create a .desktop file. I find that linking the binary to /usr/local/bin works well and keeps the system nice and tidy.

I think somebody in Arch's AUR has done that for Pale Moon. They do it for software where building is not possible or feasible, which would commonly be proprietary software, but there are browsers too which would take a long time to build for the average user.

Outside of Arch, I'm not sure... Gentoo maybe?