Announcement

Collapse
No announcement yet.

Debian Begins A General Resolution To Decide What To Do With Non-Free Firmware

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by kevmif View Post
    as I understand it, firmware should be shipped on the device, not needed to be manually loaded at boot time.
    ...
    Important to push back on this or before we know it, open source distros will start shipping closed source drivers by default due to no other option to make the hardware 'work'.
    Firmware is one place where the free software movement has some very skewed priorities. Back when I was a Debian developer and all-out free software zealot I would rail against the evils of proprietary firmware along with the rest of them. Today, I lead an embedded software development team and I see things from the other side of the fence, and I've changed my mind quite a bit as a result.

    The crux of the philosophical conundrum is where do you choose to place the boundary between the parts of the system which run free software, and the parts which are just "peripheral components". You could argue that the free software part is basically just what runs on the CPU at one extreme, or you could require every last part in the system to only run free software at the other. However, the former is a solved problem while the latter is a completely unachieveable goal.

    Firstly, the devices which are running proprietary firmware are running completely independently from the CPU where Linux is running. These range from small discrete parts on your motherboard all the way to your storage devices and GPU, and can be FPGAs, CPLDs, CPUs and MCUs all the way through to small parts which have primitive sequencers running on them. A typical computer system will have dozens of them. The CPU running Linux will use a device driver of some sort to communicate with them, but that part is completely separate to the device itself.

    The assertion that the firmware should be "shipped on the device" would mean that the code would need putting into the actual masks as a ROM area, or it would need flashing on at manufacture to some persistent storage, possibly write-once. The former and write-once updating would preclude any possibility for future updating to fix problems or change behaviour without respinning the silicon or replacing the part, yet this inflexible and wasteful strategy is the preference of the FSF! The latter implies having the capability to store the firmware in a persistent manner, but not all hardware has that capability--some hardware requires the firmware loading on after powering it up, and it's lost once the power is removed, but it's flexible and better for the environment because it reduces waste.

    The other aspect is that these parts are not general-purpose computers​. Many of these parts use custom and very expensive tooling to produce the firmware image. Someday we might have good open-source FPGA synthesis, but today we do not. There's simply no way to take the VHDL and have it synthesise a comparable image to that made with the original tools. In theory, this might happen eventually, but it's not at all practical to consider it today. The other parts might each need a separate custom toolchain. GCC won't work for everything here. This is a completely different world to conventional CPUs, and it's a world in which free software is not the rule, it is the exception. I'll look forward to the day we have this, but that day is not today.

    Firmware is written to do very specific things, requiring intimate understanding of the problem domain and the part design. Unlike regular computers, these really are not amenable to casual tinkering by non-experts. In many cases these parts have undergone extensive validation and verification to comply with various standards, including safety standards. While they might contain firmware, the part itself is classed as hardware, and it's sold and used as such. Even if the part was fully open to modification, few people would have the capability or the resources to reproduce that effort. Possibly in theory someone might do that, but at what cost, and for what benefit?

    Personally, I'd look at these parts as you look at any other electronic component: it's a black box with defined inputs and defined outputs, and you read the datasheet to understand how it all works and how to control it. What's happening inside the box is largely uninteresting from the point of view of using it. When you design your circuit you'll select an appropriate part for the job that meets the requirements and the BOM budget. Whether a part uses open-source firmware or not is not on the radar of most of the electrical engineers, and why should it be? It's a non-issue which was created by free-software fanatics who haven't really examined the problem in full detail. Their issue is a political one of their own making, and that has absolutely no bearing on manufacturing a working product that complies with the necessary regulatory and safety rules.

    Looking at the options on the GR, it looks like most of them are actually acknowledging this reality to varying degrees, even if they don't say that directly.

    Comment


    • #32
      Do they have a distribution license for non-free firmware or not?

      If they do, they could just include the firmware on the media and note during install that the piece of hardware in question won't function fully without it, and then offer the choice. This means less installation media, and it gives the user the freedom to choose, not impose choices or ideals on them. This at least allows the user to fully utilize their hardware that they chose to install Debian on.

      The biggest issue that users trying to use Linux will face is whether their hardware is supported or not, and many don't know anything about how the GPL affects hardware support. Linux DE's don't have something akin to Windows' Device Manager. It may seem trivial, but it simplifies hardware enumeration vastly over trying to weed through lines of text from lspci, lsusb, dmesg, etc. I've used Linux on and off for a number of years, and this is one thing that bugs me about Linux DE's so much - having to find and troubleshoot hardware incompatibilities. Users often assume that this other operating system should be about as compatible as Windows. And if they do separate the two installation ISO's, do you really think Debian is going to want to put up a big long-winded list on the main download page of all the hardware not supported by the fully-free download?? I'd bet not.

      Even Torvalds says that ideals shouldn't get in the way of usability. If you make something hard for the user, you're not doing it right. Of course, he's not too keen on Debian either.

      Comment


      • #33
        Originally posted by Waethorn View Post
        many don't know anything about how the GPL affects hardware support
        Count me as one of them. What on earth would the GPL have to do with anything related to hardware support? It's a distribution licence for specific software packages under that licence, and is entirely unrelated to the distribution of firmware of any description under any licence. Aggregation of free and non-free software on the same distribution medium is perfectly permissible. So where exactly would the GPL come into this?

        Comment


        • #34
          Originally posted by rleigh View Post

          Count me as one of them. What on earth would the GPL have to do with anything related to hardware support? It's a distribution licence for specific software packages under that licence, and is entirely unrelated to the distribution of firmware of any description under any licence. Aggregation of free and non-free software on the same distribution medium is perfectly permissible. So where exactly would the GPL come into this?
          Many distros package their media under the same license. When they do this, it dictates whether xyz hardware is supported because the media won't ship with non-GPL drivers or firmware.

          Comment


          • #35
            Originally posted by Waethorn View Post
            Many distros package their media under the same license. When they do this, it dictates whether xyz hardware is supported because the media won't ship with non-GPL drivers or firmware.
            No, they don't. Show me an example where a distribution has media distributed "under the same licence", where you believe this to be the case, please.

            The licence of the individual packages comprising a Linux distribution have no bearing on the licensing of other packages within the distribution. The distributor has zero rights to relicence any of the software under different terms than provided by the original copyright holders. The distribution medium isn't licenced under the terms of the GPL, but some of the constituent packages may be. The other packages remain under their original licences, be that BSD, MIT, CDDL, proprietary or whatever. There isn't a Linux distribution in existence which is solely GPL code.

            The choice to not provide non-GPL drivers or firmware isn't due to licensing, since both are entirely permissible, it's due to the choice of the distributor to create and enforce that limitation.

            Comment


            • #36
              Originally posted by rleigh View Post

              No, they don't. Show me an example where a distribution has media distributed "under the same licence", where you believe this to be the case, please.

              The licence of the individual packages comprising a Linux distribution have no bearing on the licensing of other packages within the distribution. The distributor has zero rights to relicence any of the software under different terms than provided by the original copyright holders. The distribution medium isn't licenced under the terms of the GPL, but some of the constituent packages may be. The other packages remain under their original licences, be that BSD, MIT, CDDL, proprietary or whatever. There isn't a Linux distribution in existence which is solely GPL code.

              The choice to not provide non-GPL drivers or firmware isn't due to licensing, since both are entirely permissible, it's due to the choice of the distributor to create and enforce that limitation.
              Well if you want to be facetious, show me just one BSD-licensed external module for hardware support that is shipped on Debian's official media.

              Comment


              • #37
                Originally posted by Waethorn View Post

                Well if you want to be facetious, show me just one BSD-licensed external module for hardware support that is shipped on Debian's official media.
                Err, that would be entirely unrelated to the point in question. What might be shipped is entirely different to what could be shipped. Please actually address the question I asked.

                You asserted: "Many distros package their media under the same license", so presumably you already have some examples where this is the case. Show me one example where this is true.
                Last edited by rleigh; 28 August 2022, 06:59 AM.

                Comment


                • #38
                  Originally posted by rleigh View Post

                  Err, that would be entirely unrelated to the point in question. What might be shipped is entirely different to what could be shipped. Please actually address the question I asked.

                  You asserted: "Many distros package their media under the same license", so presumably you already have some examples where this is the case. Show me one example where this is true.
                  Honestly I don't really care. Debian ships with a Linux kernel that excludes non-free firmware and closed-source modules. The kernel is licensed under the GPL. Therefore, the GPL does indeed have an effect on your hardware support with their media. Any other software packages that may or may not be GPL under a distribution agreement for any distro has no bearing on hardware support. They note that their non-free, unofficial ISO's do not comply with GPL software freedoms because of hardware support that requires non-free firmware and modules.

                  Comment


                  • #39
                    Originally posted by Waethorn View Post
                    Honestly I don't really care.
                    You cared enough to post your reply, but not enough to actually understand how software licensing works. Honestly, the quality of the discourse on Phoronix is so low, there's a reason I rarely participate.

                    Originally posted by Waethorn View Post
                    Debian ships with a Linux kernel that excludes non-free firmware and closed-source modules. The kernel is licensed under the GPL. Therefore, the GPL does indeed have an effect on your hardware support with their media.
                    The thinking here is rather muddled. The licensing of the kernel under the GPL is not in any way related to the contents and licensing of the installation media as a whole. The GPL licence is a distribution licence for individual software packages. It has no bearing on collections of software. The licence itself makes that point clear, calling it "mere aggregation".

                    The GPL does not have any effect on the "hardware support with their media" as you said it. That's not the GPL. It's not a licensing issue. That's a deliberate choice by the distributor to implement that restriction. The GPL can not preclude the distribution of third-party non-GPL kernel modules on the installation media. That is completely outside its bounds, and explicitly stated in the licence. That's a distributor choice. Plenty of other distributions make the opposite choice, and it's still all perfectly legal.

                    Originally posted by Waethorn View Post
                    Any other software packages that may or may not be GPL under a distribution agreement for any distro has no bearing on hardware support.
                    This is on its face a completely false statement. Of course other packages can provide hardware support. They can and they do. What are you even trying to say here?

                    Originally posted by Waethorn View Post
                    They note that their non-free, unofficial ISO's do not comply with GPL software freedoms because of hardware support that requires non-free firmware and modules.
                    I think you've misquoted this. It might not be compliant with "software freedoms" but it's absolutely compliant with the GPL. Providing non-free firmware is not affecting any of the GPL-licensed packages within the system, so "complying with the GPL" is not actually true or false--it's completely beside the point. It might not be free software, and it might not be GPL-licensed, but "not complying with the GPL" is a completely false assertion. Who exactly is determining whether it's "compliant" or not? It's the official opinion of Debian, as it doesn't comply with the Debian Free Software Guidelines. But that's not the same thing as the GPL. And there is a school of thought that firmware shouldn't fall under the DFSG because it isn't running on any of the CPUs which Linux runs on. That's part of what this vote is all about.

                    I was a Debian developer for over a decade, and looked in detail at licensing issues. I voted on previous GRs about non-free firmware--you can even go and look up how I voted at the time. I would like to see the points you're trying to make, but you're confusing several different concepts and it's coming across as incoherent.

                    Comment


                    • #40
                      I always install all non-free firmware. Running 100% free and open source system is imposible without open hardware. There is always non-free firmware on closed hardware, it is just not up to date, if you don't install it.
                      Last edited by LightBit; 28 August 2022, 11:07 AM.

                      Comment

                      Working...
                      X