[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: