What should Debian do about firmware?

[StCyr]

I also voted to allow "non-free firmware" in etch but having a non-free install method in etch + 1 is a must!

[ajdlinux]

But decontaminating Etch will finally mean Debian can keep its promise to its users. *Some people* actually care about Debian being 100% free, others don't. Last time the release team just said 'ignore it for sarge, we'll fix it for the next one' and now that Etch is coming around people are saying 'just let it through again and we'll fix it in etch+1.'

[smurf]

Last time the release team just said 'ignore it for sarge, we'll fix it for the next one' and now that Etch is coming around people are saying 'just let it through again and we'll fix it in etch+1.'

Last time the focus was on documentation. This time it's binary firmware.

So what?

I do not want to alienate our users. The user buys a device that's supported, it may even have a nice Linux sticker on it, every other distro installs perfectly fine with it -- only Debian doesn't.

The user will either use some other distribution (which I can live with), or be very frustrated and go back to W*ndo*s (which I don't like them to, and which is far more likely).

No thank you; that outcome is far less palatable to me than shipping another release with a few strange bits which we don't know the origin of.

[Lavene]

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

So since it happen to be done in earlier releases it's OK to keep it happening for future releases? Temorarily permanent...

Delaying Etch will off course not clean the earlier versions but that's not the question is it? The question (atleast the questions asked here) is wether or not to have sourceless firmware in Etch main. It's a problem that has to be dealt with at some point in time anyway.

So what?

I do not want to alienate our users. The user buys a device that's supported, it may even have a nice Linux sticker on it, every other distro installs perfectly fine with it -- only Debian doesn't.

To put aside what I view as one of the biggest plusses in Debian; its well know policy... the social contract et all.. towards FOSS. Continuing the dilute this with non-free/ sourceless/ whatever is not a good signal to send.

Also, by including sourceless firmware in main Debian is sending a message to the manufacturers of hardware: "We need to support your hardware so bad that we set aside all our principles for you".

To prostitute one self to gain some benefits might seem like a good idea in the moment, but remorse inevitably follows... but then you're already screwed...

Tina

Edit: Typos

[THR4K]

I have voted to release Etch in time.

The question about firmware is too complex and can not be resolved easily and rapidly. I think its better to discuss and prepare a real strategy to working efficiently on this subject for the next release(s) (etch+1 or after if necessary).

Some arguments :

1) The firmware problema not only concern a single approach of freedom. Its not simple as "black or white" because these are many ways to considerate the nature of a firmware. Where's the real boundary between the code and a component in this particular case (wich operates really really closer with the hardware depending on it) ? Am i evil if i use free software with proprietary firmware and proprietary hardware ? Am i less evil if i use free software and free firmware with proprietary hardware ?
My point of view is : if you really considers the freedom as absolute than all others considerations then you should probably doesn't use a computer at this time...

2) Until here, all releases of Debian contains sourceless firmwares, so users who have already installed Sarge, Etch, Sid or previous versions should not be more harm than actually.

3) Providing a good solution (ethical _and_ usable) for users will certainly delayed for many months (perhaps one year ?) Etch wich is quite a non-sense if we keep in mind his actual level of achievement.


Conclusion :
Debian Etch is not perfect but shows for now many improvements (and not only technical, as the free documentation is one step beyond in the way of freedom). Rome wasn't built in a day and we must admit that Etch will probably never was the free system of our dreams because there's still too many and huge goals to achieve before.

[Lavene]

It *is* indeed a complex question but never the less I think it's a question that needs to ne addressed, the sooner the better because there *will* be consequences. If it's to be allowed in main then the Debian policies has to be rewritten. If not you run the risk of more and more stuff find it's way into main which really doesen't belong there just because there is a demand for it and the easiest thing to do is just to sneak it into main.

To me it seems like Debian badly needs a clear policy on what to do with the firmware problem and decide on a policy. It's not done over night I know but the longer one waits the bigger the problem will get.

What can happen is that when the time come for Etch+1 people will say "but it's been like this since pre Sarge... why change it?" And we are suddenly stuck with what initially was a temporray (and not very good) solution because everyone has gotten used to it.

Tina

[rickh]

Absolutely ... delay the release. I may want some of that firmware, but if I do, I want it labelled "non-free" As has been noted above, the release date for etch is unimportant since everyone who wants it is using it already.

As the old saying goes, "If you don't stand for something, you'll fall for anything." Debian stands for FOSS, and that's important.

[DeanLinkous]

Dang it Lavene!

Ok, Ok.... You have good points.

One reason I use Debian is because I consider it the closest to "free" (besides Ututo, bless RMS) and I consider that very important. I feel most others distros are compromising in this regard and I dont like it a bit. I certainly would never vote for anything to be put into main but with it already there then I think we have to consider the effects of the situation. If this was a one month delay to fix then I would certainly say that it is doable. But I see this as a major issue that will cause a long delay and will introduce more problems. I have no problems with even a three month delay but six to eight month delay or longer would once again make debian the butt of all the long release quips and silliness.

