On Mon, 30 Dec 2019 at 15:24, Ian Darwin <i...@darwinsys.com> wrote: > > On 12/30/19 15:02, Peter Nicolai Mathias Hansteen wrote: > > The TL;DR version is that taking code or any other body of work that is > > offered to you under a permissive license and making your changes to it > > available only under a more restrictive one may be legal in some or all > > jurisdictions, but it is most certainly a sign of an almost total lack of > > respect for the people who did the original work. > > Not to mention: putting code under a more restrictive license than > previously, while calling it "more free", is hypocrisy, pure and simple. > Nothing gnu here, folks.
Has anything ever came out of these Linux-libre projects that fork purely for GPL reasons? I thought they usually work simply by removing the things out without having the expertise to ever write any suitable replacements; e.g., they'll probably first remove fw_update(1) to break your wireless, then after a few years, they'll find a little bit of freely redistributable microcode in various Ethernet drivers of OpenBSD, and will break those drivers as well, without ever providing any replacements, either, of course. Theo has previously addressed this whole question of freely-redistributable proprietary microcode/firmware in OpenBSD, urging the (GNU) people to stop loading the OpenBSD devs with more tasks: * http://web.archive.org/web/20060603230017/http://kerneltrap.org/node/6550 * http://archive.is/CARbI #### : Jeremy Andrews: Each OpenBSD release includes a theme song that goes along with the release's artwork. OpenBSD 3.9's theme song is titled "Blob!". Can you explain what binary blobs are and why they're a problem? : : Theo de Raadt: Vendors often try to hand off two kinds of binary code to us, which they expect we will happily incorporate into our system (and then, hopefully, we will shut up). : : The first kind to mention is firmwares. Firmwares (like for instance on a Intel wireless card, or a such) are binary pieces of code that will run on the little processor that is on the wireless card. As an operating system, we need to load the code out to the card. To include a firmware in OpenBSD, we simply need a nice copyright statement from the vendor that lets us distribute the firmware. Some vendors won't even go that far, though. : : The second kind of binary data vendors feed us are blobs. This is code that is expected to be linked against the operating system and run on the host processor. There are many problems with this. First off, can we trust the code to do what it should do? I don't think so. If there is a bug, can we fix it? No, as developers our hands are tied, and if our user community runs into bugs it just makes us look bad. Therefore when faced with the choice of supporting a device very poorly (as the blob would force us to) we instead choose to wait until we (or someone else) can reverse engineer it or. : : Jeremy Andrews: What is it about binary firmware that you're willing to ship it, versus binary blobs? How can you trust the firmware binary to do what it should do? And what if the firmware has a bug? : : Theo de Raadt: Quite honestly I prefer chips which have no firmware, and instead use correctly designed hardware logic, which our driver must then drive. Note that most ethernet chipsets do not use a processor, but many scsi chipsets do. Most IDE chipsets do not, but for wireless devices ... it is about half and half. This clearly has to do with the complexity of the data flow problem being dealt with. : : But in the end, if we wish to support any such devices, we must be practical. We must accept the risk that there is a flaw in the firmware. (Is that not what many of us have been coping with for years now with Prism wireless chipsets and their firmware update tools?) But the legal climate is a real problem for us -- that is why we must get copyright permission to distribute the firmware images. Once they are distributed... at least the device works. : : Of course, also note that we don't want to become Hermes (the architecture of the Lucent/Prism/Symbol chip) assembly language programmers... we have more than enough to do. Just a specific example. Please, people, don't load us up with more tasks ;) : : Jeremy Andrews: Blobs seem especially common with wireless ethernet cards and graphics cards, why is that? : : Theo de Raadt: Graphics cards have gotten to this point because of their complexity. But these blobs also cope with lots of bugs in the devices. These bugs are because graphics cards are devloped very quickly now, and the hope is that software would work around the hardware bugs. : : I don't know why any wireless cards use blobs. In fact, very few do. They should just document their chips. There's a lot of hogwash flying around about FCC rules, but if that was a concern of theirs they should just design their chips to lock the channels in hardware. But of course, noone in Taiwan does. So did the US vendors just tie the own hands? Certainly, we don't feel like we are constricted. The minute we are able to support another wireless device, we immediately ship the driver. #### Of course, GNU turns the whole rational part about the OpenBSD policy upside down: http://www.gnu.org/distros/common-distros.html#BSD #### : BSD systems : : FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining nonfree programs in their ports system. In addition, their kernels include nonfree firmware blobs. : : Nonfree firmware programs used with Linux, the kernel, are called “blobs”, and that's how we use the term. In BSD parlance, the term “blob” means something else: a nonfree driver. OpenBSD and perhaps other BSD distributions (called “projects” by BSD developers) have the policy of not including those. That is the right policy, as regards drivers; but when the developers say these distributions “contain no blobs”, it causes a misunderstanding. They are not talking about firmware blobs. : : None of those BSD distributions has policies against proprietary binary-only firmware that might be loaded even by free drivers. #### Anyhow, we'll see what the future brings! However, if you want no closed-source third-party binaries linked against your OS and running on your host processor, without the arbitrary GNU firmware requirements breaking every device driver imaginable, the upstream OpenBSD distribution would probably still be your best bet. Cheers, Constantine.SU.
