What should Debian do about firmware?

[Jeroen]

Since it appears Debian has to make a choice, which would you prefer we do for etch?

Please see also the poll about priorities and the Debian Developer-only poll

For more details about this poll, please read the announcement by the current DPL, Anthony Towns:
http://lists.debian.org/debian-devel-an ... 00015.html

[Harold]

Sourceless firmware? Is this different than closed-source software? Gave an example, please.

[ferlatte]

I realize that sourceless firmware is unpleasant in main.

However, etch seems almost ready, and I would much rather have Debian ship etch on time with existing hardware support than either drop existing hardware or delay the release. As a user of Debian (I work for a company called Linden Lab, and we use Debian for our server cluster), I want etch to ship on time so that I can start to use what is there, even if it's not perfect.

I am also, for what it's worth, all for Debian getting the loadable firmware interface stuff all locked in for etch + 1 so that no sourceless firmware is in main for that; at least, in that case, we have have a non-free installer so we can choose to use such hardware if necessary.

[jsmidt]

I voted for allowing firmware in main, but I hope it is a goal of etch+1 to remove it and find a way to get the installer to install it, with your permission, if your hardware needs it.

[lathspell]

Sourceless firmware? Is this different than closed-source software? Gave an example, please.

Different? Yes, Debian so far only cared about the Operating System levels and not at the ones above (Dictators and Nuclear Plants may run Debian) nor the levels below (if people want Debian in Sun - ok, if they want it on Macs - also ok). The Firmware is currently what other companies put into the ROM, just updateable which is even more convenient.

Example: Wireless network cards come to my mind

Dangers: Yes, might be that the borders between firmware and driver melt or that companies do not open this firmware due to lack of pressure, but that's a post-etch battle and may really wait a couple of month.

[yoush]

Sourceless firmware? Is this different than closed-source software? Gave an example, please.

Firmware is different because it runs not on a general-purpose computer, but on a specialized processor embedded into peripherial device. Or even not on processor - sometimes e.g. FPGA data is also called firmware.

Environment needed to develop firmware is much less common, and often not accessible for general public for different reasons. Or accessible but at very high cost. And there are much less people that have proper knowledge to develop firmware, compared to PC software. In such conditions, it's not practical to expect alternative (read: free) versions of firmware to be developed, at least in timeframe before the device becomes obsolete.

So 'free firmware' is something that just won't happen.

[chealer]

I didn't vote, as the choices look bogus. It's missing an "Other" choice.

[Jeroen]

I didn't vote, as the choices look bogus. It's missing an "Other" choice.

Which other option do you see?

[mattb]

I voted for "Allow sourceless firmware in main" as I think the assumption here (even though it's not explicit in the question) is that this will be tolerated for etch only. I certainly think that etch+1 should have a goal of getting support into the installer for loading non-free firmware.

However releasing etch "on time" is far far far more important than being overly pedantic about problematic firmwares.

[dawgie]

Sourceless firmware? Is this different than closed-source software? Gave an example, please.

Different? Yes, Debian so far only cared about the Operating System levels and not at the ones above (Dictators and Nuclear Plants may run Debian)

Does Debian provide specialized tools for dictators and nuclear plants in non-free?

[Crell]

I voted for releasing on time, with the caveat that work continues on the non-free install method in etch + 1.

Etch is already technologically a big step up from Sarge.

Etch, to my understanding, is also a step up from Sarge on the freedom front.

OK, so it's not 100% perfect on the freedom front, but it's not perfect on the tech front either. But it's better than what is currently recommended to people (Sarge). That means it should replace it as what's recommended to people. That is still furthering the goal of more freedom in the world.

And keeping to a schedule means more people are willing to rely on Debian, which means more people using it, and thus more people using and seeing the benefits of free software.

[DeanLinkous]

Allow it in main - for now! If it does not meet free guidelines then get it out of main ASAP after etch is released.

Please release etch on time. Debian is absolutely awesome in so many ways but if we have another release drag then I would only view that as disappointing and sending a signal (correct or incorrect doesn't matter) that debian can not keep up with the times. That it is too big and unwieldy to maintain the current pace of linux development and that there it truly is relegated to being a server distro and not a desktop distro.

Also I would like to see contrib and non-free become completely seperate entities and not related to the official debian project.

Oh and world peace please.

[Lavene]

Keep it out of main.

The release date for Etch is not critical. This is due to the fact that all branches (testing, unstable... even experimental) is available anyway and most of us 'can't wait' people are already running Etch.

The release hysteria seen in other distro's communities is often related to the fact that they have no alternative than using the old version untill the new one is released. It's not really like that with Debian. I see no reason what so ever to 'contaminate' main with sourceless stuff just to be able to release Etch on time.

Tina

[ajdlinux]

I voted to drop support of hardware that needs sourceless firmware for etch. As Lavene said the release date is not critical, it would be nice to have it released soon, and IMHO a release soon is still important, but not as important as making Debian compliant with the Social Contract.

[Jeroen]

I see no reason what so ever to 'contaminate' main with sourceless stuff just to be able to release Etch on time.

Woody, Sarge, current testing/etch, and sid all contain sourceless firmware at the moment. The question is not about adding it, but about whether or not removing it. The linux kernel has for a very very long time contained firmware of even mostly unknown origin.

So the current situation is that all branches are 'contaminated' if you wish to use that wording. Delaying etch does not decontaminate the current stable release, "sarge".