I'll raise adding wifi nonfree drivers to the classical iso images for Mageia 9,
to reverse the 2012 decision not to have them.

CC: (none) => davidwhodgins

Requested a formal council vote about using nonfree drivers in the installer in
https://ml.mageia.org/l/arc/council/2021-02/msg00011.html

CC: (none) => isobuild

Thanks Dave
And well worded there :)

Status comment: For Council => Formal council vote requested

If the council agrees to the change, the way I'd like to see it work would be
that during the adding of online repositories, where it currently displays
"unable to find network interface for selected device", the installer be changed
to ask if nonfree drivers should be used (default to yes), and then retry
the connection after loading the needed module.

FWIW I agree.  

If we want to give users the option to use or not use non-free software, it's much more straightforward to simply ask the question once in stage 1 rather than expect the user to (a) know enough to use a nonfree install ISO to start with, and (b) know enough to enable nonfree (and possibly tainted) repositories.  That's an architecture feature of our repositories of which casual users would not necessarily be aware.

It would be much more intuitive to have an initial panel in stage 1 following the install type (NFS, FTP, etc.) that explains the difference among free, nonfree, and tainted, allowing the user to select a preference at that point.  Based on the selection, we would automatically enable firmware options for network support during stage 1 and automatically enable repositories according to his choice.  We'd still need the repository choice panel in stage 2 to allow selection of testing or 32-bit repositories, but we could pre-set the nonfree and tainted settings based on the information collected in stage 1.

This would also cut down on the number of ISOs (at least for network install).  A single ISO would contain all of the nonfree and tainted code possibly needed, and simply ignore the unneeded code based on the users' choice.

I suppose there are people who would object to nonfree/tainted software being in an ISO even if they have the option to choose not to use it, but if they choose to go free, the resulting installed system will still be totally free.

CC: (none) => ftg

tainted media will _never_ land on any official isos.

Just to clarify, the reason tainted repositories are not on the iso images is
that it may open Mageia up to possible lawsuits by patent holders.

As it is, the user's decide if they want online access to patented software by
enabling the tainted repositories, so they accept the risk.

Including the tainted repositories in the classical iso images would mean
Mageia Organization has made that choice for them, making us responsible.

It's also the choice of sites mirroring the Mageia repositories whether or not
to include tainted repositories, and by doing so, accept the legal risk that
creates.

It's a legal technical distinction, but an important one.

OK, that makes sense, sort of.  But nothing in the install requires tainted anyway, so take my comments above to include only nonfree.

I still don't understand the legal distinction between making tainted available for download by Mageia (regardless of whether individual mirrors choose to mirror tainted) and making it available for download via ISO.  Do we actually send ISO images out to people unsolicited ?  If not, how are we any more liable in the ISO case than in the repository case ?  AFAIK, Mageia is based in France because French law allows providing tainted.

People discussing this need to understand the difference between nonfree drivers and nonfree firmware.

nonfree firmware is needed by many of the free wireless drivers, and that is what is included on the nonfree netinstall ISOs. The firmware files just need to be present in /lib/firmware so the kernel drivers can find and use them. It might be possible to add in the nonfree firmware by mounting it as an overlay filesystem on top of the base filesystem used for stage 1. Then we could add a boot menu option to enable/disable that.

nonfree drivers on the other hand need to be built and installed. That requires something to detect what drivers are required and the tools necessary to build and install them (gcc, binutils, kernel headers, ...). None of that is available in stage 1, and would bloat it enormously. So I don't see that being an option for the netinstall ISOs.

CC: (none) => mageia

well, the technical switch is simple (if we go for nonfree firmwares in installer without opt-in/opt-out)

it's basically using the nonfree initrd instead of the free one at build time.

but that adds some 55MB of iso size to cope with (iirc we are close to dvd size already)

and of course this was not an issue before as wifi (besides open/wep) was not supported so no-one really cared...

but now when martin fixed that, it exposed this as a possible enhancement :)

fix one bug, get several new ones :)

I know probably most people dont care about "nonfree" when it comes to firmwares, as they are needed to get most newer hw to work...

it's just a question of how "pure / clean" one expects the system to be.

we even have had some requests about providing de-blobbed kernels, but...

(In reply to Thomas Backlund from comment #11)
> well, the technical switch is simple (if we go for nonfree firmwares in
> installer without opt-in/opt-out)
> 
> it's basically using the nonfree initrd instead of the free one at build
> time.
> 
> but that adds some 55MB of iso size to cope with (iirc we are close to dvd
> size already)
> 

As usual, I can only comment from the point of view of the netinstall ISOs, since I don't use the others, but from the previous comments the other ISOs contain nonfree stuff anyway.  

The size of the netinstall ISOs is currently about 115MB (for the nonfree version), so the additional 55MB doesn't seem to be much of an additional burden.  If it's a burden for the full classical ISO, I can't imagine that we can't find 55MB of stuff that could be installed after the fact that would justify preventing the install itself.

(In reply to Thomas Backlund from comment #12)
> I know probably most people dont care about "nonfree" when it comes to
> firmwares, as they are needed to get most newer hw to work...
> 
> it's just a question of how "pure / clean" one expects the system to be.
> 
> we even have had some requests about providing de-blobbed kernels, but...

I really don't care about the pure/clean question, but I don't see the distinction between firmware and software in this case.  If you don't want to use nonfree stuff, what is the difference between nonfree stuff that your hardware requires and nonfree stuff that you want to use ?  If you don't want anything nonfree on your system, then buy hardware that doesn't need it, and live with the resulting restrictions.

I'm not sure why the distinction matters either, but apparently it does.

As I understand it:

Nonfree: Vendors are happy we use it, some users avoid it for potential unknown or nondiscovered security risks, and also potential spying, backdoors etc.  Example: some wifi drivers.

Tainted: May be illegal depending on who you are, what you use it for, and in what country. Decided by patents or governmental laws. Some users are happy to use it, some avoid it for same reasons as above.  Example: some video codecs.

That said nowadays there are lot of nonfree firmware hidden in modems of different kinds, mainboard firmware "BIOS", GPU, etc.  No tainted though by our definition because you pay for it included in hardware.

As I am not currently member of Council, here is my opinion on this:

No, the main issue here is not having nonfree/bloatware in Classic ISO or not.
They are already.

All we should do is to improve the User's experience by letting DrakX to use 
nonfree firmwares for WiFi connection.

The error displayed is cryptic and forbid totally a WiFi connection within the 
Installer. I know we should at least recommend the use of the nonfree 
NetInstall ISO.

By letting DrakX to use them, this will improves greatly the User's 
experience, let them download updates at Update stage. This also reduces 
bandwidth usage for installation to other computer.

But I know /usr/lib/firmware is 597,9 Mio on my system... somewhat large for 
Classic ISO constraints...

Or, we go for it with current ISO situation BUT we must advertise that Classic 
ISO can't handle WiFi connections and that installation must be done offline 
or with an Ethernet cable. 

Best regards,
Aurélien O
Bugsquad Team

CC: (none) => ouaurelien

*** Bug 28482 has been marked as a duplicate of this bug. ***

CC: (none) => omeritzicschwartz

*** Bug 30399 has been marked as a duplicate of this bug. ***

CC: (none) => estellnb

As discussed by the council in the thread
https://ml.mageia.org/l/arc/council/2021-02/msg00011.html
please ensure the Mageia 9 iso images have the nonfree firmware files
available at boot time.

Those who do not want nonfree firmware files loaded must disconnect the
hardware that needs the nonfree firmware before booting the installer.

  If you do that please enable a boot parameter like "freeonly" or better a default of "nonfree" that can be deleted at boot time from the command line for people who do not want this. Also I have added some argumentation at bug 30399 why I would rather first push for another fix of that issue.

The files must be in /lib/firmware at boot for the hardware to be usable either
for use when adding online repositories for for the installer to configure the
firewall to work with that network interface.

Unlike a kernel module, the firmware can not be loaded after boot, or, as far
as I know, have it's loading controlled by a kernel option.

(In reply to Dave Hodgins from comment #20)

> 
> Those who do not want nonfree firmware files loaded must disconnect the
> hardware that needs the nonfree firmware before booting the installer.

yeah, that does not work for builtin hardware...

(In reply to Dave Hodgins from comment #22)
> The files must be in /lib/firmware at boot for the hardware to be usable
> either
> for use when adding online repositories for for the installer to configure
> the
> firewall to work with that network interface.
> 
> Unlike a kernel module, the firmware can not be loaded after boot, or, as far
> as I know, have it's loading controlled by a kernel option.

well, one can unload/reload modules to trigger firmware reload or use sysfs interface ... but as with any feature... someone actually needs to code it....

  Is there any objection to have a 'nonfree' kernel command line parameter as suggested by me before? The installer can grep for it in /proc/cmdline and disable proprietary firmware if it is not present. Having the firmware enabled without exception at install time and selecting later whether you want nonfree sources or not, does not make much sense to my mind. It would just dazzle the unsuspecting user. 
  On the other hand figuring out any kernel driver that could possibly need proprietary firmware to disable the oss module that needs this firmware on the command line is not anything doable for the average user. The ability to disable proprietary firmware is something that makes it a far less rewarding target for intendedly harmful code that could do whatever you don´t think of, although today it does not seem like a prevalent security issue to me since it will only affect certain hardware, although certain components may be used in many many computers.

The installer doesn't automatically enable the firewall for all network
interfaces. It provides a list of the (detected) network interfaces and asks
the user which ones should be protected by the firewall.

While there are many things that could be done to make it easier to choose
whether or not to use nonfree firmware, most of them require changes to the
installer. Changes to the installer are a last resort. It's difficult to test
properly, as the available hardware for testing is limited. A developer would
need to code the changes. All changes to the installer need extensive testing
to ensure they do not add regressions in edge cases. Ideally any changes to
the installer should be completed before the first alpha iso images for Mageia
9 are created.

By only adding the /lib/firmware files to the installer, it's a very simple
change of what packages to include when building the iso images. It's a change
that can be done without delaying the start of Mageia 9 iso creation.

Whoops I had forgotten about this one.
Active bug for this is 

 Bug 32125 - Council decided to add wifi support on traditional installer DVD ISO for Mageia 9

*** This bug has been marked as a duplicate of bug 32125 ***

Status: NEW => RESOLVED
Resolution: (none) => DUPLICATE