Re: 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 Wed, Aug 23, 2006 at 03:17:27PM -0700, Steve Langasek wrote:
> On Wed, Aug 23, 2006 at 09:09:31AM +0200, Sven Luther wrote:
> > 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),
>
> This GR doesn't use the word 'code'.
Whateve, it uses the word program, so please stop nit picking, and replace
code by program or whatever word you where using. The meaning of it is the
same, and everyone is able to see that.
> > 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,
>
> This is FUD. Nothing in this proposal says that we will ignore licenses
> when distributing firmware or any other works.
Maybe, but you take the first step toward this, so when will you stop ? Also,
there are currently stuff in non-free, or even which was rejected in non-free,
which could arguably be using the same kind of permissibility as the firmware
code, like the miboot apple copyrighted boot sector, which is only 256 bytes
of m68k assembly doing some apple rom traps, which it is doubtful can be
written in another way, where the source code was probably m68k assembly to
start with (and there is a deterministic 1-1 mapping between asm and machine
code), and in any case is probably lost in some long forgotten apple box, as
it was probably not compiled since 10+ years.
Yet, this one was refused to go even in non-free, and if i remember well, even
you were of that opinion.
The miboot boot sector is needed to boot those oldworld apple machines, and as
thus are in the same category as the firmware which enable usage of the
hardware piece they are for.
So, consistency or hypocrisy ?
> > 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.
>
> I would prefer it if you would strike references to "non-free" in the above
> and replace them with the term "sourceless", to keep the scope the same as
Well, the DFSG clearly state that programs need to have sources to be free. so
i don't really see why you are afraid to use the right word for it ?
> the current GR proposal. With that change made, I would encourage you to
> propose the above as a formal amendment -- I would reject the amendment, of
> course, since it doesn't agree with my views on the matter, but I think it's
> a viewpoint that deserves to be represented on the ballot.
I will do so. I will even go beyond and propose two amendments, with the same
wording, and with or without 6). Need some time to clarify it and get help to
get it in the right english shape though.
Friendly,
Sven Luther
Reply to: