|
|
Log in / Subscribe / Register

FSFLA: Linux kernel is "open core"

[Posted November 8, 2010 by corbet]

From:  Alexandre Oliva <lxoliva-AT-fsfla.org>
To:  FSFLA press contacts and <prensa-AT-fsfla.org>, lwn-AT-lwn.net
Subject:  [en] Linux-2.6.36-libre: turning Linux's Free Bait into Free Software
Date:  Mon, 08 Nov 2010 08:57:26 -0200
Message-ID:  <orzktk2icp.fsf@livre.localdomain>
Archive‑link:  Article

For immediate publication

Cyberspace, November 8, 2010---Linux hasn't got any Freer between the
Linux-2.6.33-libre announcement, back in March, and the present
announcement, that marks the release of Linux-2.6.36-libre.  Linux now
contains more non-Free Software, and more drivers in its Free core
that require separately distributed non-Free Software to function.
The welcome news is that Open Source advocates have joined the Free
Software Movement in denouncing the practice of Free Bait or Open
Core.
http://www.fsfla.org/anuncio/2010-03-Linux-2.6.33-libre
http://linux-libre.fsfla.org/pub/linux-libre/releases/LAT...

OSI director Simon Phipps writes "Open Core Is Bad For You", "it's a
game on software freedom", "it's a bait-and-switch, wrapping the same
old lock-in in the flag of open source and hoping you won't notice."
Bait-and-switch is a deceptive commercial practice in which one
product is announced to attract customers, to sell another instead.
http://blogs.computerworlduk.com/simon-says/2010/06/open-...
http://en.wikipedia.org/wiki/Bait_and_switch

OSI director Andrew C. Oliver adds that "Open Core puts the software
user at a disadvantage in the same way that all proprietary software
puts the user at a disadvantage", it "is merely a nick-name for a
proprietary software company", and those who imply their "proprietary
software is open source or has the advantages of open source are
engaging in deception."
http://www.opensource.org/blog/OpenCore
http://web.archive.org/web/20191017182943/http://www.groklaw.net/article.php?story=20100704191126134

This agreement between the Free Software movement Freedom campaign and
Open Source spokespeople on a matter of principle signals the
importance of denouncing this practice.  However, most of our
community is not aware that Linux has this problem.  The most popular
GNU+Linux distributions, and most of their user groups, downplay the
problem of non-Free parts of Linux.

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.
http://alampitt.typepad.com/lampitt_or_leave_it/2008/08/o...
http://blogs.the451group.com/opensource/2010/10/20/what-i...
http://www.fsf.org/blogs/rms/selling-exceptions

Sad to say, Linux fits the definition of Free Bait or Open Core.  Many
believe that Linux is Free Software or Open Source, but it isn't.
Indeed, the Linux-2.6.36 distribution published by Mr. Torvalds
contains sourceless code under such restrictive licensing terms as
"This material is licensed to you strictly for use in conjunction with
the use of COPS LocalTalk adapters", presented as a list of numbers in
the corresponding driver, and "This firmware may not be modified and
may only be used with Keyspan hardware" and "Derived from proprietary
unpublished source code, Copyright Broadcom" in the firmware
subdirectory, just to name a few examples.

Although the corresponding drivers are part of the Free and GPLed
core, the features they are meant to provide will only be available to
users that accept the non-Free code that Mr. Torvalds redistributes.
The drivers work as bait, luring users into accepting the deprivation
of essential freedoms over the corresponding non-Free Software.

Most GNU+Linux distributions follow the same practice: they include
other freedom-denying programs beyond the kernel Linux, while
continuing to associate themselves with the terms Free Software or
Open Source.

Even if they, Linux included, remove all these non-Free programs, as
long as they keep software or documentation that induces users to seek
and use non-Free programs, they're still bait.

Please join us in bringing these problems to users' attention, and
also in informing users about the various Free GNU+Linux distros and
Linux-libre, our Free version of the kernel Linux.  Available since
October 21, Linux-2.6.36-libre is Bait-free Free Software; Linux and
GNU+Linux can be de-baited and Free again, if we work together at it.
http://linux-libre.fsfla.org/
http://www.gnu.org/distros/
http://www.fsf.org/working-together/

----

== About Linux-libre

Linux-libre is a project maintained by FSFLA, that releases cleaned-up
versions of Linux, suitable for use in distributions that comply with
the Free Software Distribution Guidelines published by the GNU
project, and by users who wish to run Free versions of Linux on their
GNU systems.  The project offers cleaning-up scripts and Free sources,
binaries for some Free GNU/Linux-libre distributions, binaries to
replace with minimal changes the kernels in non-Free GNU/Linux
distributions: Freed-ebian and Freed-ora, and artwork with GNU and the
Linux-libre mascot: Freedo, the clean, Free and user-friendly
light-blue penguin.  Visit our web site and Be Free!
http://linux-libre.fsfla.org/
http://www.gnu.org/distros/


== About FSFLA

Free Software Foundation Latin America joined in 2005 the
international FSF network, previously formed by Free Software
Foundations in the United States, in Europe and in India.  These
sister organizations work in their corresponding geographies towards
promoting the same Free Software ideals and defending the same
freedoms for software users and developers, working locally but
cooperating globally.
http://www.fsfla.org/

----

Copyright 2010 FSFLA

Permission is granted to make and distribute verbatim copies of this
entire document without royalty, provided the copyright notice, the
document's official URL, and this permission notice are preserved.

Permission is also granted to make and distribute verbatim copies of
individual sections of this document worldwide without royalty
provided the copyright notice and the permission notice above are
preserved, and the document's official URL is preserved or replaced by
the individual section's official URL.

http://www.fsfla.org/anuncio/2010-11-Linux-2.6.36-libre-d...

to post comments

FSFLA: Linux kernel is "open core"

