Paul Kocialkowski's coding blog

Over the past months, I've been looking at moving my computing setups to more freedom-respecting ones. Currently, both the laptop and desktop that I use for doing serious work (read: writing code) are based on recent Intel platforms and run with a proprietary UEFI/BIOS. I initially made that choice to be able to run a fully free system, such as Trisquel, since Intel platforms come with fully free GPU drivers that don't require additional non-free firmwares and are officially supported by the manufacturer. Support for most other aspects of the hardware is also close to being flawless, so this makes the whole user experience really nice. However, it goes without saying that things aren't actually all that pretty, given that there is still a proprietary UEFI/BIOS in there, CPU micro-code updates, firmwares for e.g. the USB3 (xHCI) controller (all of which are pushed by the UEFI/BIOS) as well as a management engine (ME) and Intel's active management technology (AMT). So it all looks pretty from an operating system perspective, but things aren't at all pretty under the hood. All that brings serious concerns for privacy/security, but this is not really what I am the most concerned about, personally.

Recently, I got to appreciate running with a fully free bootloader when working on various aspects of U-Boot, the popular free software bootloader that is widely used on embedded devices, when freeing some of those devices “from the ground up”. However, I am not really using any of those devices (e.g. single board computers) that I am working on, since they simply aren't a good fit for doing any serious work on them. I tried using some as home-theater PC, but the state of the art of free software support doesn't allow that use case yet. Hopefully, we will one day be able to run Kodi on those: there are promising leads on the i.MX6 platform with Etnaviv and hardware-accelerated video decoding, despite using a proprietary firmware. On the other hand, Allwinner platforms have some hardware video decoding support, both reverse engineered by the sunxi community and released by Allwinner, but I couldn't get it to work sufficiently well to allow watching a full 720p movie. Perhaps the lack of proper graphics acceleration is to blame here, I can't really tell (and there is already some 2D acceleration for Xorg). Qualcomm platforms do have some nice graphics acceleration and 3D support thanks to Rob Clark's work on freedreno, but those platforms don't allow running a free bootloader since the bootrom enforces a signature check on it, which is a no-go for me. On the other hand, I recently found out that using mesa and llvmpipe on the most powerful devices does bring a significant change, but it is still not packaged with Debian on armhf!

Still, those boards remain good for some other use cases, such as powering the servers that I use for hosting various services that I use on the Internet. This is actually one of the reasons why I got involved in working with embedded hardware, and those devices are still as good a fit as they were back when I started playing around with them. In addition, now that I started freeing mobile devices such as the LG Optimus Black (P970) and Allwinner tablets, I may also use those with Replicant. I got used to using the Galaxy Note 2 (N7100), that has a proprietary and signed bootloader, as my main phone after a year or so of daily use, but it's probably not too late to switch to a more freedom-respecting one, even if I'll probably miss some aspects of the big Samsung device. Either way, using the device I'm currently working on is one of the best ways to ensure that it's actually usable.

So this opens doors for liberating some aspects of my use of computing, but the computers I am using the most daily, my laptop and desktop, still remain fatally flawed. I have been looking at the list of devices supported by Coreboot for a long time and now that Libreboot came around, it's even easier to get an idea of what laptops and mainboards can run with fully free software, or close. At this point, the laptops supported by Libreboot are simply too old to fit my use case. I need something that can handle building a Replicant image in a decent time, that is an hour or so, without running out of memory. Thus, I wondered what could come closest to being fully free, both regarding software executed on the main processor and firmwares running in separate chips. Among the most recent boards supported by Coreboot, I decided to skip the Intel ones, since their ME is nearly impossible to disable or liberate (it is signed). In addition, not all of those have free native DRAM initialization and free video BIOS support, despite developers' truly great efforts there. Thus, I started looking at boards based on AMD platforms, the other half of x86 platforms as they exist today. A little while ago, AMD made a nice move forward by freeing their AGESA BIOS reference code for inclusion in Coreboot, which supports recent chipsets (I was told they have decided to stop contributing, though). The code itself is a nightmare to work with and the fact that it's used as-is in Coreboot doesn't make development a particularly fun time, but at least, it's there. And it allowed developers to add support for a few interesting boards that are rather recent. A few interesting desktop motherboards are there and one particularly caught my attention: the F2A85-M.
At the time of writing, a slightly different version of it, the F2A85-M PRO is still being sold brand new in (French) online shops, so it's very easy to get. Former Replicant developer GNUtoo and I decided to get one each and get Coreboot running on it as soon as possible. Apparently, someone already attempted that port in the past, but gave up without publishing all the work in progress patches. Only code for the Super I/O (that is different from the non-PRO version of the board) was found, so we still have to figure out what the other differences between the F2A85-M and the F2A85-M PRO are to properly support it in Coreboot. Getting in touch with the original developer who gave up could come-in handy for this.

Among the boards supported by Coreboot (thanks to the AMD AGESA code) is a laptop matching my expectations: the Lenovo G505s. It is somewhat similar to the F2A85-M, only that it trades its Super I/O for an embedded controller, a better fit for a laptop and its required power management constraints. Both of these come with a Radeon GPU inside the CPU (and if I got it right, some versions of the G505s also have another Radeon GPU on-board), which also holds the northbridge by the way. At this point, the Radeon GPU cannot be used out of the box without both a non-free video BIOS (that is a blob executing instructions to set up the video card at UEFI/BIOS time) and a non-free firmware. However, that situation could probably be improved.

Since we're stuck with the Radeon card on the G505s, there is very little choice but to use the video BIOS (it also holds necessary bits for the radeon driver to work). One might also prefer not to use the proprietary firmware that runs in the GPU and avoid the radeon driver at all, but this will end up in using VBE (VESA BIOS extensions), that callbacks to the video BIOS in the end. Of course, on such a powerful laptop, using llvmpipe instead of radeon as mesa backend can be painless for many use cases.

On the other hand, the F2A85-M has full PCI-e ports, so one can plug-in an external nVidia card that is supported by nouveau, the free software graphics driver for those. Display support in Coreboot still requires the non-free video BIOS (and it also has some bits that are needed by nouveau). In addition, the nouveau driver also requires a firmware to run on the card, but it was freed for the card that I decided to settle for, a GeForce 610 with 2 GiB RAM. Early tests report that it should cope just fine with the things I do on that desktop computer (gnome-shell, flightgear and some more).

In addition to full-size desktop and laptops, I also got myself interested in smaller (and more traveler-friendly) form factors on which I can still do significant work. I have been looking at Chromebooks for some time now, especially because they ship with Coreboot and free software on the embedded controller, which is quite unique. However, up until recently, all the Chromebooks needed proprietary software to boot up (for various bits on Intel x86 platforms or because the bootrom was enforcing a signature check with a manufacturer key that cannot be replaced on ARM platforms). However, Google recently released a batch of Chromebooks based on the Rockchip RK3288 SoC (the veyron family), that is known (thanks to the rockchip community and the various makers of community-friendly hardware based on Rockchip chips) to not enforce such signature checks. Thus, it allows running a free bootloader as early as possible. The C201 Chromebook by Asus was released a few months ago with a RK3288 SoC, so I decided to get one of those and see what we can do with it. The goal is to port Libreboot to it and so far, the results have been very positive: that's the machine that I am currently using to type this post and it's running with fully free software from the bootloader (Coreboot) up to the operating system. All the micro-controllers I'm using on it are also running free software (that is, using an external ath9k_htc Wi-Fi dongle). The security model implemented is truly great, kudos to the Chromium OS developers for it! I was indeed able to replace the keys inside the RO part of the SPI flash memory, sign a kernel with my own keys and have a verified boot setup that way!

All that stuff keep me busy (and sadly, makes me way behind on Replicant-related work), so stay tuned for more details on specific aspects of those things!

A couple days ago, I announced, on the behalf of the Replicant project, the release of the Replicant 4.0 SDK, motivated by some recent license change regarding the Android SDK: Google decided to put an overall non-free license for their SDK. After talking about it on IRC, FSFE member Torsten Grote decided to write an article to raise public awareness: Android SDK is now proprietary, Replicant to the rescue. In the next few hours, that news was being relayed by some online IT media and it sometimes got a bad review, calling our statement a “non-issue”. Let's check our facts and clear out the situation.

It was first brought to our attention that the SDK is being released under a non-free license only a couple days before releasing the Replicant SDK. We didn't know about it before and thus assumed that this was a recent license change. As a matter of fact, we were wrong: we have been told since then that these terms of use have been there all along the way and only a small part about fragmentation have been added with the Android 4.2 release. However, as far as I can remember from the past (and please let me know if I'm wrong), the end-user didn't have to explicitly agree to these terms before downloading the SDK. Now they are required to do so before being able to download the SDK package. That's one first thing that we find unacceptable: we believe that anyone should be able to develop applications for the Android platform without having to agree to such terms. Now let's take a closer look at what the user must actually agree to:

you may not: (a) copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the SDK or any part of the SDK; or (b) load any part of the SDK onto a mobile handset or any other hardware device except a personal computer, combine any part of the SDK with other software, or distribute any software or device incorporating a part of the SDK.

These conditions seem totally unacceptable to me and are likely to cause a reaction such as calling the Android SDK proprietary from anyone who values software freedom. However, let's not stop there and let me get back to what is right before these statements in the license text:

You may not use the SDK for any purpose not expressly permitted by this License Agreement. Except to the extent required by applicable third party licenses, 

The last sentence is the meaningful one: it means that basically, the restrictions are not applicable to software that is covered by another free software license. So that's basically how Google can avoid breaking other licenses terms. Moreover, Google is not the copyright holder for all of the software released in the SDK, so they basically have no right to apply such restrictions to it. Huh, we're safe, after all, the Android SDK still is free software. But wait, is it really? Are all the files shipped with the Android SDK proven to be free software? If that was the case, then why would Google waste some time writing down these terms if they actually do not apply to anything in the SDK? So that point gives us fair enough reasons to suspect that there is actually proprietary software in the SDK. Yet another good reason to release a free SDK such as the Replicant SDK. Now let's consider the Android SDK manager utility: it is designed, down to the source code, to check for plug-ins and updates from Google. If I recall correctly (once again, correct me if I'm wrong), there used to be a clear license statement for each components: the Google APIs were shown as non-free software in an explicit way and the emulator images were somewhat shown as containing mainly free software. Now Google changed all this, and all the components show the same EULA terms. Now how can the user make any difference between what's free and what's not in that components list? Sounds harder than it used to be, and like a problem to us. That's why the Replicant SDK won't check for new components from Google. So here are the reasons why we call the Android SDK proprietary and why we think that there is a problem with it. Even though not all of this is a sudden change, why would it be any less relevant to try and raise public awareness about the issues we've spotted?

2013-01-06 Update: I've checked the license of the individual software components shipped with the Android SDK and it turns out that all of them are covered by a free software license. What's the point of that overall proprietary license then?