:: Re: [Dng] straw poll, non-free firm…
Góra strony
Delete this message
Reply to this message
Autor: Nate Bargmann
Data:  
Dla: dng
Temat: Re: [Dng] straw poll, non-free firmware for installers
* On 2015 03 Jun 16:55 -0500, alexus / dotcommon wrote:
> On Wed, 03 Jun 2015 20:37:22 +1200
> Daniel Reurich <daniel@???> wrote:
>
> >Hi,
> >
> >I'd like a straw poll on whether we should include non-free firmware in
> >our installers by default.
>
> So that people should fork Devuan to get a truly free system by default?


Even if the questionable firmware blobs that come with the standard
Linux kernel tarball are available on the installation media, there is
no requirement that you or anyone else must use them.

> >It's a deviation from Debians traditional position, but a pragmatic one
> >that shows we care about the end users.
>
> Hum... This sounds very strange to me...
> I was thinking having care about end users should mean help to avoid
> non-free software (not to use it by default), particularly if it deals with
> non-free blobbed firmware which have heavy implications in terms of privacy,
> tracking and surveillance...


Maybe I'm the one who is in the wrong, but I think the fretting over
"non-free" is a bit excessive in this thread. No one is demanding that
the *installer* install Adobe Acrobat or Adobe Flash (that happens long
after the installer has completed its work and is rightfully a user
choice). What is at issue, as I see it, are the various in-tree kernel
hardware blobs that for one reason or another Debian chose to call
"non-free". Keep in mind that Debian also relegates certain GNU manuals
into the "non-free" category. Are they non-free? I'm guessing RMS
doesn't think so. If the "non-free" firmware blobs that Debian dubs
"non-free" really could not be distributed with the kernel, then they
wouldn't be there, so I don't think it's a legal issue. I happen to
think that Debian went too far in removing various kernel bits from the
installer.

Also, not all of the "non-free" firmware is in such a state due to
hard headed manufacturers. As I understand it, the US FCC has rules
about the end user not being able to configure the hardware
(particularly anything that transmits a radio signal) to exceed
regulatory parameters. Years ago I was led to believe that was the
reason the old Atheros MadWifi driver had the binary blob. The current
ath5k/ath9k drivers are community developed. Fortunately, the US FCC
hasn't sent the US Justice Department after the developers.

- Nate

--

"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us