Posted Nov 8, 2010 15:08 UTC (Mon) by ledow (guest, #11753) [Link] (114 responses)

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!".

FSFLA: Linux kernel is "open core"

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 (guest, #40702) [Link] (66 responses)

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] (64 responses)

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 (guest, #40702) [Link] (58 responses)

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 (guest, #2330) [Link] (23 responses)

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] (6 responses)

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] (5 responses)

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 (guest, #40702) [Link] (4 responses)

> 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] (3 responses)

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] (2 responses)

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] (1 responses)

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 (guest, #40702) [Link] (15 responses)

> 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] (13 responses)

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 (guest, #2786) [Link] (12 responses)

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] (11 responses)

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 (guest, #40702) [Link] (10 responses)

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] (5 responses)

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 (guest, #40702) [Link] (4 responses)

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] (3 responses)

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 (guest, #40702) [Link] (2 responses)

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] (1 responses)

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 (guest, #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] (3 responses)

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 (guest, #40702) [Link] (2 responses)

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] (1 responses)

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 (guest, #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] (20 responses)

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 (guest, #40702) [Link] (19 responses)

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] (7 responses)

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 (guest, #40702) [Link] (6 responses)

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] (4 responses)

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 (guest, #40702) [Link] (3 responses)

> 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] (1 responses)

> 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 (guest, #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] (10 responses)

> 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 (guest, #40702) [Link] (9 responses)

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 (guest, #5959) [Link] (8 responses)

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 (guest, #40702) [Link] (7 responses)

> 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] (6 responses)

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 (guest, #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 (guest, #40702) [Link] (4 responses)

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] (3 responses)

*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 (guest, #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 (guest, #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] (12 responses)

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 (guest, #40702) [Link] (11 responses)

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] (9 responses)

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 (guest, #40702) [Link] (8 responses)

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 (guest, #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] (6 responses)

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 (guest, #40702) [Link] (5 responses)

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] (4 responses)

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 (guest, #40702) [Link] (2 responses)

> 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] (1 responses)

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 (guest, #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 (guest, #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] (4 responses)

"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 (guest, #43281) [Link] (3 responses)

> 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:

http://www.linuxinsider.com/story/Open-Core-Debate-The-Ba...

And in my case I got something different...

Posted Nov 9, 2010 0:24 UTC (Tue) by khim (subscriber, #9252) [Link] (2 responses)

If you want some verification for the proper use of 'open core', just google it. The first result I got there is good enough:

http://www.linuxinsider.com/story/Open-Core-Debate-The-Battle-for-a-Business-Model-66807.html?wlc=1289259531

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 (guest, #43281) [Link] (1 responses)

> 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 (guest, #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 (subscriber, #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] (44 responses)

> 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] (32 responses)

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] (16 responses)

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 (subscriber, #4257) [Link] (15 responses)

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] (14 responses)

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 (guest, #4439) [Link] (13 responses)

So this stuff in the linux-2.6.xx.tar is just fine with you? Anyone suggesting they be removed is just playing politics?

Licence: Unknown, File: korg/k1212.dsp
Licence: Unknown, File: ess/maestro3_assp_kernel.fw
Licence: Unknown, File: ess/maestro3_assp_minisrc.fw
Licence: Unknown, File: yamaha/ds1_ctrl.fw
Licence: Unknown, File: yamaha/ds1_dsp.fw
Licence: Unknown, File: yamaha/ds1e_ctrl.fw
Licence: Unknown, File: kaweth/new_code.bin
Licence: Unknown, File: kaweth/new_code_fix.bin
Licence: Unknown, File: kaweth/trigger_code.bin
Licence: Unknown, File: kaweth/trigger_code_fix.bin
Licence: Unknown, File: ttusb-budget/dspbootcode.bin
Licence: Unknown, File: intelliport2.bin
Licence: Unknown, File: vicam/firmware.fw
Licence: Unknown, File: sun/cassini.bin
Licence: Unknown, File: e100/d101m_ucode.bin
Licence: Unknown, File: e100/d101s_ucode.bin
Licence: Unknown, File: e100/d102e_ucode.bin
Licence: Unknown, File: acenic/tg1.bin
Licence: Unknown, File: acenic/tg2.bin
Licence: Unknown, File: qlogic/isp1000.bin
Licence: Unknown, File: myricom/lanai.bin

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] (1 responses)

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 (guest, #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 (subscriber, #51576) [Link] (10 responses)

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 (guest, #4439) [Link] (9 responses)

> 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 (subscriber, #51576) [Link] (8 responses)

>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 (subscriber, #4257) [Link] (7 responses)

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 (guest, #40702) [Link] (6 responses)

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 (subscriber, #4257) [Link] (5 responses)

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 (guest, #40702) [Link] (4 responses)

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 (subscriber, #4257) [Link] (3 responses)

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 (guest, #40702) [Link] (2 responses)

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 (subscriber, #4257) [Link] (1 responses)

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 (guest, #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 (guest, #40702) [Link] (10 responses)

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] (1 responses)

> 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 (guest, #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] (1 responses)

> 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 (guest, #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] (5 responses)

"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 (guest, #4439) [Link] (4 responses)

> 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 (guest, #313) [Link] (3 responses)

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 (guest, #4439) [Link]

> how can you tell the difference between a binary blob that is a large data table and a blob that is code that will be run on an embedded cpu?

Personally, I can't; I defer to lxoliva on that. He has a script that he runs against the kernel that has an accept whitelist for code that looks like a non-free blob, but is ok. See:

http://www.fsfla.org/svnwiki/selibre/linux-libre/download...

An example would be something like this: drivers/input/keyboard/atkbd.c which has a blobby looking table, but is ok.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 2:26 UTC (Wed) by lxoliva (guest, #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 (guest, #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] (3 responses)

> 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 (guest, #313) [Link] (2 responses)

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] (1 responses)

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] (10 responses)

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 (guest, #5533) [Link] (8 responses)

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 (guest, #15022) [Link] (6 responses)

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!

For some reason, all this discussion reminds me of this webcomic: http://ninapaley.com/mimiandeunice/2010/08/11/advice/.

FSFLA: Linux kernel is "open core"

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] (1 responses)

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 (subscriber, #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 (guest, #40702) [Link] (1 responses)

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 (guest, #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 (guest, #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

Quotation does not imply endorsement

Posted Nov 8, 2010 15:17 UTC (Mon) by webmink (guest, #47180) [Link]

For clarity, I was not consulted about the use of a quotation of mine by FSFLA in their press release.

FSFLA: Linux kernel is "open core"

Posted Nov 8, 2010 15:54 UTC (Mon) by lxoliva (guest, #40702) [Link] (1 responses)

Corbet, it was not an attempt to tap into recent discussions about Open Core because the main argument was drafted before them. There's even an article published in Portuguese with it back in September.

If anything, recent discussions made it more confusing because there's ongoing distortion of the meaning of Open Core, away from the original definition we drew upon.

Here's hope it didn't drift too much away, and that people won't make incorrect assumptions about the meaning we cite and use.

FSFLA: Linux kernel is "open core"

Posted Nov 8, 2010 16:19 UTC (Mon) by cesarb (subscriber, #6266) [Link]

I dislike the term "Open Core" because whenever I see it I always think of OpenCores. Which is, as far as I know, the older term (from 1999 according to the FAQ). It can get really confusing: when you say "open core", are you talking about a freely licensed IP core (a good thing), or what is described above (a not-so-good thing)? My first reaction is always "good thing" (since I knew of OpenCores from way before I first heard that new usage).

FSFLA: Linux kernel is "open core"

Posted Nov 8, 2010 20:24 UTC (Mon) by Fats (guest, #14882) [Link]

If this press release has achieved anything it is me being a stronger renegade of the FSF church. Come on ! Playing language tricks to mark Linux as Open Core ?
How low can they go.

FSFLA: Linux kernel is "open core"

Posted Nov 8, 2010 21:00 UTC (Mon) by bojan (subscriber, #14302) [Link] (2 responses)

Easily fixed. For instance, on Fedora, just do:

yum install hurd

Followed by (after the reboot into Hurd):

yum remove kernel linux-firmware

;-)

FSFLA: Linux kernel is "open core"

Posted Nov 8, 2010 23:41 UTC (Mon) by tzafrir (subscriber, #11501) [Link] (1 responses)

I believe you read the whole message wrong. It's not about firmwares. There's a more fundemental problem. They want Linus to remove of the first paragraph in the COPYING file of the linux distribution.

I must agree with them that the name "open core" is a good description of the situation here.
</troll>

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 3:54 UTC (Tue) by bojan (subscriber, #14302) [Link]

Touché :-)

FSFLA: Linux kernel is "open core"

Posted Nov 8, 2010 23:00 UTC (Mon) by jebba (guest, #4439) [Link] (35 responses)

Interesting timing for this. Alexandre has been updating the linux-libre kernel regularily for a couple years or so, matching every upstream (& -stable, -rc) release.

On the LKML side, David Woodhouse has been plugging away moving firmware out of "random" locations in the kernel into a firmware/ subdirectory and using a common method for the firmware to be loaded (instead of each driver making up its own way). As I understand it, this whole firmware/ directory is likely moving out around 2.6.38, so all the non-free binary blobs that are currently in the kernel will be gone. Well, gone to a file outside of linux-2.6.xx.tar. RSN, the Linus tree will be free of non-free software. :)

Yup - this will finally clear any doubt...

Posted Nov 8, 2010 23:38 UTC (Mon) by khim (subscriber, #9252) [Link] (21 responses)

As I understand it, this whole firmware/ directory is likely moving out around 2.6.38, so all the non-free binary blobs that are currently in the kernel will be gone.

What? Will they remove it?

Well, gone to a file outside of linux-2.6.xx.tar. RSN, the Linus tree will be free of non-free software. :)

Ah. So this will finally clear any and all doubts. As was pointed out by authors of the article

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.

And after this big cleanup we'll have two packages: Linus's tree (which contains only free software) and tarball with "premium features" (and the first tarball will conveniently include hooks for the second one which are useless without it). Classic, textbook execution of open core strategy!

If anything the article is a little early: today Linux kernel mixes free software and proprietary software so it's not obvious that it's open core, after this cleanup it'll be quite easy to see.

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 0:11 UTC (Tue) by bojan (subscriber, #14302) [Link] (16 responses)

> Classic, textbook execution of open core strategy!

Feel free to not download or strip the non-free bits. Which, of course, will turn a whole lot of your hardware into bricks.

Does anyone seriously believe that Linus and other kernel developers wouldn't prefer NOT to ship binary blobs, if they could? Most of them spent their life releasing their source to general public. What possible motivation would they have for "bait-and-switch" here? Money? Fame? Power? Please.

I think members of FSFLA should do themselves and all of us a favour by rewriting all those binary blobs as free software. Yeah, I know - not as easy as writing a trashy press release, bashing folks that work hard on REAL problems every day.

Well, this is better...

Posted Nov 9, 2010 0:34 UTC (Tue) by khim (subscriber, #9252) [Link] (2 responses)

Does anyone seriously believe that Linus and other kernel developers wouldn't prefer NOT to ship binary blobs, if they could? Most of them spent their life releasing their source to general public. What possible motivation would they have for "bait-and-switch" here? Money? Fame? Power? Please.

Well, the offenders here are usually hardware vendors and I'm not sure what drives them, but I suspect all three factors play a role. But the linux developers condone this situation so even if they are not actual felons they certainly can be counted as participators.

I think members of FSFLA should do themselves and all of us a favour by rewriting all those binary blobs as free software. Yeah, I know - not as easy as writing a trashy press release, bashing folks that work hard on REAL problems every day.

That it's not as easy is not a problem - harder things were done. That it's not as effective is a problem: if there are thousands of people who are contributing to the problem and only few who are fixing it then it'll never be fixed. Non free components are increasing faster than they're being replaced as was corectly pointed out...

Well, this is better...

Posted Nov 9, 2010 1:00 UTC (Tue) by dlang (guest, #313) [Link]

many of the core linux developers are very clear that they are not worried aobut firmware blobs.

I would be very surprised if Linus made a change that caused the tarballs that he ships to be unusuable without some other tarball. He is willing to have the firmware reorganized so that a distro can easily remove it if they want to do so.

Well, this is better...

Posted Nov 9, 2010 1:17 UTC (Tue) by bojan (subscriber, #14302) [Link]

> Well, the offenders here are usually hardware vendors and I'm not sure what drives them, but I suspect all three factors play a role. But the linux developers condone this situation so even if they are not actual felons they certainly can be counted as participators.

Felons? Offenders? Please. What crime has been committed?

Really nice that FSFLA is dragging Linus' name through the mud for a problem he and other developers cannot fix all by themselves (not even close). All the while Linus and Co are contributing ALL of their work to free software. Talking about hypocrisy...

> That it's not as easy is not a problem - harder things were done.

Yeah, and that's why I run Hurd.

If FSFLA want do something for REAL, they should then talk to the hardware manufacturers to free those firmwares. Or reverse engineer it. Or whatever else that WORKS.

Whinging about Linus being the bad guy just makes them look like spoilt kids that didn't like the latest toy they received.

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 0:48 UTC (Tue) by gus3 (guest, #61103) [Link] (8 responses)

As soon as they get corporate permission, or the legal right, to reverse-engineer the devices, the firmware can be disassembled and then modified. And then we can also reverse-engineer nVidia's 3D acceleration.

Wait a minute. Didn't Linus rail against nVidia's using GPL'd API's a few years ago? Rather than outright banning the "nvidia" module, the kernel team added the "tainted" kernel flag, so that kernel crashes could be flagged as "unsupported stuff here".

How is the Intel microcode any different?

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 1:28 UTC (Tue) by bojan (subscriber, #14302) [Link] (7 responses)

> How is the Intel microcode any different?

Kernel doesn't link to it?

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 3:21 UTC (Tue) by gus3 (guest, #61103) [Link] (6 responses)

In the sense of the kernel object code in core, yes, that's true.

In the sense of affecting the behavior of the CPU, the only difference I see is that object code is external, where microcode is internal to the CPU. You can verify that the object code under the GPL doesn't run counter to your intentions, and you can also improve it or tailor it to your purposes. Why can't you do the same with microcode? It is also executable, just on a different level.

I'm not necessarily arguing for opening up Intel's microcode format (although dang, that would be sweet for my curious mind). I'm simply saying Linus is a bit two-faced for arguing against nVidia's proprietary module, but including Intel's microcode.

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 3:48 UTC (Tue) by bojan (subscriber, #14302) [Link]

> I'm simply saying Linus is a bit two-faced for arguing against nVidia's proprietary module, but including Intel's microcode.

That is one interpretation.

Mine is that because Linus writes Linux (and not Intel microcode) and nVidia drivers are linked into the kernel, the traces of such crashed kernel become next to useless, because nobody can see the source of such linked-in modules (and they could be causing the crash). Ergo, nVidia and others were put on the "tainted" list, so that users don't expect help if they come to Linus with a "tainted" trace.

Sure, if Intel provides dodgy microcode, your machine will be just as screwed. But at least this is not something Linus is supposed to support in any way, shape or form, because it really is outside the kernel.

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 6:43 UTC (Tue) by dlang (guest, #313) [Link] (4 responses)

you may not be aware that when the kernel loads, it includes microcode that it loads into the CPU. the is just the same as loading firmware into an external device.

however, in the nvidia driver situation, the code is being loaded into kernel space and can mess with other, seemingly unrelated things (if by no other way thatn by not following all the locking needed to make access to something safe)

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 13:47 UTC (Tue) by lxoliva (guest, #40702) [Link] (3 responses)

The microcode is actually not part of the kernel. The kernel supports loading it, but the actual microcode is separate.

As for tainting, I really don't understand why a driver that has access to DMA, system memory, buses and all on the primary CPU taints the kernel, but a blob that runs on a separate CPU and has access to DMA, system memory, buses and all doesn't taint it.

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 14:11 UTC (Tue) by hmh (subscriber, #3838) [Link]

You'd need to taint anything that is SMM-capable.

You'd also need to taint anything that lacks an IOMMU configured in such a way that NO device can access non-exclusive memory, and where a device cannot attack other devices in the same bus.

I.e. it would be useless.

Yup - this will finally clear any doubt...

Posted Nov 10, 2010 7:28 UTC (Wed) by Los__D (guest, #15263) [Link] (1 responses)

Then I guess you'd taint any device that we don't have complete HDLs for?

Yup - this will finally clear any doubt...

Posted Nov 10, 2010 7:34 UTC (Wed) by dlang (guest, #313) [Link]

don't forget the requirement for the installation tools for the software, so that would mean that they would not only have to provide you with the HDL for the chips, they would also have to provide you with the ability to produce a modified chip and put it on the board.

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 3:06 UTC (Tue) by jebba (guest, #4439) [Link] (3 responses)

> Feel free to not download or strip the non-free bits.

Which is exactly what the announcement is--a version you can download with non-free bits removed.

> Which, of course, will turn a whole lot of your hardware into bricks.

That is incorrect, actually. Most devices don't draw from non-free software in the kernel. The linux-libre kernel will run 100% fine on many systems. Wifi is the big exception--often (but not always) that requires uploading non-free firmware.

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 3:11 UTC (Tue) by bojan (subscriber, #14302) [Link] (2 responses)

> Wifi is the big exception--often (but not always) that requires uploading non-free firmware.

Who needs it anyway, eh? It's not like there are networks and apps out there you can connect to... :-)

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 5:09 UTC (Tue) by jebba (guest, #4439) [Link] (1 responses)

> Who needs it anyway, eh? It's not like there are networks and apps out there you can connect to... :-)

...

> But at least this is not something Linus is supposed to support in any way, shape or form, because it really is outside the kernel.

Except that these things are *in* the kernel (tarball) at the moment, in some cases. It seems most Intel wifi firmware is outside (in fedora, for example, it's a separate RPM), but some wifi blobs are in the kernel tarball proper. Do you think the Intel firmware should be moved *in*? If not, why not have the other non-free blobs moved *out*? At least, for starters....

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 7:00 UTC (Tue) by bojan (subscriber, #14302) [Link]

Outside the kernel in the sense that it doesn't really run as part of it. Same as other firmware. Kernel just treats it as data that needs to be pushed somewhere.

I'm guessing the distribution together with the rest of the kernel source is just a convenience thing.

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 15:11 UTC (Tue) by dmk (guest, #50141) [Link]

I think you are right. So, I now think open core is good. Thx for enlighten me.

Yup - this will finally clear any doubt...

Posted Nov 9, 2010 21:07 UTC (Tue) by dwmw2 (subscriber, #2063) [Link] (2 responses)

Yes, we agreed at the Kernel Summit last week that we're going to remove the legacy firmware/ directory from the kernel. It's just confusing now, since most distributions have already stopped shipping its contents and are instead shipping the separate linux-firmware.git repository which contains a lot more firmware for different devices.

I was tempted to send a patch the same day we agreed it, but then decided to wait for 2.8.38 — I want to make the transition slightly easier for those who were using CONFIG_FIRMWARE_IN_KERNEL, by doing something that'll look for MODULE_FIRMWARE tags in the drivers which are built into the kernel, and try to pull those firmware images in automatically.

Yup - this will finally clear any doubt...

Posted Nov 10, 2010 1:42 UTC (Wed) by dmarti (subscriber, #11625) [Link] (1 responses)

Is anyone doing any security audits on that firmware, or are all hardware vendors trusted with DMA access to everywhere? Just wondering.

Yup - this will finally clear any doubt...

Posted Nov 10, 2010 1:47 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]

This is what we have an IOMMU for.

FSFLA: Linux kernel is "open core"

Posted Nov 8, 2010 23:43 UTC (Mon) by BenHutchings (subscriber, #37955) [Link] (12 responses)

Nope, there are still a few blobs outside of firmware.

But this whole argument by the linux-libre folks is nonsense. Devices are no more free if they load their proprietary code from flash rather than relying on the driver to copy it from the host. Further, if the driver loads the code that is likely to make it easier to reverse-engineer and replace.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 2:43 UTC (Tue) by jebba (guest, #4439) [Link] (2 responses)

I didn't see him arguing that.

Do you think it's good that the Linus tarball is full of things like:

"Licence: Unknown
Found in hex form in kernel source."

There's a pile of that, for starters... What about all the other odd ball licenses that are floating around in there? Should they remain?

Ignoring the "open core" bit

Posted Nov 9, 2010 11:15 UTC (Tue) by pboddie (guest, #50784) [Link] (1 responses)

Agreed, the "open core" rhetoric is misplaced, but the actual point of the message remains. If anyone were to submit stuff for inclusion in Debian or Fedora with "licence unknown", they'd be told to go and fix it.

Ignoring the "open core" bit

Posted Nov 9, 2010 16:01 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]

Yes, that's exactly why Debian doesn't include those.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 9:35 UTC (Tue) by job (guest, #670) [Link]

They may well be. Please read my comment above.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 10:26 UTC (Tue) by ballombe (subscriber, #9523) [Link]

That is not clear. The laws governing hardware and software are very different, but in general laws about software are more restrictive that laws about hardware. It is much easier to sell a firmware with a very restrictive license (that e.g. prevent it being resold) than a piece of hardware. You can also more easily disclaim warranty on firmware than on hardware.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 16:02 UTC (Tue) by BenHutchings (subscriber, #37955) [Link] (6 responses)

A somewhat outdated summary of those blobs can be found at http://wiki.debian.org/KernelFirmwareLicensing

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 17:57 UTC (Tue) by jebba (guest, #4439) [Link] (5 responses)

This is probably the most recent:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 19:29 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] (4 responses)

That's for the blobs in the firmware directory; I was pointing out the blobs outside it.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 21:16 UTC (Thu) by jebba (guest, #4439) [Link] (3 responses)

Ah, interesting. I wonder why things like this didn't get moved to the firmware/ directory. From:
linux-2.6/drivers/net/appletalk/cops_ffdrv.h 

/*
 *      The firmware this driver downloads into the Localtalk card is a
 *      separate program and is not GPL'd source code, even though the Linux
 *      side driver and the routine that loads this data into the card are.
 *      
 *      It is taken from the COPS SDK and is under the following license
 *
 *      This material is licensed to you strictly for use in conjunction with
 *      the use of COPS LocalTalk adapters.

FSFLA: Linux kernel is "open core"

Posted Nov 13, 2010 1:30 UTC (Sat) by dwmw2 (subscriber, #2063) [Link] (2 responses)

That particular example didn't get moved just because we didn't notice it.

AFAICT the only person doing regular sweeps of the kernel to check for such things is Alexandre, and he's completely jumped the shark so most people who are actually doing useful work on this stuff have started ignoring him.

S'probably worth going through the current deblob script and working out if there are more examples like the one you provided above; thanks for that.

FSFLA: Linux kernel is "open core"

Posted Nov 15, 2010 19:29 UTC (Mon) by wookey (guest, #5501) [Link] (1 responses)

What does 'jumped the shark' mean?

FSFLA: Linux kernel is "open core"

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

From Wikipedia:

Jumping the shark is an idiom used to denote the point in a television program's history where the plot spins off into absurd storylines or unlikely characterizations. These changes were often the result of efforts to revive interest in a show whose audience had begun to decline.

(The above text is available under the Creative Commons Attribution Share-Alike licence.)

While I do find some of the FSFLA's publicity material surrounding Linux-libre to be of dubious quality and appropriateness, I am less than convinced that "jumping the shark" is applicable here.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 7:04 UTC (Tue) by rilder (guest, #59804) [Link] (3 responses)

AFAIK all the firmware blob in kernel tree are being moved to a separate firmware tree which should alleviate fears of a proprietary kernel. Am I right ?

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 13:42 UTC (Tue) by hmh (subscriber, #3838) [Link] (2 responses)

No. This is not a technical wording bikeshed paint color party.

If a driver requires firmware to get the device work, and that firmware is not compliant to the FSF's definition of free software[1], it is considered "bait". Whether the firmware is distributed in a separate place makes absolutely no difference whatsoever.

FSFLA is doing their job (whether they could have worded that text better or not is up to discussion, I suppose). They have their reasons, and anyone who knows the embedded device market, knows damn well that we need as much pressure as we possible can gather to keep the damage contained.

It is not in their job description to gather for the immediate needs of users, or anything else like that. Which is quite correct, the usefulness of FSF-like bodies is always in the long-term picture. We have other bodies taking care of short-term compromises (sometimes to the detriment of long-term benefits, and sometimes as a useful counterpoint to keep the balance).

[1] I prefer Debian's, so I tend to separate the various definitions of what is free software.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 17:06 UTC (Tue) by foom (subscriber, #14868) [Link] (1 responses)

> Whether the firmware is distributed in a separate place makes absolutely no difference whatsoever.

Unless of course the separate place is non-volatile memory that comes with the hardware. Then it's perfectly okay.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 20:11 UTC (Tue) by hmh (subscriber, #3838) [Link]

I don't know what the FSFLA and FSF thinks about this, but IMO what should make a difference is whether it is field-upgradeable or not.

Being an EE, I also have other criteria for field-upgradeable units, as I am perfectly aware that in some cases, open firmware would be usable only if almost all of the inner working of the hardware was documented to the public in the first place, at which point we're talking about open hardware.

Personally, I have no issues with self-contained non-free firmware as long as the API to interface with it is fully documented, and support channels are in place to get fixes for that firmware for at least 5 years after the product is available to the public. I don't expect the FSF to agree with this one...

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 12:35 UTC (Tue) by dion (guest, #2764) [Link] (4 responses)

How is a blob of firmware in the kernel tree much different from a blob of firmware in a FLASH PROM on a board?

The answer is: One takes up space on your hard disk in stead of making the device more expensive.

Maybe the FSF should concentrate on showing the world how Free software beats everything else by keeping gcc relevant in stead of alienating and confusing users and developers the biggest GPLed piece of code...

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 13:39 UTC (Tue) by anselm (subscriber, #2796) [Link] (1 responses)

Maybe the FSF should concentrate on showing the world how Free software beats everything else by keeping gcc relevant in stead of alienating and confusing users and developers the biggest GPLed piece of code...

It is probably just as well to remember that the FSFLA (the people behind the current PR stunt) and the FSF (the people in charge of GCC) have nothing to do with each other, officially.

As far as I can see the FSFLA, unlike the FSF, does not seem to release free software that (a) is of general interest, and (b) they have written themselves.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 18:46 UTC (Tue) by jebba (guest, #4439) [Link]

Uh, search for Alexandre Oliva:
http://gcc.gnu.org/onlinedocs/gcc/Contributors.html

There's points like:
* GCC contributor since early 1990s
* Compiler engineer at Red Hat since 2000
* Co-maintainer of various GCC ports and build infrastructure
* etc...

A few seem to be dissing him/FSFLA without really knowing anything (surprise...).

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 18:16 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

I think you'l find Alexandre's doing that too (and has been for many years). But that's not done wearing his FSFLA hat, as far as I know.

Isn't he allowed to do more than one thing at once? (Even if one of them *is* quixotic bordering on useless?)

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 2:50 UTC (Wed) by lxoliva (guest, #40702) [Link]

Indeed, the FSFs are political organizations, so they tend to get into software development only when there's a political reason to do so. That was the case when the FSF was started, with the initial (now broader) purpose of raising funds for the GNU project, and this is the case for FSFLA when we undertake say freeing Linux or the income tax program that Brazilian citizens are required to use to prepare their tax returns. Other than that, these organizations support other priority Free Software projects (the FSF has a list of these), but developing software is not where the focus is in defending software users' and developers' rights and freedoms any more.

Professionally, I still devote a significant amount of time to developing GNU software, which I'm happy to be paid by my employer to do. Personally, I volunteered time to maintain various GNU and non-GNU Free Software projects for some 15 years before I got involved with FSFLA, but now most of my spare time is devoted to political activism for software freedom. I consider that fighting for freedom and training the next generations to care for it is far more important and more valuable, in the long term, than most software development tasks I'd be qualified to undertake.

What is FSFLA doing about it?

Posted Nov 9, 2010 12:37 UTC (Tue) by buchanmilne (guest, #42315) [Link] (1 responses)

If FSFLA can't point to any contributions to open-source replacements for the pieces they are removing from the kernel, I believe this is pure sensationalist FUD.

How is kernel-libre any better, for users who already have hardware that requires non-free drivers or firmware? It isn't. Whereas there are drivers distributed with the kernel that *are* free implementations of drivers where previously only proprietary drivers were available.

Does FSFLA provide toolchains for common hardware platforms? Example source code? For how many devices have they written free firmwares? Do you even compile the ath9k firmware from source, or are you distributing pre-built binaries, or none?

In removing non-free firmware, FSFLA themselves are actually distributing an open-core distribution, because there are other members of the "community" who provide the "premium" non-free firmware. So, I think they should either stop using the term, or provide free replacements.

Do I support hardware with Free firmware? Yes, I bought an ath9k card over other cards due to open driver+open firmware. Will I assist users, friends, family in running a mostly-free-software environment with proprietary firmware or drivers? Yes, because a greater demand for free software support is *also* important to device manufacturers.

What is going to be more effective at getting better open-source support:
-a tiny minority (0.01% of entire market) insisting on 100% free (BIOS, firmware etc.)
-a much larger minority (>1% of entire market) asking for free drivers, and a community who have made it *easier* for vendors to ship free firmware than propietary firmware.

I see you wanting to make it difficult to ship proprietary firmware, what are you doing to make it easier to ship free firmware?

What is FSFLA doing about it?

Posted Nov 10, 2010 18:15 UTC (Wed) by alankila (guest, #47141) [Link]

I must say I have personally had almost nothing but trouble with my ath9k. With ubuntu 10.10, nearly 2 years after I bought the card, I can finally use this device.

Yeah, this open sourcing everything seems to make everything great instantly.

Oh. I nearly forgot to mention that this n-hardware card still transmits no faster than 1-2 MB/s despite Windows driver has worked at full 15 MB/s speed from day one.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 14:24 UTC (Tue) by dmaxwell (guest, #14010) [Link] (91 responses)

How and why are devices that use uploadable firmware the Linux devs' fault? The only thing ANY kernel can do is talk to a device's interface. If the closed firmware provides an open interface that a FOSS driver can be written for and obtaining that firmware isn't some sort of legal PITA then I'm having a hard time seeing what the problem is. To be sure, it would be better if the device was running documented and open firmware but isn't the Linux devs' fault and it isn't the fault of anyone else who is writing kernels. I suppose all the BSD kernels that implement drivers for these devices are likewise "baitware"?

As a user, I prefer having a wider choice than "all or none". In the past, firmware wasn't easily field upgradeable and kernels just used a straightforward driver. But now the firmware is either uploaded to the device first or the device can just accept firmware upgrades. Now I must forswear using the same open kernel driver on ideological grounds because a piece of code that has almost always been closed anyway is replaceable. Er....that doesn't strike me as a terribly productive thing to do. I'd rather see the FSFLA doing the reverse engineering and creating the open firmware rather than throwing brickbats at a project that doesn't have that responsibility.

The only sane thing kernel devs can do is cope with it. Having a consistent place and method for uploading firmwares to devices is a good way to do it. From the kernel's POV it matters little whether the firmware is open or not. All it can do is talk to the interface it provides.

Now binary blobs that execute inside the kernel are another matter.....

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 18:01 UTC (Tue) by jebba (guest, #4439) [Link] (71 responses)

> I'd rather see the FSFLA doing the reverse engineering and creating the open firmware rather than throwing brickbats at a project that doesn't have that responsibility.
>
> The only sane thing kernel devs can do is cope with it. Having a consistent place and method for uploading firmwares to devices is a good way to do it.

Did you know that it was from lxoliva/FSFLA pushing this that lead to the reorganization of firmware in the kernel? It originated after some flamefest on fedora-devel (just like this) a couple/few years back.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 18:28 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (70 responses)

I will credit David Woodhouse for driving the actual effort however. It is a far more effective method of accomplishing the task.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 18:31 UTC (Tue) by jebba (guest, #4439) [Link] (69 responses)

> I will credit David Woodhouse for driving the actual effort however. It is a far more effective method of accomplishing the task.

I did credit him above, btw. Regardless, -libre stoked the fire to get things rolling.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 18:58 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (68 responses)

I don't think so. If you talk to David Woodhouse, you will find that his motivations are quite different and I am pretty disappointed that people with the technical expertise to accomplish it are refusing to engage in it.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 19:16 UTC (Tue) by jebba (guest, #4439) [Link] (3 responses)

Ah, I understand he's coming at it from a very different perspective than Oliva and I personally think it's fantastic what both Woodhouse & Oliva have done. To me it seems obvious that non-free software should be moved out of linux-2.6.x.tar. Why ship stuff with various odd ball licenses or even in many cases *NO* license? For plenty of files, it's not even known if they can be legally shipped. Clearly, they should be removed.

Lots of time (see above), the discussion gets lost around where the fine line is between software/hardware, if stuff is burned into the eeprom, etc., completely forgetting about the actual code in the kernel. Oliva actually does the work to show what a fully GPL'd kernel looks like, which highlights the differences.

Really only Woodhouse could answer whether it was during/after the -libre fedora-devel discussion that he decided to work on it, or whether it was an earlier project. I just saw the work commence publicly at that point.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 19:36 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

You can always ask the person instead of guessing :-)

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 21:29 UTC (Tue) by dwmw2 (subscriber, #2063) [Link]

"You can always ask the person instead of guessing :-)"
Anyone who's ever had the misfortune of trying to manage me will tell you that it's hard to tell what really ever provokes me into actually working on a given task.

I don't really remember the details, but I think that Alex came to FESCo (during my tenure) with his totally impractical 'kernel-libre' package, wanting to ship a crippled kernel as a Fedora package. We told him "no, do it sensibly", but he didn't seem to want to, so eventually I got bored and did it myself.

So yeah, if you want to credit Alex with pissing me off enough that I eventually did it, that seems fair.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 21:38 UTC (Tue) by jebba (guest, #4439) [Link]

I did email him, but perhaps it's moot after finding this:

http://lists.fedoraproject.org/pipermail/devel/2008-March...

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 19:39 UTC (Tue) by lxoliva (guest, #40702) [Link] (63 responses)

Yeah, his motivations and his goals are completely different. He's not trying to address the problem that the drivers that request non-Free firmware are bait.

FWIW, I recently sent Linus private email offering to help address that problem, with a plan that would still allow those who want to see the bait (and presumably take the poison) to do so. So far, no response.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 20:01 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (61 responses)

You have been adamantly ignoring the point that his work has practical benefits and is a help to your goals as well. Rhetoric in a bad press release is hardly going to help anything at all. Just some stupid flame war about firmware and we are back to square one. Continue.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 20:54 UTC (Tue) by lxoliva (guest, #40702) [Link] (60 responses)

If you think it helps my goals, you don't understand my goals. I've already explained at length when the issue first came up why the location of the firmware is irrelevant, as long as the kernel still points users at it. The present announcement also covers this topic.

I'm not concerned with the legality of the situation. That's what dwmw2 is concerned with. I'm concerned with the problem of inducing users to give up their freedoms.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 21:44 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (58 responses)

"If you think it helps my goals, you don't understand my goals"

This is an easy claim and one I hear very often but it just isn't true. It is so blatantly obvious why. After the firmware has been split up from the Linux kernel and move off into a separate tarball as it is going to happen soon(http://lwn.net/Articles/414275/), what would be the purpose of linux-libre patchset be? If you even agree that it would reduce the patchset, then you must concede that it does help your goals by reducing the amount of work you are doing.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 0:29 UTC (Wed) by lxoliva (guest, #40702) [Link] (57 responses)

> After the firmware has been split up from the Linux kernel and move off into a separate tarball as it is going to happen soon(http://lwn.net/Articles/414275/), what would be the purpose of linux-libre patchset be?

The answer is right there in the announcement:

> Even if they, Linux included, remove all these non-Free programs, as long as they keep software or documentation that induces users to seek and use non-Free programs, they're still bait.

How do you think we turn request_firmware("blobname"...) into bait-free Free Software? What part of “the location of the blob is irrelevant” (upthread) is so hard to understand? Even the earlier announcement said:

> we accumulated thousands of patterns to recognize blobs, sequences that look like blobs but that aren't, requests for non-Free firmware external to Linux, and documentation that induces users to install it

and then went to great lengths to explain a plan to *retain* the ability to request_firmware while removing the inducement problem. Linux-libre won't serve its purpose, of offering a kernel that satisfies the FSDG, without removing this problem. Simply pushing the blobs out isn't enough to comply with FSDG.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 1:37 UTC (Wed) by foom (subscriber, #14868) [Link]

> Simply pushing the blobs out isn't enough to comply with FSDG.

Unless you push them out into non-volatile memory in the hardware?

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 2:20 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (42 responses)

It is really quite hard to understand because separating out firmware makes it easy for users to exclude it and you don't consider it a win in any way. That's puzzling and I don't buy that.

After the firmware is moved into a separate tarball, Linux kernel is fully Free software by FSF standards and at that point, I don't see much of a benefit to linux-libre. Users will have a clear option to install or exclude the firmware as per their needs and that's fine by me. I suppose you are going to continue patching all the firmware requests but you cannot deny that it will reduce the effort and has benefited your goals by doing so. David Woodhouse deserves the credit for his effort.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 3:06 UTC (Wed) by lxoliva (guest, #40702) [Link] (41 responses)

Yeah, he deserves credit for making more work for me, and for making the Linux-libre changes larger.

I didn't save Linux-libre patch files from before 2.6.27, when the latest generation of deblobbing was adopted. By then, the conversion to request_firmware had just started, but see how the Linux-libre patch files grew from release to release:

$ wc -l linux-2.6.??-libre*.patch
122075 linux-2.6.27-libre4.patch
164985 linux-2.6.28-libre4.patch
185328 linux-2.6.29-libre2.patch
176353 linux-2.6.30-libre2.patch
196246 linux-2.6.31-libre3.patch
153416 linux-2.6.32-libre1.patch
174534 linux-2.6.33-libre.patch
168578 linux-2.6.34-libre1.patch
170201 linux-2.6.35-libre2.patch
170152 linux-2.6.36-libre.patch

You're welcome to try to find any other metric that shows improvement. The tarballs, deblobbing scripts, and xdeltas are all publicly available.

Not an improvement, not even easier, for sure. Earlier, I could run something such as:

for each of a list of files
replace sequences of numbers that aren't false positives with /*DEBLOBBED*/

Now, I have to track files containing request_firmware calls, figure out where the blob name comes from (quite often headers or separate files), determine whether the requested file is Free or non-Free, add a blob pattern to deblob-check if the file name refers to a non-Free file, disable (conditionally) the request_firmware call, and run the files containing blob names through the deblobber. Rins and repeat every time the filenames change or the way they're computed changes (more often than you'd think) adjusting patterns and deblobbing requests accordingly. Oh, and until the blobs are finally removed, I have to clean them up, as well as the WHENCE file.

You honestly think that not having to clean up the blob files and the WHENCE file would make things easier than they were before?

Again, the goal is not just to be Free Software, it's to be bait-free, so as to satisfy the Free Software Distribution Guidelines, so that the recommended distros don't recommend non-Free Software. It's clear you don't care about that, but your disregard for the difference doesn't turn my goals into yours, or dwmw2's.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 7:33 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

"Again, the goal is not just to be Free Software, it's to be bait-free"

Which seems to be moving the goal post really. Its kind of funny to say that a fully Free kernel wouldn't satisfy the Free system distribution guidelines. Yes, at that point, I wouldn't care anymore.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 11:04 UTC (Wed) by dwmw2 (subscriber, #2063) [Link] (39 responses)

I find it amusing that you do it this way, when it would be so simple to patch the userspace side instead, and make it check the firmware licence using the WHENCE file. (That'll actually get easier soon, when I replace the WHENCE file with something less free-form, probably based on the proposed Debian Copyright File Format).

That way, you could trivially configure the system to refuse to load the non-free firmware files. And as and when replacement firmware becomes available (as with b43) you can allow it to be loaded because you know its licence is acceptable to you. Assuming that a given filename will always have a given licence is simply wrong.

By doing it that way, you also avoid crippling those drivers which have optional support for upgrading the firmware which is in flash on the hardware, but which normally just use the firmware from flash.(Which, despite it being non-free, you seem to be quite happy about? Just so I understand… firmware in flash: OK, firmware loaded from host OS so that we can see it and folks like the OpenFWWF team can replace it: not OK, firmware in flash which is optionally reflashable from the kernel: also not OK?)

Even if you want your users to believe that we were always at war with Eastasia, and that the kernel has never had support for those devices with non-free firmware, I suspect you could achieve your patching a lot more easily than your existing method. You could probably just have a whitelist of those (lamentably few) drivers which use firmware images that are free, and then force-disable everything else which depends on CONFIG_FW_LOADER.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 19:21 UTC (Wed) by lxoliva (guest, #40702) [Link] (38 responses)

Can it be done in userspace? Yes, if the goal was to make just GNU+Linux compliant with FSDG. But if you take one component from a FSDG system and install it on another system, that one component shouldn't start luring users into a trap. So each component has to be FSDG-compliant individually.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 0:42 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] (37 responses)

The kernel neither knows nor cares about the licence of:
  • The ACPI AML code it finds in the BIOS
  • The SMI code in the BIOS which provides various system features
  • The firmware resident in flash on peripheral devices
  • The firmware loaded by the request_firmware() mechanism
It is completely ambivalent to all these things. I really have no sympathy for you when you insist that the kernel shouldn't ask for a firmware file which doesn't currently have a free implementation — when licensing isn't within the scope of the kernel, and that can be so easily handled by the firmware-loading mechanism in userspace.

I find it particularly unimpressive that your religious fervour renders that approach unacceptable to you, while you are simultaneously content to completely ignore three out of the four classes of non-free software mentioned above. (There may well be more examples; those were just off the top of my head.)

Are you planning to remove the ACPI AML interpreter, because it only ever runs non-free code? And often that code just traps into SMI, etc.?

Are you planning to remove the drivers which depend on an in-flash firmware on the devices they support? It's just as non-free if it's in flash. Arguably more non-free; isn't that what the 'Tivoisation' debate is all about? Although perhaps it isn't about Tivoisation, because while you accept device drivers that rely on in-flash firmware, you do seem to rip them out if they grow an option to replace that in-flash firmware with an updated version.

So of the devices which require firmware, it's only the Tivoised devices with non-updateable flash which you are content to support?

Your whole position seems massively inconsistent and impractical.

There are real technical reasons for wanting to separate the loadable firmware from the kernel source code and use request_firmware() to obtain it. There are good reasons to have those firmware files available in a separate repository from the kernel source, too. And certainly there are good reasons to have the licensing information clearly available for each, and I can understand your desire to avoid using (or distributing) those parts which are non-free. But that's the limit of what I'm trying to achieve, personally.

I'm almost ashamed to be associated with what you're trying to do; I consider it ill-conceived and counter-productive.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 1:29 UTC (Thu) by lxoliva (guest, #40702) [Link] (36 responses)

The fundamental difference is that it doesn't *ask* the user for any of these pieces of software. The moment it does is the moment it induces the user to give up their freedom.

When the kernel doesn't say “give me this piece of non-Free Software”, but rather just works with whatever is on the system it's running, there isn't any problem.

We're not fighting against users' ability to run the non-Free firmware. Even if we wanted to do that, it would be pointless: users can always install the software provided directly by the unethical supplier.

What we're fighting against is precisely the inducement to error: presenting the non-Free Software, or recommending its use, as if it was a solution to a problem, rather than a social problem in itself. Sometimes worse: presenting the non-Free Software as if it was Free Software.

If a user has already opted for hardware that requires non-Free Software, there's very little social harm in letting the user make use of it, as long as the user doesn't happily recommend it to others. But the user will do just that if not made aware that there is a problem in there, and then more victims will be made.

I really don't understand why clever, savvy people accept to be used by hardware suppliers, without realizing they're being induced to betray their goals of a Free (or Open Source, as is sometimes the case) system to take part in a popularity contest that serves hardware vendors that stand against these goals. Hardware vendors that managed to twist the picture so as to enlist the help of those who allegedly stand for freedom or openness, and so that users blame these developers, rather than the hardware vendors, when the developers decide to stand for users' freedoms.

That's what I consider massively inconsistent and impractical. But then, as Simon also says, the best enemy of freedom is a happy slave.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 2:27 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] (35 responses)

"The fundamental difference is that it doesn't *ask* the user for any of these pieces of software. The moment it does is the moment it induces the user to give up their freedom."
So it's OK to have this closed, undebuggable, unfixable crap as long as you aren't asked about it? If you look at it like that, then your goals are entirely out of sync with mine because you aren't going anywhere near far enough :)

I do care about the problems caused by crappy system BIOS code which we can't fix, and which the vendors usually don't bother even to test competently. And about broken device firmware like the Marvell wireless abomination that I had to deal with for OLPC which was so unreliable that we had to hook up an extra GPIO line to the module's reset pin. I care about these things regardless of whether they're loaded from flash or whether they're loaded through the kernel.

To me, that seems like an arbitrary and pointless distinction. I really don't understand why clever, savvy people would accept that these instances of non-free software are acceptable, as long as they aren't asked about it.

I find it astonishing that a crappy piece of closed-source firmware becomes more acceptable to you if it's flashed into the hardware such that you can't replace it with a free reimplementation. If the Broadcom b43 devices were like that, we'd never have got OpenFWWF.

"When the kernel doesn't say “give me this piece of non-Free Software”, but rather just works with whatever is on the system it's running, there isn't any problem."
The kernel never says that. The kernel says "give me a piece of software which drives this device" and cares not about the licensing. It doesn't care whether it's using the Broadcom b43 firmware or the OpenFWWF version, for example (except to the extent that the different firmware has different behaviour which it has to adapt to). Only if you choose to give it a non-free version will it use it.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 3:54 UTC (Thu) by lxoliva (guest, #40702) [Link] (34 responses)

> So it's OK to have this closed, undebuggable, unfixable crap as long as you aren't asked about it?

No, it's not ok at all, and it surprises me that you're bringing up this straw man again. We've already covered it, both in this discussion, and in our personal conversations.

What is ok is for a program (even the kernel) to interface and work with the environment in which the user started it. If the user decided to run the kernel on a machine that has a crappy non-Free BIOS, well, too bad, it can lament for the user but still do the best it can to work, even without telling the user anything about it.

However, the moment the kernel runs request_firmware(), it's asking for something. If this something is known to be non-Free Software, it's not OK for the kernel to ask for it, even though it would be ok (but unfortunate) for the user to ask the kernel to use it and for the kernel to then use it.

> It doesn't care whether it's using the Broadcom b43 firmware or the OpenFWWF version, for example

Except that, indeed, it does. It doesn't just use different pathnames to ask for one or the other, it also tests properties of the user-supplied file to figure out which one it got.

If it didn't have to tell the difference, then Linux-libre would make the request and just take whatever the user gave it, for it would be indistinguishable from an inducement perspective, i.e., the kernel would not be inducing the user to give up her freedom. From the point of view of the kernel, it would be just as indistinguishable as a hardware device that is implemented entirely as hardware circuits or driven by a piece of software stored in ROM or non-volatile RAM, in that no inducement is involved.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 10:37 UTC (Thu) by cesarb (subscriber, #6266) [Link] (1 responses)

> However, the moment the kernel runs request_firmware(), it's asking for something. If this something is known to be non-Free Software, it's not OK for the kernel to ask for it, even though it would be ok (but unfortunate) for the user to ask the kernel to use it and for the kernel to then use it.

"The moment the kernel runs pci_enable_device(), it's asking for something. If this something is known to be non-Free hardware or hardware with non-Free firmware, it's not OK for the kernel to ask for it, even though it would be ok (but unfortunate) for the user to ask the kernel to use it and for the kernel to then use it."

(I do not know if this variation on your argument is a good one or even if it makes sense, but it sounded too good to let it pass.)

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 11:41 UTC (Thu) by lxoliva (guest, #40702) [Link]

It doesn't even begin to make sense. pci_enable_device() doesn't ask the user to install a device, so there's no inducement to error involved.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 10:45 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] (31 responses)

This is pure sophistry. When I bought my laptop, it arrived with a bunch of closed firmware for the devices it contains. Some of that firmware was present in various flash chips, and some of it was encoded in magnetic patterns on spinning rust.

And you're telling me it's OK to use one but not the other, just because the kernel is slightly more involved in getting the latter into the correct place in device RAM? On the basis that if you can stick your fingers in your ears and sing 'la la la' and ignore it, it's not really happening?

Quite frankly, we have much better things to be doing.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 12:42 UTC (Thu) by lxoliva (guest, #40702) [Link] (30 responses)

No, that's not what I'm saying.

What I'm telling you is that your kernel can't tell that this is your case, it can't tell whether there's any non-Free firmware in the devices that are present in the system, but it does know about devices that require non-Free firmware, and it wouldn't be right for it to induce you to install this additional non-Free Software on your system.

What I'm also saying is that it's not the kernel business to tell you what is or isn't ok, but it is the business of any freedom-caring program to avoid inducing users to install non-Free Software. If you want to install them and use them, it shouldn't stop you from doing so, but it shouldn't encourage you to install them.

Sadly, the request_firmware interface is designed in such a way that the kernel can't tell whether a certain piece of non-Free Software is available without actually asking for it, so it needs to be disabled until we can implement some alternate interface that enables testing without inducing (e.g. as described in the 2.6.33-libre announcement). But for firmware that is present in flash chips that need not even be visible to the kernel, the kernel doesn't ask for the firmware it doesn't even know about, so it may as well assume the user has already made the decision to use it (if it's there at all) and proceed to use it.

I can understand that you don't agree with the notion that freedom-respecting programs shouldn't induce users into non-Free traps, but I don't think it's such a hard notion to understand either. There's no reason for you to resort to name calling and other disrespectful behavior just because you don't agree with someone else's opinion. If you have honestly failed to understand it, I'll be happy to try to explain further, but I'm not really interested in your verbal abuse.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 13:54 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] (29 responses)

"What I'm telling you is that your kernel can't tell that this is your case, it can't tell whether there's any non-Free firmware in the devices that are present in the system, but it does know about devices that require non-Free firmware…"
Kind of true and yet still so wrong.

Yeah, the kernel can't tell whether my hard drive has non-free firmware, or whether my Prism2 PCMCIA wireless card does, etc.

But we know they do, we even detect certain revisions or features of the firmware and behave accordingly.

And the kernel can't tell whether a given firmware which it asks for with request_firmware() is free or not, either. The developer might have a-priori knowledge, just as they do in the firmware-in-flash case, but why's that any different? In addition, in the case of a loadable firmware it's actually possible that it could be replaced by a free reimplementation, even if there was only a non-free version available when the driver was first written.

"I can understand that you don't agree with the notion that freedom-respecting programs shouldn't induce users into non-Free traps, but I don't think it's such a hard notion to understand either."
You are mistaken; I understand that completely — and I even sympathise to a certain extent¹. I just think that you're going about it the wrong way.

You're pushing a policy decision into the kernel where it doesn't belong, when the kernel doesn't even have access to the information it would need to enforce that policy.

I even understand, syntactically and semantically, your argument against doing this in the technically-appropriate place; in the userspace firmware loader where the request could be silently ignored without the user ever knowing or being "induced" to do anything. But I think it's entirely specious.

¹ when I say I sympathise "to a certain extent", I mean only until I reach the realisation that your "no inducement" policy really seems to translate into silent failure without letting the user know why something isn't working. If there's anything that really annoys me, it's crappy error handling where the user has to jump through hoops and rebuild things to debug and work out why they didn't work the first time. And that's what you seem to be advocating.

And then I realise that the long-term effect of what you're trying to do would actually induce users to favour the "Tivoised" devices which have firmware built-in on flash, over the devices where it's easier to replace the firmware because it's loaded through the OS. And by that time I really don't have much sympathy left for your position at all.

FSFLA: Linux kernel is "open core"

Posted Nov 12, 2010 4:16 UTC (Fri) by lxoliva (guest, #40702) [Link] (28 responses)

> But we know they do, we even detect certain revisions or features of the firmware and behave accordingly.

That's kind of fine as far as the kernel is concerned: it's not inducing users to install or accept it, just assuming the user has accepted it.

It's completely unlike *asking* the user to install (or update an EEPROM) firmware.

Because, again, the point is not to *prevent* people from using non-Free Software, it's to avoid *inducing* them to do so.

It might make sense to add a run-time option to the kernel for drivers that somehow detect or know about non-Free firmware in devices they drive to fail, issue a warning or silently proceed depending on how the option is set. Do you have other examples of such drivers?

FSFLA: Linux kernel is "open core"

Posted Nov 12, 2010 14:45 UTC (Fri) by dwmw2 (subscriber, #2063) [Link] (27 responses)

I gave some examples — hard drives and ACPI. Those drivers could reasonably by marked by your CONFIG_NONFREE option too.

Going back to my laptop… I don't see why it's reasonable to assume that I've accepted the non-free firmware which is built in; I may not even know that it's there. Many people don't even think about firmware as a separate entity; they know only of the operating system, and the hardware.

On the other hand, my laptop was also delivered with non-free firmware for the wireless card, which was bundled within binary driver in the preinstalled operating system. You can tell that I've accepted that, because otherwise I wouldn't have run the b43-fwcutter tool, and the firmware blob wouldn't be present in my /lib/firmware directory.

What you're doing is trying to make the kernel NOT EVEN LOOK at the latter case where I have clearly and explicitly accepted the non-free firmware, while still blindly accepting the former case where you only have a fairly dubious assumption that I'm OK with it.

If I run your kernel, you are preventing me from using that wireless firmware that was already in my system when I bought it; you're not just avoiding the inducement.

Really, if it's just about the *inducement* then all you need to do is disable the automatic PackageKit trigger which makes it go looking for a firmware file that it can't find locally. You don't need to break the kernel so that it can no longer use firmware blobs that the user has installed on their system. And you don't need to push policies into the kernel where they don't belong, and where the information required to implement them is not available.

FSFLA: Linux kernel is "open core"

Posted Nov 12, 2010 18:59 UTC (Fri) by lxoliva (guest, #40702) [Link] (26 responses)

I agree it's important to inform users about the non-Free firmware built into their computers. I'll give some thought about how to do that.

As for the b43 non-Free firmware, I think it's presence is not an indicator that you're even aware of it either. I mean, Free and nearly-Free distros aren't normally permitted to bundle it, but I suppose a computer vendor would obtain a license to ship the b43 firmware pre-installed along with a GNU+Linux distro of its choice, and would presumably silence any warnings to that effect that we might have put in upstream :-(

Now, your characterization of what I'm trying to make is unfair. I'm not tryign to make the kernel not even look; I'm rather trying to avoid a situation in which the kernel issues a request for it without knowing whether it's there. There's more than one way to improve the situation that doesn't involve completely disabling the firmware request.

One example is the hash-based implementation suggested in the 2.6.33-libre announcement. Another is to have userland pre-register available pieces of firmware, and have the kernel only issue requests for those that have been pre-registered. Both of these would remove the inducement without disabling functionality.

Would you help get either of these, or some other solution that accomplishes the same within the kernel, into upstream?

FSFLA: Linux kernel is "open core"

Posted Nov 12, 2010 19:10 UTC (Fri) by jebba (guest, #4439) [Link] (2 responses)

Lets say that by 2.6.38 the firmware/ directory is gone (ignoring for the moment the fact that there appears to be more non-free blobs remaining). At that point linux-2.6.38.tar is clean in terms of containing only GPL code.

So the kernel can say "I need firmware for $foo" and it becomes a userspace issue. Userspace can hand the kernel a proprietary blob, a FLOSS blob, or say it has nothing.

In this scenario it seems the best place for stopping the "inducement" would be in userspace. That way it can have a nice list of free and non-free firmware images (via sha1sums or somesuch). So if you want to have a system which doesn't pester you with non-free software, you could launch it (hypothetically), like: firmware-loader --daemon --floss-only. And people who don't mind running proprietary software just launch the daemon allowing it to feed their system anything.

Just a suggestion. I hesitate to make it. ;)

FSFLA: Linux kernel is "open core"

Posted Nov 12, 2010 19:34 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

I'll point out that trying to maintain a list of free sha1 signatures defeats the purpose of the firmware being free because if the user modifies it, the sha1 won't match anymore.

FSFLA: Linux kernel is "open core"

Posted Nov 12, 2010 21:08 UTC (Fri) by dwmw2 (subscriber, #2063) [Link]

We don't need the list of signatures. If we do this the sensible way in the userspace firmware loader, we have the proper licensing information; in the WHENCE file or the more machine-readable thing which will shortly replace it.

It's only if we try to do this in the kernel where it doesn't belong that we end up with broken hacks like the sha1 hashes.

FSFLA: Linux kernel is "open core"

Posted Nov 12, 2010 21:12 UTC (Fri) by foom (subscriber, #14868) [Link] (2 responses)

> I agree it's important to inform users about the non-Free firmware built into their computers. I'll give some thought about how to do that.

It would be useful for someone to start cataloging what non-free firmware there is, and which alternative hardware you can purchase instead (if any) that has free firmware available. There is currently essentially *no* information about this problem available currently.

Things I can think of with Flash-based (upgradable!) non-free firmware in my computer for which there are to my knowledge zero devices with free firmware available:
- Hard Drive
- DVD Drive
- Ethernet card
- Keyboard
- Trackpad
- Video card (may not matter? Do the free drivers actually call any functionality in the non-free firmware?)
- LCD Display

Things that come with non-free firmware that people have started working on a replacement for:
- Motherboard (see coreboot project)

And I bet there's more that I forgot about.

I think it would greatly increase the credibility of linux-libre if it also advised users of the danger of using non-free firmware in all the above devices, as well as the devices that require firmware to be uploaded at boot. I bet most people don't even think about the dangers of the non-free OS running in their hard drive.

FSFLA: Linux kernel is "open core"

Posted Nov 12, 2010 22:30 UTC (Fri) by jebba (guest, #4439) [Link] (1 responses)

I think the Lemote Yeeloong would fit most or all of the above. At least it has free wifi, ethernet, video, and BIOS.

http://www.lemote.com/en/products/Notebook/2010/0310/112....
http://tekmote.nl
http://freedomincluded.com

FSFLA: Linux kernel is "open core"

Posted Nov 14, 2010 4:50 UTC (Sun) by foom (subscriber, #14868) [Link]

That's great! I was unaware that such a freedom-supporting laptop was available for sale. Clearly it could use more prominent mention whenever people talk about non-freeness of firmware.

I do wonder about its card reader, keyboard, and touchpad, however...

And I'm *sure* its Hard Drive has non-free firmware in it. They could fix that part, at least, by putting raw flash chips in instead, and using one of Linux's raw-flash filesystems like JFFS2 or UBIFS.

FSFLA: Linux kernel is "open core"

Posted Nov 12, 2010 21:16 UTC (Fri) by dwmw2 (subscriber, #2063) [Link] (19 responses)

I think you misunderstood the situation with the b43 non-free firmware.

Broadcom are not giving permission for anyone to distribute that firmware for use with Linux, because of their crack-inspired concerns about regulatory stuff. Its presence in /lib/firmware is an indicator that the user has manually extracted it from a Windows or Mac OS driver and installed it there. When I talked about it coming with the hardware, that's because it was in the preinstalled copy of OS X. Not because it would ever be found in any pre-installed Linux system.

No, I won't help you get any of your suggestions into the upstream kernel. As I've already said, it doesn't belong in the kernel. It can be done in the userspace loader so much more easily, where the licensing information is actually available.

I just don't agree with your claim that the simple udev event which triggers the userspace firmware loader is equivalent to inducing the user to use non-free software. I find it completely insane. It would be perfectly acceptable just to refuse the firmware request in userspace where we have the required licensing information and can implement the policy the user desires.

And whatever you said, unless I'm missing a technical detail your scheme has actually broken the drivers. I could no longer use my b43 wireless card without actually rebuilding the kernel to undo your damage.

Seriously, Alexandre, just do it in udev.

FSFLA: Linux kernel is "open core"

Posted Nov 13, 2010 7:55 UTC (Sat) by lxoliva (guest, #40702) [Link] (18 responses)

> Broadcom are not giving permission for anyone to distribute that firmware for use with Linux

Interesting... I'm pretty sure I've seen laptops with b43 WiFi and GNU/Linux preinstalled for sale. I wonder if the laptop vendors actually ship this stuff without functional WiFi. That would be... surprising.

> unless I'm missing a technical detail your scheme has actually broken the drivers

it looks lke you are indeed missing something, for I have proposed *3* options, and only one of them is currently implemented: the one that indeed refrains from asking for the non-Free b43 blob, asking for /*(DEBLOBBED)*/ and discarding the userland response instead.

The two other options are:

- have the kernel ask for a unidirectional hash of the blob name, and have udev look for a blob whose name hashes to the same value (as proposed in the 2.6.33-libre announcement)

- have userland register with the kernel available firmware names early in initrd, and right after switch_root, so that the kernel (optionally) won't even ask for names that aren't registered. This won't just make such requests faster: it can also enable pieces of firwmare built into the kernel to be updated from userland, something that can't be done ATM AFAIK.

Now, you'll see that both of these are actually orthogonal to the licensing of the blobs: they're just ways to enable the kernel to tell whether a certain file is available without inducing users to go get them, in one case, by refraining from naming the blobs so they can't be identified unless you have them; in the other, by having them named at first, so the kernel knows it's not asking for something that the user doesn't want to be bothered about.

FSFLA: Linux kernel is "open core"

Posted Nov 13, 2010 9:55 UTC (Sat) by dwmw2 (subscriber, #2063) [Link] (17 responses)

"Interesting... I'm pretty sure I've seen laptops with b43 WiFi and GNU/Linux preinstalled for sale."
If that's true, then those devices wouldn't be using the normal kernel driver for b43; they'd be using the illegal binary-only one which has the firmware built in to it. And thus the same point applies — for the user to have extracted that firmware and placed it into /lib/firmware requires a deliberate effort on their part.
"Now, you'll see that both of these are actually orthogonal to the licensing of the blobs: they're just ways to enable the kernel to tell whether a certain file is available without inducing users to go get them"
Alexandre, this is getting stupid and I'm getting bored. DO IT IN USERSPACE

A simple upcall from kernel to udev with a filename such as cpia2/stv0672_vp4.bin is NOT an inducement to the user to use non-free software. Not even if the user is currently running udev-monitor to watch for such things. That's just a stupid thing to say. It's almost as if you're confusing "userspace" with "the user".

The process which handles the request in userspace is in a much better position to do what you want. It has the licensing information, and can easily implement the policy you desire — which seems to be a silent failure without inducing the user to know why their hardware isn't working.

Or you could do the filtering in modprobe instead — you could look at the MODULE_FIRMWARE tag in the module, then refuse to load the module at all if it is going to ask for a firmware file that you cannot provide. And that way you do get to avoid the request_firmware() call that you are so bizarrely concerned about.

FSFLA: Linux kernel is "open core"

Posted Nov 13, 2010 12:37 UTC (Sat) by foom (subscriber, #14868) [Link]

+1: exactly what I was going to say. A RPC call from kernel->udev is not inducing the *user* (a person, who receive RPC calls!) in any way.

FSFLA: Linux kernel is "open core"

Posted Nov 14, 2010 22:15 UTC (Sun) by lxoliva (guest, #40702) [Link] (15 responses)

> The process which handles the request in userspace is in a much better position to do what you want

This just shows that you don't have any idea of what I want.

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

If you're assuming that myself or Linux-libre have any intention of taking this control away from users, of, like, protecting users from themselves, you'd be wrong, because the assumption is wrong. The goal is rather to help users defend themselves from the luring by unethical vendors that tempt them into giving up control over their computers, giving up freedom and betraying their community; unethical vendors that try to fool them into thinking of it all as ok, even desirable.

Now, you may get as bored and stupid as you wish, and rationalize that a request might be hidden from the user by userland programs, and that ignorant users wouldn't know to look at log files to investigate and troubleshoot why their devices aren't working, and that they wouldn't know to search for the log filename in a web search engine and find the file along with a message that is biased towards accepting it without questioning or even thinking about it. If you assume users wouldn't do that, you'd again be mistaken, because the assumption is wrong.

Now, let's look at your statement that a userland program is in a much better position to do what I want. Even if the userland program could indeed clean up the log messages from a local machine, it can't go back in time and prevent the kernel from having issued the request, so it can't do what I want.

Setting aside this key problem, that you'd surely qualify as irrelevant, I can see how a hotplug program could look at a request from the kernel (or a module's firmware requirements) and decide whether or not to satisfy the request, for firmware files that are installed on the system. But then, why would you want to deny loading of modules that the user installed? That doesn't make sense! It's obvious to me that you're trying to solve a different problem.

It gets even more interesting when you get to a module that is *not* installed. The userland program can't possibly know anything about it, but the developer of the kernel module that asks for it knows everything there is to know. So how can you say that the userland program is at a better position to decide how to inform the user about the problem in a way that makes it clear that the hardware vendor is trying to take her freedom away? That's demonstrably false for precisely the cases that matter, and you state that the one piece of software whose developer holds the relevant knowledge is the wrong place to encode it?!?

Finally, you suggest that some other piece of software even prevents modules from being loaded if their meta-information says they might request some unavailable or undesirable module. That's a terrible suggestion. A number of modules request firmware only for specific variants of the hardware they drive, while other variants work just fine without any firmware. For others, the firmware may provide fixes or additional functionality, but the hardware still works fine (sometimes without loss of functionality) without it. See? It doesn't even begin to make sense! Userland just doesn't *have* the information it takes to make even the sort of decision you want it to make. It's the module that knows what it expects.

Also, you mention licensing information. That's only one of the dimensions of the software freedom problem. A number of blobs are under licenses that qualify as Free Software licenses, but since they are missing source code, they are non-Free. I suspect (but can't prove) that they were provided under such licenses so as to fool kernel developers that have a fixation on license-compatibility issues without realizing that X11-licensed code is only compatible with the GPL when you can offer the corresponding sources also under the GPL. Without it, redistributing the binaries as part of a work licensed (even if partially) under the GPL from a third party amounts to copyright infringement. And that's just one of the ways in which fake contributors to the kernel keep other kernel developers legally hostage, and that shows why knowing licensing information is also insufficient.

What userland has that the module doesn't have is a good way to interact with the user and display useful information. That's why Linux-libre is not the best place for that, but it still conveys to userland the information needed to display a useful message. The /*(DEBLOBBED)*/ firmware name was designed that way so that it never matches a real file, and so that hotplug scripts can match in the slow path and send an informative message to users through a graphical interface. This string also makes to logs, so that users can immediately find out there's something wrong with the blob that's being asked for, when they web-search for this string they found in their logs.

So, your design is pointless for my goals, and even for yours it uses insufficient information, it misses even that at cases that matter, and the proposed improvement breaks it further. All of this because you seem *DETERMINED* to do it at a place other than the one that has all the relevant information. I *will* let you do that, Dave ;-), but since that will do nothing to accomplish my goals, I'll have to keep on doing what needs to be done at the place where it can actually be done. Your shouting and misrepresentation (out of misunderstanding?) of my goals won't change that.

FSFLA: Linux kernel is "open core"

Posted Nov 14, 2010 23:13 UTC (Sun) by anselm (subscriber, #2796) [Link] (8 responses)

Now, you may get as bored and stupid as you wish, and rationalize that a request might be hidden from the user by userland programs, and that ignorant users wouldn't know to look at log files to investigate and troubleshoot why their devices aren't working, and that they wouldn't know to search for the log filename in a web search engine and find the file along with a message that is biased towards accepting it without questioning or even thinking about it. If you assume users wouldn't do that, you'd again be mistaken, because the assumption is wrong.

Just so I get this right: You'd prefer if the Linux kernel was generally modified to the effect that the fact that driver X missed firmware blob Y not be logged in the first place, just so a clever Linux user won't go out of their way to obtain blob Y in order to make their system work. So your proposal is, in effect, to keep users ignorant of their options. They do not get the chance to make a conscious decision towards freedom because you have decided that this decision isn't really theirs to make, since you have made it already on their behalf without bothering to consult them as to their actual preference.

I'd say feel free to put together and publish a Linux distribution that works exactly like you describe. Those Linux users who are truly freedom-minded (in the sense of the FSFLA) will surely flock to it and it will thrive. But leave it to the rest of us to make our own conscious decisions as to what level of »freedom« we want to accept on our systems. Thank you.

FSFLA: Linux kernel is "open core"

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

> You'd prefer if the Linux kernel was generally modified to the effect that the fact that driver X missed firmware blob Y not be logged in the first place

No, but that's one of the favorite straw men against Linux-libre.

We do log a message, and we intend to keep on logging messages, just not messages that sound like “please get me file blobname.bin so that device works”, but rather more along the lines of “missing Free firmware for device”.

FSFLA: Linux kernel is "open core"

Posted Nov 15, 2010 11:32 UTC (Mon) by anselm (subscriber, #2796) [Link] (6 responses)

but rather more along the lines of “missing Free firmware for device”

I don't think this will keep people from checking the Internet to find out exactly what file they are missing, and installing that – so this is no more or less an »inducement« than posting the full name of the missing file. Your only real alternative is to post nothing at all, which I believe is ethically unsound because it tries to keep people from knowing their options.

Speaking as somebody who keeps Linux servers running for money, I would much rather see the kernel tell me exactly what a problem (any problem, not just loading firmware blobs) was in order to make it easier to fix, rather than post cryptic messages to the log that make me do extra detective work. If the missing firmware blob in question is non-free, let me decide whether I want it installed, and don't make my life more difficult by having me perform extra detective work in order to find out what it even is. (It would be naive to assume that little obfuscation games like hashing the file names would make a big difference here.)

As I said (and as you didn't reply to), feel free to publish a Linux distribution that adheres to your concept of »freedom« and see how you get on – but don't try, by getting the standard kernel changed, to force your concept of »freedom« on to those of us who can make our own decisions, thank you very much.

FSFLA: Linux kernel is "open core"

Posted Nov 15, 2010 19:37 UTC (Mon) by lxoliva (guest, #40702) [Link] (4 responses)

Telling you that there isn't Free firmware to run a certain device, to me, is a complete description of the problem. Now, I'm not suggesting the standard kernel to do that, not even by default. All I'm asking for is an *option* to have it do that. But even that is denied. It's clear who's forcing whom, isn't it?

As for publishing a Linux distribution that adheres to this concept of freedom, I've already done that. This announcement refers to precisely that: it's a Free and bait-free version of the Linux distribution published by Mr Torvalds.

Now, it might be that you mistakenly believe that Linux is a complete system. It isn't. Mr Torvalds himself said so when he first announced his kernel, noting that, to get a functional system, you'd need a number of core components of the GNU operating system.
http://www.kernel.org/pub/linux/kernel/Historic/old-versi...

So, if you meant a GNU/Linux distro (or rather a GNU/Linux-libre distro, since it's the GNU system running on top of the Linux-libre kernel), I'm not sure what the point of my creating yet another such distro. The Linux-libre page already refers to a number of distros that have adopted Linux-libre. Just yesterday I learned of one more. It's spreading!

Now, would I prefer that Linux itself offered them this option? Of course! I'd even gladly help Linux get there. But Linux is unfortunately a project that prefers to sacrifice long-term convenience and freedom for short-term convenience, so we software freedom advocates end up having to maintain our own version of it. That's unfortunate, but it's understandable.

FSFLA: Linux kernel is "open core"

Posted Nov 15, 2010 21:02 UTC (Mon) by kfiles (subscriber, #11628) [Link] (1 responses)

Holy moly! COuld you two please take your personal dispute to private mail?

I read the LWN comments through the RSS feed, and the noise from your bitter thread has shouted down the rest of the wonderful signal on LWN (well, to be fair, you and the Florian Muller thread).

The rest of us would just like to read our tech news, please.

using the comment filter

Posted Nov 15, 2010 23:00 UTC (Mon) by biged (guest, #50106) [Link]

I hope it's not too impolite to recommend that subscribers use the Comment Filtering preference. Even if you read with RSS, so it doesn't help you directly, it's a form of voting which might be useful to the editors. (I had to abandon RSS: I now use the Unread Comments page instead. It buries most of these annoying arguments.)

FSFLA: Linux kernel is "open core"

Posted Nov 16, 2010 14:31 UTC (Tue) by vonbrand (subscriber, #4458) [Link] (1 responses)

How the heck is the kernel to know there is no free firmware for some random device?!

FSFLA: Linux kernel is "open core"

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

That, it won't know. But the developers of the driver will know what firmware is recommended to work with it (it was written and tested to work with), and whether it's Free.

As soon as Free firmware is developed for a hardware component (and any driver adjustments are made for it, as in b43), the kernel will likely be the first component to “know” about it.

(I use quotes because anthropomorphizing programs is a bad idea: they don't like when we do that ;-)

FSFLA: Linux kernel is "open core"

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

To be fair - if you've installed the linux-libre kernel variant then it's fairly clear that you don't want any non-free blobs so getting a 'deblobbed' log message in this case seems fair enough.

FSFLA: Linux kernel is "open core"

Posted Nov 14, 2010 23:19 UTC (Sun) by dwmw2 (subscriber, #2063) [Link] (5 responses)

"I believe computers should obey their users. This userspace program you suggest could do nothing but accept or reject software that users have installed on their computers. IMHO, that doesn't make sense. If users chose to install certain software on their computers, the computers had better obey when users command “run it” or “install it”. Anything else is, erhm, defective by design, if you get what I mean."
And yet you're still peddling an implementation which is broken by design in precisely this way.

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

"Even if the userland program could indeed clean up the log messages from a local machine, it can't go back in time and prevent the kernel from having issued the request, so it can't do what I want."
I do understand what you want; I just think it's fundamentally misguided. What you now claim you want is pointless, and no longer directly related to the originally stated goals.

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

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

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

"All of this because you seem *DETERMINED* to do it at a place other than the one that has all the relevant information."
This is also completely incorrect. The kernel does not have all the relevant information. It is only userspace which can know the current licence status of the firmware which is available for download from the various package repositories, not the kernel.

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

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

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

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

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

FSFLA: Linux kernel is "open core"

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

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

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

> I do understand what you want

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

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

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

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

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

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

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

FSFLA: Linux kernel is "open core"

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

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

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

FSFLA: Linux kernel is "open core"

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

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

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

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

FSFLA: Linux kernel is "open core"

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

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

FSFLA: Linux kernel is "open core"

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

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

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

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

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

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

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 7:43 UTC (Wed) by Los__D (guest, #15263) [Link] (12 responses)

> as long as they keep software or documentation that induces users to seek and use non-Free programs, they're still bait.
Ahhh... Denying access to knowledge and the means to help one self is now INCREASING freedom?

FSFLA are doing much more damage than good...

"Freedom of choice is what you've got, freedom from choice is what you want" seems fitting here in a backward, perverted way.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 8:15 UTC (Wed) by anselm (subscriber, #2796) [Link] (11 responses)

Denying access to knowledge and the means to help one self is now INCREASING freedom?

It's been that way for quite some time. For example, the FSF has objected to distributions that even hint that non-free software exists for them, no matter if (e.g., in the case of Debian) that software is not part of the actual distribution.

Also consider the recent »FSF hardware endorsement« issue, where one of the conditions of FSF approval was that the packaging of the approved device will not display Windows or MacOS compatibility badges.

The idea seems to be that people won't know that non-free software exists unless they are explicitly told, and that this knowledge must be withheld from them at all costs so they won't be lured away by the non-free side. In effect, the FSF (and FSFLA) appear to think that free-software users are mindless sheep who need somebody smart (like themselves) to keep them out of harm's way. Religions and dictatorships work that way but I don't think it is really appropriate for the Linux community, where people are mostly fairly savvy.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 8:45 UTC (Wed) by Los__D (guest, #15263) [Link]

Hmmm... I seem to be in quote mood today: 
Pay no mind what other voices say
They don't care about you, like I do, (like I do)
Safe from pain, and truth, and choice, and other poison devils,
See, they don't give a f*** about you, like I do.

Just stay with me
safe and ignorant
go back to sleep
go back to sleep

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 17:54 UTC (Wed) by jebba (guest, #4439) [Link] (9 responses)

Actually, I find it a feature to not have non-free software suggested. I mean, if you're running a FSF-approved distro you probably don't want the "knowledge" popups that you can install Adobe Flash everytime you go out and surf the web. You can just install things from the repo and not have to worry about getting proprietary junk.

For example, I had been using OpenBSD, primarily as a firewall, for a few years. I thought that OpenBSD was more-or-less free so I didn't mind installing from ports. Then one day I came across Opera in there and was like WTF? Great, I have the precious "knowledge" that I can install Opera, but I'd far prefer the *feature* that would leave crap like that out.

Freedom really is a feature. It's not about trying to keep people ignorant. FUD on...

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 19:45 UTC (Wed) by anselm (subscriber, #2796) [Link] (8 responses)

People should be given the freedom to make informed decisions instead of deliberately being kept ignorant in the name of »freedom«.

When you install Debian GNU/Linux, the installer asks you once whether you want the non-free repository made available. Apparently this is enough to tick off the FSF, which would much rather not see that question asked at all. I believe anybody adhering to the FSF school of software freedom can be troubled to answer »no« this once – from then on they won't »have to worry about getting proprietary junk« (by the Debian definition, anyway). It takes a special type of person to declare Debian GNU/Linux a »non-free« operating system simply for asking the question.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 20:01 UTC (Wed) by jebba (guest, #4439) [Link] (7 responses)

I run debian, fwiw. In fact, so did rms himself for a long time. He certainly is a special type of person, no doubt.

People have had the freedom to install flash by having the decision repeatedly offered to them via their browsers. Now a huge amount of content is locked up in a format owned by Adobe. Are we freer for this? Perhaps it would have been best if we never went down that path, no?

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 21:09 UTC (Wed) by anselm (subscriber, #2796) [Link] (6 responses)

Maybe we would all be better off if everyone had simply refused to go for Flash when it was new. However it would have been much better for people to avoid Flash because they made the conscious decision that Flash was a proprietary format with lock-in, portability and security issues and as such not worth the trouble, rather than to avoid Flash because they were never told that it even exists. (It would have been helpful to have had a viable free (as in speech) alternative around at the time, but that is neither here nor there.)

The problem with this approach is, of course, that it presupposes that people will actually take the trouble to think this over. It requires educating people to be smart enough to take that decision rather than keeping them ignorant by taking the decision on their behalf and then not telling them about it.

Politics teaches us that it is difficult to get many people to think rationally about important issues, which may explain why the FSF school of software freedom seems to favour the second option. Unfortunately, the Linux community consists to a large extent of fairly savvy people who do not appreciate being patronised, hence this discussion.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 21:19 UTC (Wed) by jebba (guest, #4439) [Link] (4 responses)

It is not *patronizing* to people who actually *want* to run free software. It is convenience and a feature. If you want to run non-free software, you have tons of options. Why does it bother you so much that there is a subset of the community that wants to have things 100% free and doesn't even want a suggestion of non-free software? Why not just let us do that without all the attacks?

Suggesting that the FSF, of all organizations, is trying to keep people ignorant is ridiculous. It would be hard to come up with an organization that has made people more aware of these issues than anyone else.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 21:43 UTC (Wed) by anselm (subscriber, #2796) [Link]

Why does it bother you so much that there is a subset of the community that wants to have things 100% free and doesn't even want a suggestion of non-free software? Why not just let us do that without all the attacks?

The last time I checked it was the FSFLA which started »the attacks« by taking the Linux kernel developers to task for producing »free bait« software. If the FSFLA wants to distribute a Linux kernel that is »free« enough for them to use then I'm all in favour. This is what free software is about, after all. However, I'll personally stick to the Debian-provided kernel, which is good enough for me, and I'll not have the FSFLA chide me for not pursuing the correct kind of freedom, thank you very much.

Suggesting that the FSF, of all organizations, is trying to keep people ignorant is ridiculous. It would be hard to come up with an organization that has made people more aware of these issues than anyone else.

You will have to explain to me again how not offering to install the Flash plugin in a browser at all makes people more aware of the issues behind Flash.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 21:54 UTC (Wed) by Los__D (guest, #15263) [Link] (2 responses)

Let me see... First you (FSFLA) comes with an announcement that attacks the Linux developers for not buying into your narrow interpretation of freedom, and when someone responds critically, you whine "Help, help, I'm being oppressed!".

Do you really expect to be part of any rational conversation?

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 22:31 UTC (Wed) by jebba (guest, #4439) [Link] (1 responses)

> First you (FSFLA) comes with an announcement...

I'm the FSFLA? I came with an announcement? How do you make that out? I'm not in it nor have I ever been a member. I don't think I'm even in the FSF, for that matter. But I appreciate what both are doing and have done.

> Do you really expect to be part of any rational conversation?

Not anymore. You can't even identify who you are talking to.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 22:33 UTC (Wed) by Los__D (guest, #15263) [Link]

Sorry, my bad. You just seem to half the writing on FSFLA's behalf.

[OT] Flash plugin (was: FSFLA: Linux kernel is "open core")

Posted Nov 10, 2010 22:27 UTC (Wed) by cesarb (subscriber, #6266) [Link]

> Maybe we would all be better off if everyone had simply refused to go for Flash when it was new.

People never made that choice (installing or not Flash). IIRC, it came bundled with Netscape, back when everyone used Netscape. Most people do not even know what a plugin is.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 3:43 UTC (Wed) by foom (subscriber, #14868) [Link]

> why the location of the firmware is irrelevant

Unless it's in non-volatile memory on the hardware, of course?

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 20:05 UTC (Tue) by jebba (guest, #4439) [Link]

Probably best if the discussion was on LKML, per kernel development practices, than in a private mail. Regardless, the approach Woodhouse is taking is definitely the traditional LKML-way and appears headed towards getting the firmware at least split out (which Linus thinks is a better arrangement, which is why it can happen). The question is, at that point when it's removed, will a -libre kernel still be needed?

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 19:29 UTC (Tue) by lxoliva (guest, #40702) [Link] (18 responses)

There's far more the kernel devs could do to encourage vendors to free up their devices.

They could refuse to accept drivers that depended on non-Free firmware.

What then? Vendors would then have to decide between:

1. not supporting GNU/Linux at all
2. maintaining Linux drivers themselves, like they do for other relevant OSs
3. freeing up the firmware and getting help and goodwill from the FLOSS communities to maintain them

Yeah, a few might keep on choosing 1.

Some will choose 2, and users will will get Free drivers and non-Free firmware from them just like they would from other OSes, and would be presumably be unhappy about that and prefer...

... those who choose 3.

See?

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 19:37 UTC (Tue) by dlang (guest, #313) [Link] (12 responses)

you assume that the kernel developers agree with your evaluation of the problems of closed firmware.

many of the developers don't see much (if any) more of a problem with closed firmware (including blobs in the kernel) than they are with the idea that the switch they plug their computer into has closed firmware.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 20:08 UTC (Tue) by jebba (guest, #4439) [Link] (1 responses)

> many of the developers don't see much (if any) more of a problem with closed firmware (including blobs in the kernel)

Are they concerned about shipping hex code of unknown origin with an unknown license? Because that is the current state.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 19:38 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

That is the current unfortunate state of some existing blobs. No new blobs will be accepted into linux-2.6 or linux-firmware without a proper licence.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 3:11 UTC (Wed) by lxoliva (guest, #40702) [Link] (9 responses)

I don't assume they do. I *know* many of them do *not* give a damn about this problem, or about Open Core. Which is why it's so deceptive when they play the “we love Open Source, we promote Open Source, we do Open Source” card: blobs, and combinations of blobs with any other software, aren't Open Source (or Free Software, obviously).

It's precisely because they don't care that we, the Free Software community, have to take the problem into our hands and deal with it.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 13:20 UTC (Wed) by cesarb (subscriber, #6266) [Link] (8 responses)

Perhaps they do not care because they assume (correctly) that the firmware is part of the hardware, even if it is shipped separately. Developing free hardware, or freeing already existing hardware, while being a good thing, is separate from developing the Linux kernel.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 17:41 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (5 responses)

> Perhaps they do not care because they assume (correctly) that the firmware
> is part of the hardware, even if it is shipped separately.

Wait until the day a security problem in a network card is exploited. The distinction between firmware and software maybe made sense in the day of ROMs, but right now graphics and network cards are effectively small specialized computers, and I see no reason why software for those computers should be treated differently.

As somebody else put it elsewhere in the thread, your computer without a software is a "nice brick" as much as your network card without its firmware. Yet, we call it with two different names.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 18:23 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

this isn't a new scenerio, and it doesn't require that the device firmware be loaded from the drivers.

back in the 80's MACs had problems along these lines where the device firmware (which was in ROM) had bugs that allowed bad things to happen.

the way that the firmware is loaded into the device doesn't change things.

people talk as if devices being smart and having embedded processors as if it's a new thing, but going all the way back to the c-64, the floppy drive had it's own cpu, and people reprogrammed it so that you could plug two floppy drives togeather and they would copy any floppy inserted into the first drive to the second drive without being connected to the computer.

note that the source for these devices was not available, but people were able to reverse engineer the devices (assisted by the excellent hardware documentation).

The critical feature that made this possible was that the firmware could be modified from the computer. This is why many of us see systems wher ethe firmware is loaded from the driver as being significantly better than systems where the firmware is locked in flash/rom. Nobody is arguing that such a device is as good as one with open source firmware, we are just arguing that it's better than the same firmware locked in flash/rom.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 12:26 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

> we are just arguing that it's better than the same firmware locked in flash/rom.

I entirely agree with this.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 18:31 UTC (Wed) by cesarb (subscriber, #6266) [Link] (1 responses)

> Wait until the day a security problem in a network card is exploited.

This does not change the fact that the firmware is part of the box we call "network card". Does it matter whether the security issue was on the firmware or for instance a race condition on a hard-coded sequencing logic? In both cases, it is a bug in the network card. And yes, it would be better if we could fix bugs in the firmware ourselves, or enhance it to add new features.

> As somebody else put it elsewhere in the thread, your computer without a software is a "nice brick" as much as your network card without its firmware. Yet, we call it with two different names.

So, let's call it the "network card kernel". The "network card kernel" runs on the network card, the "operating system kernel" runs on the main CPU, or the "application processor" as the smartphone people would call it.

They are still separate, unless your network card can run Linux itself.

Smartphones are an insteresting example: we have the application processor, which often runs Linux nowadays, and the baseband processor, which runs a closed-source GSM stack. Instead of going against the creation of drivers allowing Linux to talk to the closed GSM stack, making it impossible to productively run Linux on smartphones, isn't it better to allow Linux to dominate on the application processor, while separate projects like OsmocomBB focus on freeing the baseband processor (and only it)? An all-or-nothing approach can be very counterproductive.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 12:14 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

> > As somebody else put it elsewhere in the thread, your computer without a
> > software is a "nice brick" as much as your network card without its
> > firmware. Yet, we call it with two different names.
>
> So, let's call it the "network card kernel". The "network card kernel"
> runs on the network card, the "operating system kernel" runs on the main
> CPU, or the "application processor" as the smartphone people would call it.

That's fine. Just to make it clearer, let's call it "network card software". At this point the double standard being applied to "network card software" and "application processor software" should be obvious.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 21:00 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

I.e., if the bug is in silicon or ROM (that is, unfixable) it is A-OK; if it is in firmware to be loaded by Windows via Windows programs into flash memory it is OK, if it is in firmware to be loaded into RAM on the device it is anathema.

I just don't "get" this "distinction"...

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 19:18 UTC (Wed) by lxoliva (guest, #40702) [Link] (1 responses)

> the firmware is part of the hardware, even if it is shipped separately

I'll remember that when the firmware starts being shipped separately from the kernel that requires it as much as the hardware. Then I'll say “Linux is still proprietary software, because the firmware is still part of Linux, even though it is shipped separately, per cesarb's twisted logic” :-)

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 22:21 UTC (Wed) by cesarb (subscriber, #6266) [Link]

That would be really bizarre, because by that logic, it was never part of the kernel to begin with (you could count it as part of the kernel if by that you mean "distributed with the kernel", but not as "part of the code which runs on the kernel").

Either you use the same logic on both situations (meaning the firmware was always part of the hardware, and so you cannot say it was ever really "part of Linux"), or you use it on neither (so it was "part of Linux" and stopped being so after being moved to the firmware tree).

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 13:46 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

Most would choose 1, as least as long as the choice was lengthy legal deliberations and possible legal risk [wireless] or maintaining two entirely separate firmwares because of nonpublic DRM requirements on the Windows firmware (which MS insist on, last I heard) [graphics] versus Linux support.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 19:44 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] (1 responses)

Many OEMs (particularly for servers) now require drivers for the components they buy to be included in-tree. The combination of requirements for kernel developers and OEMs might then force some hardware component vendors to go for option 3. But certainly there would be many others that would just go for option 2. Option 1 just doesn't exist any more except for niche products.

FSFLA: Linux kernel is "open core"

Posted Nov 12, 2010 9:56 UTC (Fri) by mpr22 (subscriber, #60784) [Link]

There's an awful lot of hardcrapware out there that would never see the inside of a server room in a million years.

FSFLA: Linux kernel is "open core"

Posted Nov 11, 2010 19:24 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (1 responses)

  1. Not supporting Linux at all: 99.5% or so (what support is there was done by individual developers/hobbyists until there was sufficient (server side) interest in Linux...)
  2. Maintaining their drivers themselves: Say 0.5% or so (and see what crap most of them are where source is available, recently it was said that just looking at the code gave eye cancer)
  3. Freeing up firmware: Hasn't happened yet in any relevant way, AFAIK.

FSFLA: Linux kernel is "open core"

Posted Nov 18, 2010 11:13 UTC (Thu) by daenzer (subscriber, #7050) [Link]

> 3. Freeing up firmware: Hasn't happened yet in any relevant way, AFAIK.

The question is if we have/want to accept that as a fact of life, or if we might be able to change it in the future.

At least some versions of the microcode for the Radeon Command Processor (commonly abbreviated as CP) have certainly had bugs that could probably be fixed easily if the source code and toolchain for it was available. Clearly this is not providing the freedoms we've come to expect from free software such as the Linux kernel when it should be technically feasible to provide it. (Note that I don't mean to belittle in any way AMD's very commendable efforts providing documentation and free code, just pointing out there's still more that could be done)

I share doubts with many in this thread about whether the effort described in the article is the right approach, but although unfortunately I don't know what the best approach would be, I can't help feeling that not putting any pressure on vendors to open up this stuff isn't the right answer either.

FSFLA: Linux kernel is "open core"

Posted Nov 9, 2010 19:37 UTC (Tue) by gat3way (guest, #47864) [Link] (1 responses)

A bunch of crap. Whinning and trolling is of course much easier than writing a _REAL_ opensource ATI driver for example. I hate it when someone fighting for freedom urges me to do something that fits their idea of "freedom". Or kernel developers for that matter. If you are so much against blobs, then either reverse-engineer them and write open-source drivers, or use HURD, or just shut up.

FSFLA: Linux kernel is "open core"

Posted Nov 10, 2010 13:48 UTC (Wed) by nix (subscriber, #2304) [Link]

The one who should shut up is the one who's admonishing Alexandre for not writing free code without knowing who the hell he is (the most trivial google search would reveal that).

An Unfortunate Style of Communication.

Posted Nov 13, 2010 14:21 UTC (Sat) by gmatht (subscriber, #58961) [Link]

Debian has just as much cause to call the Emacs manual Free Bait as the FSFLA (or FSF) has to call Linux Free Bait. I understand that the Emacs manual claims to be Free but has invariant sections denying the user the freedom to modify the document as they wish, thus failing to meet the DFSG.

However none of the FSFLA, FSF, Richard Stallman or Linus Torvalds think that tricking users into using non-free software is good. The particular point of disagreement that led to this press release is whether moving non-free firmware from ROM to RAM is bad; One point of view is that it makes very little difference; Another point-of-view is roughly that it is bad because now we have an artificial barrier rather than a physical barrier to modifying the firmware.

This announcement does not make an argument as to why their point-of-view is correct. It does even make it clear what the opposing view-points are. Accusations of being "Free Bait" also do not assist in understanding the view points, as this accusation could be made against any project that happens to have even the most minute disagreement as to the dividing line between free and non-free. My experience has been that this style of communication actually impedes understanding, and can be quite destructive to a community.


Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds