Hmmm... my first reaction is "troll" purely because of addressing Linus personally and in such a fashion. It's turning a huge project into "this man did something naughty" and that's just childish.
Next I read the thing and think: So there's some code in the kernel, that's not GPLv2, but is clearly marked as such. It's in a separate folder, with a separate warning that says they have separate permission to distribute those things with the Linux source. It uses the kernel firmware loader so you have to place them manually in a certain place during installation in order to use them.
The only possible, practical use of those files in there is to run that particular piece of hardware. Granted, you can't take it, modify it, distribute it, etc. but it's pretty much locked to that hardware even if you could. And the restriction merely says that's all it should be used for in one or two particular instances. Thus it's of zero interest to most people, even the programmers. Without it the device is, presumably, a brick.
They are binary blobs but CLEARLY MARKED binary blobs, and can be replaced with any number of other binary blobs or properly licensed code should they exist (which, on the whole, don't exist). If the other choice is "this device MUST HAVE a binary blob to operate" and not distributing that blob, then I'd rather have a clearly marked binary blob. If I'm worried about GPL purity, I can not purchase that hardware. If I purchase that hardware, I can (in theory) write a firmware that replaces that binary blob for everybody. The nearest equivalent I can think of is Madwifi where that situation presented itself.
I quite agree that it would be better not to have drivers that are reliant on them. But if the choice is "a pretty brick", I'd rather have the capability of working hardware that can have alternate firmwares loaded at will and thus it's only a small project ("replace this firmware") rather than having to write an entire driver from scratch. It moves the boundaries to somewhere where, say, a MIPS embedded programmer can take the firmware, write his own and keep pushing it into the kernel on module load rather than having to recompile and write every line of a new "firmwareless" driver from scratch (which may not even be possible with most such hardware).
Nobody makes you use it. It has permission to be in the kernel. It can be replaced the second an alternative becomes available. People can use, test and compare the hardware running on different firmwares themselves when they become available and choose what they want. Programmers only have to replace that single file in order to test and create their own properly licensed driver. Pedants can just NOT copy that firmware to the firmware directories, the kernel won't crash. I find no problem with someone saying "Here's a kernel without it", but I imagine adoption to be incredibly low and that it won't help out-of-tree driver development at all. Anybody writing a driver for that device will want to compare their replacement firmware with that original one and the easiest way to do that is to use the in-kernel firmware loading and thus a bog-standard kernel.
I find the Madwifi issues to be the greatest precedent and it's not easy to argue that not having access to the proprietary firmware for users actually aids development or adoption of a replacement driver. If anything, it discourages a "half-done" open source driver because if it's a choice between a "half-done" driver and nothing, people will use a half-done driver. But if it's a choice between a "half-done" open source driver and a "fully-working" proprietary one, history (e.g. NVidia, MadWifi, etc.) shows that it's the existence of a fully-working driver that pushes development quality up (because otherwise people will just use the binary blob that does the job better).
I'm more inclined to say "If you want it, make it" for such obscure devices as those listed in the firmware directory anyway, moreso than "oh, that's terrible!".
Posted Nov 8, 2010 15:15 UTC (Mon) by NAR (subscriber, #1313)
[Link]
You should have read only the first 3 characters: FSF :-)
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 15:24 UTC (Mon) by lxoliva (subscriber, #40702)
[Link]
It looks like you're are arguing that non-Free Software is just fine when there isn't Free Software that performs an equivalent function, so it's ok that Linux and GNU+Linux distros are (increasingly) non-Free in this regard.
If that is indeed your opinion, I respect it, but I don't share it.
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 20:29 UTC (Mon) by cmccabe (guest, #60281)
[Link]
If you choose not to use non-free firmware, even when it means that many hardware devices are unusable for you, that's fine. I can understand why you would take this position. From what I understand, Richard Stallman practices what he preaches, and has a computer with no BIOS, no hardware that loads firmware, and no microcode running on the CPU.
What isn't fine is calling Linux "open core" just because it supports certain pieces of hardware that operate this way. "Open core" is a specific business model based on keeping part of the code proprietary and forcing users to pay you for its use. Simply interoperating with existing closed-source devices or code doesn't make something
"open core."
By using the term this way, the FSF is diluting its meaning. People who really do have open core business models will now point to their press release and say "look! The Linux kernel is open core too! So our business model is fine." As usual for the FSF: ready, fire, aim.
What also isn't fine is blasting people working on open source software because their computers have BIOSes, contain hardware devices that need microcode, and have modern CPUs.
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 21:30 UTC (Mon) by lxoliva (subscriber, #40702)
[Link]
Open Core Licensing, as originally defined and then clarified in the provided URLs, covers the practice of combining a Free core with non-Free add-ons that offer high-value, enterprisey features. In what way do you think Linux and GNU+Linux distros that include non-Free add-ons diverge from this licensing model?
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 1:17 UTC (Tue) by JoeBuck (subscriber, #2330)
[Link]
A couple of points:
In the case of the "Open Core" business model, the developer is giving away the free software for the purpose of getting people to buy proprietary add-ons. However, the Linux kernel developers are not profiting from the firmware blobs in any way.
And to the extent that a firmware blob loads itself into a separate processor (on a peripheral device), I don't believe that we are in a worse position, freedom-wise, than if the peripheral has its firmware in ROM. In fact, I would argue the reverse: the fact that new code can be loaded into the peripheral means that eventually some FLOSS programmer will figure out how to do it, while the device with its code in ROM is locked down harder than the most aggressive DRM system can achieve. It's better still if we have devices that are completely programmable all the way down, but there is more than one path to get there, and the purist approach advocated by the FSF and its international affiliates might not be the best path.
Software-as-firmware vs software-as-software
Posted Nov 9, 2010 9:30 UTC (Tue) by job (guest, #670)
[Link]
There are important differences between shipping firmware with the device or separately. In the latter case, there may be additional restrictions for redistribution. If the non-free software does not allow redistribution, the combined package with Linux is something you are not allowed to redistribute. If the non-free software merely restricts redistribution to "Linux" as published by Linus, your right to fork is void.
There is also different impact of copyright law when applied to software-as-firmware and software-as-software. I suspect for example that the first sale doctrine which is recently and famously in question in the United States, works differently for a physical device where resale would be less problematic. But IANAL and where I am laws are different.
Software-as-firmware vs software-as-software
Posted Nov 9, 2010 16:46 UTC (Tue) by vonbrand (subscriber, #4458)
[Link]
AFAICS, this point is moot: You are usually allowed to redistribute said firmware and use it on the device it is shipped for, no Linux restriction per se. Sure, in the ATMEL case it might be "firmware for use with the driver for Linux 2.6", but it is not restricted to it.
What is funny is that by current FSF standards, no GNU code could ever have been written...
Software-as-firmware vs software-as-software
Posted Nov 10, 2010 2:17 UTC (Wed) by lxoliva (subscriber, #40702)
[Link]
> by current FSF standards, no GNU code could ever have been written
This is not true. There is some incorrect assumption you're making about the FSF stance. I wonder what it is. Why do you think no GNU code could ever have been written?
Software-as-firmware vs software-as-software
Posted Nov 11, 2010 17:51 UTC (Thu) by vonbrand (subscriber, #4458)
[Link]
Because they now insist that everything has to be/run on "free software", even down to firmware for random devices; that certainly wasn't the idea when GNU was hailed as a nice complement to propietary Unices...
Software-as-firmware vs software-as-software
Posted Nov 11, 2010 18:16 UTC (Thu) by Arker (guest, #14205)
[Link]
Nonsense.
They have never had any problem bootstrapping with non-free software. There point is simply that this should always be understood clearly as a temporary expedient, rather than an acceptable end-point.
Software-as-firmware vs software-as-software
Posted Nov 11, 2010 19:30 UTC (Thu) by vonbrand (subscriber, #4458)
[Link]
So running forever on totally propietary Unices was fine, having an (eventually replaceable) blob loaded into some crevice of the system which is running otherwise "free" software isn't? I'd expect that kind of attitude given FLOSS was on at least 80% of desktops, until then...
Software-as-firmware vs software-as-software
Posted Nov 11, 2010 21:47 UTC (Thu) by DOT (subscriber, #58786)
[Link]
"temporary"
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 13:37 UTC (Tue) by lxoliva (subscriber, #40702)
[Link]
> Linux kernel developers are not profiting from the firmware blobs in any way
Why would they have put them in, if it's not to their (presumed) advantage?
I can't count the number of times I heard phrases such as if we take out these blobs, nobody is going to buy our distro.
No profit motive? Sorry, I beg to differ vehemently.
Furthermore, it seems like the denial has focused mainly on the thin objection that Open Core is a business model, so if there's no separate sale, the criticism doesn't apply.
Last I looked, neither Free Software nor Open Source Software had to do wtih price, but rather with freedom. With that in mind, let's look at Phipps' article and Oliver's statement and see whether the objections to Open Core raised by them, particularly the ones we quoted in the announcement, disappear just because the profit or other advantages saught out of either deception is indirect, shall we?
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 15:04 UTC (Tue) by nix (subscriber, #2304)
[Link]
Obviously open source will be helped greatly if Linux distros cease to be able to work with most wireless adapters and virtually all modern graphics cards because you can't modify the (apparently desperately boring) firmware: meanwhile, the entirely proprietary competition can keep going, full strength.
I use nothing but free software on my home systems, excepting non-free firmware for which there is no effective replacement, and, y'know what? I think this is preferable than being stuck with Windows because I can't make my graphics card display anything without a few kB of non-free firmware.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 15:14 UTC (Tue) by anselm (subscriber, #2796)
[Link]
Why would they have put them in, if it's not to their (presumed) advantage?
What about »so people who happen to own the device in question actually get to use it with Linux«?
Supporting a large variety of hardware devices makes Linux more of a viable proposition as a general-purpose operating system. This increases general interest in Linux and may even cause companies in the Linux business to make money, some of which may filter down to some kernel developers (not all of it to all of them). It is safe to say that many kernel developers are not in the game for personal monetary gain but because they enjoy doing difficult things for the benefit of the Linux community. This includes helping people actually use Linux (as opposed to preaching people sermons on what they really should be doing, buying, etc.) by adding whatever support is required for Linux to deal with the hardware that people have. These activities may earn most of them nothing except a certain amount of name recognition. I think this type of »advantage« is quite different from the very tangible advantage a company like SugarCRM, Inc., derives from selling the interesting pieces of their software for money.
As an aside, labelling the kernel developers as enemies of software freedom when one does nothing, oneself, to advance software freedom except trying to curtail the freedom of others to make their own lifestyle choices is disingenuous. The community tends to listen to doers more than talkers – and the FSF of the 1980s at least tried actively to come up with and promote free alternatives to many proprietary software choices of the day, but I don't see the FSFLA trying to develop free replacements of the firmware they are attempting to expunge from the Linux kernel.
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 19:24 UTC (Thu) by oak (subscriber, #2786)
[Link]
There's a very good reason to get rid of opaque binary blobs. If some piece of HW can write to any memory location, it having buggy firmware can corrupt internal kernel (or user space) memory silently and you have no way to review these things.
Catching bad memory writes done by HW is really hard (how _you_ would do it?). And if you don't have source, how do you fix the firmware?
Otherwise I have neutral attitude to firmware. Linux is at least on desktop too small to have much effect on manufacturers. On embedded side it may make sense to refuse binary blobs to make sure that there's open firmware... Aat least until manufacturer stops selling the HW at which point refusing the blob probably doesn't anymore act as encouragement for opening.
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 19:51 UTC (Thu) by mjg59 (subscriber, #23239)
[Link]
I don't think anyone disagrees that it would be preferable to have the source to all firmware. The disagreement rests upon whether, if we *are* going to have closed firmware, it's better to have it be runtime loadable (in which case it's much easier for us to replace it with open firmware, as happened in the b43 case) or for it to be in ROM (in which case it's impossible to replace and thus will never be open). I don't see how dropping support for runtime loadable firmware helps us encourage open replacements.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 3:04 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
I'd say the disagreement rests upon this straw man.
The issue is not whether users are allowed to use the non-Free firmware. Nobody's trying to stop them.
The issue is whether we, as a community, should encourage that. Whether we, as a community, should help vendors of hardware that requires non-Free Software capture customers. Whether we, as a community, want to encourage users to be happy slaves, keeping them comfortable and ignorant so that they will even invite others into the trap and feed the aggressors, or take a stand against non-Free Software with us.
The question really boils down to whether or not GNU+Linux distros and Linux should induce and help users accept the oppression from non-Free Software suppliers. The alternative is to refrain from aiding users in this regard. Which, again, doesn't mean *preventing* users from doing so: they wouldn't be stopped from obtaining and installing the non-Free Software, from those who *want* to oppress users.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 3:11 UTC (Fri) by mjg59 (subscriber, #23239)
[Link]
The problem is that removing loadable firmware support from the kernel does little to reduce the quantity of non-free firmware used in systems. To do that you'd also have to remove the drivers for all the hardware we know to be using non-free firmware. My understanding is that there's currently no completely functional open embedded controller firmware, so shouldn't you remove drivers/acpi/ec.c?
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 5:10 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
I don't know. Please help me understand what you're suggesting. How is it that drivers/acpi/ec.c encourages users to install non-Free Software?
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 13:40 UTC (Fri) by mjg59 (subscriber, #23239)
[Link]
Because every piece of hardware it manages contains non-free software.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 18:38 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
Yeah, but that software is installed by the manufacturer, not by the user, so that doesn't come even close to answering the question.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 21:54 UTC (Fri) by mjg59 (subscriber, #23239)
[Link]
How does Linux supporting hardware that can only (at present) function with non-free firmware not encourage the user to purchase that hardware and run non-free firmware? If the kernel didn't do it, they'd be forced to find a free alternative.
FSFLA: Linux kernel is "open core"
Posted Nov 13, 2010 7:37 UTC (Sat) by lxoliva (subscriber, #40702)
[Link]
Aah, thanks, I see what you mean now. I think the forcing part is not a good one, though. Nudging towards Free Software, I think is fine, but forcing is a bit too much unfreedom to me.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 3:49 UTC (Fri) by sfeam (subscriber, #2841)
[Link]
Your statements are both nonsensical and insulting. You refer to the user community as "happy slaves". You characterize distros that work to deliver a system that is most likely to work out of the box on the widest variety of machines, and thereby attract new linux users, as "oppressing users" or "feeding the aggressors".
At the start of this thread I was under the impression that the FSFLA had a positive, though unrealistic goal. You have now succeeded in convincing me that the FSFLA's goals (or at least your representation of them) are actively harmful to the adoption of linux. Should we as a community help and encourage users to use linux, even when that means accommodating their needs to use propriety hardware and non-free applications? Absolutely we should! Doing so does not "oppress" anyone. Rather it increases their range of options and therefore their freedom of choice. To advocate as you do that we should deliberately hide or avoid mentioning exactly the information that would allow potential users to realize that using linux is indeed an option -- well, that is counter-productive and just a really bad idea. It is especially counter-productive when you manage to insult everyone from developers to packagers to end users at the same time. Please stop it.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 5:17 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
For clarity, the oppressors are those who deny users their freedoms, i.e., the developers and original distributors of the non-Free Software. I wouldn't quite qualify as oppressors those who feed the aggressors, merely aiding them in capturing victims. If it seemed like I did, I apologize for the lack of clarity.
I don't see why the Free Software community should help and encourage users to use a non-Free kernel that induces them to install and use more non-Free Software, whose dependence on non-Free Software is growing faster than its Free core, and whose lead developer is proud of not being a member of the Free Software community, and despiteful to our social and ethical values while at that.
Choosing between non-Free systems is choice, but it's not freedom.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 5:49 UTC (Fri) by sfeam (subscriber, #2841)
[Link]
Choosing between non-Free systems is choice, but it's not freedom.
Nice aphorism. And now you have specifically relegated linux to that category, and castigated Linus for having the temerity to disagree with you.
At the end of the road to ideological purity down which you are headed, there will be no useful systems left that are sufficiently pure to meet your peculiar definition of "free". At that point freedom will be just another word for nothing left to choose*. I hope you are happy when you reach that dead end, but I shall not join you there.
*which is not quite the way Dylan said it, but makes at least as much sense :-)
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 6:55 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
Whereas at the end of the road which you appear to be defending, there won't even be systems left that meet *your* definition of free any more.
I'd rather use whatever freedom and power of choice I have now to try to avert this course. I wish you would, too.
If we give up our freedom without a fight, we'll end up without it. If we fight for it, there's a chance we retain whatever we still have, and even gain back some of what we've already lost. I'd rather fight and risk failing than give it up and be certain of ending up without it.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 4:33 UTC (Tue) by cmccabe (guest, #60281)
[Link]
Let's go with the definition that's in the announcement itself.
> Free Bait, or Open Core as first coined by Andrew Lampitt, is a
> licensing strategy that combines Free and non-Free Software: the
> distributor offers, under non-Free terms, premium features that are
> not available in the Free, typically copyleft, core. The original
> definition, presented in the context of deriving benefits such as
> profit or code contributions, may appear confusing because it
> conflates non-Free with commercial, but Free Bait does not mean
> selling additional permissions to the same code, letting others offer
> non-Free extensions, or offering Free extensions to paying customers.
> Rather, it means that a community member or distributor of the Free
> core also offers non-Free extensions to go with it.
Ok. So this definition deliberately obfuscates the difference between a project that *requires* a proprietary add-on, and a project that simply offers the ability to interoperate with existing proprietary software or hardware. I do not feel that your definition of Open Core is useful or widely accepted.
But let's follow this definition and see where it leads us. Are any GNU projects actually "FSFLA Open Core"?
Consider Gimp, the GNU Image Manipulation program. Gimp has features that allow it to run under Windows. Is Windows Free Software? No, it is not. Does running Gimp on Windows offer features that are not available if Gimp is run on other operating systems? Yes, it does. Certain printers, tablet input devices, and other hardware only have Windows drivers. By using the combination of Gimp and Windows, the user gains additional functionality. Therefore, Gimp is "FSFLA open core". Shock, horror!
The fact that you can run Gimp on operating systems that are Free apparently doesn't matter to the FSFLA. You can use the Linux kernel without binary blobs, too. The fact that the folks behind Gimp don't encourage you to use Windows or profit from Windows doesn't matter at all. Linus doesn't encourage or profit from binary blobs, either. The fact that Windows is an operating system, and Gimp is an image editor-- the "mere aggregation" of two unrelated products, as copyright law would have it, apparently doesn't matter either. Binary blobs loaded on firmwares are not derived works of the Linux kernel, either.
By this definition, any program that interoperates with proprietary software in any way-- any program that runs, or could be run by some "community member or distributor" on a proprietary platform, is "FSFLA open core."
Therefore, I claim that *all* FSF projects are open core.
Even GNU Hurd can be run inside a proprietary VMWare virtual machine. You will gain additional, premium features by doing this, like the ability to debug kernel crashes while running other programs on your computer. If you like, I will ship you a CD that contains both GNU Hurd and VMWare, hence tainting it forever in the eyes of the faithful. Are we done now?
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 14:11 UTC (Tue) by lxoliva (subscriber, #40702)
[Link]
Offering the ability to interoperate is not the problem. It's inducing users to get caught in a proprietary trap that makes it bait. It's offering the combination that makes the *combination* fit Free Bait/Open Core. See, it's covered in the definition: letting *others* offer non-Free extensions is not Free Bait/Open Core, as clarified in the announcement, a clarification drawn from Aslett's referenced article.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 15:54 UTC (Tue) by BenHutchings (subscriber, #37955)
[Link]
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.
FSFLA: Linux kernel is "open core"
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.
FSFLA: Linux kernel is "open core"
Posted Nov 10, 2010 18:45 UTC (Wed) by cmccabe (guest, #60281)
[Link]
> Offering the ability to interoperate is not the problem. It's inducing
> users to get caught in a proprietary trap that makes it bait.
So when it's a project you're associated with, adding these features is "offering the ability to interoperate." When it's someone else's project, it's "inducing users to get caught in a proprietary trap."
Inducing users to use Windows is much more of a trap than inducing them to use a certain network card, which they can always swap out for a different card. Swapping out network cards is literally a 5 minute process; switching operating systems could take months or years for an individual or organization to fully accomplish.
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 4:17 UTC (Thu) by lxoliva (subscriber, #40702)
[Link]
It seems that we're miscommunicating. In the English I've learned, inducing doesn't mean tolerating whatever unfortunate choices your party may have done, but rather trying to influence your party into doing something they might not have chosen to do otherwise.
So, if the kernel works with what the user chose, no problem in the kernel. But if the kernel asks the user to install something that's known to be non-Free Software, and refuses to work until the user complies, there's a freedom bug in the kernel.
Similarly, Free Software that works on Windows is tolerable, but Free Software that, if started on GNU/Linux-libre, demands the user to install Windows isn't.
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 6:32 UTC (Thu) by sitaram (subscriber, #5959)
[Link]
Usually the "user chose" the hardware already, and then it's either use the kernel because it has some blobs that help you use it, or not use Linux at all.
In an ideal world, people would say "oh, Linux doesn't work with this, so I wont buy this hardware". In the real world, they shoot the other way.
You cant call that inducing anymore than having a Windows version of GIMP is inducing the person to use Windows.
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 6:56 UTC (Thu) by lxoliva (subscriber, #40702)
[Link]
> Usually the "user chose" the hardware already
If that is so, that's a reality we'd better try to change.
A number of people at least try a 100% Free distro before buying a computer or peripheral device. If more people did this, we'd see fewer users trapped to hardware that deprives them of freedom.
Now, if the hardware was already chosen and it can't be returned, the goal becomes to avoid spreading the mistake. If the user remains unaware that the device is a programmable computer programmed to control her and limit what she can do with it, odds are she will recommend it to others, so that's an argument against making it just work. Some slight inconvenience, such as requiring drivers and firmware to be obtained from the vendor, media, a third-party repository, and having to do that every time the system is reinstalled, will not prevent the user from using the device she's stuck with if she wants to, which is ok since the harm is already done and the monster is already fed, but it will help avoid the repetition of the mistake when the user upgrades or replaces the computer.
The approach taken by Linux-libre is a bit better than that, in that the driver will recognize a device that requires non-Free firmware instead of silently failing to work, and userland can then explain the problem to the user, and then the user can make an informed decision as to whether to seek a Free driver that will work with the non-Free firmware, or refrain from installing non-Free Software on their system, perhaps by replacing the hardware component.
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 10:32 UTC (Thu) by cesarb (subscriber, #6266)
[Link]
A point many people are trying to make here is that this is a tactical mistake.
> and then the user can make an informed decision as to whether to seek a Free driver that will work with the non-Free firmware, or refrain from installing non-Free Software on their system, perhaps by replacing the hardware component.
There is another option you seem to be ignoring: the user can refrain from using free software on their system, and go back to whichever operating system they were using before. And the user will recommend against free systems to others.
There is a reason the most popular distribution makes it easy (though I think it makes it too easy) to enabled closed drivers when the open option is not available (or sometimes even when it is). It is a bait: by making the distribution work very well, even if they have to sacrifice a bit of purity, they entice the user to use more and more free software instead of closed alternatives.
Yes, it is a bait, used in the exact opposite direction that you are fearing: instead of luring users to non-free, they are luring users to free.
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 11:28 UTC (Thu) by sitaram (subscriber, #5959)
[Link]
> Yes, it is a bait, used in the exact opposite direction that you are fearing: instead of luring users to non-free, they are luring users to free.
dang... that is what I was trying to say but you said it much better!
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 11:55 UTC (Thu) by lxoliva (subscriber, #40702)
[Link]
Enabling non-Free drivers and firmware is a growing problem. They're growing faster than the Free parts of those systems. They send users a message that it's ok to accept software that denies essential freedoms. That reasoning accummulates, and from few pieces of firmware under Free licenses and with sources, we went to tons of pieces of firmware under non-Free licenses, without licenses, without sources, while still pretending to be Free. Distros add non-Free drivers on top of that, and often non-Free applications. The set of non-Free firmware, drivers and applications is growing over time and, per your reasoning, that would be the right thing to do to avoid sending users away.
At this rate, eventually, we'll have a proportionally thin layer of Free Software surrounded by non-Free drivers and applications, and then I wonder whether you'll be asking yourself what the point was of trying to convince users to switch from one non-Free system to another in the first place.
Me, I prefer to tell users about software freedom first, get them to realize it's important, and make them jump when they're ready to. I don't fault any victims for finding out their current computers are enemies of their freedoms, or for installing pieces of software that will make them work as they wish, as long as they're aware of the problem and display an interest in correcting the purchasing mistake next time. If they're not interested in freedom, what's the point of suggesting them to go through the trouble of replacing one non-Free system with another? They might as well keep on using the non-Free system they're used to, perhaps with a bunch of Free Software applications that run on it. Yeah, they won't be as Free, but remember, in this case they were not interested in freedom.
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 13:48 UTC (Thu) by cesarb (subscriber, #6266)
[Link]
*scratches head*
I think this post of yours is perhaps the one which explains your position the clearest.
But it sounds as if you believe non-free is some sort of cancer which will spread if given even the thinnest of wedges, and push free software into the tiniest of niches. I am not that pessimistic.
I believe that, instead of only allowing a perfect system with no non-free components, it is better to attack on multiple layers at the same time, while accepting some temporary imperfection. While one team deals with freeing the core of an operating system kernel, another set of teams can deal with freeing the drivers, yet another set can deal with freeing the firmware, and in a corner another team is working on creating completely free hardware, and so on, all working independently and at the same time. Each team has to allow for some non-free parts while good free alternatives aren't available.
I also do not think the situation is getting worse. For a while, you had to use closed-source drivers if you wanted decent 3D acceleration on common desktops; nowadays, we are near having free decent 3D acceleration on common desktops, both with help of hardware vendors (AMD and Intel) and via sheer reverse engineering (nVidia). The situation with wireless drivers is similar; nowadays, even Broadcom has started helping (see http://lwn.net/Articles/404248/). The synergy advantages of free software start showing; with the free graphics drivers, we have kernel modesetting, and now even the kernel debugger can work with them. And I do not doubt that, as soon as nouveau is good enough that people do not feel the need to install the "official" nVidia drivers, the mechanisms which make the non-free driver easier to install will start to get neglected.
Finally, I do not think we must tell users about the philosophical side first. I myself started by using DJGPP, and only later learned of the philosophy. If you force users to learn about software freedom first, you will lose a lot of people who would learn about it later. And even if they do not learn or do not care about it, isn't it better, if only because of the network effects, that they use free software, even if only for part of their needs?
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 2:57 UTC (Fri) by cmccabe (guest, #60281)
[Link]
"The perfect is the enemy of the good."
- Linus Torvalds, quoting Voltaire.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 3:25 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
> you will lose a lot of people who would learn about it later
Can't lose something I don't have.
> isn't it better, if only because of the network effects, that they use free software, even if only for part of their needs
For themselves, yes, it's better. For the Free Software movement, I'd say it isn't: if they're taught that short-term practical reasons are the reason to try Free Software, that will also get them away from software freedom when short-term practical advantages are present in non-Free Software. If they're taught that sacrificing their freedoms is ok, that's what they will do when offered bait that shines of short-term practical reasons. I.e., just when we'd most need them to stand firm with us for software freedom, they'd detract, because they haven't got the right message.
It is true that a few of those who start by learning the short-erm practical advantages will see through that and find out about the deeper, long-term practical and ethical reasons. But a majority doesn't. And when the majority doesn't stand for our values, our whole community is vulnerable: we lose, because the network effects, instead of favoring our goals of eliminating the non-Free Software oppression, play against them.
I wish I was just pessimistic, but a social experiment started in 1998 shows just how perverse that is. A group you might be familiar with launched a campaign to promote Free Software on its short-term practical benefits, leaving ethical values out of the picture. It got very popular, and the result is that a lot of software those who subscribe to that ideology produce is not quite Free, and many of them will attack and ridicule those who stand for software freedom.
I'd much rather the Free Software movement had grown slowly but surely, just not as slowly as it does now because of the detrimental effects of that campaign.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 3:38 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
> it sounds as if you believe non-free is some sort of cancer
I don't, and the difference is quite significant.
Cancer is a natural, biological phenomenom. As harmful as it is, it has no will of its own. The damage is not intentional, so it's not unethical, and there's no economic drive for the cancer to spread the harm.
Depriving others of software freedom is an artificial phenomenom. Many who engage in such a harmful practice do so intentionally, so as to obtain an economic advantage, including power over others. That is unethical, and the gained advantages imply it will tend to grow and concentrate power unless it meets strong resistance that renders the unethical behavior disadvantageous.
The Free Software movement is a movement to build up that resistance. Please help us!
I don't think Linux is "Open Core"
Posted Nov 10, 2010 13:28 UTC (Wed) by bkuhn (subscriber, #58642)
[Link]
There's no doubt that “Open Core” is a poorly defined term. However, I've come to the conclusion that whatever “Open Core” is, it is at least a special case of proprietary relicensing, whereby one entity has a monopoly on the relicensing of a codebase under non-copyleft terms.
Linux is not this. It's very bad that Linux includes so much proprietary software as part of its default distribution, and I am very grateful that @lxoliva maintains Linux Libre to help document how much proprietary code is in Linux, and to give users who value software freedom an alternative version of Linux that's 100% Free Software.
However, I think that @lxoliva's use of the term “Open Core” here only serves to make an ill-defined term even more confusing.
— bkuhn
Disclaimer: While I do serve on the Board of Directors of the FSF, the comments here reflect only my personal opinion, not the official opinion of FSF.
I don't think Linux is "Open Core"
Posted Nov 10, 2010 19:41 UTC (Wed) by lxoliva (subscriber, #40702)
[Link]
I don't see why you consider proprietary relicensing as a requirement for Open Core. Indeed, it appears to me that you regard Open Core as covering even the practice of selling exceptions, which is explicitly excluded from the definition by both Aslett (downstream from Lampitt) and Mickos (upstream).
Linux and GNU/Linux distros have shown us that relicensing of the Free core isn't always necessary to offer non-Free add-ons to go with it, together or separately.
After all these discussions, I must agree that Open Core is understood in different ways by different people, but I'm not sure how much of it is a consequence of the way the definition is phrased, how much is just the normal sort of communication partnership in which different readers get different messages from the same text because of different personal backgrounds, and how much follows from the common twisting of meaning that we so often see term such as Free and Open Source undergo.
In retrospect, I'm very happy we used a different term, Free Bait, implicitly defined as equivalent to what we perceived and described as Open Core. It might be wise now to publish a stand-alone definition, independent from that of Open Core. Since our understanding of the meaning of Free Bait won't have changed, it's clear that Linux and GNU+Linux distros will still fit it, and that the deceptive practices of passing non-Free (or partially Free, as some prefer) for Free Software will still be subject to criticism, but it remains to be seen whether the criticism from third parties to the Open Core practices (however they understand them) will be sustained or retracted when it comes to Free Bait.
I don't think Linux is "Open Core"
Posted Nov 10, 2010 22:10 UTC (Wed) by nix (subscriber, #2304)
[Link]
I'm not sure we're speaking the same language. In the English I speak, 'Linux supports my hardware, for which no free firmware exists, and for which no competition exists that has free firmware' is not code for 'Linux is bait for my hardware'. After all, what could I replace it with? Nothing?
There are some -- I'd venture to say many -- classes of hardware for which *every single device that exists* has non-free firmware: it's just that the firmware on some of those devices is burned into EEPROM. Your decision to allow the one but not the other based purely on whether there is (possibly upgradeable) non-free firmware in the device as shipped seems completely arbitrary to me.
I don't think Linux is "Open Core"
Posted Nov 11, 2010 1:53 UTC (Thu) by lxoliva (subscriber, #40702)
[Link]
Say you're a fish living in an acquarium. The acquarium will rent boats for amateur fishermen to fish there.
At a certain moment, you're hungry, and all the food available to you turns out to be shrimp/worms/whatever around hooks. Does the fact that you don't have anything else to eat make them any less bait?
Now, the interesting bit to realize is that the reason you don't have anythiign else to eat is that you've already lost your freedom: living in such an acquarium, you can't possibly be Free.
If you were Free, you could swim elsewhere and try to get food (rather than bait) there. But you'd also have to be aware of the bait and the hook, to avoid getting caught.
Now, if you've already made your decision to be caught, be it to be taken to an acquarium, be it to become someone's dinner, nobody's stopping you. We're just exposing the deception: that some who claim to stand for your freedom are actually helping others keep you a happy slave. See the response to dwmw2 with this phrase for more on non-loadable firmware.
I don't think Linux is "Open Core"
Posted Nov 11, 2010 1:58 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
so now the kernel developers are not only dishonest, they are slavers as well.
I don't think Linux is "Open Core"
Posted Nov 11, 2010 7:26 UTC (Thu) by nix (subscriber, #2304)
[Link]
But that means that the linux-libre kernel is *completely useless* for such hardware, until such time as the kernel devs write new firmware (which they very possibly aren't going to anytime soon because writing new firmware probably requires knowledge of the hardware unavailable to anyone without a lengthy reverse-engineering process). And as I've said, this applies to *entire classes* of hardware. (e.g. it's just luck and the need to display things in VGA mode at bootup that means it isn't true for all current graphics cards.)
I don't think Linux is "Open Core"
Posted Nov 11, 2010 11:38 UTC (Thu) by lxoliva (subscriber, #40702)
[Link]
I don't know what *entire classes* of hardware you have in mind, but it seems like you're totally off in your guess. Linux-libre works just fine with nVidia, Intel, and ATi cards, all tested personally. Sure, you won't get 3D on ATi because that requires blobs.
Besides, nothing in Linux-libre stops you from installing drivers and accompanying firmware of your choice, so the completely useless assessment is, again, totally off.
I don't think Linux is "Open Core"
Posted Nov 11, 2010 12:13 UTC (Thu) by anselm (subscriber, #2796)
[Link]
Besides, nothing in Linux-libre stops you from installing drivers and accompanying firmware of your choice, so the “completely useless” assessment is, again, totally off.
Right. So I install linux-libre and manually put all the »non-free« stuff I need to get my actual hardware running on top of it.
Why would I want to do that instead of installing a stock distribution kernel from, say, Debian, which already comes with most of the stuff I need to get my hardware running, and makes it convenient to install the rest? Both options result in a system that the FSF would call »non-free«, but the Debian route is much less hassle, not to mention better-maintained and easier to upgrade as bugs get fixed.
I don't think Linux is "Open Core"
Posted Nov 12, 2010 3:45 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
> Why would I want to do that instead of installing a stock distribution kernel from, say, Debian, which already comes with most of the stuff I need to get my hardware running, and makes it convenient to install the rest?
Precisely because this convenience will play against you and the community when the time comes to recommend a computer for someone else to buy, or even at your next purchase.
If you make it easy and convenient for yourself to remain captured, odds are you won't fight as hard to release yourself.
If you go through a painful experience, and you understand that the pain is inflicted by the hardware vendor rather than by the operating system community, you will work hard to avoid that pain next time.
It's a way of using your own emotional feedback for long-term personal and social advantage.
I don't think Linux is "Open Core"
Posted Nov 12, 2010 9:21 UTC (Fri) by anselm (subscriber, #2796)
[Link]
Precisely because this convenience will play against you and the community when the time comes to recommend a computer for someone else to buy, or even at your next purchase.
Whenever I want to buy a new computer I take a Debian CD into the shop to check and see what it does to the machine I have in mind. If important parts don't seem to work I don't buy the computer, and tell the shop attendants why.
I've been a Linux user since 1993, and so far, over the years Linux support has improved, not deteriorated, with every single computer I have bought. On my current laptop, which is a very nice machine with lots of built-in goodies, everything except for the fingerprint reader worked from the get-go. If you can live without 3D graphics for the sake of »freedom« then I can certainly live without a fingerprint reader.
If you go through a painful experience, and you understand that the pain is inflicted by the hardware vendor rather than by the operating system community, you will work hard to avoid that pain next time.
I don't know about you, but personally I avoid pain by not going through a painful experience in the first place if I can help it. I appreciate the efforts of the Linux kernel development community, the Debian project (as the makers of my preferred Linux distribution), and those hardware manufacturers who encourage Linux support for their products (who will always get my business in preference to other vendors). All of these together work very hard to help me avoid pain, and so far they have never let me down. I'm grateful.
I don't think Linux is "Open Core"
Posted Nov 12, 2010 18:48 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
Thank you for being a good, freedom-supporting customer. I wish more people were like us.
Now, may I suggest that you use one of the 100% Free distros instead? Debian has been shipping a growing lot of non-Free firmware in its kernel for quite a long time. Your improved experience may unfortunately be a reflection of an illusion that the software you've tried is Free, while in reality some of the components only work because of the non-Free blobs hiding in there.
I applaud Debian's decision to push those blobs out of its main kernel for the upcoming release. If they also refrain from placing those blobs in the CDs you use for testing, you should start getting a more accurate picture of the reality of the situation.
Which, as you say, isn't as bad as it once was. Whereas before you'd only have hope of a fully functional computer selecting off-board components individually and assembling the computer yourself, it is nowadays possible to find mass-produced computers (netbooks, notebooks, desktops, workstations, servers) at mass retailers at affordable prices that will work 100% with a wholly Free operating system. Let's keep the pressure on!
I don't think Linux is "Open Core"
Posted Nov 15, 2010 18:55 UTC (Mon) by wookey (subscriber, #5501)
[Link]
Debian is not a good example of a distro that includes non-free software. They have taken a fairly hard-line (but also somewhat pragmatic in terms of still getting a release out from time to time) on removing any non-free drivers. Blobs which are non-free but redistributable are still made available in the nonfree repository, so life is rather more convenient than I assume it is with linux-libre, (add the repo and install linux-firmware-nonfree) but I hope it's clear to users that they had to install some non-free software to make their hardware work, which is the fundamental point lxolivera wants made (and I agree with him that it's important).
There is a real tension here (as illustrated in this thread). For each user (that already has hardware needing non-free drivers) it is better if the distros just put it in. But this is bad for Free Software as a whole, because it legitimises non-free drivers and hardware, and reduces the incentive for people to buy free stuff.
I try very hard to buy only hardware that works with free drivers, but of course its often hard to know. One can't blame 'average' users from buying whatever is (cheapest and) in front of them, especially if the software freedom issues are not even explained. OK a lot of them couldn't care less anyway, but currently for those that _do_ care there is almost no pressure to make manufacturers label their hardware in a manner which allows consumer choice. And very little progress has been made on this in the last few years. The graphics card situation has improved (on the desktop), but got worse on embedded. Not sure if network cards and wireless cards is worse of better - I think it's improved a little in that free drivers are available for some cards, but things like DVB-T TV tuner cards is a sorry area, and no doubt so are 3G dongles and the like.
Almost everything now has some firmware in it, and not much of that firmware is free. This is a bad thing. And I don't think we are doing a good job of fixing this problem collectively. Do you expect it to be better or worse in 10 years time?
I don't know what the answer is here but I'm glad to see linux-libre at least making the point that this is a serious issue that is being allowed to slide. On the one hand its great to see Linux desktops becoming more mainstream daily, but if none of those users understand why free software matters then I'm not sure we have sustainable progress - we'll end up with most people using some free software surrounded by proprietary parts and users will only be marginally better off than they were using a fully proprietary system.
I guess for those that only care about Open Source as a development model, then software freedom per se doesn't really matter. I suppose it's that divide that makes this thread so long :-)
Free Bait (was: I don't think Linux is "Open Core")
Posted Nov 10, 2010 22:42 UTC (Wed) by cesarb (subscriber, #6266)
[Link]
The problem with "Free Bait" is that it implies malice (or at least to me sounds like it does). It implies that whoever is doing it wants to purposely deceive people as to their true intentions.
It is no wonder the discussion got so heated; people do not like being called liars.
Citation needed!
Posted Nov 8, 2010 23:21 UTC (Mon) by khim (subscriber, #9252)
[Link]
"Open core" is a specific business model based on keeping part of the code proprietary and forcing users to pay you for its use.
This is quite novel idea, indeed. Can you, please, cite respactable source which says that you must "force users to pay" to qualify for "open core" label? I was under impression that things like Google Chrome (which includes proprietary Flash plugin and PDF reader plugin) are perceived as "open core" - even if Google distributes it for free.
Linus does the same thing with Linux. We can discuss if it's good thing or bad thing (I personally think it's good thing) but it's "open core" by any sane definition.
Citation needed!
Posted Nov 8, 2010 23:40 UTC (Mon) by kripkenstein (subscriber, #43281)
[Link]
> This is quite novel idea, indeed. Can you, please, cite respactable source which says that you must "force users to pay" to qualify for "open core" label?
GP is right, 'open core' is a term used to describe a particular business model. As a business model, it speaks about how to make money.
Of course, you can use the two words 'open' and 'core' together and mean something else. It's confusing though, to people that are familiar with the term as it's currently used.
It's like using the words 'open' and 'source' and saying that "all JavaScript code on the web is open source - I can look at it!" as people say now and then. But the 'source being open' is not the same as 'open source', as the term is correctly used.
If you want some verification for the proper use of 'open core', just google it. The first result I got there is good enough:
Interesting. I've tried to reproduce the experiment and got entirely different page. Which clearly says "the important thing to note is that in the dual license strategy a single code base is available under an open source or closed license, while with open core the closed source licensed code is a superset of the open source code".
Looks like as with "open source" we have different definitions which are not always agree on details. But as for Linux - the difference is not so big: there are already some drivers which can only be used if you buy the Windows driver and pull the firmware blob from it (think winmodems), so Linux will satisfy even these requirements.
And in my case I got something different...
Posted Nov 9, 2010 2:22 UTC (Tue) by kripkenstein (subscriber, #43281)
[Link]
> I've tried to reproduce the experiment and got entirely different page. Which clearly says "the important thing to note is that in the dual license strategy a single code base is available under an open source or closed license, while with open core the closed source licensed code is a superset of the open source code".
Actually your article is also clear that it is a business model, here are some quotes from there:
> Open core is a commercial open source strategy
> the commercial license is a super-set of the open source product,
etc.
You picked a quote that compares dual-licensing with open core, and focuses on the licensing aspect. But the rest of the article is clear that open core is a commercial matter, a business model.
But again, it doesn't really matter what words we use, just as long as we are clear on what they mean. The Linux kernel is not commercial w.r.t the binary non-FOSS parts in it. Those parts are annoying, but not there for a commercial purpose. What we call that is less important.
And in my case I got something different...
Posted Nov 9, 2010 14:18 UTC (Tue) by lxoliva (subscriber, #40702)
[Link]
There is Open Core Licensing, as canonically defined by Lampitt, and there are the Open Core Business Models it supports. Whether adding blobs and bait to Linux makes business sense is not the issue: the blobs are non-Free Software, the bait is harmful, and misrepresenting Linux and distros that include the blobs as Free (or Open Source), or as advantageous as, is bait-and-switch (Phipps' term) and deception (Oliver's word).
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 21:43 UTC (Mon) by chad.netzer (✭ supporter ✭, #4257)
[Link]
I think the phrase "just fine" is an unfair characterization of ledow's comments. Unless the firmware blobs represent a GPL (ie. copyright) violation, how are firmware blobs worse than a device with the blob already in flash or ROM?
Frankly, there is a world of difference between a firmware blob that is downloaded into hardware, and a driver blob that is loaded into kernel address space. I think much care should be taken by free software advocates not to conflate the two (not to imply that has happened here). And the continuing emphasis should be on promoting hardware providers who provide the documentation to write good drivers, whether or not the firmware source itself is "free".
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 16:23 UTC (Mon) by coriordan (guest, #7544)
[Link]
> Without it the device is, presumably, a brick.
If I take Windows 95 off my computer, it's also like a brick.
That is, until I put some new software on it.
The question is about what sort of software to put on these devices, and FSFLA is saying we should put free software on them. The default Linux kernel is unfortunately taking the other side.
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 16:38 UTC (Mon) by cesarb (subscriber, #6266)
[Link]
Your analogy would make sense if there was a free software replacement for these firmware blobs. Since there isn't, the options are "binary firmware" or "brick". There is no question as to what sort of software to put on these devices, since there is only one option.
If there was a case where you had both non-free firmware and free firmware for the same hardware, and the Linux kernel developers rejected the free firmware on non-technical merits (they will not accept it if it is buggy crap that crashes all the time or introduces a security hole), then you would have a point. I know of no case where that happened.
Not to mention that the whole argument is a bit bizarre. Non-free binary code on flash memory within device = OK; the exact same non-free binary code running on the exact same device but uploaded from the operating system = not OK? Either both are wrong or neither is, since it is the exact same code running in the exact same place doing the exact same things. The only difference being where it is stored while the device is powered off.
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 16:45 UTC (Mon) by mpr22 (subscriber, #60784)
[Link]
I'm pretty sure the line is drawn between ROM (permanent storage) and EEPROM (field-programmable storage) rather than between EEPROM (non-volatile programmable storage) and RAM (volatile programmable storage).
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 21:57 UTC (Mon) by chad.netzer (✭ supporter ✭, #4257)
[Link]
So wait. If the logic is hardcoded, but you cannot get the circuit schematics, that's fine? Why not insist that *every* logic gate must be published in order to be "free"? If an opaque firmware blob is distributed via the internet, rather than via an EEPROM on the device itself, what difference does it make to "freedom"?
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 7:27 UTC (Tue) by jmm82 (guest, #59425)
[Link]
plus 1 for this comment.
The only people in the world who care about this are the 10 people on LWN who are trying to push their politics. 99.99% of the world does not know this exists until their wifi diver breaks because the fsf was trying to prove a point. Now they have to find the correct firmware out of tree and load it themselves. That is the kind of stuff that scares away new users.
I love Linux, open source, and playing with my hardware, but in the end I would prefer my hardware works.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 18:20 UTC (Tue) by jebba (✭ supporter ✭, #4439)
[Link]
So this stuff in the linux-2.6.xx.tar is just fine with you? Anyone suggesting they be removed is just playing politics?
I think *all* of those were "Found in hex form in the kernel source". Is that OK? Should we add another few hundred? Or better to remove?
How about these?
Licence: (C) F6FBB 1998, File: yam/1200.bin
Licence: (C) F6FBB 1998, File: yam/9600.bin
"Found in hex form in kernel source". You sure that file is redistributable? What about the others?
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 19:21 UTC (Tue) by sfeam (subscriber, #2841)
[Link]
So this stuff in the linux-2.6.xx.tar is just fine with you? Anyone suggesting they be removed is just playing politics?
Yes, on both counts.
If someone is self-motivated to do the work to split them out into a separate directory tree, whether in the cause of ideological purity or for other reasons, that's also just fine with me. If they then take the next step of removing them altogether in order to fork and distribute a less functional kernel - well, I think that's very foolish but ultimately harmless. That small number of people who feel that their karma is increased by following this route to ideological purity will cheer, while the rest of us will continue to use a distribution that actually runs on the machines we use.
What's not "just fine" with me is to actively hinder the continued improvement and popularity of linux by imposing unnecessary hurdles to adoption. The FSF is IMHO guilty of this many times over; the FSFLA rather less so. Leading by example is a good thing. So while I am dubious that a large community will gather behind the banner of linux-libre, I wish them well. By contrast the FSF seems to have lost it's way entirely. They are admonishing rather than creating, and proselytizing rather than leading.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 19:31 UTC (Tue) by jebba (✭ supporter ✭, #4439)
[Link]
> while the rest of us will continue to use a distribution that actually runs on the machines we use.
Really? Do you need any of the above firmware on your machine? Still hanging on to that 1998 sound card?
Boot up a -libre kernel and see if it works. Perhaps your system *can* run a kernel with non-free software removed.
FSFLA: Linux kernel is "open core"
Posted Nov 10, 2010 18:04 UTC (Wed) by nye (guest, #51576)
[Link]
I don't really understand what 'found in hex form in the kernel source' actually means - are these sections extracted from drivers of entirely unknown provenance? Why would they not be licensed in the same way as the containing code, which presumably is considered legally sound?
(I'm not asking rhetorically BTW; I'd just like to see some clarification of how this situation came about.)
FSFLA: Linux kernel is "open core"
Posted Nov 10, 2010 20:40 UTC (Wed) by jebba (✭ supporter ✭, #4439)
[Link]
> I don't really understand what 'found in hex form in the kernel source' actually means - are these sections extracted from drivers of entirely unknown provenance? Why would they not be licensed in the same way as the containing code, which presumably is considered legally sound?
Well, taking the first one on the list as an example, it appears so. The firmware was found at sound/pci/korg1212/korg1212-firmware.h and moved into firmware/. I tried to find where it was added in Linus' git and in the history.git but I can't see where the file was actually added. Most of the ones above are pretty ancient. The firmware can't be under the same license (GPLv2) because no source code is provided for the firmware.
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 15:25 UTC (Thu) by nye (guest, #51576)
[Link]
>The firmware can't be under the same license (GPLv2) because no source code is provided for the firmware.
Ah, right. So the issue is that the 'source' initially available actually included binaries in textual form, making that source GPL incompatible, and the combined work thus (potentially) non-redistributable.
That makes sense (in a sigh-inducing, twisted sort of way :P) - thanks for clarifying.
FSFLA: Linux kernel is "open core"
Posted Nov 11, 2010 20:37 UTC (Thu) by chad.netzer (✭ supporter ✭, #4257)
[Link]
Ah, but that is a copyright issue, and that, as far as I can see is *not* the topic of debate here. The kernel developers should obviously be concerned with clarifying and keeping clear the distinct copyright of the firmware (which moving into a separate directory, or tarball, may help). I think most everyone can agree on that. The issue really being discussed is that these binary firmware blobs represent non-free "taint" of the system/hardware in use, not the kernel itself. Hence, being "baited" into using "proprietary" hardware, even if the kernel drivers themselves are free.
It doesn't fly, at least not the part about accusing the Linux developers of complicity in "baiting" us into using non-free firmware. It would be similar to faulting Linux for allowing me to run a user-space binary that isn't "free". Should the kernel developers now be chastised for "baiting" us into using things like Matlab or Photoshop? Ridiculous, and FSFLA should be ashamed for framing their argument in such accusatory terms.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 4:00 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
Baiting is inducing, allowing means not standing in the way. There's a fundamental ethical and moral difference in there.
Consider smart fish, and scenarios in which one fish sees another going for a piece of food, that may or may not be bait around a hook.
1. the first fish knows it's bait around a hook, or in a trap
1.a) the first fish says there, go for it!
1.b) the first fish gets in the way and says hey, that's bait, you'll get trapped, you sure you want to?, so the other fish, if still decided to take the bait, has to take a detour to get to it
2. the first fish can't tell whether there's a hook or a trap, so it says nothing and doesn't stand in the way
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 4:44 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257)
[Link]
These fishing analogies you keep using really aren't the best metaphors, imo. Can you phrase it in terms of sports or movies?
Or better yet, drop the analogies, since we aren't children; this is our field, we basically understand the scenario. Are cellphone technology providers to be chastised for "baiting" me into use one, while not providing free/libre firmware (even if the the OS is free), or are they to be thanked for allowing people to be able to call an ambulance when they are having a heart attack on a camping trip? I'll take the freedom to survive in that scenario.
If the firmware blobs are a copyright problem, by all means say so plainly. But to state that the Linux developers have set a trap for users, is low.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 4:56 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
I don't see that their offering you the ability to make calls at emergencies justifies or legitimizes their depriving you of your freedoms. The ability to make calls is still a way of luring you to give up your privacy and your freedom (there's a reason why these tracking devices are called *cell* phones :-) So, thank them for what you're grateful of, but also complain and use your freedom and power of choice to demand respect. Don't let the bait buy your silence or make you complacent.
I'm not concerned with the copyriht issues. They're just a distraction. Even if there was no copyright issue whatsoever, the blobs would still be non-Free Software (i.e., software that deprives users of their four essential software freedoms), and inducing people to accept them is socially harmful practice that proponents of software freedom had better not engage in.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 6:45 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257)
[Link]
I want your pledge that when one of the providers of these firmware blobs has said, "Fine, here's the register interface to the custom chip we built, feel free to write your own firmware.", you'll refuse to use them until they also provide the VHDL files they used to create it. Because *clearly* there can be no design firewall that you don't deem as an affront to your freedom.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 7:28 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
Wait a minute! You're thinking of firmware as pure configuration data, with a few dozens of registers set to a certain fixed values so that the device does the job it was designed to do? That's is not what this is about! That's not non-Free Software, it doesn't even qualify as software!
The blobs we're talking about contain machine instructions that run on actual computers. Many of them are regularly modified fixing errors or even adding features. Some implement anti-features. You remember when Linux fit in a single floppy disk, and with a couple of floppy disks you could have an entire functional Free GNU+Linux operating system? Some of the blobs we're facing these days wouldn't fit in one of those floppy disks! They're entire operating systems for the computers hiding inside our computers, often hiding from you their true power.
Please help us (re)conquer freedom in that field! Don't let the expanding meaning of firmware fool you.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 8:09 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257)
[Link]
I'm not sure why you chose to interpret my statements that way. I said elsewhere, for example, that a distinction must be made between firmware blobs that run outside of the kernel (ie. on processors not running Linux), and binary driver blobs which run in kernel space. So I, and others, are aware that the firmware blobs represent code and running programs. Not just "configuration data".
Whatever. You don't appear to be responding to my points. Fair enough. A campaign to publicize the problems with binary code in the form of firmware blobs is perhaps a good one. But the way you go about it seems all wrong to me. It's kind of like PETA. A core part of their message (let's treat animals humanely) is pretty sane and agreeable. And yet they go about promoting it like complete dicks. I've stopped being a strict vegetarian, in very small part, because I didn't wanna end up like those kooks. I hope the same doesn't happen to my attitudes about Free Software...
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 18:35 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
> I'm not sure why you chose to interpret my statements that way
Because the register file interface is hardly enough to write the software to run on the embedded computer, but it would likely be plenty to configure a device whose firmware is just configuration data.
Now, perhaps the VHDL description would be desirable to have, but if the embedded device contains a general-purpose programmable computer, having a description of its ISA would come in handier than the VHDL description for the purposes of writing the software to run on it.
Thanks for your apparent support to the campaign. If you can find better ways to spread the message, by all means go for it, and be sure to let us know!
Freegards, ;-)
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 18:26 UTC (Mon) by lxoliva (subscriber, #40702)
[Link]
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.
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:
- Now you probably can't even upgrade your firmware without installing non-free Microsoft Windows and a non-free firmware flashing utility, as well as providing the non-free firmware.
- Permanently-stored Flash firmware has a greater chance of being verified by a cryptographically secure signature mechanism, ensuring that it is even more difficult to make a free replacement.
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:
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.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 6:23 UTC (Tue) by coriordan (guest, #7544)
[Link]
> the options are "binary firmware" or "brick"
Those were also the options in the 80s for computers. A bunch of people decided that neither was acceptable, and now we have a third option: free software.
When we tell device manufacturers that blobs are acceptable, we get blobs. We need to say loud and clear that we won't accept blobs.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 6:51 UTC (Tue) by dlang (✭ supporter ✭, #313)
[Link]
but that's not what you or the FSF are saying.
you are saying that blobs loaded by drivers are not acceptable, but devices that contain the exact same blob in ROM or flash are acceptable (although, if the flash can be modified from the OS, the FSF may change and say it's no longer acceptable, but if it requires some special cable to plug into the board it is just as acceptable as ROM)
so something that nobody can change is accpetable, something that can be changed, but you don't have documentation on what is in it is not.
I (and many others) see the ability to load something in at startup time to be a step forward, it at least allows you to replace what was there once you develop an open replacement (and this has happened in a handful of cases)
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 11:17 UTC (Tue) by kevinm (guest, #69913)
[Link]
Exactly - to turn coriordan's example around, it would have been like saying back in the 80s: "... but if you want to burn the OS into ROM instead of loading it from disk, that'll be fine."
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 15:13 UTC (Tue) by RobSeace (subscriber, #4435)
[Link]
Indeed, and I actually had an old Tandy 1000HX that had DOS (2.something, I think)
burned into ROM, so it needed no disks (floppy or hard) to boot... Was that
somehow acceptable from FSF's POV, or actually superior to being able to load
any OS one wanted via disk (merely because the disk happened to ship with DOS
on it by default)? If so, I think they've gone completely off the deep end...
But, if not, they're being hypocritical regarding this "binary blob" situation...
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 16:40 UTC (Mon) by mpr22 (subscriber, #60784)
[Link]
Of course we should load Free software onto those devices. Until a Free software load for a given device exists, however, is it better to tell people "your device won't work" (in which case they'll likely come back and say "this free software stuff sounds like a real 'you get what you pay for' case", keep using Windows, and quite possibly generate negative PR for Linux among their friends) or "your device will work if you use this firmware blob"?
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 19:07 UTC (Mon) by ewan (subscriber, #5533)
[Link]
Sometimes it's better to say: "That device won't work because its manufacturer is actively hostile to you. Buy this device instead."
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 19:48 UTC (Mon) by kirkengaard (subscriber, #15022)
[Link]
And one in ten will respond, "I already bought this one; why are you being actively hostile to me?" The other nine will route around the problem, whether by leaving Linux or by taking a solution which the FSF has decided is haram. All ten will be more likely to ignore what you say in the future, when they ask for help. "Which is the way he wants it. Well, he gets it. And I don't like it any more than you men."
"Help" that merely says "you made the wrong choice" is barely any help at all. "Help" that says "this is the choice you should have made" may be better, but isn't likely to be appreciated any more. Help that says "You made a choice that we don't have free support for yet, but here's what to do in the meantime," is much more likely to do The Right Thing in the long run. Especially if "what to do in the meantime" includes how to help change the situation. It says we're working on the problem (including you, now that you're with us), rather than suggesting that the problem will not be solved.
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 20:04 UTC (Mon) by cesarb (subscriber, #6266)
[Link]
You put what I was trying to say on my latest comment better than I did. Thanks!
Posted Nov 8, 2010 23:14 UTC (Mon) by Zack (guest, #37335)
[Link]
>"Help" that merely says "you made the wrong choice" is barely any help at all.
No, in my opinion ewan is correct. It should be made clear that the hardware manufacturer is the hostile party that is causing problems. Whether others want to shift the blame, and even others are willing to *take* the blame is something different.
>"Help" that merely says "you made the wrong choice" is barely any help at all.
If I understand the press release correctly, it is pointing out that the current appeasement strategy is not working, but is looking to be a slippery slope instead. It looks like it's not a matter of catching up with non-free software in the kernel and its presence declining over time due to replacing it with free equivalents. Non free components are increasing faster than they're being replaced.
So yes, for now users might have more functional devices in their computers, but those who feel that a larger market share will automatically lead to more pressure on hardware manufacurers are mistaken; it will only lead to complacency and too much commercial interests getting involved to ever reach the right percentage for a "big push" to take off before you've painted yourself into a corner.
"open core" (however ill defined it might be) might be a little far fetched at this moment, but it's not an illogical outcome if this process continues. And what is any FSF good for but pointing out the obvious, only to be ignored in the name of "pragmatism" ? It doesn't make them wrong though.
This is exactly what happens now, no?
Posted Nov 8, 2010 23:59 UTC (Mon) by khim (subscriber, #9252)
[Link]
Help that says "You made a choice that we don't have free support for yet, but here's what to do in the meantime," is much more likely to do The Right Thing in the long run.
Yes, this is right thing to do (that's why I don't like FSF's idea that Debian is "unclean" since it includes non-free repository), but till now the message was "here is working thing - don't think about freedom, Ok"? I actually like the fact that firmware blobs are moving to separate repository (and in Debian they will probably marked "non-free"), but it means that people actually admitted that Linux is "open core" already - yet they don't like the consequences.
I don't see what the hoopla is all about. Yes, Linux is "open core" software. Yes, it is the problem and we should think about the ways to solve it. No, it's not the end of the world and no, it's not a reason to drop everything and switch to Linux-libre... just like the fact that Flash is proprietary is not a reason to stop visiting YouTube. But to say that this situation is "just fine"... I don't see how can you say that. If it's Ok for firmware blobs then why it's not Ok for nVidia drivers? And if it's Ok for nVidia drivers then why not for Flash? And if it's Ok for Flash then why not for ICC? And if it's Ok for ICC then why it's not Ok for MS Office?
People have different tolerance levels (witness huge amount of activity behind office suites and compare to stagnation of "free flash replacement" front), there are no absolute freedom and there are no absolute slavery - and it's just so happened that the mix usually described as "open code" includes Linux kernel - that's all.
Unclean Software
Posted Nov 9, 2010 5:15 UTC (Tue) by gmatht (guest, #58961)
[Link]
that's why I don't like FSF's idea that Debian is "unclean" since it includes non-free repository
Thats OK, Debian gets to call FSF unclean due to their use of GFDL.
If it's Ok for firmware blobs then why it's not Ok for ... MS Office?
Well, my view is that this progression never becomes "Not OK", rather it becomes increasingly less useful for software freedom the less parts of the stack can be modified. Further more, I'd consider even fully CSS software to offer more freedom than Software-as-a-Service which in turn often offers more freedom than not having any access to the software. The only point when it becomes truely "Not OK" is when it relies on misleading the user as to what rights they have, denying them the "freedom" to make an informed choice as to whether to use the software.
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 19:56 UTC (Fri) by lxoliva (subscriber, #40702)
[Link]
I agree that putting thee blame on the user for a poor choice is not helpful. After all, the user is the victim of the social problem at hand.
What I find odd (but not really) is that people who accuse us of withholding useful information quite often also vehemently oppose sharing information that would cast the non-Free Software in question: they want things to just work, without informing the user of any problems.
I (obviously) don't agree with their stance, so here's an initial draft for a message that I think would be useful to display to users when a user-friendly system encounters a device that requires non-Free firmware or drivers to work:
We have found component FOO on your computer, and we're sorry to say inform you that, as of this release, it won't work on a wholly Free Software system. Here's why:
- the component designer does not provide you with Free Software (drivers or firmware) to operate this device
- the component designer does not provide you (or us) with enough information to write Free Software to make it work
- the component designer provides you with non-Free Software to run it, and so far we have not been able to reverse engineer it to develop equivalent software that respects your freedoms, at jurisdictions where the designer's hostile reverse engineering prohibitions are not enforceable
What you can do to fix this problem:
- if you're at a shop testing the computer or the peripheral device with Live media, keep your money and your freedom: don't buy it
- if you've already purchased it, try to return it for a refund, so that the hostile vendors who designed and selected this hardware component don't get the prize at your expense
- if you can't return it, try to find a replacement for the hardware component from a friendly vendor, and purchase it so as to offer incentive to vendors who respect you as a person, user and customer
- if you can't replace it, you may want to look at community support lists and web sites, maybe there are newer developments that can make it work in freedom
- if you don't find any, write to the hardware retailer, vendor and component designer to express your dissatisfaction, request a solution for the problem and let them and others in the community know how you feel about buying their products again.
You might find recommendations that involve installing non-Free Software provided by the vendors or from third parties. Please realize that those who offer you these recommendations may even think they're helping you, but in reality they're helping the hostile vendor keep you under control. We do not recommend or support the use of non-Free Software, for we find it harmful to you, the user, and to the community as a whole. Please remember this even if you decide to follow those recommendations, and keep them in mind next time you shop for a computer or try to help others.
Now, if at the end of this message, the installer wrote if you click on Ok, we will install the non-Free Software and make the device work for you, wouldn't you qualify it as highly hypocritical? :-)
FSFLA: Linux kernel is "open core"
Posted Nov 12, 2010 23:05 UTC (Fri) by mpr22 (subscriber, #60784)
[Link]
I can tell you exactly how end users will react to that message: "tl; dr; click OK".
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 9:37 UTC (Tue) by nhippi (subscriber, #34640)
[Link]
Better wording would be:
"Warning: We only provide support for %s on as-is basis. Due to licencing terms from %s we are unable to fix any problems you may have with it."
Non-preaching yet explains *why* non-free driver is bad for you as an user.
FSFLA: Linux kernel is "open core"
Posted Nov 8, 2010 19:32 UTC (Mon) by Lionel_Debroux (subscriber, #30014)
[Link]
"your device will work if you use this firmware blob", of course.
Fortunately for all of us, there are many more distributors directed by pragmatism (making hardware work for users, which helps growing the user base of 99+%-free platforms) than distributors directed by ideology (reducing hardware support by depriving users from working firmware, thereby reducing the usability of free platforms and turning users back to the familiar nearly-100%-proprietary platforms...).
This is not to say that there _should_ be some work, somewhere, on replacing firmware blobs and proprietary drivers, though.
FSFLA: Linux kernel is "open core"
Posted Nov 9, 2010 20:33 UTC (Tue) by jebba (✭ supporter ✭, #4439)
[Link]
> So there's some code in the kernel, that's not GPLv2, but is clearly marked as such. It's in a separate folder...
When lxoliva started working on linux-libre, it *wasn't* marked as such. It was scattered all about the kernel tree sometimes in separate files, sometimes mixed in with the main driver, etc.
> ...with a separate warning that says they have separate permission to distribute those things with the Linux source.
Except there are many cases where they *don't* have permission to distribute them. See linux-2.6/firmware/WHENCE