Where is the trap in a graphics or network card that requires proprietary code loaded via the driver? I can replace it with another graphics or network card. There isn't the same 'lock-in' that exists with some software applications. And to the extent that there is dependence on a vendor-specific feature, this is an attribute of the hardware, not Linux.
Posted Nov 9, 2010 19:11 UTC (Tue) by lxoliva (subscriber, #40702)
[Link]
Network controllers are increasingly tied to the motherboard chipset, and value and compact mobos have few expansion points. For graphics, the prospect is even worse: AMD increasingly tying their CPUs to ATI GPUs, Intel exploring similar paths, and nVidia getting their own x86 CPU designs to be able to do the same. How long you think you'll still be able to "just" replace these cards?
FSFLA: Linux kernel is "open core"
Posted Nov 10, 2010 9:50 UTC (Wed) by mpr22 (subscriber, #60784)
[Link]
How long you think you'll still be able to "just" replace these cards?
For as long as you need a separate graphics card to play flashy proprietary 3D games at 1920x1080 high detail 60Hz. On-board CPUs tend to suck at that, because they're almost invariably sharing the host RAM with the CPU.
FSFLA: Linux kernel is "open core"
Posted Nov 10, 2010 20:50 UTC (Wed) by cmccabe (guest, #60281)
[Link]
First of all, I notice that you didn't reply to my central point: that all the FSF's projects are "FSFLA open core".
> Network controllers are increasingly tied to the motherboard chipset, and
> value and compact mobos have few expansion points. For graphics, the
> prospect is even worse: AMD increasingly tying their CPUs to ATI GPUs,
> Intel exploring similar paths, and nVidia getting their own x86 CPU
> designs to be able to do the same. How long you think you'll still be able
> to "just" replace these cards?
From the perspective of freedom, Intel's drivers are a lot better than NVidia's. Some companies are indifferent towards open source drivers, but NVidia is actively hostile. Their driver contains a binary blob that's loaded into kernel space and interacts with X.org and other subsystems in very unwholesome ways.
Running closed-source firmware inside a sealed device is just not a big deal. Yes, we would all prefer if the firmware was open source, but that's not likely to happen in the near future. The important thing for freedom is the interfaces presented to developers and users. Proprietary user interfaces and APIs limit users' freedom by encouraging them to depend on non-free code.
The FSF's position on firmware is inconsistent. At various times, I have seen comments to the effect that if the firmware was implemented in hardware, or if it were burned into the chip and unchangeable, it would be ok. However, let's be generous and assume that the FSF just wants the code, all the code, all the time. Ok, fine. Even if they gave you all the code, you would need the circuit specifications in order to make any use of it. And even the circuit specifications are unusable without a chip fabrication facility. And that is unusable without...
And so we encounter an infinite regression that finally ends up with the perverse conclusion that nothing is truly free software. This is pure silliness. In practice, not having circuit schematics or firmware source code has not prevented great open source drivers from being written, and these drivers do promote the open source cause.
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 4:29 UTC (Thu) by lxoliva (subscriber, #40702)
[Link]
> you didn't reply to my central point: that all the FSF's projects are "FSFLA open core"
I did. Upthread I wrote It's offering the combination that makes the *combination* fit Free Bait/Open Core.
As for promoting the open source cause, I don't dispute that a number of undesirable behaviors do. But that's not the cause I'm interested in. My cause is that of the Free Software movement, a cause concerned with the lack of ethics in denying users control over their computing, and the freedom to help their neighbors.
It is probably true that in your infinite regression, founded on open source ideas, you'd conclude that nothing is truly open source, because you don't seem to be taking the ethics into account.
Only when you do will you realize that, from an standpoint that takes both practical and ethical concerns into account, e.g. being denied access to source code of ROM or a hardware circuit doesn't make it any more difficult for you to adapt the device so that it does what you wish than if you had source code.
Once you see that difference, you might realize that software freedom may indeed exist, even when a piece of hardware is, well, hard-coded and opaque.
That's not to say that its being hard-coded and opaque is desirable, but it's outside the scope of Free *Software*, and, until duplicating hardware is as easy as duplicating software, it will be a lesser issue, in practical and ethical terms. IMHO ;-)
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 17:48 UTC (Thu) by vonbrand (subscriber, #4458)
[Link]
If just using a device with firmware in ROM is what you are after, surely having to place said firmware into the device's RAM doesn't detract one bit of your use of the device. It really does make you freer, as you have the option of placing other firmware on the device (which you haven't if it is ROM).
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 3:30 UTC (Fri) by cmccabe (guest, #60281)
[Link]
> It is probably true that in your infinite regression, founded on open
> source ideas, you'd conclude that nothing is truly open source, because
> you don't seem to be taking the ethics into account.
My argument wasn't about the definition of "open source"; it was about the definition of "FSFLA open core," a very poorly thought-out concept.
You may argue that distributing the closed source binary blob makes the kernel FSFLA open core. But as I'm sure you're aware, not all firmwares are contained in the Linux kernel; some have to be cut out of the Windows driver or downloaded from the manufacturer's web site. It should be obvious to anyone that these are no more or less free than the others.
> Only when you do will you realize that, from an standpoint that takes both
> practical and ethical concerns into account, e.g. being denied access to
> source code of ROM or a hardware circuit doesn't make it any more
> difficult for you to adapt the device so that it does what you wish than
> if you had source code.
>
> Once you see that difference, you might realize that software freedom may
> indeed exist, even when a piece of hardware is, well, hard-coded and
> opaque.
How about a standpoint that takes logic into account? Allowing users the freedom to load new firmware on their devices gives them more freedom, by any reasonable non-Orwellian definition of the term, than disallowing firmware modification.
You should be embarrassed to promote the concept that locked-down devices, that can't be modified once they leave the factory, are better for the cause of open source than modifiable ones. You should be ashamed of attacking open source projects for doing what you also do-- allowing users to interoperate with non-free code and hardware. And you should realize that ridiculous announcements like this are destroying any credibility the FSF has left.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 5:07 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
> it was about the definition of "FSFLA open core," a very poorly thought-out concept.
Or rather poorly understood.
You seem to be dismissing that, in order for the combination of Free and non-Free Software to fit the Free Bait definition, the non-Free add-on must be offered by a distributor or contributor (community member in the announcement) of the Free core.
So, if we don't distribute the non-Free add-ons, we don't engage in Free Bait. If someone else who participates in Linux-libre did offer the combination, he'd be engaging in Free Baiting. A third party that offered only the add-ons would be just a regular non-Free Software distributor.
As for allowing users any freedom, I don't understand what that means. I'd understand *respecting* users' freedom, and we certainly don't fail to respect any such freedoms, because we don't prevent users from exercising the freedom. We don't set roadblocks, we just refrain from helping them get themselves trapped. If they install the non-Free software themselves, be it drivers or firmware, we won't stop them from running it (although, for current technical limitations, users might have to install a separate Free driver in order to use the corresponding non-Free firmware). That's not an attack on anyone's freedom, although some might resent the inconvenience.
As for embarrassment, you should be embarrassed of parroting this straw man one more time. After my stating several times that I don't hold that position and explaining why, you're just showing that you're not paying sufficient attention. If you want to take part in intelligent conversation, please pay some more attention.