How did Librem5 find manufacturers for their phone that starts shipping in April?
I might be wrong but I was under the impression that Librem was building that phone by themselves.
1 Like
Thanks manoj, yes of course, there’s still a frontrunner needed to break up behaviours.
But if not preinstalled from manufacurers, do you have other strategies to get /e/ quickly into the market? Or is that still ‘under construction’?
Yes as mentioned above we are looking at other options like setting up a flash by post service . Users send us their phone and we flash /e/ on them and send them back. Checking on the feasibility of the process. Any ideas and suggestion on other methods are welcome.
2 Likes
Negotiate with one or more companies present in the various countries that could install the Rom / e /.
The sending by the customer of the telephone, the reception by / e /, the installation, the return of the telephone to the customer.
It is tedious with a double risk for the transport, it will be necessary to follow up the reception by / e / return to the customer etc …
As I had already written in another subject, a simple software that would install the rom / e / directly by the client with little manipulation would be really ideal to reach a larger audience at first to let more time to think and set up another solution for distribution.
1 Like
Hi @lcjmle agree that the flash-by-post method has its disadvantages. The suggestion of a software to facilitate ROM flashing…something like the UBports project may be considered at a later stage - once we have a bigger development team.
2 Likes
At well known online marketplaces there are traders for used and for refurbished phones. They often update the software of these phones. They might as well offer them with /e/ if e.foundation can motivate them. But that way e.foundation would probably not generate any revenue.
By the way, there was a “Minor Shipping Adjustment” for the Librem 5 from April to “Q3 2019”. But we do not know yet, if there will be an /e/ version for the Librem 5 or for PinePhone and of course both do not help to meet the Q1 2019 goal.
UB-Ports installer has some disadvantages: it didn’t recognize my FP2 as being an FP2 (guess it will work on a FP2 with the old camera). That’s why I hope both installation methods will remain available.
A few years ago, the spanish company BQ did sell the first Ubuntu phones, along with their usual Android phones. Even them are not interested in being part of the /e/ aventure, with their own phones (not (yet ?) available with /e/) or with some other phones ?
Hi, Vincent, I recently read that BQ was sold to a Vietnamese company, so I guess the philosophy, goals and priorities of the company have changed.
A flashing service would be a good idea, for it enables customers who are not tech savvy to obtain a device without becoming enslaved to Google’s system.
Yes, Google rules the waves of Android by contracting manufacturers. This is revealing:
https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/
1 Like
I also think this should be the way. Sort of an universal flashing tool.
Alternatively, maybe a pre.filled virtual machine with a play button in it? Perhaps we could pack everything on 10gb or less and expand the usage at a faster paste.
Additionally, I would not mind a sort of yearly pay subscription to use this OS, donations are nice but maybe people would engage more… And if all went well the team could expand faster, have better conditions, etc etc. Anything like this in the pipe?
3 Likes
It only needs very little forked parts.
An earlier version of the UBports installer was actually based on shell scripts, and that version could also download and install other images (e.g. lineage and sailfish). I didn’t find it on the UBports page anymore, but adapting those shell scripts to flash /e/ images should be rather trivial.
1 Like
We are working on an easy installer - no GUI only command line - to help users flash the ROM. Still under development and with no ETA. Will be updating once it is done…in fact I am also looking forward to getting my hands on that tool 
2 Likes
Great
Too bad I don’t find the old UBports shell-script based installer anymore, it would be worth a look. Does anybody here have it? Or better yet, have the link to the github repo, IIRC the initial instructions told the user to do a git clone.
Dear all, this is a post to give a status update on the “anti-fragmentation agreements” noted above. I asked for some help at the European Parliament and they provided me with a link to this document: https://ec.europa.eu/competition/antitrust/cases/dec_docs/40099/40099_9993_3.pdf
This document describes decisions by the European Commission about an antitrust procedure against Google. Please note the following section on page 313:
18.2.2. Remedies concerning the licensing of the Play Store and the Google Search app on condition that hardware manufacturers enter into the anti-fragmentation obligations in the AFAs
(1398) First, Google and Alphabet should refrain from licensing of the Play Store and the Google Search app on condition that hardware manufacturers enter into the anti-fragmentation obligations in the AFAs. This shall not affect Google’s ability to put in place reasonable, fair and objective measures that would only be limited in scope to GMS devices and that would not, therefore, affect hardware manufacturers’ commercial freedom to sell non-GMS devices based on Android forks.
(1399) Second, Google and Alphabet should refrain from adopting any practice or measure having an equivalent object or effect. This shall include at least the following:
(1) Google and Alphabet must refrain from licensing the Play Store and the Google Search app on condition that hardware manufacturers enter into the anti-fragmentation obligations contained in any other agreements (e.g. MADAs or revenue sharing agreements);
(2) Google and Alphabet cannot make the grant of a royalty-free or discounted licence to the Play Store or the Google Search app conditional on an obligation not to sell devices based on Android forks;
(3) Google and Alphabet cannot make the obligation not to sell devices based on Android forks conditional on any payment or discount;
(4) Google and Alphabet cannot use one or more of Google’s other proprietary apps, APIs, the Android SDK or the Android PDK to remove or restrict the freedom of hardware manufacturers to sell devices based on Android forks;
(5) Google and Alphabet cannot impose on hardware manufacturers any obligation to pre-install one or more of Google’s proprietary apps that would remove or restrict the freedom of third parties to sell devices based on Android forks; and
(6) Google and Alphabet cannot punish or threaten hardware manufacturers that sell devices based on Android forks.
(1400) Recitals (1398) and (1399) are without prejudice to any proportionate and necessary remedies that the Commission may by decision impose in the event that Google and Alphabet were not to bring the Infringement effectively to an end or would adopt a practice or measure having an equivalent object or effect.
This is really good news!! This means that the EC officially disagrees with Google on its anti-fragmentation agreements and that it can no longer use them. /e/ can use this information in its discussions with hardware manufacturers to show them the anti-fragmentation agreements are not valid anylonger.
9 Likes
Nice. This is indeed good new for us. We will have to go through it in detail.
Now expect Google and its army of lawyers to come out with loop holes in this!!
1 Like
in relation to this, Google was fined 4.34 billion euros for this, see:
https://ec.europa.eu/commission/presscorner/detail/en/IP_18_4581
Blockquote * has prevented manufacturers wishing to pre-install Google apps from selling even a single smart mobile device running on alternative versions of Android that were not approved by Google (so-called “Android forks”).
1 Like