Fairphone

English

FP2: Compiling a blob-free variant of Fairphone OS

Participate Development
,
#1

Hi folks (read: developers),

since there are many problems reporting build issues and no prebuilt images for the open source edition of Fairphone OS available (yet), I am opening this thread to discuss the idea for building a blob-free (yet not functional) version of the FP-osos. This would have the huge advantage, that builds could be shared in public and we maybe we could also set up an integration server so we would know, which states of the repo/source code build successfully and which don’t in a reference build environment. But to make the builds actually useful, we would need to evaluate at least the following aspects:

  • is it possible to successfully compile the system without downloading/extracting the blobs? (read: are they a compile-time requirement?)
  • can the blobs be re-packaged into a flashable ZIP, so they can be flashed on top of a blob-free build in recovery to make the build actually useful? We could develop and distribute some sort of script / installer for that. And maybe even the FP team could provide the blobs in such an repackaged form?

Btw.: The mozilla ppl are developing something similar for Firefox OS, but it relies on having a desktop computer connected to the phone:
https://bugzilla.mozilla.org/show_bug.cgi?id=1166276

What do you guys think about this approach?

7 Likes
Fairphone 2 and CyanogenMod / LineageOS
Fairphone 2 and CyanogenMod / LineageOS
#2

I think so. The easiest way would be a little server at FP that just offers “secure” builds. If you compress them with LZMA/LZMA2 (“xz”) all images together are only around ~216 MB. I don’t think that there’s a secret google NDA out there that forbids FP to share a 2nd free’ed image, so I guess all it needs is some more time and a reliable build/bug tracker system on the FP side.

But I think their biggest fear right now is to get too much work by providing all these different images. They just don’t have the manpower to do all this (4-5 people + some help in China and maybe Qualcomm). Currently they are busy enough fixing the existing Google FP2 images.

But I fear nothing else will work, due to the pretty stupid license.

1 Like
#3

Well, there are third-party continous integration services / stacks like OpenShift or travis-ci where you could compile stuff in the (more or less trustworthy) cloud. My intent was not to have directly “secure” builds for production use, but to have a clean reference environment and be notified when things break due to commits in the source code or dependant reposities. Talking about secure builds: The Fairphone builds are compiled using a precompiled toolchain, like most other Android ROMs.

The “pretty stupid license” is no issue as long as you can really compile things blob-free and apply the blobs afterwards during installation, as long as all code from AOSP and Fairphone is available under free licenses.

2 Likes
#4

Dear moderators (@joe @Lidwien @Stefan @paulakreuzer)

could one of you give this thread the “Developing” badge, please? Thank you!

:de: Fairphone Open für Dummies?
#5

I’m assuming you mean “move it to the #software:dev category”? Done.

1 Like
#6

But it should be theoretically possible to rewrite the binary blobs to free drivers…Theoretically, i’m in no position to estimate the work which has to be done :wink:

#7

Theoretically yes, practically (almost) no. There are very few examples of this, one is Replicant’s libril /“Samsung RIL”) for old Samsung Exynos devices, where the proprietary RIL stack was successfully replaced. But even on such old devices things like wifi, bluetooth or 3D accelleration don’t work without blobs.

#8

Possible but not allowed by law. The companies do it anyway, but they exchange money and patents later. For normal people, this is impossible … it’s too much and too expansive. It needs a lab with lots of equipment, well educated people … and years of work.

You can buy schematics and code fragments to get started on the net but all this money would be spend in vain and you would get sued later anyway. :frowning:

But yes it’s a business model and it keeps people employed to develop new things. It’s a “two edged sword” and way too often used for the wrong reasons :frowning: (Bluetooth, anyone?)

#9

I don’t think the legal issues are the main concern here - but it depends on whether you attempt to decompile the binaries and so on. The binaries are basically just firmware and drivers, why shouldn’t it be allowed to produce free replacements? And there is alternative hardware for which these free replacements do exist…

1 Like
#10

I think this is a great idea. It looks like Fairphone may be willing to work something out with the community, for example prodiving the precompiled non-open-source components separately. In that way we could have a community repository, make our own builds (e.g. apply for an OpenStack grant), and figure something out to add the non-free binaries (ideally from the phone itself, otherwise a simple script to put them in the community-build images).

3 Likes
#11

I’m not against it, I’m just trying to explain how it is right now. And yes, people implemented stuff. Because people could access schematics and code fragments for those chipsets and/or reverse engineered it parts of it. As I said there are countless examples that people tried and sometimes it work – and most of it happens in companies. But it was never easy for “normal” people and it is a lot of work. Especially if one want to release it in the public. That’s all I can say about it.

