Kurt Roeckx's journal

Today the voting period starts for this general resolution about firmware and the Lenny release.

As many have pointed about before this is very complex vote with many orthogonal issues.

The issues and some of the options:

• Where do we want to ship firmware that doesn't comply with the Debian Free Software Guidelines (DFSG)?
  • If it doesn't comply with the DFSG it should go to non-free
  • Change the DFSG so that we don't require source for firmware
  • Create a separate section for it.
• Is a DFSG violation a release critical bug or can we make a release with known DFSG violations?
  • DFSG violation are release critical
  • Sourceless firmware can be part of Lenny as long as we are legally allowed to do so.
  • Sourceless firmware can be part of Lenny
• It's not clear whether some blobs in the kernel comply with their license and the DFSG
  • Remove those parts that are not clear or don't comply with the DFSG
  • Assume that blobs in the kernel are source
• Does the release team have the right to decide if something is release critical or not?
  • Override them and say that DFSG violations are release critical
  • Explicitly give the release team the power to decide whether a bug is release critical or not

And then we're going to decide all of that in 1 single vote. I interpret the options we have as:

Choice 1:

• non-free firmware should go to non-free.
• It is a release critical bug
• remove unclear parts
• override the release team

Choice 2:

• We're not saying anything about where non-free firmware should go
• sourceless firmware can be part of Lenny as long as we are legally allowed to do so.
• We're not saying anything about the unclear parts
• Don't override the release team

Choice 3:

• We're not saying anything about where non-free firmware should go
• sourceless firmware can be part of Lenny
• We're not saying anything about the unclear parts
• Don't override the release team

Choice 4:

• We're not saying anything about where non-free firmware should go
• We're not saying anything about whether it's a release critical bug or not
• We're not saying anything about the unclear parts
• Release team decides if something is release critical

Choice 5:

• We're not saying anything about where non-free firmware should go
• We're not saying anything about whether it's a release critical bug or not
• Assume that blobs in the kernel are source
• Don't override the release team

Choice 6:

• Change the DFSG to not require source for firmware
• We're not saying anything about whether it's a release critical bug or not
• We're not saying anything about the unclear parts
• Don't override the release team

Choice 7:

• We're not saying anything about where non-free firmware should go
• We're not saying anything about whether it's a release critical bug or not
• We're not saying anything about the unclear parts
• Don't override the release team

So in my opinion, options 2, 3, 4, 5 and 6 all decide on 1 of the 4 questions, and only 2 of them about the same question.

I also don't see any bugs filed against the linux-2.6 package about any issues the kernel might have with firmware, so I have to wonder why we're voting about this.

My current vote is "2222221". I'm not sure it's the best options, but I currently don't see a better one.

One of the discussion that always seems to come back is what to do with firmware. It's mostly about freedom versus usability. I think the main question is where do we want to put non-free firmware in our archive.

The opinion seems to range from that it should be in the non-free archive to that it should be in the main archive, with many opinions in between, and they all have good arguments.

We have 3 options that are related to it in our current vote that seem to come down to:

• Move all firmware that doesn't comply with the DFSG to non-free
• Change the DFSG to not require source for firmware so that it can be in main
• Assume that the blobs in the kernel are source so that it can be in main

I don't see the point of that second option, and really have to wonder if there is any firmware under a license that would comply with the DFSG except that the source isn't available.

The third option can make sense for some of the blobs in the kernel that are basically settings that are written to the device. You could write an editor for it, assuming there is documentation for it. But I doubt that they're all settings, and it just seems to ignore the problem.

I find Theodore Ts'o' suggestion about creating a new section for firmware the best idea so far, specially if we can agree that our official CD/DVD images will have that section on it.

It has the advantage that all software in our main archive can comply with the DFSG, that you don't need to add the non-free section just to be able to use hardware that requires firmware and that you can just take a CD/DVD that works.