Yes, I realize that most of us do not run stable but how many people do we see installing just that on these forums. Stable is old now yet we are willing to let stable be considered THE debian release for another year. Stable (like it or not) is considered the official release. Now if we could rebrand stable to 'server' and officially support testing as the 'desktop' release then well....that is chit chat and nothing much besides that.

So maybe we should ask the devs how long of a delay they feel like this would cause, getting it out of main and preferably some type of non-free solution implemented? I feel like it would mean a long delay which I think would show that all of debians efforts to speed up release and become more up to date was nothing more than a lot of hot air and debian will always be behind the times.

I think a resolution that after etch is released that priority one is resolving this issue would be good enough....for me at least.

I would truly like to see contrib and non-free become unofficial projects also - while I am wishing.

[Burnside]

My gut reaction to this is "On time. I want to run etch on my laptop." Then I remember that I already am running Etch/Sid on my laptop. Tina is right, Etch is available to anyone who wants it, so it's not like putting the official release date back while firmware is transfered to non-free is a huge deal.

I vote for www.debian.org getting a makeover so it's clear to new people that they are not stuck with Sarge if they want something closer to SOTA.

[Lavene]

So maybe we should ask the devs how long of a delay they feel like this would cause, getting it out of main and preferably some type of non-free solution implemented? I feel like it would mean a long delay which I think would show that all of debians efforts to speed up release and become more up to date was nothing more than a lot of hot air and debian will always be behind the times.

What makes short release cycles so important? What *makes* Debain is it's policies. Other distros take care of the short release cycles which usually mean a more laxed attitude towards things like licencing, source availability etc (no... I'm not going to mention any by name).

I came to Debian via several derative distros, most of which was released atleast twice a year. I'm sure alot of you will agree when I say (most of) their licence policy etc was mildly confusing at best. And where to get the sources? Is there source available?

Debian is above that and should remain above that. You should know that when you install Debian, and you should be able to trust it. You should know that in main you can get the sources... period! In main it's all free software... period!

Cutting corners in order to meet a release date is not the Debian way... or atleast it shouldn't be.

Tina

[brsa]

Last time the release team just said 'ignore it for sarge, we'll fix it for the next one' and now that Etch is coming around people are saying 'just let it through again and we'll fix it in etch+1.'

This argument would be valid if "it" would be constant in both instances. However, it is not.

With Sarge, the fuss was mainly about documentation - most of which has been fixed for Etch, which constitutes remarkable progress. This time around there is much ado about firmware. Some issues may be postponed to Etch+1 without making the initial argument valid.

As long as there is (real) progress, a release is making things better and is therefore a good thing.

[DeanLinkous]

Well you know I am a fanatic zealot about free! So should we even bother having a release? Should we expect new users to use testing even though it may end up broken. How relevant will debian be to a desktop user if their choice is to run a very old stable or a possibly borked tommorow testing? Does it matter...

Maybe you are right. Maybe I have the 'I want debian to be popular' bug? Maybe I think everyone knows debian is all about free and releasing when it is time but maybe I do not want that to also be asociated with old, stale, too big to move quickly, and just plain out of date stable release. Can't we get some middle ground? Work as quickly on turning into the free distro we have always claimed, make that a high priority and at the same time improve on the release front and the newer software front.

You may be right, in fact you are probably morally right and that is the route we should go. I honestly have never cared about linux taking over the world or even gaining market share, same as I have never cared about debian being popular or easier. I have always said you get out of linux/debian exactly what you put into it and that debians strength has always been that it won't compromise on free and that is why I respect it. I just feel like in this case it is something that has already been compromised on and that while it should not continue it isn't something we should worry about today.

Maybe Debian should do this. It would set the record that Debian is about free above all else. Is that what Debian wants to ONLY be known for? It is a good thing but not sure if we would gain any users from it or gain any repuation except for being free.

Awww heck, either way I love em

Well shouldn't you also be supporting contrib and non-free being removed officially from debian? Just wondering.

edit-nothing makes a hoot about short release cycles but a release that is dragged out for a year longer than it should over a issue that while important is still a wishy-washy kind of issue... This is about firmware afterall.

[THR4K]

If not you run the risk of more and more stuff find it's way into main which really doesen't belong there just because there is a demand for it and the easiest thing to do is just to sneak it into main.

It is question of firmwares only : no drivers, no softwares (there's no compromise : proprietary drivers or softwares never hit main until here and never will). Because there's already *a lot* of sourceless firmwares in main (especially into the kernel packages) and because *a lot* of usal hardware relies on them, launching Etch "as is" will not run any supplementary risk than the past or now...

Another important aspect is to think about the usability of an OS without sourceless firmwares.
In the case of a free network card driver (shipped with Etch without problems) wich requires to load an external sourceless firmware (only available via non-free on a distant site) there's a frustrating situation for the user if no free solution exists.
More painful is the similar situation where you can't initialize your system or his installation because you have an IDE or SCSI chipset wich needs a sourceless firmware not shipped with the installer or distro...

Simply ignoring or underestimate this technical aspects implies to discriminate number of users. Using free drivers is a thing, but using free firmware is a bit more complicated as we have see previously.


I agree that excluding sourceless firmwares from main is clearly a good thing, but especially if you can provide an alternate free solution at the same time. For that, the *huge* amount of work needed to clean main and provide a free and reliable firmware solution to the users will delayed Etch for too long time (are we sure we want Etch for 2008 or 2009 ?)

[neroden]

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

False. Counterexamples in the Linux 2.6 kernel are:

drivers/char/ser_a2232fw.ax
drivers/net/ixp2000/ixp2400_rx.uc
drivers/net/ixp2000/ixp2400_tx.uc
drivers/net/wan/wanxlfw.S
drivers/net/wireless/atmel.c
drivers/scsi/53c700.scr
drivers/scsi/53c7xx.scr
drivers/scsi/aic7xx/aic79xx.seq
drivers/scsi/aic7xx/aic7sxx.seq
drivers/scsi/sym53c8xx_2/sym_fw1.h
drivers/scsi/sym53c8xx_2/sym_fw2.h
drivers/usb/serial/keyspan_pda.S
drivers/usb/serial/xircom_pgs.S

These are all source code files for firmware, which can be compiled to produce the binary firmware files.

See http://doolittle.icarus.com/~larry/fwin ... .6.17.html.

If eight drivers have already done it, it can most certainly be done.[/quote]

[Lavene]

I agree that excluding sourceless firmwares from main is clearly a good thing, but especially if you can provide an alternate free solution at the same time. For that, the *huge* amount of work needed to clean main and provide a free and reliable firmware solution to the users will delayed Etch for too long time (are we sure we want Etch for 2008 or 2009 ?)

Anyone know the actual estimate for the delay it would cause? A couple of months wouldn't mean much... a year or more however is impossible. When one of the options in the poll was "Delay Etc" I assumed it was a manageable delay. IANADD and I don't know the details in the work needed to be done in order to move sourceless firmware out of main, but the original mail suggests 6+ months.

If resoliving the issue will result in an 'impossible' delay then there is basically no other option that release Etch and immediately start working the problem for Etch+1.

Tina

[Hein Zelle]

I've voted to allow the firmware in main, but I also want to add the remark that I hope the modifications to the debian installer will be high on the priority list for the next debian release.

[Jeroen]

Anyone know the actual estimate for the delay it would cause?

6 months of real and steady work (unsure how many people are actually willing to undertake this huge task, that's a different issue):
http://lists.debian.org/debian-vote/200 ... 00122.html

The above mail is by Joey Hess, who was the debian-installer release manager from very early on until recently, and one of the most significant contributors to it, if not the most significant.

[Lavene]

6 months of real and steady work (unsure how many people are actually willing to undertake this huge task, that's a different issue):
http://lists.debian.org/debian-vote/200 ... 00122.html

The above mail is by Joey Hess, who was the debian-installer release manager from very early on until recently, and one of the most significant contributors to it, if not the most significant.

So six months minimum. Which probably translates into a year or more realisticly. That changes a few things...

I didn't realize it was such a mammoth task, but the fact that it is kinda renders the questions in the polls completly uninteresting since in reality it's only leave one alternative;
I doubt it's even possible to delay Etch another six months to a year without affectivly commit distro suicide. And simply drop all support for quite a deal of hardware by dumping it from main without making it available in non-free is equally destructive.
As I see it the only possible solution for Etch is to leave it in main and then address the problem *in time* for it to be resolved before the release of Etch+1.

I still wish it was in non-free though

Tina

[THR4K]

I doubt it's even possible to delay Etch another six months to a year without affectivly commit distro suicide. And simply drop all support for quite a deal of hardware by dumping it from main without making it available in non-free is equally destructive.
As I see it the only possible solution for Etch is to leave it in main and then address the problem *in time* for it to be resolved before the release of Etch+1.

I still wish it was in non-free though

Tina

I Agree with your point of view. It resume well all i said previously.

The countdown for Etch is now about 4 months approximatively, so delaying it for fall 2007 or in the course of 2008 will be a big mistake. Because the amount of work for kernel-related packages will simply need too much time, it is better to planned them for Etch+1.

For me fighting for an ideal of freedom is great, but it becomes only benefic to all if the goals are realistic, even at the cost of few compromise sometimes.

[rickh]

Yeah, 6 months to a year is a pretty big bullet to bite. I would not be surprised to see some delay in the Etch release anyway, based on the fact that the conversion from XFree86 to Xorg seems to still be causing a lot of grief.

If anyone is systematically moving unsourced firmware and drivers from main to non-free, I would hope they're working backward from the most recent. I suspect that the newer hardware gets the most use, and if there is old stuff still in main that noone uses anyway, it's reminiscent of the falling tree in the forest.