FSFLA: Linux kernel is "open core" [LWN.net]

FSFLA: Linux kernel is "open core"

Posted Nov 14, 2010 23:19 UTC (Sun) by dwmw2 (subscriber, #2063)
In reply to: FSFLA: Linux kernel is "open core" by lxoliva
Parent article: FSFLA: Linux kernel is "open core"

"I believe computers should obey their users. This userspace program you suggest could do nothing but accept or reject software that users have installed on their computers. IMHO, that doesn't make sense. If users chose to install certain software on their computers, the computers had better obey when users command run it or install it. Anything else is, erhm, defective by design, if you get what I mean."

And yet you're still peddling an implementation which is broken by design in precisely this way.

If I run your linux-libre kernel but I do still need my wireless to work using the firmware which was present in my laptop when it arrived, your current implementation does "protect me from myself", because it won't load that firmware even when I deliberately extract it from the OSX driver and place it in /lib/firmware in my Linux system. That used to work, and you have broken it even for the user who has made an informed choice.

"Even if the userland program could indeed clean up the log messages from a local machine, it can't go back in time and prevent the kernel from having issued the request, so it can't do what I want."

I do understand what you want; I just think it's fundamentally misguided. What you now claim you want is pointless, and no longer directly related to the originally stated goals.

Your argument that a call from kernel to udev is inducement is just nonsense. I don't know why you're fixating on it, but there seems to be no valid technical reason. You might just as well argue that the call from the driver into the core kernel is similarly inducing the user to use the specified firmware (if, of course, said firmware happens to be only available in a non-free form today). And thus even your version would be inducing the user to use non-Free software.

You have chosen to draw the technical line in a completely arbitrary place, and you now seems to be making up arguments to support your implementation instead of trying to come up with an implementation which makes more technical sense. That's your prerogative, but don't pretend it's because we don't understand what you want.

To me, this argument is not about the ethical issue; the fact here is that you have made a technically poor decision and you're trying to back it up with transparently empty rhetoric instead of discarding your precious implementation and doing something more sensible.

"All of this because you seem *DETERMINED* to do it at a place other than the one that has all the relevant information."

This is also completely incorrect. The kernel does not have all the relevant information. It is only userspace which can know the current licence status of the firmware which is available for download from the various package repositories, not the kernel.

In the kernel we can only have an out-of-date idea of the last known status; we can't know if there has been a free reimplementation in the last few days. And as you say, the kernel developers aren't always completely on the ball when it comes to licence status. The distributions are far better at labelling things correctly.

Only by leaving the kernel unbroken and handling the full request in userspace can we actually achieve what you said was your technical goal. Anything else is disingenuous.

And if you do plan to rely on the out-of-date knowledge of the author of the kernel driver, then it is doubly disingenuous to do so in the case of devices which load their firmware through the OS, but not in the case of devices which load their firmware from built-in storage. There is no excuse for breaking one but not the other, if you're claiming that the most up-to-date licensing information is from the kernel authors.

So unless your next version of the linux-libre patch also removes support for hard drives on the basis that there are no known devices with fully free firmware, I call you a fraud.

¹ I note with interest that you don't include the option of looking for, or even implementing, a free version of the firmware for the device in question. That's what we should be encouraging, but you seem to have entirely missed what I and many others think should be the point. You are being destructive, not constructive.

(Log in to post comments)

FSFLA: Linux kernel is "open core"

Posted Nov 15, 2010 2:46 UTC (Mon) by lxoliva (guest, #40702) [Link]

> And yet you're still peddling an implementation which is broken by design in precisely this way.

Not quite. You said you had to build your own kernel for it to work, but you could have just built a driver. Which, I agree, is still undesirable, which is why we've been discussing other possibilities to make it even easier. Oddly, *none* of the freedom-caring users seems to have voiced any support for the proposal, which to me sounds like they don't need that anyway.

> I do understand what you want

Then why do you keep on insisting I want something else, and that I implement it in a way that will not just fail to solve the problem I want to solve, but that will also just not work at all on Free distros?

> You might just as well argue that the call from the driver into the core kernel is similarly inducing the user to use the specified firmware

If the driver was distributed separately, I'd make this very call. Since itś part fo the same component, and that one component will take care of buffering the inducement from the user, I think that's acceptable.

> Only by leaving the kernel unbroken and handling the full request in userspace can we actually achieve what you said was your technical goal

Sorry, can you please remind me what my technical goal was? From what you say, I get the impression that I forgot it, but in fact I think I remember it, and it was to avoid requesting non-Free Software. I still don't see how userland could go back in time and stop the kernel from issuing the request it already did and got userland to decide it shouldn't have happened. And clear the logs that were already transmitted to a separate machine that recorded them in append-only media.

I agree the kernel driver may have an out-of-date notion, which is why userland should get a chance to tell users about what's going on, just not in a way that sounds like give me blobname.bin or else. And then, as I wrote (but you seem to have chosen to ignore it), how could userland possibly know better than the kernel driver when the driver asks for a firmware that userland (including repositories) know nothing about? How could userland know better and give decent advice, when the distro chooses to leave out the non-Free blobs?

Your solution appears to be once again geared towards making more blobs more easily forced into distros and users, rather than helping solve the social problem at hand, that requires users to realize the blobs are a problem.

FSFLA: Linux kernel is "open core"

Posted Nov 15, 2010 13:10 UTC (Mon) by foom (subscriber, #14868) [Link]

lxoliva clearly believes that the kernel asking udev for a firmware filename is equivalent to inducing the user to use non-free software, while dwmw2 (and I, for that matter) think that's crazy. It seems pretty useless to continue this discussion further, since it's just going around in circles now.

And I really hope that simply posting a filename is never ever counted as "inducement to infringe" in a *legal* sense: that'd be a huge pain in the ass...

FSFLA: Linux kernel is "open core"

Posted Nov 15, 2010 20:11 UTC (Mon) by lxoliva (guest, #40702) [Link]

I have little hope of convincing dwmw2. I just want the records to show that we're trying to solve different problems, and that whatever solution he seems to think and impose on me won't solve the problem I'm trying to solve. A number of people got out of the previous round of discussions about Linux and Linux-libre with the mistaken impression that his proposed solution then would do anything to advance Linux-libre's goals, in spite of my attempts to show it didn't. I'd like to avoid a recurrence of this error.

Now, I don't want to turn this into a debate on legal issues, but I'd like to point out that Red Hat legal advises the Fedora project to refrain from as much as mentioning Free Software projects that apparently read on certain patents. That would be considered a material legal risk, with liability arising out of contributory infringement claims IIUC.

Now, baiting users towards non-Free Software, or even providing them with the poison, doesn't break any laws (except for those pieces of firmware for which no license can be found, that is ;-). It's an ethical and social issue. It's just good to see clearly where one's priorities are. I wish ethical hazards would get at least as much attention as legal ones.

FSFLA: Linux kernel is "open core"

Posted Nov 18, 2010 14:10 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

I can think of at least one approach to this matter which is both technically correct and avoids the behaviour you regard as unethical "baiting". Don't break the drivers that depend on being able to receive non-Free firmware from the userland firmware daemon; remove them.

FSFLA: Linux kernel is "open core"

Posted Nov 18, 2010 15:48 UTC (Thu) by lxoliva (guest, #40702) [Link]

This was the approach taken by gNewSense in its first release. Their cleaned-up kernel eventually became Linux-libre and the approach evolved in response to problems and changes in Linux.

One major problem was that some drivers would work just fine, or in a degraded way, without the blobs. Some were patched, but others were removed taking out useful functionality (video capture and graphics come to mind).

The changes in Linux were the widespread adoption of request_firmware(). We had already developed technology to selectively remove parts of drivers that contained blobs, and since moving firmware about didn't make any difference as to the ethics of providing or using them, we figured we'd be better off retaining the same functionality that we had when the blobs were part of the drivers. This implied disabling the blob requests.

However, instead of simply logging an error, like we did before, we figured we could use the hotplug interface to notify userland about the lack of Free firmware for that driver, so that's what we did. It's arguably better than silent (or quieter) failure to work, and it doesn't stop anyone who wants to use the blob from installing a driver that will take it.

That's where we are now, with a couple of plans to enable users to use blobs without having to install alternate drivers.