Laws in this field are just Industrial lobby work, so it hard to quote something meaningful. But in the end there are very small exceptions, but … see for yourself:

“The unauthorised reproduction, translation, adaptation or transformation of the form of the code in which a copy of a computer program has been made available constitutes an infringement of the exclusive rights of the author. Nevertheless, circumstances may exist when such a reproduction of the code and translation of its form are indispensable to obtain the necessary information to achieve the interoperability of an independently created program with other programs. It has therefore to be considered that, in these limited circumstances only, performance of the acts of reproduction and translation by or on behalf of a person having a right to use a copy of the program is legitimate and compatible with fair practice and must therefore be deemed not to require the authorisation of the rightholder. An objective of this exception is to make it possible to connect all components of a computer system, including those of different manufacturers, so that they can work together. Such an exception to the author’s exclusive rights may not be used in a way which prejudices the legitimate interests of the rightholder or which conflicts with a normal exploitation of the program.”

Source: Directive 2009/24/EC

1 Like
#12

Thanks for the background info @fp1_wo_sw_updates - but let’s keep the discussion here ontopic which is not replacing the non-free binaries by free alternatives but providing just a “crippled” blob-free build where those binaries can be flashed on afterwards - or free alternatives, in the (very unlikely) case they should become available.

1 Like
#13

I think you should ask the developers/support if it’s possible to just remove the blobs from the build after the fact and copy them into the images later.

I don’t think so and even if, this is just a crazy “lawyer” workaround that wouldn’t change a thing. Because if FP will offer the builds, they can also just include the bin blobs. I don’t see the point here. But maybe I just misunderstand something.

#14

The idea is not to remove the bin blob afterwards but to compile without them, making sure that the open source parts build without them and they are not included at all. It’s not a “lawyer workaround” but a clean build that can be freely shared and distributed without any fears from the lawyer, since we are building pure Apache 2.0 and GPL licensed code here.

For making such builds actually useful for the end-users, we need a way for them to install the blobs on top of this build. So either we could build a script/apk/whatever which extract the builds from their device and puts them in a flashable ZIP they flash later or we give them some desktop tool which turns the blob-archive available from the website into something flashable.

5 Likes
#15

Currently such a script would be docker. I’m not sure if there is a better way, I fear not. And I think docker is a waste of time and resources for each end user. :frowning:

But I will shut up now, maybe other people will know more than I do.

#16

@fp1_wo_sw_updates a docker script sounds too complicated for a regular end-user to me. Did you look at Mozilla’s blob-free installer linked in my first posting already?

#17

My wild guess would be that this only suits Firefox OS builds, doesn’t it? And I don’t think that the FP team has the resources to code a similar tool only for FPosOS.

#18

Ok guys maybe I am seeing thing too simple here. But my understanding is, that the bin blobs wont be changed in the compiling process, but rather copied to some destination in the final image, right? I think that’s the whole idea of having them in binary form in the first place, so they won’t change… Wouldn’t it be possible to identify this location by comparing some strings (or the entire file) of the raw input blob to the finished image? If we could identify the exact location and the blobs indeed remain unchanged during compilation, then it should be able to build the image with dummy blobs of the same size and replace them with the real ones afterwards, right?
If I see it correctly, the binary blob starts on line 577 in fp2-sibon-2.0.1-blobs.sh. Now if I took that string (or a part of it) and looked for it in the system.img, wouldn’t I find it? Couldn’t I replace it? Shouldn’t that be possible to do with a rather simple script?
Best regards,

Moritz

#19

The fp2-sibon-2.0.1-blobs.sh is just a tarball. It’s not a bin blob. It’s just a yes/no wrapper that contains a lot of “blob files”/libs that get copied into:

./vendor/qcom/proprietary/

These Makefiles are added:
./vendor/qcom/proprietary/prebuilt_HY11/target/product/msm8974/Android.mk
./vendor/qcom/proprietary/vendorsetup.sh
./vendor/qcom/proprietary/common/msm8974/BoardConfigVendor.mk

This is also an important file to see what is going on:
./build/core/Makefile

I think this question below has to be asked/answered if you want to start your “cloud” build-service:

#20

Why? They are facing exactly the same problem, and FirefoxOS is also just an Android with some of the upper layers replaced by Gonk/Gaia.

That’s right.

I agree. The question is if we really need dummy blobs at all or if the build doesn’t compile even without them. Did anyone try already? I did with some early builds and it failed, but back then the build WITH the blobs were failing as well.

2 Likes