FSF announces Librephone project

It rather depends on what that 1% is.

The low-level code is what's most important to be free. If you have free firmware and drivers and operating system but then you still have to run a Windows VM or WINE for an old proprietary app, you can only have problems when running that app.

If you have opaque blobs interacting with the hardware, they can crash the whole system, expose firmware-level security vulnerabilities with persistence and the blobs are specific to a kernel version so when the vendor stops providing updates, you're stuck with an obsolete kernel version with known security vulnerabilities. If anything needs to be free software, it's that.

> This is especially noticeable when they fight against projects that precisely do a lot for open source, like github (See GitLab/Savannah), or Android, they are 99% of the way there, give them a break.

Android is "open source" but then the devices are Tivoized or you run into attestation failures if you actually want to run your own version of it. GitHub literally got bought out by Microsoft. These seem like legitimate concerns.

>extracting/copying a firmware blob is not clean-room design

It's stage 1. Clean-room reverse engineering is about working with the nature of copyright, and classically goes roughly like this:

1. You set things up with a "contaminated" or "dirty" side team who have direct exposure to the IP in question, and a "clean" (or "virgin" is another older term) side team that are thoroughly firewalled. The clean side must only have devs who have never ever had any exposure to whatever it is you're trying to clean replicate [0].

2. The dirty side is in charge of producing a "fact sheet"/spec. That side absolutely extracts/disassembles or whatever else to get at the target, which is precisely what "contaminates" them. They are looking at copyrighted code. Then they use that research to a create a purely factual spec, which is then passed across the firewall to the clean side. This must be the only communication.

3. The clean side then uses that to write new code themselves that will handle state per the factual spec they've been given.

The reason it works is that (in the US) purely factual information cannot be copyrighted, there's no "sweat of the brow" doctrine or the like. Copyright, unlike patents, does not cover ideas or methods, it's about the creativity of the person in question. You can't copyright the mathematics of a function, of "when X input is received Y is output", or of general concepts. So if two (or more) people independently create works that happen to cover the exact same subject matter, but can prove they were fully independent, then it doesn't matter even if it happened to be literally identical (however improbable that would be). Each would have their own independent copyright on it.

So clean-room RE avoids all the legal snarls around "how close is this" in favor of the simple binary question of "did the team that wrote this RE'd code have any exposure whatsoever to copyrighted IP?" If the answer to that is "no" that's the end of any legal complaint, because by definition their output cannot be a derivative work. Software patents short circuit that, part of the many reasons they're evil, but as a practical matter the number of really fundamental hard to avoid ones is rapidly shrinking because it's 2025 and by 2005 a lot of the foundations had long since been done.

----

0: Which is not necessarily trivial to hire for, because the kind of person who has the kind of skills you need also is going to tend to enjoy hacking around and reverse engineering stuff for fun anyway increasing the chance they've managed to contaminate themselves.

/e/ rolls back privacy and security far more than LineageOS and /e/ includes their own invasive services. Murena services even send data to OpenAI without user consent.

https://discuss.grapheneos.org/d/24134-devices-lacking-stand... is a detailed post covering the lack of privacy and security of /e/ with a bunch of linked sources including other detailed posts by third party privacy and security researchers. It also touches on the lack of security of Fairphone hardware including end-of-life Linux kernel branches not getting LTS updates and delays for driver/firmware patches, but it's much worse with /e/.