all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: taylanbayirli@gmail.com (Taylan Ulrich Bayırlı/Kammer)
To: David Craven <david@craven.ch>
Cc: guix-devel <guix-devel@gnu.org>, gnu-linux-libre@nongnu.org
Subject: Re: Free firmware - A redefinition of the term and a new metric for it's measurement.
Date: Fri, 03 Feb 2017 18:40:01 +0100	[thread overview]
Message-ID: <87tw8bjhqm.fsf@gmail.com> (raw)
In-Reply-To: <CAL1_im=_R__Cp2aOAEAne7dveu6aYkg17zu0Pftg+pKAv_JbuA@mail.gmail.com> (David Craven's message of "Fri, 3 Feb 2017 15:37:32 +0100")

David Craven <david@craven.ch> writes:

> Solution:
> We need to encourage and allow option 1 as opposed to option 2.
> Hardware suggestions by the FSF should instead of focusing on a black
> and white - needs binary blobs or does not need binary blobs - focus
> on the following:
>
> 1. The firmware is freely redistributeable - allowing free software
> distributions to redistribute the firmware as opposed to the user
> having to download the firmware themselves and accept arbitrary terms
> and conditions.

Being freely redistributeable doesn't make a blob free software
obviously, so endorsing such blobs would be out of the question as per
the core principles of the FSF.  Correct me if I misunderstand.

> 2. The firmware can be loaded using the standard kernel api and the
> device does not contain any internal storage.

Sounds good.  Having non-free software hidden within a hardware device
is obviously no better than having the OS insert it there whenever the
device is connected, as per the reasons you explained.  (Assuming I
understood it correctly that that's how it normally works; I'm a
hardware noob.  I actually thought firmware blobs are just code loaded
into kernel space, like drivers.  Embarrassing?)

> 3. There is documentation available that enables the developement of
> free firmware.

Definitely yes.

If I understand the situation correctly, I definitely agree that the FSF
should stop being blind to proprietary software hidden within hardware
devices in their endorsements.  Such devices should be discouraged.  But
the FSF would never endorse any other proprietary software / binary
blobs either, if I know anything about their principles. :-)  (And I
agree with those principles, to be clear.)

Thanks for raising this issue.  I had not heard of the trend of putting
proprietary firmware directly into flash storage on hardware devices to
give the illusion that they don't require binary blobs to run.

Taylan

  reply	other threads:[~2017-02-03 17:40 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-03 14:37 Free firmware - A redefinition of the term and a new metric for it's measurement David Craven
2017-02-03 17:40 ` Taylan Ulrich Bayırlı/Kammer [this message]
2017-02-03 18:18   ` David Craven
2017-02-03 18:44     ` Christopher Howard
2017-02-03 20:12       ` David Craven
2017-02-05 22:53       ` [GNU-linux-libre] " Maxim Cournoyer
2017-02-10 17:31         ` David Craven
2017-02-10 18:21           ` Christopher Howard
2017-02-13  7:02             ` Maxim Cournoyer
2017-02-13  8:42               ` [GNU-linux-libre] " John Darrington
2017-02-13 19:24                 ` David Craven
2017-02-13 21:21                   ` [GNU-linux-libre] " Hartmut Goebel
2017-02-13 22:48                     ` David Craven
2017-02-14  6:55                   ` Maxim Cournoyer
2017-02-14 10:41                     ` [GNU-linux-libre] " David Craven
2017-02-14 17:47                       ` Maxim Cournoyer
2017-02-14 12:15 ` Denis 'GNUtoo' Carikli
2017-02-14 18:43   ` [GNU-linux-libre] " David Craven
2017-02-14 20:11     ` Adonay Felipe Nogueira
2017-02-14 20:47       ` David Craven
2017-02-14 20:57         ` Christopher Howard
2017-02-14 21:01           ` David Craven
2017-02-14 21:13             ` [GNU-linux-libre] " David Craven
2017-02-20  7:50     ` Denis 'GNUtoo' Carikli
2017-02-21 12:15       ` David Craven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tw8bjhqm.fsf@gmail.com \
    --to=taylanbayirli@gmail.com \
    --cc=david@craven.ch \
    --cc=gnu-linux-libre@nongnu.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.