Shared publicly  - 
A little late on the share due to travel.

To those bashing Qualcomm here - I would advise you to read the followon post from +Jean-Baptiste Quéru .  Qualcomm's rules for redistribution of binaries are arcane and absurd, but the other SoC companies in the industry are no angels either.  I'm guessing that this one incident alone was not responsible for JBQ's burnout, but just the straw that broke the camel's back.  If you're going to boycott Qualcomm over this, you'd better sell all of your cell phones and just live in a cabin in the woods with no electrity, cell service, etc.

It is really disappointing the direction that the ARM SoC industry is taking - all of the manufacturers have done very unfriendly things in relation to open source mobile operating systems.  Qualcomm is, with the exception of TI (who are exiting the industry), probably one of the more friendly manufacturers.  (Edit:  From initial looks at Freescale and the i.MX6 - they are very promising, but so far they've primarily focused on set-top-box type stuff, I don't think a single i.MX6 phone or tablet exists anywhere.  I'll know more on this as I find more time to play with the Wandboard I bought two weeks ago.)

Qualcomm provides robust reference source code at CodeAurora, that is frequently pretty close to what is actually running on OEM handsets.  It's always close enough that with some effort, you can figure out which tag from an OEM started, and usually that's a great starting point for a bringup of a community project such as +CyanogenMod .  The negatives, of course, are arcane binary redistribution licensing agreements that are idiotic and absurd.

Contrast this to, for example Samsung Exynos4 - Samsung's reference source, in addition to being vastly outdated, is not even remotely architecturally similar to what ships on handsets and tablets.  Exynos5 is similarly poorly documented, with the exception of the 5250 present in the Nexus 10 - but Samsung seems to almost have gone out of their way to avoid using this chip in any other device than the ARM Chromebook (this could partly be due to power management issues that are plaguing most Cortex-A15 designs, but - the 5410 is on the market and last I checked, had zero platform reference source of any kind.)  In fact it seems to be a continuing pattern that Samsung Mobile avoids sharing chipsets between Nexus devices and the rest of their lineup wherever they can - such as with the Galaxy Nexus being OMAP4-based.

Such agreements are a nightmare for people like JBQ, for whom they cannot consider their job to be done until everything required to build a device is available in a 100% legal above-the-board manner with no grey areas, but remember, if you're using a community derivative like +CyanogenMod , the team has been working around braindead idiocy like this for years.  (Look at in almost any device's device tree.  Which is WHY Qualcomm's policies are so idiotic - the files in question can be obtained using 'adb pull' from any device, even without root privileges, as they're all world readable.)

As to bitching about lack of factory images, from a user standpoint (all of those calling for Qualcomm boycotts) - Samsung doesn't provide factory images for any of their devices.  HTC doesn't and in fact it seems like every year they're suing someone who does provide images for the community.  Sony does not provide factory images for download - you can only do a factory restore using their flashtool, which will only download a firmware image when a compatible device is detected (Qualcomm lawyerisms strike again...)

That said, it obviously isn't good for community projects like CM if idiot lawyers make upstream burn out.  :(  It's not hard for the community to route around braindamage like the factory image mess, but it's extremely difficult to replace someone like JBQ.  :(
Well, I see that people have figured out why I'm quitting AOSP.

There's no point being the maintainer of an Operating System that can't boot to the home screen on its flagship device for lack of GPU support, especially when I'm getting the blame for something that I don't have authority to fix myself and that I had anticipated and escalated more than 6 months ahead.
James Mason's profile photoFilippos Papalitsas's profile photoQualcomm Developer Network's profile photoAndrew Dodd's profile photo
So you're saying, the parts that Qualcomm doesn't want to release aren't even that important for the rom community?
Andrew Dodd
With the exception of the situation driving burnout for people working upstream (official AOSP work) - not really.  It's shit that CyanogenMod and the aftermarket firmware communities have been working around for years on all non-Nexus devices.

What's really ridiculous in this particular case is that +Qualcomm Developer Network provides many of the items in question at - but for various reasons, the AOSP guys at Google can't really say "go over to QDevNet and download this stuff"

And people need to stop calling it ROM - flash memory has never been readonly, and if you're able to write files to the filesystem with a simple "adb remount" - it sure as hell isn't readonly.  In the old days, it might have been effectively readonly on old WinMo devices when you could only write a prebuilt system image all at once, but when /system is just an ext4 filesystem that you can mount as writable with root privileges - ROM isn't an appropriate term at all.  It's firmware, not ROM.
+Kirill Rakhman The binaries in question can be extracted off the device with a single adb command. It's not that they aren't important, they are necessary in fact. Since these files are easily accessible, it is no problem for the ROM community. It's more harmful for AOSP and the future of Android in this regard.
+Andrew Dodd You're right about the ROM thing. It just has become the synonym of custom firmware, at least in my book.
Thanks for this explanation +Andrew Dodd ! I always thought that Qualcomm was one of the better SoC manufacturers for +CyanogenMod , so this situation was confusing. 
To clarify about the binaries that are available from Qualcomm:

-nothing is available for the latest AOSP release at release time. Even right now 2+ weeks after 4.3 has been released they have nothing for it.

-the binaries they have only work with the CAF tree, not with the AOSP one, and the CAF tree doesn't contain support for any recent Google flagship device (neither N4 nor the new N7).

-the license they provide for the binaries they distribute doesn't allow any further redistribution to users, which is something that is considered required for AOSP support to enable community builds, as the expression of the 3rd freedom of the Free Software Definition (right to distribute modified copies for other people to use).
Excellent information! 
+Jean-Baptiste Quéru Thanks for the clarification.  The last item is the most absurd and illogical - no redistribution to users, even though, every user has the binaries on their device if they take an official update!  It's stupid, their OEMs have effectively given users flash drives with the binaries in question - why the heck is it so hard to do a factory restore of a device that gets corrupted?  (From a corporate logic perspective - even if you hate open source with a passion, not giving a factory restore method to users in the event of corruption is Dumb.  You can claim "oh /system will only be corrupted if the user roots their device" - but exploits and malware happen, and it's dumb and arrogant to assume your device will never get compromised by a privilege escalation exploit that malware can use.)

If the files weren't world-readable and "adb pull"able, there might be some valid logic (even though it would still be a douchey/asshatey thing to do), but right now - those files are readily available from the device itself - why not make it SLIGHTLY more convenient and make everyone happy?

At one point, they at least claimed that one of the 4.2 blob sets were compatible with the mako, and it was possible to swap those blobs in place of mako's blobs without any kernel patches - of course, now it's 4.3, so the cycle starts again.  :(
What about tegra 4, according to nVidia should be more developer friendly?
Thanks great post.
+Vasco Gervasi It's an improvement, but only time will tell.  It could easily wind up being another insignal (where published reference source is vastly different from what is running on any device other than the developer reference device), or the same problem as Tegra2/3 where blobs from one device are unusable on another, even one with the exact same SoC, due to board-level dependencies of the GPU blobs.
WiFi only; not the LTE version. Still, that's a big deal!
+Vitaly D I'm guessing that there are probably other reasons contributing to the burnout.  People rarely change tasking over just one incident.
Just because Scumsung and FailTC are worst, this doesn't mean we should appreciate Qualcomm being a less of a dick.
+Filippos Papalitsas Thing is, people are calling for a boycott of Qualcomm over this.  If you're going to boycott Qualcomm over this, you'd better sell every single mobile phone you own and stick with analog landline phones.
+Andrew Dodd or just don't get a new phone until they change their tune. Current phones can handle most tasks for the next 2 years
Qualcomm and Google have a strong partnership dating back to the very first Android device, the G1. The latest launch of the Nexus 7 demonstrates our continued collaboration. The factory image for the Nexus 7 is now also publicly available.
+Qualcomm Developer Network It's nice to know that things are resolved now, after a public mess - but why is it that there have been not one but two Nexus device launches where factory image and proprietary binary redistribution rights were not sorted out by the launch date, despite the AOSP team escalating the issue well in advance of launch?  What changes have been made to prevent this from happening again with the next Qualcomm-based Nexus?

Edit:  p.s. nice canned form letter/comment there.
Add a comment...