| |||||||||||||
FSFLA: Linux kernel is "open core"FSFLA: Linux kernel is "open core"Posted Nov 8, 2010 18:26 UTC (Mon) by lxoliva (subscriber, #40702)In reply to: FSFLA: Linux kernel is "open core" by cesarb Parent article: FSFLA: Linux kernel is "open core"
Whether or not a replacement exists is orthogonal to whether the code in question is Free or not, right?
The presented argument is a false dilemma. The short-term options are indeed blob or brick, but the long term options are blob, brick or freedom. Clever use of your freedom (and power) of choice will bring us all freedom, because hardware suppliers ultimately want to sell their stuff. Unwise choices will lead to progressive erosion of freedom, with more blobs controlling more parts of our computers.
As to whether non-Free code on flash memory is ok, I wonder where you got that idea from the announcement. If it's there at all, it was my mistake, and I'd very much like to correct it.
(Log in to post comments)
FSFLA: Linux kernel is "open core" Posted Nov 8, 2010 19:30 UTC (Mon) by cesarb (subscriber, #6266) [Link]
> As to whether non-Free code on flash memory is ok, I wonder where you got that idea from the announcement.
I did not see it on this announcement, but I recall seeing it on other related discussions (that somehow it was better for wireless cards to have flash memory with their firmware instead of saving some cents and pushing the firmware storage into the driver). I think it is better that the code is free no matter where it is stored; it being distributed within the hardware itself, on a CD on the hardware's box, on the firmware tree, or on the main kernel tree, should not make a difference. I would prefer to avoid the main kernel tree only to avoid a very small possibility of confusion (the kernel being GPLv2 except for one small directory can be confusing, since most people would expect it all to be GPLv2; the separate firmware tree makes things more obvious).
> Clever use of your freedom (and power) of choice will bring us all freedom, because hardware suppliers ultimately want to sell their stuff.
Yes, but there is also the other side: users want to use the stuff they bought. If you do not have many users, your ability to put pressure on the manufacturers is much weakened. What you need is to put pressure on the manufacturers without driving away the users. I believe the way it currently works with drivers goes in that direction; if your driver is not on the upstream kernel it is a second-class citzen, subject to breaking every single kernel release, and to get into the upstream kernel it has to be GPLv2 or compatible. What we need is something like that but for firmware (which is completely separate from the drivers, since it even runs on a separate chip, so the "it is a part of the kernel thus it must be GPLv2" argument does not work).
FSFLA: Linux kernel is "open core" Posted Nov 8, 2010 20:34 UTC (Mon) by lxoliva (subscriber, #40702) [Link]
I'd go further than pushing blobs out of the tree: drivers that require non-Free firmware should be kept out, so as to put pressure on the hardware suppliers to respect users' freedom.
Of course, none of this would prevent distros from going the Free Bait way, or users who already took the hardware bait from building and using the drivers themselves, possibly with help from other victims.
FSFLA: Linux kernel is "open core" Posted Nov 8, 2010 20:35 UTC (Mon) by foom (subscriber, #14868) [Link]
> As to whether non-Free code on flash memory is ok, I wonder where you got that idea from the announcement. If it's there at all, it was my mistake, and I'd very much like to correct it.
It's implicit in how the FSF is not campaigning against non-free firmware on flash memory shipped with devices, but they are against non-free firmware that users have to upload themselves every time the device is booted.
The practical effect of making it difficult to use uploadable non-free firmware with linux is that users may instead purchase hardware which has the non-free firmware stored in flash memory on the device.
This should be considered exactly as bad in terms of user freedom, except for two things:
It's a total lose.
FSFLA: Linux kernel is "open core" Posted Nov 8, 2010 20:57 UTC (Mon) by lxoliva (subscriber, #40702) [Link]
It looks like you are mistaking FSFLA for a subsidiary of the FSF or some such, but it's an independent organization.
That said, there is *some* overlap in the shared opinions of all members of the FSF network, and there's also some difference between the opinions held by organizations and individuals. For clarity, what follows is my personal opinion.
Hardware circuits can't be modified by the users, but they don't generally present the ethical issue of creating artificial barriers for users to exercise this freedom, that non-Free Software on programmable computers generally does.
Programmable computers hidden inside hardware devices carry this ethical problem, but then a question that arises is, whose freedom is on the line. Say, if a hardware designer chooses between a hardware circuit and programmable non-volatile memory, the presented interface to the user is exactly the same, so one could argue it's within the hardware designer's freedom, in much the same way that say a service provider can decide what tools to use to perform a job s/he was hired to perform.
Now, the moment the service provider tells the user I need you to provide me with $whatever so that I can do the job, the user-visible interface changed, and now the user takes an active role in the process. When it comes to user-uploadable blobs, tt becomes perfectly clear that there is a programmable computer in there, and the only reason the user can't control it is because of the unethical imposition by the hardware designer, who's shifting costs to third-party distributors.
That's why I perceive the latter as a more serious offence, but I don't entirely dismiss the issue of hardware with non-volatile memory, or even hardware circuits. Denying access to specs that would enable users to copy and adapt the hardware (it's getting closer to possible), know in detail what it does or doesn't, verify that it is so, and adapt it so it does what you wish, are not quite the issues that the Free *Software* movement deals with, but there are similar ethical issues in there, and they are getting more relevant as they approach the realm of the possible.
So, even though uploadable non-Free firmware is a present problem, I keep the hardware-related freedoms on sight, for I consider them worth fighting for.
FSFLA: Linux kernel is "open core" Posted Nov 9, 2010 14:31 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
"Whether or not a replacement exists is orthogonal to whether the code in question is Free or not, right?"
Our device requires a binary blob to operate. However, it's not code, but rather large data tables compiled using a proprietary tools from VHDL hardware description.
What would you achieve by getting the source? Exactly nothing. You can't modify VHDL since you probably lack a fab to manufacture the resulting schematics. You can't even recompile it, because it requires a proprietary tools (working only on Windows, alas).
So firmware blobs should often be thought as a part of hardware rather than software.
FSFLA: Linux kernel is "open core" Posted Nov 9, 2010 18:30 UTC (Tue) by jebba (✭ supporter ✭, #4439) [Link]
> Our device requires a binary blob to operate. However, it's not code, but rather large data tables compiled using a proprietary tools from VHDL hardware description.
I may be mistaken, but I think in those cases, the blobs are left in linux-libre. If I knew which driver in particular you were talking about, I could look it up.
FSFLA: Linux kernel is "open core" Posted Nov 9, 2010 19:22 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
how can you tell the difference between a binary blob that is a large data table and a blob that is code that will be run on an embedded cpu?
FSFLA: Linux kernel is "open core" Posted Nov 9, 2010 19:47 UTC (Tue) by jebba (✭ supporter ✭, #4439) [Link]
> how can you tell the difference between a binary blob that is a large data table and a blob that is code that will be run on an embedded cpu?
Personally, I can't; I defer to lxoliva on that. He has a script that he runs against the kernel that has an accept whitelist for code that looks like a non-free blob, but is ok. See:
http://www.fsfla.org/svnwiki/selibre/linux-libre/download...
An example would be something like this: drivers/input/keyboard/atkbd.c which has a blobby looking table, but is ok.
FSFLA: Linux kernel is "open core" Posted Nov 10, 2010 2:26 UTC (Wed) by lxoliva (subscriber, #40702) [Link]
In the general case, that's not possible. The procedure I use starts with a sniff test, looking for regularity in the sequences of numbers or trying to make sense of them from their given names, numbers and the way they're used. If I can't determine it's just data, or find strong indication that it's code, I try to get ahold of the driver maintainer or the hardware designer. Ultimately, I have to go by whatever info I get and a sense of trust for whoever provides it and, in the worst case, make a conservative assumption that it may be software (instructions to configure a general-purpose computer to behave in a certain way) or a mix of software and pure data, and go with that.
FSFLA: Linux kernel is "open core" Posted Nov 10, 2010 2:33 UTC (Wed) by lxoliva (subscriber, #40702) [Link]
In the general case, that's not possible. The procedure I use starts with a sniff test, looking for regularity in the sequences of numbers or trying to make sense of them from their given names, numbers and the way they're used. If I can't determine it's just data, or find strong indication that it's code, I try to get ahold of the driver maintainer or the hardware designer. Ultimately, I have to go by whatever info I get and a sense of trust for whoever provides it and, in the worst case, make a conservative assumption that it may be software (instructions to configure a general-purpose computer to behave in a certain way) or a mix of software and pure data, and go with that.
|
|||||||||||||