Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Make proprietary firmware and userspace optional #756
The built-in wifi and baseband will not work without proprietary firmware on practically all phones. However, we could allow the user to avoid installing these blobs, just like libre distributions do it.
(This is really easy in APKBUILDs and can be done with very few lines.)
We could directly skip the question, in case there is no nonfree subpackage for the device, and only show the firmware/userland choice when such a package exists.
The idea to let the user choose during the
What is not really clear, at least for me, are the options of the question.
With firmware I mean blobs, that other chips on the phone require to function. Such as the Wifi chip. They are not really part of the kernel, but the kernel loads them from the disk and passes them to these chips.
Speaking in package names, this would be any
With userland I mean blobs running in userland, such as proprietary Android RIL implementations (#598) or the userland GPU drivers (which work in combination with open source kernel module stubs, just like the proprietary nvidia driver for PCs as I understand it).
(In a broader sense, when we would port Anbox or similar software to run Android programs, WhatsApp etc. would also be proprietary userland programs. But differentiating between them and Free and open source programs from F-Droid running in Anbox isn't that easy and not worth discussing about right now in my opinion.)
referenced this issue
Oct 27, 2017
referenced this issue
Dec 12, 2017
This is going to change soon, as the userland blobs for talking to the GPU of the Nokia N9 have been packaged for postmarketOS. This is not in our
I have also considered naming the new folder
What do you think, everyone?
referenced this issue
Feb 24, 2018
I would be much more comfortable if it was in another repo altogether. Maybe we could add an "overlay" feature that supersedes pmbootstrap's packages if they are in some specially-named folders? That way, multiple projects could live on top of pmbootstrap, just a git clone away.
There are a few reasons to want to do this:
As for the wiki, I really don't know what's best. I really like the idea of having device information centralized. But maybe add a guideline that everything non-free should be in a dedicated category?
So, these are my two cents. What are your opinions on this?
Blobs in master?
This is probably what you've meant, but just to make sure no one gets this wrong: We don't have blobs in the master branch, we have package build recipes (APKBUILDs) which allow to build packages that have such blobs. They can easily be differentiated from the other packages, because they are in an extra folder (
Right now, firmware packages get automatically built/installed when you build any device package where WiFi works for example. The idea of this issue is to change that, so you can build/install the device packages without building non-free firmware (and possibly in the future: userspace) driver packages.
Having proprietary drivers around at all?
Motorola Droid 4
The Droid 4 from the pull request you have mentioned is a special case, because in contrary to almost all other devices on which pmOS boots, there's active mainlining progress and most stuff is working already (recent FOSDEM talk). That means going with mainline for that device is a no-brainer for postmarketOS.
So much for the theory. Practically, @NotKit was the only contributor who had access to the device. And his opinion regarding mainline on the Droid 4 is:
(This weekend the situation changed, there are 3 people now who have a Droid 4 and are interested in porting pmOS to it. They may decide to go with mainline now, or with both, and I will as usually help with making either solution work. pmOS does have support for multiple kernels per device btw, although that isn't really used at this point and may need some tweaking.)
Proprietary user-space drivers and postmarketOS
Personally, I prefer running with mainline and no accelerated graphics over having accelerated graphics with userspace blobs and being stuck with a downstream kernel fork. But NotKit is a skilled developer who, besides his huge libhybris work, has put a lot of work in porting Hildon for postmarketOS already (which is great for the whole project, no matter if one wants to run mainline or not - especially now that it's maintained very actively by Maemo Leste).
The Nokia N9 is a similar story: Filippz is mainlining it, and ported postmarketOS to it. He also made proprietary userspace blobs for the PowerVR GPU working on it (with the mainline kernel, not integrated in the master branch yet).
So I had a conflict of interests there: not supporting blobs vs. helping users accomplish what they want to do with pmOS. And I decided to go with my recommendation of integrating libhybris (userspace blob drivers in general), but making them entirely optional (and while we're at it, make firmware files optional as well). I think that is the way it fits best with what we wrote in the 100 days of postmarketOS post:
Split it into an extra repository or distro, make one of them FSF approved?
You're basically saying: Keep the non-free stuff around for people who want it, but split it from the main distribution so we can get the Free Software Foundation's Respects Your Freedom approval. Reading up on this again, the RYF is for hardware actually, but the GNU FSDG is the software counterpart.
I see a couple of problems with that approach for postmarketOS in general:
Besides that I can think of a lot more points that are debatable for FSF endorsement (Alpine not using the GNU stack, postmarketOS being a phone distribution without using cellular modem firmware is a joke, I think binary patching security holes in firmware is a good idea, what about the environmental aspect of not throwing devices away which only require one blob we could sandbox to still use them ...). I am not sure about what the FSF's points of view are on those exactly (PureOS is FSF-endorsed nowadays, does that also count for the Librem 5 and what about their Wifi firmware, do they work around that in hardware, so it can not be updated from the main OS? what about security updates then?). This leads me to another point: I don't have the time or energy to figure that stuff out. And whoever else would try to get the FSF approval for pmOS would have to deal with this as well.
Dude wrap it up
In conclusion, I think the FSF does a lot of great things and I would love to have devices entirely open sourced, including firmware, and I think the hacker community is skilled enough to do this with enough time (years) and manpower. But for the reasons outlined above I don't see why we should split postmarketOS in a libre and non-libre distribution.
Thanks for sharing your thoughts @MayeulC!
Thank you for the great writeup and in-depth answer, I generally agree with all the above points, which means I'm OK with the current approach.
Kind of off-topic, but just an idea regarding multiple kernels: maybe pmbootstrap will be able to offer the user a choice at some point; I think the way pacman handles multiple providers is nice, and such a mechanism could be unified for choosing between DE, kernel and other components.