Package Details: firefox-appmenu-bin 70.0.1-1

Git Clone URL: https://aur.archlinux.org/firefox-appmenu-bin.git (read-only)
Package Base: firefox-appmenu-bin
Description: Firefox-appmenu, binary version
Upstream URL: https://www.mozilla.org/firefox/
Licenses: GPL, MPL, LGPL
Provides: firefox=70.0.1
Submitter: nikatar
Maintainer: nikatar
Last Packager: nikatar
Votes: 1
Popularity: 0.91
First Submitted: 2019-10-01 14:52
Last Updated: 2019-11-12 18:42

Dependencies (35)

Required by (191)

Sources (2)

Pinned Comments

nikatar commented on 2019-11-12 18:40

gpg --keyserver keys.gnupg.net --recv-keys 85F86E317555BECC1C2184BF2C45BA09ABC5D7DA

Latest Comments

jmodo commented on 2019-11-13 03:28

CAUGHT MY MISUNDERSTANDING BEFORE SUBMISSION: I totally goofed. I had no idea you maintained the source based package as well, that makes way more sense. It may be noted somewhere, but until I searched for it with 'yay -s firefox-appmenu' to check that it installs well enough, I would have never known otherwise. But I am a blind bat...

So not to have wrote all this for absolutely nothing, and since you already maintain the source package, I'll change my scope to teeny suggestions for improving both.

The fact that I couldn't tell where the code used to build this was, goes to show that this package still falls just short of proper COMPLIANCY! Hehehe.

Ignore all my nonsense below, I'm going to leave it since it's not utterly worthless info, and maybe one day it helps someone somehow, heh. TBH, I thought you had patched in support yourself, (I don't use, and don't really know anything about, appmenu), but clearly if I was to read the header comments, there were patches of varying source, I would recommend clearing things up in two ways.

I: Update firefox-appmenu-bin's PKGBUILD to clearly reflect origin of this binary, so it was compiled by Arne Fahrenwalde macgeneral@macgeneral.de, FANTASTIC!!! Where's his source then?! :P OH Jan Steffens maintains this? Hmm, I can't tell him anything regarding licensing! Things are messy.

In the AUR, we're free to be verbose with comments, so I abuse that, I'd header the PKGBUILD as so,

Maintainer: Nikita Tarasov nikatar@disroot.org

# Contributor: Jan Alexander Steffens (heftig) jan.steffens@gmail.com # Contributor: Ionut Biru ibiru@archlinux.org # Contributor: Jakub Schmidtke sjakub@gmail.com # Compiled by: Arne Fahrenwalde macgeneral@macgeneral.de

It's super-duper misleading to leave the maintainer listing Jan Steffens, it gives it undue "clout", and I don't think they'd appreciate it, even if your intention is to show that the majority of the PKGBUILD is their work, do that with comments. like.....

## Built from sources provided by AUR/firefox-appmenu, also maintained by $USER # this build script is adapted from extra/firefox PKGBUILD, with few changes aside from inclusion of appmenu patches # so a big thanks to arch-repo packaging god, Jan Steffens, for maintaining the PKGBUILD I've unforgivingly molested, # whith patches from #source, #source and #source

And aside from comments, definitely add to the package description to make clear to all, up front, that this binary package is built from sources at AUR/firefox-appimage, I often only read up on packages in the terminal, so I would have had to make assumptions, and would have just passed up on this package as is.

################# ORIGINAL HYPER-BABBLE NONSENSE

@nikatar it seems you missed the point of @American_Jesus's comment... The problem isn't the fact it's hosted on your personal github/gitlab/etc repo, but that you are distributing binary packages with seemingly no availability of your source code.

Since you've essentially created your own Firefox build, differing from upstream, you have to comply with the Mozilla Public License (MPL2.0), and you are not in compliance here.

Read the agreement you're required to adhere to, now that you've distributed your own modified binary release, you can't just host a binary without providing us the freedom to inspect all source code involved, particularly any changes, modifications, patches, etc, so we can study it, modify it, share it, fork it, f%3k it, whatever!!!! But by only delivering a binary release, you are infringing on our rights! Hindering our freedom!! Heh, but seriously, you are not in compliance, see the link, and except I've copied here, as well as my suggestions for bringing this PKGBUILD into compliance after that.

The offending secion is 3.2, and potentially 3.3 (the pairing of firefox with appmenu may be considered a larger work, I don't know that appmenu is, or entails). Since you do not comply with 3.2/B, the rights granted to you to distribute by section 2.1 are not currently valid, as you've not met all conditions detailed in 2.7, so your license to distribute is thereby not valid, and you're essentially infringing on the rights of all prior contributors until compliance is reached. I'm copying the essential issues, but you should read it all, considering it's your license now, too!

https://www.mozilla.org/en-US/MPL/2.0/

2.1. Grants

Each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license:

A) under intellectual property rights (other than patent or trademark) Licensable by such Contributor to use, reproduce, make available, modify, display, perform, distribute, and otherwise exploit its Contributions, either on an unmodified basis, with Modifications, or as part of a Larger Work; and

