calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment (Was: Proposal: The DFSG do not require source code for data, including firmware)
On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote:
> Hi folks,
>
> Ever since the sarge release, an ongoing question has been: what do the DFSG
> require for works that are not "programs" as previously understood in
> Debian? Several rounds of general resolutions have now given us answers for
> some subclasses of non-program works, but debate still rages regarding one
> particularly important class: firmware for peripheral devices.
>
> Andi Barth and I have discussed how we think the DFSG requirements apply to
> firmware and have fairly similar views on the subject, but we also know that
> there are other viewpoints within the project, so we're reluctant to make a
> unilateral decision about firmware handling for the etch release policy
> without finding out how the project as a whole feels about it. In the
> meantime, the ongoing discussions within the kernel team and without have
> shed, as they say, more heat than light on the subject, so I feel it's time
> to answer this question so we can stop being paralyzed by these differences
> of opinion, agree to disagree, and move forward with the work that needs to
> be done for etch -- whichever set of work we decide that is.
>
> So below is a proposal that I'm seeking seconds on to establish how DFSG#2
> should be understood to apply to firmware -- i.e., that for Debian's
> purposes firmware should be considered data, not programs, and along with
...
> 4. determines that for the purposes of DFSG #2, device firmware
> shall also not be considered a program.
Hello,
As i have warned you on irc, when you first asked the kernel team about this
GR, i think that the whole reasoning you propose is flawed, based on patently
wrong assumptions.
There is no way you can just decide that firmware is not code, especially as
there is overwhelming evidence in some case that it is indeed code (or
microcode as some call it), ranging from declaration on the LKML mailing list
by the drivers author, or when the peripheral processor holds a mips or arm or
whatever core. Sure, other firmware cases consist of only register dumps, but
my own involvement in hardware development shows me that the trend is more and
more for peripheral hardware with embedded processor cores, and the firmware
of those being actual processors, some of them could run some variant of linux
(or uclinux at least) in their own right. This is especially true for high-end
raid cards and wireless applications.
Trying to argue, as other did before you, that it is just data, because that
is more convenient, thus ignoring the facts, is kind of misleading and
dishonest, and furthermore is the wrong strategical choise for debian, who has
long stood for free software, and would thus compromise its ideals for the
sake of convenience.
Furthermore, if you start going down this way, ignoring blatant issues like
the lack of source code for those firmware blobs, some of which are defacto
under GPL, and thus becoming fully non-distributable, and making the linux
kernel non-distributable, then you take the first step down a road debian
doesn't want to go. You will have to consider cases like the unicorn driver
(currently in non-free), which includes a soft-adsl binary-only library, or
issues like tge miboot bootloader, which includes a half sector of m68k
instructions, copyrighted by apple, and very analogous to the firmware case,
and then from there, you have to go further, and if you are true to yourself,
end up allowing everything in main.
Notice also that in the social contract, we already claim to support our users
and free software equally, and that we furthermore agreed to keep non-free
around for exactly those users needing non-free components, like those
non-free drivers or firmware, and there only needs to be a relatively small
technical work to be done for this to work seamlessly for all users.
So, if we of debian want to stay true to ourself, and not live in
self-deception just because it convenience us, then the right argumentation on
this should be of the following :
1) We aknowledge that there are some firmware blobs which consist of actual
code running on an processor embedded in a peripheral device, or
configuration code for fpgas and such, as opposed to pure register dumps,
which need actual source code to be considered free enough to pass the DFSG.
2) But, as the removal of those firmwares and drivers cause a major
inconvenience on the usability of the system, and
3) Peripherals allowing for uploadable firmwares are orders of magnitude
more free than peripheral where everything is hardcoded, or peripherals
where the firmware blob is embedded on a rom or flash or similar.
4) Upstream has long resisted considering the firmware situation, and is now
slowly setting up infrastucture to handle these cases, and removing those
firmwares from the main linux code, so the problem, will solve itself in the
future.
5) There is no way the kernel team alone or even with help, can solve all
the legal and technical issues in a timely fashion in order to not let the
etch release slip.
6) Given the above, and the fact that every past release of debian included
those non-free firmware blobs, the fact of delaying etch in order to solve
the issue, or releaseing etch with the non-free firmware blobs and then
working the solution, is not going to change anything with respect of the
released and development versions of debian.
6) We thus ask the project to temporarily waive the DFSG requirement for
those non-free firmware blobs, in order to let the etch release to ship in a
timely fashion, and let us work on these issues, within the kernel and
related affected teams, the project as a whole (The DPL could mandate a
delegate or delegate team to contact manufacturers and such), but also
upstream, in a calm and posed way, not hurried by the needs of the release,
and other such pressure.
I welcome help to turn the above in a GR, as i believe that this would be a
better and more honest way to allow non-free firmware in main, in all good
concience. This cannot be solved in a satisfactory manner by deluding
ourselves and the world at large, and it is always best to face reality, and
call things as they are, instead of what is attempted here.
Friendly,
Sven Luther
Reply to: