Any chance of an official Flatpak release?

[[PCMartin]]

Is there any chance we can look forward to an official, actively maintained Flatpak release of Pale Moon? There are a number of distros that refuse to carry Pale Moon in their repos but that do support Flatpak. (Case in point: Solus.) A Flatpak version would expand the range of distros available to dedicated Pale Moon users who aren't Linux wizards. (Case in point: me.)

[mrnhmath]

There is none. [size=25]Thankfully.[/size]

[[PCMartin]]

Thanks for getting back to me.

I see I should have searched the forum for "Snap" and "AppImage" as well. I think I understand the broad strokes of the licensing conflict. As for bloat, it seems to me that a little bloat might be preferable to potential library conflicts in some contexts. But I'm a Linux noob, so I don't really know what I'm talking about.

I appreciate getting a fast, definitive answer, regardless!

[Moonchild]

Package bloat isn't really a big issue. In fact we work on the premise that people use libs that are in our source tree, and not system-installed ones, when building the browser -- which could be seen as bloat too (but highly functional bloat).

The licensing issue is however a much much bigger problem and as long as the GPL is the way it is, it can never legally be done because of license conflicts.

[mr tribute]

Package bloat isn't really a big issue. In fact we work on the premise that people use libs that are in our source tree, and not system-installed ones, when building the browser -- which could be seen as bloat too (but highly functional bloat).

The licensing issue is however a much much bigger problem and as long as the GPL is the way it is, it can never legally be done because of license conflicts.

I'm no expert, but maybe Linux distros break GPL all the time when they ship Firefox as default browser bundled with the ISO download.
I remember there was an issue with the Mozilla trademark that was solved with Debian hence Firefox instead of IceWeasel. But the problem may go deeper than that if indeed the Mozilla license (and Pale Moon license) isn't compatible for bundling with the Linux kernel and other GPL software.

Maybe strict GPL enforcement would kill Linux distros in a heartbeat (as they ship today) and that's why "no one" is taking GPL seriously.

[yami_]

I remember there was an issue with the Mozilla trademark that was solved with Debian hence Firefox instead of IceWeasel.

IIRC Mozilla did not want Debian to use their Firefox trademark for the modified build that was distributed with Debian.

[mr tribute]

Off-topic:
Android handsets are very proprietary but use the Linux kernel. I think GPL allows for bundling as long as the GPL binaries are kept pure/open source. So if I understand correctly Android has to run proprietary drivers in user space instead of kernel space (which means reduced performance), because otherwise the drivers would have to be open sourced under the GPL.

[Moonchild]

