In bug 766773 and then https://github.com/gentoo/portage/commit/3c587280434d7f36a45117ed0732362b9c49018f, we disabled --autounmask-license=y by default. I'm not so sure about this. A few developers who do front-line support (myself included) were surprised to have found this change was made and I don't think it's super clear to users what they should do when they first hit the message. Note that this is one of the first "masked by" messages users will hit when doing an install, because of linux-firmware and/or genkernel. We did discuss in #gentoo-dev a few weeks ago about possible compromises to make this more palatable: Edited snippet: ``` <@iamben> should be easy enough to print a message about what license is about to be accepted and where you can read it <@sam_> honestly this argument pretty much works against autounmask entirely, "users should understand their systems", and while it's true, it's not really helpful if you're new & confused <@iamben> we know that most people are going to need to accept more non-free licenses, do we intend to make it painful on purpose just so people become more aware of non-free lice nses? <@iamben> i tend to think it'd be enough to just more clearly print "Say yes to accept FOO license, a full copy can be found at $gentoo/licenses/FOO" <@iamben> no spawning of pagers or second "yes" needed ``` .. and I think that seems like a reasonable way forward.
The reasoning from bug 766773 still applies: Accepting a license should always be a conscious choice of the user.
(In reply to Ulrich Müller from comment #1) > The reasoning from bug 766773 still applies: Accepting a license should > always be a conscious choice of the user. It still is, as they have to: 1. say yes 2. run dispatch-conf/etc-update to accept the licence. As I said in the report, the same argument could be used against autounmask entirely, depending on one's interpretation of "conscious". But the suggested change by iamben may make it more palatable to you.
I doubt that it will be a well informed choice if users just have to answer "y" to yet another of Portage's questions. What is wrong with accepting only free software licenses by default? Can someone please explain to me why this is met by so much resistance?
(In reply to Ulrich Müller from comment #3) > What is wrong with accepting only free software licenses by default? Can > someone please explain to me why this is met by so much resistance? Yes, it baffles me as well why Gentoo users would prefer working hardware over ideological sanity.
(In reply to Ulrich Müller from comment #3) > I doubt that it will be a well informed choice if users just have to answer > "y" to yet another of Portage's questions. > > What is wrong with accepting only free software licenses by default? Can > someone please explain to me why this is met by so much resistance? "<@iamben> we know that most people are going to need to accept more non-free licenses, do we intend to make it painful on purpose just so people become more aware of non-free licenses?" So that's a "yes" from you on that question.
(In reply to Michał Górny from comment #4) > Yes, it baffles me as well why Gentoo users would prefer working hardware > over ideological sanity. Right, we must not have a factual discussion. Let's derail this bug instead. :( Unbelievable. Licenses team is out of here.
I think that maybe the licenses team "can't see the forest for the trees" here. The ideal handling of licenses from the license team perspective makes for a terrible user experience. Let's work on improving the information given to the user at license-autounmask time, to make it very clear what is being agreed to when the user says "yes".
Without autounmask we see this: $ emerge -pvO =intel-microcode-20210608_p20210830 These are the packages that would be merged, in order: !!! All ebuilds that could satisfy "=intel-microcode-20210608_p20210830" have been masked. !!! One of the following masked packages is required to complete your request: - sys-firmware/intel-microcode-20210608_p20210830::gentoo (masked by: intel-ucode license(s)) A copy of the 'intel-ucode' license is located at '/var/db/repos/gentoo/licenses/intel-ucode'. For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. $ ------------ The good: it prints a full path to the license for reading, this is exactly what we want. The bad: it points a user to a large man page section, which actually points the user to a DIFFERENT man page for reading about package.license or ACCEPT_LICENSE in make.conf. If portage could just tell the user what to add to package.license (or make.conf), that would be a huge usability improvement, and in my opinion we'd be ok with keeping --autounmask-license=n default.
With autounmask: $ emerge -pvO =intel-microcode-20210608_p20210830 --autounmask These are the packages that would be merged, in order: [ebuild N ] sys-firmware/intel-microcode-20210608_p20210830::gentoo USE="split-ucode -hostonly -initramfs -vanilla" 13248 KiB Total: 1 package (1 new), Size of downloads: 13248 KiB The following license changes are necessary to proceed: (see "package.license" in the portage(5) man page for more details) # required by =intel-microcode-20210608_p20210830 (argument) >=sys-firmware/intel-microcode-20210608_p20210830 intel-ucode $ ------- The good: it prints exactly what's needed in package.license (though I wish it would be more straightforward in saying that this specific line goes in that specific file). The bad: it doesn't print a path to a license or really tell the user that they're about to accept a non-free license.
