I’m assuming you mean “move it to the #software:dev category”? Done.
1 Like
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 
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.
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. 
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 (Bluetooth, anyone?)
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
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
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
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
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.
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
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.
But I will shut up now, maybe other people will know more than I do.
@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?
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.
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
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:
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
The tar ball contains a lot of stuff. More than just some binary blobs. If you look at it, it also contains config files, data files, libs (.so). All also “protected” with funny headers “Qualcomm Technologies Proprietary and Confidential.” The “real” proprietary firmware (.fw,.bin,.b*) mostly ends up in “product/FP2/system/etc/firmware”.
I don’t see a problem with the last part (/etc/firmware), but I’m not so sure about the rest. I think the images would have to be opened and “repacked” on the users machine to add the libs again I think. And even linking the code … I’m not so sure about that, but I would like to see an official answer on this. I guess it’s a no, but a automatic build service could still be provided by FP if they find the manpower.
Or to put it very simple:
a) Build working code without “bin blobs”
b) Build working code with “bin blobs”
Make a diff/compare checksums. Check if you can make “a” match “b” just by copying files from the “bin blob” tarball into the images.
2 Likes
Thanks for the input (I am just too busy these days to investigate the details myself).
Provided you can build the system without the blobs (and the proprietary config files with the funny headers) and without linking to these parts during compilcation - why do you think the image would need to be unpacked and repacked? The files normally just end up on the system partition, so having just a flashable ZIP which will copy them there should do the job? Of course, to produce this flashable ZIP we would need need to build some script/whatever which either uses the files present on the device already or the archive which is available on the web.
Not sure if I understand the question. The system files in the out directory are packed up into an image. You will see something like that during the build. This also includes the famous “vendor/lib” directory.
mkuserimg.sh -s out/target/product/FP2/system out/target/product/FP2/obj/PACKAGING/systemimage_intermediates/system.img ext4 system 2147483648 out/target/product/FP2/root/file_contexts
The script is located here:
out/host/linux-x86/obj/EXECUTABLES/mkuserimg.sh_intermediates/mkuserimg.sh
I think the idea was to pack the blobs and any other non-distributable files into their own flashable zip. Then you could flash the blob-free system image first and add the blobs by installing another zip just like you could do with e.g. Open GApps.
2 Likes