Moin
On Tue, May 10, 2022 at 02:30:04PM -0600, Sam Hartman wrote:
> Build Dependencies
> ==================
>
> As a consequence of options 2-4, non-free-firmware would typically need
> to be enabled whenever non-free is enabled.
I don't understand why this is the case? Option 2 just needs non-free
for building non-free-firmware, not always.
Do we have that case that firmware needs non-free tools to build? Do we
now have just non-free or also no-source tools to build a firmware, just
to avoid shipping the binary of the firmware directly? It is not likely
that we could in any way modify such a firmware without access to many
other tools and documentation.
> Binary Dependencies
> ===================
>
> It's possible that packages in non-free-firmware could depend on
> non-free libraries or downloader tools or whatever.
Downloaders can go to contrib already, so we would not need
non-free-firmware for that.
Bundling firmware and libraries is done only in one case as far as I
know: nvidia.
> Source Distributions
> ====================
>
> 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.
I usualy would say: they are free to rebuild the media without the
firmware on it.
> As I understand it, a source package in main can build both binary
> packages in main and contrib.
It is technically possible, but AFAIK discouraged, as it breaks several
assumptions dak and the release team tooling does.
> 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).
Sure, UEFI is a firmware. But in the past we always talked about the
firmware stuff that does _not_ run on the main CPU, but on the CPU
integrated into other hardware pieces. The same for microcode, it is
not stuff running on the main CPU.
> * 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.
I see what you mean. But nothing of that actually enables the use of a
particular hardware.
> * Proprietary Nvidia graphics drivers.
This is explicitly code built and run on the main CPU, not firmware. It
also needs firmware running on the device itself.
> 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.
Actually they are not in the same category.
> 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.
But then we can't call it firmware. And this definition does not longer
fit firmware. Hardware and firmware are a unit, you need both to use
it. So it is not "no free alternative", but "integral but separate
shipped part of the hardware".
Regards,
Bastian
--
One does not thank logic.
-- Sarek, "Journey to Babel", stardate 3842.4