B) under Patent Claims of such Contributor to make, use, sell, offer for sale, have made, import, and otherwise transfer either its Contributions or its Contributor Version.

2.7. Conditions

Sections 3.1, 3.2, 3.3, and 3.4 are conditions of the licenses granted in Section 2.1.

3.2. Distribution of Executable Form

If You distribute Covered Software in Executable Form then:

B) such Covered Software must also be made available in Source Code Form, as described in Section 3.1, and You must inform recipients of the Executable Form how they can obtain a copy of such Source Code Form by reasonable means in a timely manner, at a charge no more than the cost of distribution to the recipient;

3.3. Distribution of a Larger Work

You may create and distribute a Larger Work under terms of Your choice, provided that You also comply with the requirements of this License for the Covered Software. If the Larger Work is a combination of Covered Software with a work governed by one or more Secondary Licenses, and the Covered Software is not Incompatible With Secondary Licenses, this License permits You to additionally distribute such Covered Software under the terms of such Secondary License(s), so that the recipient of the Larger Work may, at their option, further distribute the Covered Software under the terms of either this License or such Secondary License(s)

SOOO YEAH!

In a nutshell you gotta reach this...

your.code.appmenu.code.license.files.PATCH + firefoxUpsteamCode = the source code you used to produce these binary releases, and BAM! you'll have an MPL/2.0 license compliant distribution (granted appmenu's license is wholly compatible, I still haven't googled it)

So my suggested roadmap to compliance!

Create a new git repo "firefox-appmenu-bin" you are wholly compliant once all code needed to build the same binary is freely accessible, and LICENSE(S) are shared and compatible.

I'd suggest not pulling in all of upstream, just give credit to mozilla and link to developer.mozilla.org, hg.mozilla, and mozilla.org/firefox, and maybe the current tarball in new readme, mention MPL/2.0 license(s), you don't need to provide upstream code itself, since they do it already, and better than we ever could. (but if you absolutely need to (you don't), you can pull the trunk in as asub:module from hg, over to git using hg-git, or use the mozilla/gecko-dev mirror to do the same, but that's extra messiness with no readily apparent benefits imo)

Compile your additions to source into a patch, share upstream urls, have LICENSE(s), and a README.md detailing a way to go from what you're providing,to a binary release, the exact same code should be shared and used to build by you, and anything withheld would make it a different release, requiring a different source code to be shared... so no funny biznizz. Oh, share the same build instruction in the readme that you have used to make your release binary, as well. You can include alternative build instructions as well.

So to break it down to the bits and bytes, inodez and wide loads...

At a minimum, your repo should be looking like this....

/firefox-appmenu-bin/ /firefox-appmenu-bin/LICENSE ## (MPL/2.0+any necessary for appmenu code) /firefox-appmenu-bin/README.md ## See my ramblings about that below /firefox-appmenu-bin/add-appmenu-compatibility.patch

whether you provide an amended PKGBUILD there is your call, but might as well move it, for simplification.

You should definitely switch to this repo to host release binaries, as well. Then it's obvious that source and binary are available for all, from the end-user, casual meth-abusers, holier than thou free software losers (just pokin' the beehive, with corny wack rhymez pulled from my behind, I'm one of 'em), and their lawyers who will take you on over a packaging issue... they are the literal worst. So yeah! Read licensing agreements! And learn the proper way to adhere to licensing criteria when distributing from now on, so I don't have to get my hands so dirty!

All I need to feel freer, and therefore might even consider installing this package, is a simple readme linking upstream, a diff patch of your changes to upstream, license, that's pretty much it! I know this feels ridiculous, why the need for a binary release, but rules are rules!

Should be a simple thing to accomplish, since you already have your source. Run a diff on it vs upstream, and pipe into a patch file! Them licensing compliance will be yours! Or don't and keep denying me freedom, get your package flagged, piss off Richard Stallman's team of suits, end up homeless & ~/homeless, all because you didn't share the sauce.

nikatar commented on 2019-11-12 18:40

gpg --keyserver keys.gnupg.net --recv-keys 85F86E317555BECC1C2184BF2C45BA09ABC5D7DA

nikatar commented on 2019-10-01 21:05

What do you have in mind? The binary stored on my GitLab repo, because it is not possible on AUR. Also the binary is signed with my pgp-key for security reasons.Thus, even if my GitLab and AUR accounts are hacked, you can always make sure whether I am the author of this package

American_Jesus commented on 2019-10-01 16:37

Why is this a binary stored on a random site and no link pointing to source?