From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxim Cournoyer Subject: Re: [GNU-linux-libre] Free firmware - A redefinition of the term and a new metric for it's measurement. Date: Sun, 05 Feb 2017 14:53:01 -0800 Message-ID: <87k2948d2q.fsf@gmail.com> References: <87tw8bjhqm.fsf@gmail.com> <2c7ae911-863f-4831-f024-060e5f899d3a@alaskasi.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37613) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1caVgD-000401-Cz for guix-devel@gnu.org; Sun, 05 Feb 2017 17:53:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1caVgC-0000WP-3O for guix-devel@gnu.org; Sun, 05 Feb 2017 17:53:09 -0500 Received: from mail-pg0-x243.google.com ([2607:f8b0:400e:c05::243]:33323) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1caVgB-0000WB-Qx for guix-devel@gnu.org; Sun, 05 Feb 2017 17:53:08 -0500 Received: by mail-pg0-x243.google.com with SMTP id 194so7339935pgd.0 for ; Sun, 05 Feb 2017 14:53:07 -0800 (PST) In-Reply-To: <2c7ae911-863f-4831-f024-060e5f899d3a@alaskasi.com> (Christopher Howard's message of "Fri, 3 Feb 2017 09:44:16 -0900") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Christopher Howard Cc: guix-devel , Workgroup for fully free GNU/Linux distributions --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Christopher Howard writes: > Hi David, I don't agree that just being given a redistributable blob is > any wonderful thing. What you end up with down the road (and this is > where we are now) is systems that need several (or many) blobs that only > the providing company understands and controls. Usually these blobs are > in control of critical or highly desirable functionality. You don't know > for sure what the blobs do or whether or not they have security > vulnerabilities. And sometimes the blobs come with restrict licensing > allowing distribution but not allowing you to reverse engineer. > +1. I don't see how having blobs helps security at all. David, you mentioned that having blobs could help manufacturers fix security issues (human errors) in their products; while true, this is a double-edged sword; it could also be used to insert spyware or whatnot, and very easily (simply release a new version of the blob for distribution, advertising it as bringing "fixes"). I think the FSF's position, as expressed in their "Respects Your Freedom" certification guidelines [0], is reasonable given the current state of things. Basically it says that "All the product software must be free software.", but grants some exceptions for software equivalent to hardware (e.g., fixed in ROM and non-upgradable) [1] and which runs on "secondary embedded processors" (which can include firmware built into I/O devices). For the time being, the hardware we use is closed. Just as we reluctantly accept to use non-free hardware for the time being, we can reluctantly accept to use non-free software which is equivalent to hardware. Whether the non-free firmware is stored as a loadable blob or in the ROM of a device doesn't change the fact that it's non-free. The subtlety is whether this firmware is used as hardware (upgradable) or software (easily replaced or extended). The later puts more control in the hands of the manufacturer, which is why the former is preferred. The RYF criteria page also states that they "want users to be able to upgrade and control the software on as many levels as possible.". In other words, a device with completely free firmware is more valued than a device with a closed firmware used as hardware, as it should be. Finally, preferring built-in, closed firmware to loadable blobs (closed firmware) could be seen as an incentive for manufacturers to release their firmware as free software (user-upgradable): releasing it as free software enables them to fix things (in a transparent manner) after the product is launched, which reduces risk (if the firmware is non-upgradable, the product could have to be recalled in case a serious problem is later found with it). > For firmware development to be practical, you want more than > documentation. You want source code. Also (for embedded development) you > want a tool chain. You might have the source code but find it near > impossible to build because you don't have a good tool chain. > The RYF criteria includes a "Compilation" (all the software must be buildable using free tools) and "Documentation", so this is at least summarily covered. > Yeah, with documentation, you might be able to engineer the source code > and tool chain... but it might take you 3+ years, and then only if > enough people are interested. And by that time no one will want the > hardware anymore. This isn't a moderately annoying problem for x86, but > it is a major problem for tablets, cell phones, and other embedded > development. > > The companies that should be the rewarded are the ones that release > firmware, source code, and tool chain. E.g., Thinkpenguin and the TPE-R11= 00. > Indeed, we ought to put our money where our mouth is, i.e. back the companies which are helping the cause of free software/hardware. My two cents, Maxim [0] http://www.fsf.org/resources/hw/endorsement/criteria [1] The "fixed" part is not worded directly in the RYF criteria, but from the anti-tivoization clause found in the GPLv3, I would expect that this is how they would consider the matter. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJ9WGpPiQCFQyn/CfEmDkZILmNWIFAliXrM0ACgkQEmDkZILm NWKnCg//bFTsK//DE/m8qtBoxLg6Q/+3YB8BefzdUT7RB+caNsRx/GOM//CkEIYV Sehcj73XEqsohSN/rIamGB3Km5kI4wmd/DOwB8VcG/u91/ok0oZq+Gyd8u15jwM2 9Klv0VZ+WJ+q5i21otgdlG9ttX79Gh4CHEAIQaIVWv9PWswQ9B0+ItqqhfkYtrcc 4xxc+Es/Gm6WXB0NBdDQ9IfbXP2filDUq+/DHAQX80KbN5+cnokU9uLm5kut5cpP AQBmnctm42Rawa/Xakacl2KBaA1VpGYUxlBwKmqReuNYWpKMhsHiBU7Dl5VbyRet bXEN844U2VEiQcIWioYvIJIruK5EaZj9U6SCjX3m829BXc+DQRo/Yu9u7/2j+n8i Jg1SnRY5bB83ms1Fp1LnqF6VBCFzzndx9x97EVHWAhPN5dcO4pBRpsDzJIbQcrLQ OijpidqOBGKKSbeEtu3UXrBjFR7lMJMvBYpYKjPTQHbyeGu7Lt9xQO+WgmcR11Zd /nB/TEY9rGxTIp8F9y0SM68I5K9VeVk3x2jG1Qe2lQYQyCep9dCrBGdaa9GkETqt G9p3Uz71jQH8KZYhippeU+B3NMhfTrpTkCG1++XjNQ9ad4FhZKAyoo663bA+kiIh TpNVqt6+8GKAnlcfQkpx7iTbD93AjrPo2Bk2XF2E0vvvZGNvbko= =XkiE -----END PGP SIGNATURE----- --=-=-=--