As part of the Nexus device support, Google releases factory images. These images contain all the blobs and whatnot necessary to restore your device's OS even in the event of a soft-brick. In the case of the new Nexus 7, it appears Google won't be releasing factory images and the cause is almost certainly the fact that Qualcomm doesn't want to release it's proprietary blobs for the Adreno GPU.
JBQ is pissed about this, this isn't the first time a vendor hasn't allowed release of certain blobs or the first time a vendor has refused to release the code necessary to even boot the device.
I'm guessing the old N7 got factory images so quickly as it was uses a pretty old GPU at the time. Having owned a Nexus One I was pretty sad there were no factory images
Sure. And the community projects use them, often via complicated scripting to pull them off of existing devices, or just a "gray market" where people share blobs directly or just throw them up on servers without worrying about it.
But what Google needs is a license to redistribute this software in a form where it can be used by an AOSP build, not just as part of a finished device. Apparently the couldn't get it.
Do you mean the redistributable Marvell wifi firmware? That permission came through pretty quickly, unrelated to Theo deRaadt's weird flame. It just took time, but still happened before production of the laptop started. As I recall, there was never any disagreement between Marvell and OLPC about whether it ought to happen.
Actually the onus here is on Google. They could create a pre-condition of using someone's chip that the blobs for the GPU can be released. But they didn't do that.
Well in one regard they already did a variation, when the original G1 was being designed it was a deal breaker if the blobs for the radio couldn't be distributed.
That said, one of the interesting "advantages" that Samsung and Apple get here is that they are their own SoC vendors. Google will have to get into this game eventually.
>That said, one of the interesting "advantages" that Samsung and Apple get here is that they are their own SoC vendors.
Both Apple and Samsung heavily use Qualcomm products. The Samsung S4 is powered by a Qualcomm Snapdragon 600. It should say something when Samsung isn't using it's own Exynos for it's premiere flagship device. The S4 also features a Qualcomm 4G LTE modem. And a Qualcomm power management chip. And audio codec.
The iPhone5 is almost as Qualcomm heavy itself, too.
I think Samsung and Apple would have equally as difficult of a time trying to release binaries (or source) as well, regardless of who is designing or assembling the SoC!
I don't disagree with your last point per se, but it seems weird that it would be necessary. For very tightly integrated things, I can believe that vertical integration is the optimal solution. But having to vertically integrate just because doing it any other way requires dealing with shit vendors seems to suggest a rather poorly functioning marketplace. If all Google wants is an off-the-shelf product with non-onerous licensing, but the only way to get that is to actually acquire a vendor because nobody will sell otherwise, that comes across as at least somewhat troubling.
It's not that weird if you're the SOC vendor. After all, if you withhold the blobs, then whenever people want a newer operating system, they have to buy a new device. The last thing someone like Qualcomm want is for you to be able to run Android 5 on your 2 year old device. They like the current throwaway model just fine, thanks.
To tell whether or not it's a poorly functioning marketplace we'd have to know how much more Google was willing to pay for more generous licensing terms. My guess is $0, because the benefit for Google is questionable.
This is a very good point. When Android was first released, it was a unique opportunity to study the relationship between an open source RIL layer and the underlying RIL library, in part because you could build and run Android with the RIL library. There are tons of claims of secret sauce in RIL implementations, no less than there are for GPU drivers.
There's no need to be pointlessly snarky. Nobody has any idea how many units of the Ubuntu edge will "sell", because it's not for sale yet. It's ridiculous to consider an $800 commitment to back a product which will exist a year from now at best a "sale".
This was not a comment on ubuntu edge per-se, only the likelihood of it actually having free drivers at launch if they are only kickstarting 45k units.
The same thing would be true if it sold a million units.
This implies a dramatic lack of competition in the SoC market if you can't shop around and find a vendor that will at least provide release images to flash devices with openly, if not actual open specification devices with FOSS drivers.
The Nexus question was about permission to distribute the proprietary blobs - free software drivers (in the case of Ubuntu Edge) is a different problem.
Google could always use chips only from vendors that allow redistribution of the blobs, make it a contractual requirement when commissioning Nexus devices.
"So in this first generation Edge, no, we didn't look for open hardware specifically. We can choose silicon with more open drivers as we finalise the spec"
If you assume that they're doing something that they haven't claimed to, then you can continue laughing at nothing, I suppose.
Then I see mixed messages.
" '... we'll ship this with Android and Ubuntu, no plans to put proprietary applications on it. We haven't finalized the silicon selection so we're looking at the next generation silicon from all major vendors. I would like to ship it with all Free drivers.'"
Yeah, but what smartphone vendor is willing to take a 20x hit on performance in exchange for open blob licensing? Performance sells phones much more than blob licensing ever will.
The Nexus devices are supposed to be developer devices and should therefore have other priorities. An unlocked bootloader is not enough for a developer phone.
They don't need negotiating power. Qualcomm can tell Google to shove it -- the Android code is still published under the Apache license and as long as they don't claim to have written it themselves, they're free to do whatever they want with it.
Google could certainly tell LG/Samsung/HTC that a condition of getting the next Nexus deal is that all binaries must be able to be freely distributed by Google and let them put pressure on the SoC vendors, but I doubt the Nexus line sells enough or drives enough profit for anyone to take such a threat seriously.
Patents are absolutely unnecessary, and arguably immoral. Copyrights, on the other hand, I'm not so sure. They absolutely go too far both in age and scope, and the market would benefit greatly by moving to 10-20 year copyrights with stronger "fair use" protections.
But capitalism works based not just on what you can produce, but what you can withhold. It's a "tragedy of the commons" problem: if anyone can hit a "clone chair" button for zero cost, few would pay to sustain enough professional chair makers. Perhaps spare-time activity or alternative business models would supply the necessary labor, but it's iffy: see the never-ending battle between open-source and propietary software, which I expect will persist long into the future.
Believe me, I'm in favor of a free global library of all intellectual and creative human output, which algorithmically rewards all creators proportional to their results (or alternately, a society wealthy enough to subsidize its creators such that incentives aren't as necessary). But that represents an enourmous technical and political challenge, to say the least.
> But capitalism works based not just on what you can produce, but what you can withhold. It's a "tragedy of the commons" problem: if anyone can hit a "clone chair" button for zero cost, few would pay to sustain enough professional chair makers.
You contradict yourself once here. You say capitalism is based on what can be withheld. Another word for that might be scarcity. In 1932 Lionel Robbins said "Economics is the science which studies human behaviour as a relationship between ends and scarce means which have alternative uses." This is still the modern mainstram definition of capitalism.
Then you say:
> if anyone can hit a 'clone chair' button for zero cost, few would pay to sustain enough professional chair makers
The idea that value comes from the labor of chair makers is a Marxist idea. You are making a Marxist argument here. It also contradicts your first argument. You say value comes from scarcity (modern mainstream economists agree), then you say value comes from labor (which is what Marx said) which contradicts the first argument.
You're trying to make a Marxist argument for capitalism (Actually Marx did make an argument for capitalism - he said it was better than feudalism and slavery, but that's not what I mean here).
You should go on the web and read about the subjective theory of value, and then about the labor theory of value. You argue STV in the first sentence and then LTV in the second. They can not both be right, their definition of value is contradictory.
I should note you're not the first person I see making this error. As things become digital they lose their scarcity. I see all kinds of odd statements come out of this. You're not alone in this. But across the entire political spectrum, from far left to far right, all serious students of the economy agree only one side can be right, value comes from either subjective marginal/scarce/utility reasons or from a certain type of labor, but it is either one or the other. You flip back and forth between a capitalist-supporting argument and a Marxist argument. A Marxist argument for capitalism. I see this more and more, and I find it odd.
> In 1932 Lionel Robbins said "Economics is the science which studies human behaviour as a relationship between ends and scarce means which have alternative uses." This is still the modern mainstram definition of capitalism.
The quote there appears to be defining "Economics", not "capitalism".
I'm curious about this: when did Capitalism stop meaning "the opposite of cottage industry" and start meaning "a market with limited regulation"? Was it Marx that introduced this?
The academics are interesting, but I'm talking about the more tangible microeconomic concerns: How can an author get paid for their book if anyone can print their own copy? What investor would invest in a movie if it can be downloaded for free? There are possible answers to these questions, but I'm skeptical whether replacing copyright completely with alternative business models and hobbyists would result in the same level (and quality) of production.
Patents are only possible through government regulation. Without the government's interference, there would be no such concept. Pure capitalism has no patents.
Even with Patent trolls and week patents, patents still allow companies to license innovative technology rather than hide it away for fear of copying (ala qualcomm)
Patents are a good idea, it's the current implementation that sucks
This is only the case when you have something to fear from superior competition. That is the capitalist system. Even in the FOSS world, which is largely affected by capitalism the spirit of sharing and collective advancement is incredibly common.
Let me rephrase my statement, because I didn't make my main idea clear enough:
"When the competition starts using your own improvements/innovations against your products, and they are not moving a single finger to push innovation, you are obliged to keep the secret."
I don't mind if the competition improves my work, this is more than enough incentive to push innovation forward, but when the competition stalls and makes a verbatim implementation of my work, or worse enough, depends solely on my improvements to stay relevant, I honestly prefer to keep the secret to myself. I don't want parasite competitors, I want talented competitors.
Well, in this particular case I agree. Its unlikley that you will make your own ARM SOC or blobs because the Snapdragon blobs are unavalible to you. But one can see the secrets as an anti-feature and choose an alternative supplier that is less secret. While Google / Asus didnt the end users might.
Ah I see you're saying that keeping secrets may motivate clients to pick someone other than you, and potentially increase competitiveness if the market presence of 'secret keepers' is minimal.
I think it's pretty tricky to consider that a real 'effect', as if the alternative companies kept secrets then it would be just as bad.
You can't blame capitalism for that. In a free market, consumers can just stop buying Qualcomm products for a month, and I can guarantee you that a choking Qualcomm would release all they have as FOSS as fast as they could.
But most of the population is uneducated in that regard. Blame the lack of enthusiasm for FOSS.
I was saying that with enough pressure, they wouldn't just allow redistribution or even publish the source code, they would even release it under the GPL and kiss the buyers' feet if asked to.
I work for Qualcomm, and I never would have expected it, but apparently this happens. There are groups that buy busted phones, get the Qualcomm cellular modem chips out of them, and then put those chips into new devices. It's significantly cheaper than licensing, and I believe the current tactic to fight it is firmware-based.
I get the impression the resulting products aren't particularly high quality and there's some notion of protecting consumers, but I would imagine the primary motivator is the loss of license fees.
I don't want to come across too harshly, since you've engaged in the discussion and revealed that you work for qualcomm, but:
Do you morally and ethically agree with the position that Qualcomm should get paid a licence fee for the firmware for each and every resale of a particular chip? (vs the spirit of the first sale doctrine)
At the moment, it seems that you're giving tacit approval to this position.
I identified myself as an employee of Qualcomm because, per policy, we're supposed to do so when discussing the company. :)
I think it's reasonable to sell the chips under a restricted license - you don't expect people to use the chip in a product you don't know about. Consider a metaphor using a collection of short stories. You include your story in an anthology, which lets the buyer re-sell it at will. However, it would be questionable for the buyer to remove your story, and re-bind it as part of another book, which they then sell.
These actions are not restricting the actions of customers in any way (as far as I know), so they seem ok to me.
They are, but it sounds like Qualcomm is trying to introduce some kind of driver DRM so that the driver will only work on "new" chips but not "used" ones.
Imitations sneak into above-the-table supply streams all the time. The bootlegger need only imitate the package shape and markings, and even knowledgeable people may not notice.
Chips as complex as SoC's having GPUs are being produced by counterfeiters who are not just copying the package and artwork, but actually making clones working only from published documentation and redistributable drivers?
But they would be thwarted by license agreements making the drivers generally nonredistributable?
It definitely is something that usually happens to simpler chips that are easy to reproduce. I'm not even trying to say it is likely that someone is or would bootleg the SoCs- just that the earlier argument that there wouldn't be any black-market buyers is irrelevant, because bootleg parts make their way in to legitimate supply streams all the time.
Hell yeah! If I'm shipping 10M units to my 5 favorite customers, and my documentation comes in Engineer form, I don't want to waste my time writing up 20K pages of documentation (which is about how much it takes) so that hobbyists can buy the chips and then demand support, 5 units at a time.
Who are these 'hobbyists' who 'demand' 20K pages of specially-written documentation?
I suspect there are a lot of professional Engineers working on products that will ship fewer than 10M units. Sometimes these Engineers then go on to design products that ship more than 10M units and prefer to keep working with the chips they know. Sometimes those Engineers are 'hobbyists' too.
Some vendors follow your suggested model, and are very open with support and documentation. Other vendors (some of the biggest are in this group) have terrible/non-existent documentation and provide application-specific support by shipping an engineer with the product.
Modern SoCs demand thousands of pages to cover all available features and possible applications, and putting together that documentation in a self-consistent way is a challenge. Some vendors have decided that supporting low-revenue clients is not worth the cost of putting together said general-purpose documentation and providing support to each and every buyer. They'd rather not sell you the product in the first place than sell you something and stiff you on documentation & support, which is a reasonable position.
Often when you're a low-quantity company you deal with low-quantity vendors who are willing to support you. When you move to high volume you might prefer to keep working with the chips you know. But when your operations guy comes back to you and says that the Big Co (who wouldn't talk to you in the past) can sell you chips for $5 less, that's $50M you just saved (given your 10M unit quantity). So you switch. In this example you have two different vendors: high cost / high support, low cost / "exclusive" support. Both have markets, just different ones.
TI is an example of a vendor that is very hobbyist / small quantity friendly. Even that wasn't enough to save them - they've pulled out of the phone SoC business.
I recall going to TI's site regularly over a period of months looking at OMAP chips in small quantities and finding them continually backordered. I know some people got dev kits. Ultimately, they were just an another ARM licensee with a GPU of questionable utility (to me).
Or if you are in the vast percentage of the world that is working stupid hours for pittance and barely able to feed their families or personally develop in any way, or had their land and homes sold off by the government to multinationals, or those who wish to contribute to charity or the world but cannot because of extortionate rents and cost of living, or those in prisons because they are run for profit and thus courts favour custodial sentences, or those who's race means that they do not have access to the tools to succeed as easily (or at all), or those who are pressured into insecurity because people make a buck off of their lack of self-confidence, all the time.
We in the west are overfed pigs standing on the backs of billions.
Frankly, if the internet had been driven by the desire to make profit in the early days, we wouldn't have TCP/IP, the web, email or any other open protocol for that matter.
This is such a load of nonsense. Did Curie, Feynman, Einstein, Turing, Berners-Lee, and the inventors/scientists behind 99% of human history do it for the money? No. Of course not. How absurd and insulting to cheapen the wonders of their invention and minds with the banality of money.
In fact, imagine how far we'd be if great minds weren't restrained by having to pay rent, or work around mainstream stupidity, or having to use cheap equipment, or facing patents and other laws created to protect the captalists.
Just because we've never seen a working communist country, it doesn't mean it could never work - to think otherwise would be luddite and ignorant.
The mistake that Marx, like you, made was in thinking that inequality was a product of capitalism, when in fact inequality is the inherent state of mankind, and moreover of all living things.
I don't think it was a mistake, and I don't think it's a static state. I believe that a group of people could come together and form a community founded on equality.
The problem, to me, is more of a logistics problem, because once you get more than ~100 people in an organization, you start losing the immediate connection with them, which means you care less about their well being, because you don't know them. The issue is managing people, and meaningfully punishing ne'er-do-wells.
What you are essentially saying is that people can create a community with the intent of making everyone equal, but they will invariably fail because people are, in fact, not equal. Liberalism and Leninism are two consequences of this axiom. The former tries to provide the weaker but more feasible guarantee of equality of opportunity. The latter tries to make people believe they are equal by getting them to ignore inequality.
No, because communities are small scale. History has proven that communities can exist in such a state. Societies need to have intent behind them. No society has ever existed without intent behind it.
Leninism worked, we know for a fact that it worked, at least until Stalin took over and made it something worse that ultimately didn't work.
History has proven no such thing. Every community has its leaders, and those leaders enjoy a privileged position. Indeed, Leninism is quite successful: at establishing a party of elites, whose job it is to convince everybody else that they're equal and to teach them to ignore the obvious contradictions. I did not say that "society [should] exist[] without intent behind it"; I said that intentions don't matter if the results contradict them.
>thinking that inequality was a product of capitalism //
I don't think that [nor am I inclined to think did Marx]. I think capitalism exacerbates it drastically to a markedly negative effect (though not so negative as say malevolent dictatorship). Moreover I don't perceive inequality as detrimental, it's a truism that none are equal after all.
However I do certainly have communist beliefs about the best forms for society to adopt.
And what of those who dissent to your "best form for society to adopt"? It takes intelligent and productive people (as in, it takes intelligent people, productive people, and people who are both) to make such a society work. When you provide no incentives for intelligence or productivity, because those incentives create inequality, then such people will complain (upsetting the balance), leave (gutting the society), sabotage (undermining the society), or simply stop caring (grinding the society to a halt). What then?
The problem is that capitalism only seeks to enhance the positive feedback system of inequality - having money gives you more power to make more money and thus have more power. Being poor gives you less power to make money and thus it is much harder to become richer.
The problem with redistribution (aside from its inherent immorality as theft backed by force) is that you simply shift power from the people who had wealth to the people who are doing the redistributing. At no point do the vast majority of people ever become more powerful. In the new system, power is obtained by currying the favor of party officials. Even contrasted against the most egregious Marxist caricature of capitalism, how is this any better?
Not an Android user, but from what I understand the issue is that Google has released the new Nexus 7, but a) the GPU uses proprietary drivers (binary blobs) and b) the actual "factory image" (i.e. what runs on the device when you buy it) of the Nexus 7 is still unreleased and closed source.
This means that the Nexus 7 is, practically, no more open than the iPad/MS Surface/etc.. That would definitely be upsetting to me if the gig had been sold as a way to strongly impact an open source piece of software, and Jean-Baptiste's decision seems very reasonable.
Can android users/developers weigh in? I'm sure I'm getting some part of it wrong.
That's overstating the case. Google can't distribute a tree that can build for the new N7 because of one (or maybe a handful of) component licenses. The rest of the system remains open source though, and can be built (for the N7 and others) by community projects. There is value there.
Certainly the new N7 isn't a "free" device in any meaningful sense. But Android as a whole remains vastly more open than iOS or Windows.
It's not overstating the case though. When a huge component of the system isn't open source, that clouds the openness of the system as a whole. People make fun of Stallman for his ridiculous practices, but at least he's principled about this very issue. Here, the AOSP maintainer is making the same principled stand. If you can't boot the device (hence use it) because it doesn't have open GPU devices drivers, then it's not an open device, plain and simple. None of the other stuff you allude to matters if you can't use the device.
As with many questions of openness, it's a question of pragmatism. It might be fair if some Kickstarted device did this or something, but this is Google's flagship tablet. Google uses the "Open" moniker as a marketing tool to both sell the devices to like-minded supporters as well as to bash others (Apple, MS, etc) pretty much whenever they can, as do many of their affiliates/partners. As such, it's completely fair to hold them accountable when that ends up not being the case.
Sorry, that's dumb. If it's really a question of "pragmatism", then in a practical sense there is no distinction between this device and, say, the HTC One which uses the same GPU and is subject to the same restrictions.
Yet I can go to www.cyanogenmod.com and pull and build a tree for the One and boot it, with access to the source code for virtually all of the system (sans things like the GPU blob in question).
That you would argue this is no more open than iOS or Windows is weird, and sounds more like a stand on vain principle and not "pragmatism".
If you can't even see the screen of the phone you're booting then how does it matter if the rest of the kernel is Free or not?
A lot of the theory of optimization can be reduced to speeding up parts of code actually being executed and paging out parts of the code never actually touched, which works because the source is not uniformly useful. A kernel would be useless without a scheduler, a GUI program would be useless without an event loop, no matter how "open" the code surrounding those are.
Darwin is open source too. You just can't build a booting IOS image from the code that's available, due to a lack of certain binary blobs. It's almost the same problem.
Darwin is but a single (very small) part of iOS. Only if you consider all of iOS's frameworks & apps to be a binary blobs is it "almost the same problem".
Google is choosing not to leverage licensing opportunities that could solve this situation for all of the Google Experience Devices.
This is not about the apache or gnu license. This is not about binary blobs. This is about a huge company that is playing games with "open source" for strategic reasons, full stop.
Google could put in licensing conditions that would resolve this driver situation for any company that implements GED services, but they choose not to. It always comes back to the fact that their primary product is you the user, and they only are interested in selling advertising services. Google executives are behaving unethically with this platform.
Android is "open" because there's a lot of GPL code in there. And the irony is that with all this "openess" is still the most fragmented OS out there. The whole situation is ridiculous.
I always thought Android's openness was a driving force behind the platform's fragmentation. If anyone can build an Android device, and modify it however, wouldn't you expect it? Wasn't it an expected byproduct of Google's initial strategy?
There's nothing ironic about that. Due to it's open nature (i.e. anyone can manufacture an android device that runs whichever version of the os he likes) there is fragmentations. Just like the different linux distros...
I don't have knowledge about this particular case.
But I can tell you that multiple, multiple times people have cried wolf on this. There's always a gap between when Google releases a device and when they release the accompanying source.
This is different though, as most of the components that are used in this device require you to sign an NDA to even get the datasheet. Most devices beforehand had at least a semblance of the open source movement.
Android is usually considered open compared to iOS because developers can distribute software directly to consumers, without permission from a third party.
I don't think 3rd party software distribution is a main contributor to openness. Before Apple's app store most software was distributed directly to customers. For example, Symbian, J2ME phones, Windows Mobile, etc. None of these were considered open.
"None of these were considered open."
I would say they are now, because of this:
"Before Apple's app store most software was distributed directly to customers."
Most discussions I see on the net these days are about free markets vs privately regulated markets. Windows and Android and Mac OS X belong to the former, while iOS and the XBox to the latter.
Should people provide products and services to other people, maybe with some government regulation? Or should a few private companies control and regulate the distribution? Would the world be a better or worse place when Microsoft had the power to prevent the distribution of Web Browsers?
Well, I suppose if you define "open" as being able to build the software, but don't promise you can actually use the result, that makes it acceptable.
The other important thing to note here is that Jean-Baptiste Quéru is not just some random Android developer. He is the the point person for what everyone previously believed was "open" development on Android.
I can't use Linux on my laptop without some closed source blobs - does that make Linux not open?
No, because you can get other laptops without this problem. Likewise, you can get other Android devices such as the Nexus 10 or Galaxy Nexus which are capable of using the result.
This sucks as it means you now need to choose between a device that's sufficiently open or a device that's up to date, and it's certainly worth criticising Google for, but it's not enough to claim that Android is as closed as iOS or Windows (yet - if they do the same to the next Nexus 10 and continue releasing Nexus devices that can't boot AOSP, then it's concerning, or if they drop support for the devices that are currently able to use the open source code)
Of course they were aware of the issue, if you read what JBQ wrote, he mentioned this was escalated 6 months ago. It doesn't take a leap of the imagination to conclude that the expectation was the issue would be resolved by the time the product was available for sale. Perhaps Qualcomm even stringed them along (I'm speculating)
JBQ says he's very frustrated with the "lawyers", for what exact reasons- I don't know. Maybe he feels like they are not exerting enough pressure, or maybe it's Qualcomm's lawyers he's pissed at. You cannot say Google (or at least JBQ) knew how this would turn out.
I agree with you overall but find the Linux analogy a bit flawed since it doesn't apply to any laptops that are officially "blessed" in the way Nexus devices are with Google/Android.
> Well, I suppose if you define "open" as being able to build the software, but don't promise you can actually use the result, that makes it acceptable.
You can still use the result, but not with all devices (same thing as any linux distro, despite being open source, you need driver supports for your particular hardware). There are still many devices who can boot aosp (from the nexus line, from sony, etc.).
Did you read Jean-Baptiste's post? In this particular case, there's no video device support for Google flagship devices!
...can't boot to the home screen on its flagship device for lack of GPU support...
That sort of makes it useless. I'd only be willing to buy the device argument if we were talking about a microphone or webcam, but when you lack the most basic of support (video), I think that's not a useful argument to have.
Well, if it weren't for the fact that the image flash procedure requires one to know which attached Android device one wishes to flash, and to have that device in fastboot mode, one could very easily have a generic "make install" step.
Seriously, "make install" is:
adb -s $DEVICE reboot-bootloader
#wait for a while
fastboot -s $DEVICE flash system $IMAGE_FILENAME
(Except for the binary drivers that are specificaly being discussed here... like, no: that simply doesn't work, and that's exactly what JBQ is complaining about.)
I know that AOSP cannot create a useful system image for the new Nexus 7 and the Nexus 4. Google has made a terribly bad decision here, and I do hope that they have the wisdom to neverever make it again. Given that Rubin is no longer managing the Android project, I would bet that this is a mistake that they're gonna keep making.
And, I mean, the Linux kernel makefile has a "make install" target, but it
a) produces a partially-functional or completely useless kernel on a wide array of hardware unless the linux-firmware package is present
b) even if linux-firmware is present or not required, it won't actually work on the majority of people's systems as it (IIRC) doesn't update initrds, or update the GRUB bootloader menu to point to the newly installed kernel
Both Freedom and Openness are more complicated than an install target. That's the point that I was making. :)
This kind of stuff is run-of-the-mill when working with the large chipset/SoC vendors. I've worked on projects that have crashed and burned because at the last minute the chip vendor decided they're not going to provide the SDK for the chips we've bought and designed in.
Vendors suck (some more than others) and it's not Google's fault that they can't convince the vendor to open source their device drivers. This sort of thing is extremely common in the embedded world and when you're making a device to a price point often times you have to put up with this sort of nonsense because only one vendor makes a chip with your feature set at a given price point.
I suspect it's a combination of support, documentation, and trade secrets. I've worked with numerous vendors over the last decade and the support strategies vary dramatically. Some vendors put up very nice datasheets, manuals, source code, etc, while some give you almost nothing at all, and instead ship an engineer with the product to help you design it in. The rationale is that these chips are very complicated, applications vary dramatically, and it's sometimes better to increase the quantity of manpower (in engineer form) for your favorite 5 customers (that make up most of your market anyway) rather than to increase the quantity of documentation so that you can also sell to Joe & Jane Hobbyist.
I have no experience with GPUs, but I once read something that indicated that the driver, in fact, has a lot of proprietary code in it. For example, nVidia often releases driver updates after a new game is released that can give 10-25% performance boosts in those games. That's not because it's running the GPU faster, that's because of optimizations within the driver on how GPU commands get processed by the GPU.
Someone with more knowledge about this please correct me if I'm wrong.
There exists a patent troll who owns patents for using pink unicorns to render pixels. Vendor ships a chip that uses red horses to render pixels... close enough for a legal patent battle? Who knows. But if they try to keep it a secret, maybe it'll all work out.
What makes no sense to me is what's the risk for the vendor in letting someone redistribute the driver's binary blobs. Any competitor who wants to reverse-engineer the code can already extract it from the released product anyway!
What if the driver is only unlocking part of the GPU's capabilities? A vendor can spin one chip for n customers, all paying different royalty and licensing fees based on need.
But isn't the problem they aren't allowing the binary blob to be released? There's little reason to believe someone is going to reverse engineer and open up capabilities of a chip in a binary blob (at least little reason to believe that will be more likely because it's released rather than pulled directly from a device).
The fact is that Google tries to make their devices as open as possible. That philosophy is beneficial to the community, for the software, for their brand, and for the tech industry. If legal issues or unforeseen problems appear while they are launching a product that prevent stock images on a particular device, then oh well, shit happens.
There will be a dozen other Nexus devices within the next year and hopefully Google will learn from their mistakes, and will partner with suppliers who won't prevent source code from being published.
Does Google benefit monetarily from not releasing source code? Nope, it likely decreases their profit and tarnishes their reputation, so I would like to believe that they are doing everything in their power to keep Android and the Nexus brand as open as possible.
If Google was "doing everything in their power to keep Android and the Nexus brand as open as possible", they would have gave a shit about qualcomm's ridiculous conditions on source and redistribution before release.
Especially considering that they managed it with the old Nexus 7. This is clearly not impossible, though I can buy that there are difficulties and tradeoffs.
> The fact is that Google tries to make their devices as open as possible.
Well, sort of. Keeping GPU drivers closed is a charade. There is no secret sauce of any great value in these drivers. There might be embarrassing coding horrors. But there is no good reason to keep these drivers closed.
In this case, not even the binary blobs are available. That's gratuitous pig-headedness from the GPU licensor and SoC maker. Google could have extracted at least that concession. When someone with as much integrity as JBQ quits, it's not just the run of the mill SoC vendor crap that caused it.
I work for a GPU vendor so my viewpoint might be clouded, but there is a lot of competitive information to be gleaned from the source code of modern drivers.
I used to write graphics device drivers so I'm going to bite. Usually most vendors think that their 'solutions', details about their hardware designs exposed in the drivers and optimizations are extremely valuable. Personally in my experience I found that most of what vendors considered secret was well known and not that novel and the majority of what was being done was application of the same or similar techniques in their hardware and drivers. Sure there are some novel things, but enough people have moved between the graphics card companies that the drivers really have very little truly unique information about the designs that would help a competitor.
One thing that I think does cause problems for opening up hardware though is that many graphics implementations use the same or similar chips (to save on asic costs) and the drivers enable options based on the product the customer bought, but the underlying chip will actually still implement the higher end functionality. This is a common enough technique and to avoid people getting 500 dollar parts for 99 they can't open up the drivers. I don't understand why they don't push this sort of thing exclusively to device microcode (many do this or at least partially) rather than having software components that do some of this logic.
You might have been right at one point in time, but respectfully you're not right today. Today's modern GPU implementations -- especially on mobile because the APIs we support are so (intentionally) vague and encode a system with a wide spectrum of possible implementations -- are so complex and hide a lot of implementation specific secrets that other vendors would love to freely discover in source code.
Discovering the secret sauce is the very embodiment of my job for my employer, and I make a great and exciting living figuring out our competitors' myriad secrets, a lot of which is controlled entirely by the driver.
I could write an entire book about why there's potentially very valuable competitive data enshrined in GPU driver code. Some obvious examples: execution resources and scheduler details (including full software schedulers in many cases), register allocation strategies, optimising shader compilers, hardware bug workarounds, power management limitations, clocking schemes, API compliance workarounds; all highly valuable competitive data that would be plain as day if GPU driver source were available.
What about the binaries? Isn't it possible to them off the device? Since you can't stop reverse-engineering, is there any sensible motivation for not officially releasing them?
Yeah, but most of it is encumbered so it'd be really hard for a competitor to go and read your driver code and then do the same thing without ending up in trouble later on.
For example, NVIDIA vs SGI on Texture Mapping, or NVIDIA vs 3dfx on stochastic mipmapping. (NV lost both of these cases, but managed to get what they wanted in the settlement...).
If you wanted to find that information about one of your competitors, what would it cost you to hire a consultant to reverse engineer their driver and tell you all its secrets?
Licencing of components is done before you, well, put those components inside a million phones.
Someone who "tries to make their devices as open as possible" chooses components that can be made open. Someone who intentionally chooses a component and does not ask/licence it's driver to be open - hasn't even tried.
I think their options were either to delay the launch of the new Nexus 7 and possibly break a contract with Qualcomm or release it, let some non-devs enjoy the nice new hardware, and focus on the next new products. Makes sense to me, but I don't think Google benefited as much as they would have if Qualcomm would have allowed the source code to be published.
Oh of course they would have been better off in a world where Qualcomm was friendlier, but that's not the question. Let's look at the cost/benefit to Google's decision if we assume there isn't a huge outcry.
If Google insisted on shipping stock images it would have cost them. Either by picking an inferior chip, or by upsetting Qualcomm, or by Qualcomm charging them a higher price. Therefore they chose a position of some benefit to them when they decided not to ship stock images.
The best way to counter this benefit is a public shaming, so that in the end it's costlier than the other options would have been. But Google's not stupid; they wouldn't have made such an anti-openness move if they expected it to cost them.
I personally see the lack of a Factory Image for a single device as being very minor. An overwhelming majority of Nexus users still choose to use stock Android and have no use for the source code. So what if there are a couple of devices missing from https://developers.google.com/android/nexus/images , it's really not that big of a deal in the grand scheme of things, especially considering how rapidly Google is pushing out new devices.
Android is still open-source and the AOSP is still very alive and will live on.
> I personally see the lack of a Factory Image for a single device as being very minor.
It's not the lack of a factory image for a single device. It's the lack of a factory image for Google's flagship device when they've made so much hay about it in the mists of time (oh, about three months ago).
I'm not particularly sympathetic to most "open" argumentation when it comes to devices, but Google should walk their talk.
This sounds like an apology. Openness is just not a high enough priority for them. It's just not their goal to release an open device otherwise they wouldn't have released this.
It's their goal to do whatever it takes to compete aggressively and if openness can win them PR, they'll do it, but it isn't a goal in itself.
JBQ's quitting is devastating to the AOSP ecosystem. In so many different ways that I'm having a hard time putting my thoughts together on this topic.
Having had the benefit of following his posts and rants both from inside as well as outside google, I find it difficult to overstate the impact of this event on real and perceived openness of the platform.
I'm guessing Google got caught between a rock and a hard place here, with the qualcomm processor being the best choice (and the performance of the Nexus 7 is great), but being ridiculously locked down (you can easily extract binary blobs, so why restrict google from hosting them, they will be hosting them for the OTA updates anyway!).
Should they have put out a worse device in order to stand up to this stuff though? Difficult choice.
This is a pain - It's nice being able to download the factory images direct from Google for quickly restoring the device to stock or applying an update before the OTA is out, having to try to find them on XDA is annoying for a Nexus device. Kudos to JBQ for standing up to this, hopefully the fallout will cause something to change.
So AOSP is a lot of things but not really open and the geniuses at Google deliberately let the shit hit the fan despite 6 months of warnings by JBQ. Stay classy, Google.
AOSP itself is open, and has no issues on the Nexus 10, Galaxy Nexus or old Nexus 7. However, the Nexus 4 and new Nexus 7 are not capable of booting from just the AOSP source alone. In practice this is the same as most non-Nexus devices, except the bootloader still ships unlocked.
However, the Nexus 4 and new Nexus 7 are the flagships for AOSP, and the maintainer was upset at the fact that the open bit is useless on newer devices without parts that can't be distributed.
I don't know about the Nexus 10 or the GNex, but I do know that you need the binary blobs to boot the Nexus 4 from source. However you can get the factory image (which contains the blobs and doesn't require you to extract them from the device) from here: https://developers.google.com/android/nexus/images
The controversy is that there is no factory image available for the new Nexus 7, and therefore, the only way to boot a new Nexus 7 from AOSP source is to pull the blobs from the device, incurring in a legal gray area.
JBQ is a great guy, and well loved from his days working for Be Inc. His wife cool too, if notoriously opinionated :-) Wish him all the best! Stand by your convictions.
Google is still able to release updates to the affected Nexus devices, and they have a good track record of doing so; they just can't put those blobs into AOSP.
> and makes literally the only CDMA radio chipsets you can buy
Actually, this is not true. The CDMA/LTE Galaxy Nexus, Droid Charge, and Stratosphere (all made by Samsung) actually used VIA Telecom's CBP 7.1 baseband for EVDO/1XRTT (and a Samsung LTE radio for that). I'm not sure how/why VIA Telecom was able to license QCOM's patents covering CDMA2000, but they did.
To my knowledge, these are the first non-QCOM CDMA2000 phones shipped (at least in the US) since Nokia's ill-fated CDMA S30 phones made for Verizon/Sprint from ~2003-2005, the 3589i, 6235i, and maybe others. I believe TI/ST/Nokia teamed up to make that baseband, but it all ended in lawsuits from Qualcomm a few years later.
I hope that Mozilla and Ubuntu are more successful in keeping binary blobs under control on their hardware. It will probably mean avoiding Nvidia and Qualcomm hardware though. Whether or not this is even realistic or possible is an interesting question.
They would not have more leverage then Google does . Actually, it's worse, as Android is way bigger them both of them (together).
I guess one of the only hopes is that intel can get up with an option for arm socs, as they are pretty good opensource citizens.
This is a worrying development for Android as an open source project.
That Google doesn't care enough about keeping ASOP relevant, to even make sure their new Nexus 7 is supported in it, is rather depressing.
Some here are blaming Qualcomm and I'm sure they are part of the reason this happened. But the new Nexus 7 is probably going to bring in a sizeable chunk of money, and Google could have used this to force Qualcomm's hand.
That Google didn't, sends a clear message about their priorities.
It is depressing because if AOSP becomes irrelevant, it hurts community involvement in android, and, in a way even worse than that, they miss the opportunity to refine AOSP for fast porting so that OEMs can keep up with Android releases and update their product in the field.
This really shows poor planning on Google's part. If their goal with the Nexus line it to be able to release builds to ASOP, they need to source their parts accordingly.
It's puzzling to me that Qualcomm has managed to get to the position now where it is virtually a monopoly provider for ARM chipsets that support LTE. A lot of discussion happens about standards essential patents wrt Motorola and Samsung - surely that equally applies to Qualcomm and the other chip makers (not least of all Samsung) should be able to readily license these patents and build competitive chipsets?
It may be more that Verizon and Sprint require CDMA and Qualcomm has a monopoly on that, so if you want to support Verizon you need Qualcomm and once you've designed that version it's easier to also use Qualcomm for the AT&T version as well.
The situation is somewhat similar to what was happening on desktop Linux some years ago. On the desktop, the kernel _and_ most of the core userland is GPL (mostly v2), an extremely powerful license. nVidia got away with being able to distribute proprietary GPU kernel modules for some time, because distributions weren't moving fast enough. Why did they do it? Some vague illusion of their "Intellectual Property" being stolen, and competitors destroying them. All in all, they suffered (because they had to keep up with a fast-moving linux.git), and users suffered (because they had to get the precise version for their kernel). After many years of work, the cards were eventually reverse-engineered, and the noveau drivers are technically superior today. All in all, nVidia gained nothing and lost a huge amount of trust: if they'd upstreamed their driver, it would have been maintained for free (and improved upon); they could have concentrated on their core competency: making chips.
Today, AOSP (contrary to what its name suggests) is mostly just a code-dump project. They've forked Linux and have stripped out the GNU (GPL) userland. Broadly speaking, there are two ways to stay in power. 1. release minimal source code, and don't let other parties get in (aka. the Apple/Microsoft strategy). 2. simply assign all copyright to a neckbeard foundation with no money and nothing to lose (aka. FSF/GNU). Provided there's a big enough market (unlike nVidia being virtually the only manufacturer of decent GPUs back in the day), people will simply stop buying your hardware because their software doesn't run on it.
Google is pretty much on its own here, because there is no "open source project": various vendors fork the code and make their own modifications on top and distribute it happily. I run a CM nightly myself, because I get updates in the form of commit SHA-1s every night: _that_ is how you involve users and build a community. Can anyone threaten CM? Now, Qualcomm is attacking Google: Google can't give them the finger because they're powerless.
Fragmentation (aka. forks) are part and parcel of any uncontrolled development. GNOME is one very famous example: not everyone is happy with the same thing (GNOME Shell, Cinnamon, Unity etc.). For another example, look at mplayer: mplayer, mplayer2, and (now) mpv. The forks compete against each other, and the competent communities eventually achieve dominance. Contrast that with how many times Torvalds' tree has been forked: the forks don't survive because the community and leadership is strong and won't bend to anyone's demands (you're probably seen the media reporting how Linus gives nVidia the finger, or bashes patches that further Microsoft's UEFI agenda). Emacs has also had various forks in the past (remember XEmacs?), but all of them died off because of weak leadership.
AOSP should think about these issues seriously, and figure out how to keep the project running. I don't know what they should specifically change, because nobody has any idea about what problems they are facing.
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.
So much for all that noise from Google about 'openness'. The detractors were right.
The non-Atom chips usually have real Open GPU drivers that work the same as the desktop ones; the Atom chips [AFAIK] are the ones that primarily suffer from being PowerVR-licensed things with badly half-working "open" drivers.
All of us that buy, or let relatives buy Android devices that use restrictive and closed blobs.
Customers and only customers have the power to make the change.
Every time we encourage someone else to buy a non-Android device make sure to publicise the fact on open social media like Farcebook or Twatter on the corporate tags and pages to raise awareness in the less technology literate and make some voices heard.
It is one thing for companies to see bottom-lines get affected, but they also need to understand why. Don't just boycott, let the world know why too!
Is there someone/somewhere you can read ranking of manufacturer openness? For instance, Sony seem pretty active in the AOSP[0] but you never even hear them mentioned.
How about Google actually sells Nexus devices in my country and then I'll recommend them to people.
As it is, a few places sell the old Nexus 7, and that's it. The only Nexus phone ever to get sold here was the Nexus One, and there's no Nexus 10 either, no new Nexus 7.
Exactly which non android devices would you recommend? Not iOS, that's so closed down you can't even run unapproved apps. Not Windows Phone, that's the same problem as iOS. What would you recommend?
Not suspicious at all. Are you being paranoid? Binary blobs are so widespread unfortunately that you will find it difficult to have something that doesn't ship them. Graphic card drivers? Wireless chips? Even a computer BIOS is mostly a binary blob.
As part of the Nexus device support, Google releases factory images. These images contain all the blobs and whatnot necessary to restore your device's OS even in the event of a soft-brick. In the case of the new Nexus 7, it appears Google won't be releasing factory images and the cause is almost certainly the fact that Qualcomm doesn't want to release it's proprietary blobs for the Adreno GPU.
JBQ is pissed about this, this isn't the first time a vendor hasn't allowed release of certain blobs or the first time a vendor has refused to release the code necessary to even boot the device.