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

Re: NEW handling: About rejects, and kernels

On Mar 27, Thomas Bushnell BSG <tb@becket.net> wrote:

> > Maybe. But why won't you refute the arguments that are there?
> I don't need to.  What we are lacking is not those arguments, but the
> key missing pieces: what freedoms do you want to insist on (as opposed
> to the DFSG)? and why should we accept lesser freedoms for this one
> class of software?
You are showing again that bad case of selective reading... I answered
to both questions in this thread.

> > "Refusing to distribute binary firmwares does not help free software. You
> > may choose between getting the firmware with your hardware on a flash
> > EPROM chip or having your driver load it, but at the end of the day you
> > will still use some software whose source code is not available. If
> > removing binary firmwares from debian makes using free software harder
> > for our user then it harms the free software cause."
> This is like saying that people will use star office whether it's DFSG
> free or not, so there is no reason to say "we won't distribute this
> until it's DFSG free".  In fact, people can and do make things free.
Maybe eventually this will be true for firmwares too, but so far I have
not seen any third party writing from scratch a non-trivial firmware
without help from the hardware vendor.
This is why the proposed exception is temporary, recognizing that things
may change.

> We should tell users: we are unable to support this hardware, because
> we don't have the source.  Among other things, we are unable to fix
> security bugs in it.
We are unable to fix security bugs in hardware with non-modifiable
firmware and modifiable but permanently stored firmware too. Should we
drop support for these devices too?

> No.  Why do you think we insist on the source for programs in general?
> Why do we insist on the source for openoffice.org or emacs?  Is it
> just mindless?  No.  It's for good and worthy reasons.  You need to
> explain why those reasons somehow don't apply in the case of firmware.
We tried, but you are just not listening...


Attachment: signature.asc
Description: Digital signature

Reply to: