TL;DR: I tried to think about what all would go in non-free-firmware if we create it. I think there are some complicated questions especially around source dvds and dependencies.
Hi. So it sounds like a number of the options involve creating a non-free-firmware component, and we might even have rough consensus to do that. I'd like to explore what would go in that component and how that component would interact with the existing archive components. I started by running apt search firmware and admittedly found that it was a bit more tricky to figure out what was actually firmware than I hoped. But we have lists of packages presumably from the existing unofficial non-free images. So let's assume that at least all those packages can move to non-free-firmware. And for binary packages, that's probably a good starting place at least if we don't think too hard. Unfortunately, things get more complicated when I start thinking about source and building, and there are even some complicated cases for binaries. Some Assumptions ================ 1) We are making changes around firmware for practical reasons. We are not revisiting questions like whether firmware is software in the meaning of DFSG, or whether everything other than licenses in main needs to follow the DFSG. Yes, some people might want to revisit those things, but for the most part, our motivation is about helping our users by giving them images that actually work securely on hardware they have. 2) We value being able to build from source when we can. We value being able to have reproducible builds when we can. We don't want to take steps backward in those areas in order to get hardware working better. 3) We want to limit what goes into non-free-firmware so as not to encourage people to install arbitrary non-free software. I think the actual limits are unclear, but are no broader than non-free packages that make hardware work. I'll talk about the specific limits later. But I think that it is widely agreed that if we're going to create a non-free-firmware component we don't want all of non-free sneaking in. If we didn't care about that, we could just use the existing non-free. Build Dependencies ================== So, many packages containing firmware are just binary blobs. If assumption 2 is true, we don't want to require that be the case. If partial source code is available, we want to be able to build those parts. If source code is available, but has restrictions (for example certain modifications are not permitted), we want to be able to use that. So, when possible, we want to b e able to build firmware. What happens when firmware wants to build-depend on tools in non-free? I think we have a few options: 1) Don't actually build the firmware; ask maintainers to include build artifacts in the source package. This violates assumption 2. 2) Allow non-free-firmware to build-depend on non-free. This is fine, and may be my preferred option. It has implications for source distribution: effectively sources to the non-free-firmware component would not be useful without sources to non-free. See below in the "Source Distributions" section for why that might be problematic. 3) Move build tools needed by non-free-firmware into non-free-firmware. That at least partially violates assumption 3 above, because we are now making some non-free build tools available with non-free-firmware. 4) Create a non-free-firmware-build component and move the build tools needed by non-free-firmware there. Builds of packages in non-free-firmware are permitted to build-depend on non-free-firmware-build, but the installer would not enable non-free-firmware-build in the same situations it enables non-free-firmware. In options 2-4, I think it makes sense to enable build-dependencies on contrib for packages in non-free-firmware. In option 3, dependencies of contrib packages needed in a build would be moved into non-free-firmware. In option 4, they would be moved into non-free-firmware-build. As a consequence of options 2-4, non-free-firmware would typically need to be enabled whenever non-free is enabled. As a consequence of option 4, non-free-firmware-build would need to be enabled whenever non-free is enabled. Binary Dependencies =================== It's possible that packages in non-free-firmware could depend on non-free libraries or downloader tools or whatever. In this case I think it's fairly clear those packages would need to move into non-free-firmware. The arguments about build-dependencies don't really apply. Yes, doing this may partially violate assumption 3 about limiting contents of non-free-firmware. However, if the dependency is accurate, then the libraries or downloader tools or whatever actually need to make their way onto the system with the firmware, and additional separation doesn't appear to provide value. I'm hoping that packages in non-free-firmware don't end up depending on contrib (except as part of building a package in non-free-firmware). If they do, that gets messy. Source Distributions ==================== We know that Debian gets used by a lot of downstreams both in terms of derivative distributions and also organizations that directly consume our media even if they customize it heavily. We know some of these organizations care a lot about software freedom like we do, and some of them make different trade offs between their users and free software. I hope we choose to support this diverse community as much as we can. Some people who use Debian are going to only consume Debian main just as they do today. However it seems likely that some people will join us in accepting the practical necessity of firmware while wanting to avoid other non-free software. So, for example, they might well want binary media with non-free-firmware and main. Yet anyone who cares that much about software freedom is likely to care about distributing complete source for a work including source for anything it depends on. Earlier we talked about how it would simplify how we think about build-depends if packages in non-free-firmware could build-depend on non-free. If we do that, then we are effectively linking the source components together. To get the source for all of the build-depends in non-free-firmware you are going to need to get the sources for non-free. That might be okay, but we should consider the impact on people who want to minimize the non-free software they are exposed to. There's a related question of what components a source package can build for. As I understand it, a source package in main can build both binary packages in main and contrib. Would we permit a source package in non-free to build binaries in non-free-firmware? (Or alternatively a source package in non-free-firmware to build binaries in non-free?) Allowing this would simplify situations where for example a manufacturer provides a package that includes both firmware needed for booting a device and a non-free management tool inappropriate for non-free-firmware. However it would complicate things for people wanting to minimize free software on their media. Back to What Goes in Non-free-firmware ====================================== I will admit that I find it fairly hard to define what is firmware and what isn't. I also find it challenging to really defend that boundary as the boundary we're willing to cross for practical reasons. Steve did a good job of summarizing how what it is to be firmware has gotten more complicated over the years. As a reminder, firmware does sometimes run on the CPU (microcode, UEFI), sometimes is software, sometimes is more like data. (And yes, I know that the way in which microcode runs on the CPU is different than UEFI). I'll admit that I find it easier to think about non-free stuff that allows people to use their hardware than strictly thinking of firmware. As examples to consider, do we want to include the following in our practical divergence from software freedom purity? * High quality proprietary voices that can improve accessibility for screen reader users * Data for input methods that makes input easier for non-English environments. (I don't know if this is an area where free alternatives have caught up) * Machine learning models for speech that would make it easier for people who cannot easily type to use Debian. * Proprietary Nvidia graphics drivers. Personally I think most if not all of the above are in the same category as firmware at least in terms of how I think about them and software freedom. I'd rather come up with some rules based on other categories than firmware vs not. Perhaps something like non-free-firmware is for packages that make it possible to use the system or its hardware where there is no free alternative providing comparable functionality. Whatever it is, I'd be very appreciative if we could take some time to come up with guidelines rather than firmware vs not. (And if it is going to come down to firmware vs not to articulate why that's a reasonable compromise for our users and free software).
signature.asc
Description: PGP signature