The key difference between bundling as a software collection and bundling as a flatpak is that the flatpak bundling will be bundling GPLed libs that are an an integral part of the application (it won't work without them) and not just a "software collection". That is a specific difference that the GPL distinguishes. The flatpak bundling forces GPL to be applied to the whole, the "part of an ISO" bundling does not.

Please understand that I have read through all the applicable documentation and am by now pretty familiar with the compatibility and incompatibility of the GPL with other licensing models. MPL and GPL licensed components are incompatible when bundled as one larger work/application.

So, please stop asking for these kinds of virtualization/bundling/packaging releases. It's not going to be legally compatible, period.

[vannilla]

Off-topic:
Android handsets are very proprietary but use the Linux kernel. I think GPL allows for bundling as long as the GPL binaries are kept pure/open source. So if I understand correctly Android has to run proprietary drivers in user space instead of kernel space (which means reduced performance), because otherwise the drivers would have to be open sourced under the GPL.

Off-topic:
Linux is licensed under the GPLv2, which has some "loopholes" that allow Android to run certain proprietary drivers alongside the kernel.
Version 3 doesn't allow this, and the "Linux case" is one of the reasons version 3 was released.

[mr tribute]

Off-topic:
Linux is licensed under the GPLv2, which has some "loopholes" that allow Android to run certain proprietary drivers alongside the kernel.
Version 3 doesn't allow this, and the "Linux case" is one of the reasons version 3 was released.

Off-topic:
Mozilla breaking all the rules
https://snapcraft.io/firefox

[Lunokhod]

There used to be Java installers for Debian & derivatives to get around licensing issues like this. It made it easy to install by downloading from the main website and only the installer was in the package. Nothing like that exists for Pale Moon of course, but theoretically speaking would some flatpak package containing an installer be license compatible, or desirable? You might not want loads of users taking up server bandwidth and not visiting the Pale Moon site, and Linux distros tend to like everything to be packaged so they can control what their users will receive, and complain about such ideas being 'Windows'ish'! The Mozilla license isn't written by Pale Moon so must be observed as written, copyright holders can permit any use individually regardless of what license they apply universally iirc. If Mozilla accepts material provided under the license but not holding the copyright then perhaps even they cannot vary the terms.

[Moonchild]

theoretically speaking would some flatpak package containing an installer be license compatible, or desirable?

Compatible? Unknown
Desirable? No. Not only for the reason you thought of, but the whole point of a flatpak is that it is "self-contained". If you're going to break that premise, then why bother having a flatpak/snap/... to begin with? Might as well just "install" the software from archive, or, if dependencies are a concern, use the package manager of the O.S. to take care of those.

At this point I would also like to point out that this kind of packaging and virtualization is explicitly prohibited without my permission by our binary redistribution license (even if it wouldn't directly fly in the face of the code license) which does apply to anything with official branding on it. These kinds of packages are repacks in a custom format (3a), add third party libraries (3c) and employ virtualization/obscure the structure/binaries (3i). In the case of a custom installer in a flatpak, it would violate point 4.

[plushkava]

The key difference between bundling as a software collection and bundling as a flatpak is that the flatpak bundling will be bundling GPLed libs that are an an integral part of the application (it won't work without them) and not just a "software collection".

With all due respect, I don't see why the kind of bundling you describe would be a requirement. I wrote a script to walk the palemoon binary distribution and print any libraries that cannot be resolved by the org.freedesktop.Platform and org.gnome.Platform runtimes, which are independently distributed - and installable - as part of the flatpak ecosystem. Here is the script:

Code: Select all

#!/bin/bash

# Collect executables files from the stock Pale Moon binary distribution
files=()
while IFS= read -r f; do
	[[ -f $f && -x $f ]] && files+=("$f")
done< <(pacman -Qql palemoon-bin)

# Determine their runtime dependencies (requires pax-utils)
mapfile -t deps < <(printf '%s\n' "${files[@]}" | scanelf -f - -Bn | awk '{ print $2 }' | tr ',' '\n' | sort -u)

# Print dependencies that cannot be satisfied by flatpak's freedesktop and gnome runtimes
for lib in "${deps[@]}"; do
	if ! find /var/lib/flatpak/runtime/org.{freedesktop.Platform,gnome.Platform} -name "$lib" | read; then
		echo "$lib"
	fi
done

And here are the libraries that are printed by the script:

Code: Select all

liblgpllibs.so
libmozavutil.so
libmozsqlite3.so
libxul.so

As you can see, all four of those are false positives because they are already bundled by your existing Pale Moon distribution. Ergo, it would appear that everything else that it needs appears to be satisfied by the aformentioned runtimes, all the way down to glibc and that you would not need to bundle anything further. Even ffmpeg is covered.

Granted, there are some nuances. For example, you would need to assert a dependency on version 3.28 of org.gnome.Platform if you want to continue distributing a gtk2 build, because it looks as though gtk2 got the boot from version 3.30. Anyway, the point is that it only requires the manifest to be defined correctly, which is fundamentally no different from the metadata that is used to express the dependencies in other package formats; that is, for libraries that you are unable to bundle.

All in all, I wouldn't be so quick to pooh-pooh the idea because flatpak would conceivably help a lot to make Pale Moon accessible to a larger population of Linux users.

EDIT: Several cosmetic changes and typo fixes.

[New Tobin Paradigm]

I don't understand why you keep persisting.. It is already apparent that some distros need specific builds to run properly because of requirements and distro-specific quirks.. Gentoo, Debian, even latest Fedora now even though we are doing a generic binary on CentOS 7.

Even if there wasn't other concerns, get this through your head. We don't WANT to. End of story, end of discussion. Go hock flatpak at someone else. Moonchild Productions and, for the record, Binary Outcast are not interested.

[plushkava]

I don't understand why you keep persisting..

Who is? This is now my second comment on the thread and will be the last. I only commented in the first place because of a statement that seemed to be in error.

It is already apparent that some distros need specific builds to run properly because of requirements and distro-specific quirks.. Gentoo, Debian, even latest Fedora now even though we are doing a generic binary on CentOS 7.

Not if delivered through a distribution system that provides a consistent set of runtimes. Hell, you can run flatpak packages just fine on a distro that uses musl libc, as Void Linux has demonstrated.

Even if there wasn't other concerns, get this through your head. We don't WANT to. End of story, end of discussion. Go hock flatpak at someone else. Moonchild Productions and, for the record, Binary Outcast are not interested.

Fine.

[New Tobin Paradigm]

Eh, you all blend together though. So sorry if you aren't actually a carbon copy of every other person who has been out to push this crap on us.

[Moonchild]

It should already have been implied by the redist license point 3a/3b (since it's more than just repackaging), but I've adapted it now to explicitly exclude permission for "bundling" archive formats as a new point 3b, moving the rest up a letter.

http://www.palemoon.org/redist.shtml

[New Tobin Paradigm]

As an addendem if you are thinking of asking about Basilisk: redist simply isn't allowed at all without permission.

BinOC software like Interlink has a EULA attached which only allows distribution of unaltered or otherwise identical to what I dist.. and dist of built binaries on open source operating systems require my direct permission.

So you distro-independent package bundle people are simply SOL on every side