Rogue Amoeba responds to Phil Schiller
rogueamoeba.com
rogueamoeba.com
It's time for someone to re-edit Apple's 1984 commercial and swap the logos.
Which would be pretty nice irony too.
At the same time, Apple is under no obligation to make it easy for us to trample on their licensing deals for technologies that form part of Apple's unique selling proposition in a consumer's mind. AirPlay is so well implemented, consumers find it magical. To keep that mystique, Apple has a right to review and license AirPlay to those vendors that it finds aligned with its long term goals. If you want Apple to be forced to do something different, you're not a "hacker", you're on the side of big government and "Big Brother" demanding to oversee and meddle in a company's right to sell the product it wants that works in the way that it wants.
Finally, I personally want to encourage the hell out of a computing environment that makes everyday people find computing approachable and fun. Just as you don't want a power outlet that needs constant tweaking before you can plug something in, normals don't want a computer or smartphone that requires maintenance just to be able to have fun and get things done.
Apple's forced the mainstream computing industry to stop designing for ourselves, and start thinking about everyone else. This is why computing has finally gone viral.
Did you use that first Mac? It was never about "open" or "hackable", it was about appliance computing that gets the computer out of the user's way.
Nothing has changed since Apple's 1984 when Apple adopted the slogan, "The computer for the rest of us."
Nobody is forcing you to buy Apple's products either. The solution is perfectly laissez-faire: Stop buying them. There are plenty of hacker-friendly alternatives to Apple products which, while not quite as pretty, are still fun to use - and often enable "magical" features like the ability to use an international SIM or free WiFi tethering.
And hackerism is not the computing environment Apple wants to encourage. Besides the obvious benefit of more control = better stronghold of their market, Apple is also philosophically in favor of closed, well defined systems and minimal end user confusion, not pro open-ended, experimentation lands, "we give you the building blocks, you make it whatever you want".
And, as much as I like the notion of open systems and hacking, there should be room for the other side too, systems that are designed top-to-bottom and sold "as is".
I believe that history has proved that while it is possible to get quality UIs from open ended/open source style development projects, you get them with LESS consistency that you get them from an Apple-like process, and you also get more competing stuff/chaos/design by committee, unless you coordinate the whole process, from the kernel, to the end user apps.
Open source projects are mostly islands, so you don't get to have that long term vision / whole stack co-ordination.
To put it another way, an OS called OS X exists as ONE thing where one person had ultimate responsibility for what's included and in what shape to ship it. An OS called Linux does not: it only exists as disparate things collected and distributed together (a distro). The Gnome desktop environment, for example, is not produced for a specific OS: it's produced for whoever wants to use it, from various flavors of Linux, to FreeBSD, its apps even run on OS X.
>It's time for someone to re-edit Apple's 1984 commercial and swap the logos.
Why, did Apple ever changed course? The Mac was about a "computer for the rest of us" (ie simple users), and it remains the same now. Neither Mac, nor the 1984 ad was about tinkering. It was about empowering people with simple technology (a simple spreadsheet, a simple text editor, etc), not about empowering hackers to build things.
Actually, now, with the Unix underpinnings, the Mac is also a computer that lures tons of hackers (prevalent in any programming convention and most alpha hackers use a Mac, --even Linus, although he runs Linux on it), but the main market for Apple was an is the common user.
Perhaps you missed this?
http://www.youtube.com/watch?v=No1MxAnHuJM http://en.wikipedia.org/wiki/Think_Different
"Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can’t do is ignore them. Because they change things. They push the human race forward. While some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do. - Apple Inc."
Whereas Apple's focus of making simple computers/software for common people to use was a constant in their corporate story.
This wasn't just a single marketing campaign. It was THE marketing campaign. They even played the Steve Jobs narrated version at the Celebrating Steve event. After reading the Steve Jobs biography, I'm pretty sure that he and the others at Apple truly believe that this campaign represents Apples values.
Yeah, only it was only played once, decades ago, and nothing similar ever appeared in Apple ads since then.
The Think Different campaign was created in 1997 and ended in 2002, and I'm having a hard time believing they played that ad _once_.
iOS would be just as integrated and nice if Apple released it as Open Source. But it would give people more choice, Apple would make make less money from it, and they would then be at a disadvantage compared to other companies that did control their entire ecosystem.
The problem is that closed, proprietary systems tend to create monopolies, and while the initial products may be great, monopolies are seldom good for customers.
The other mistake people make is thinking that closed or open is an either-or proposition. Apples nice iOS ecosystem wouldn't be destroyed overnight if they had a settings option marked "allow unsigned third party apps". Would that compromise their long term / whole stack vision? No.
My mother should never experience the benefits a computer can bring to her life because the only device she could understand how to use would be something like an iPad—and since the iPad is made by a company that isn't 100% open, it shouldn't exist at all. Everyone should use Ubuntu, and if you can't use it, it's because you're too stupid and thus don't deserve to have a computing device in your life. Open source principals are more important than anything else, and they must be applied in a binary fashion, scaled across all approaches to computing in the world.
----
A pet peeve of mine is "hackers" ignoring design, and showing zero empathy towards humans [1]. Perhaps we need more designers in the world and not more hackers who stick tight to principals, often completely blinded by these binary maxims they drum up to the real end goal: enabling our species to advance.
[1] http://krisgosser.com/journal/2011/08/empathy-is-most-import...
You, presumably, are a hacker. While hackers represent a small part of the population, they represent a very important part of the market - the part that builds the wider ecosystem. We have a disproportionate effect on the evolution of technology. Use devices that advance an agenda that should be important to you - the ability to make devices do what you want, not what its manufacturer wants them to do.
Besides, you make the non-Apple world sound more bleak than it is. While Android is not quite as polished as iOS, it's perfectly usable by nontechies.
The hypothesis that it has to do with Apple preparing to bring out a competitive offering is laughable. Airfoil would not have a gram of impact on anything Apple does in this realm.
Rogue conspicuously makes no mention of this part: "Apple asked Rogue Amoeba to update their app to remain in compliance with our terms and conditions."
But it's not Apple's audio stream, it's the user's audio stream. I don't think it's particularly unreasonable to expect that user should be able to decrypt his or her own data (assuming we're talking about data that isn't under DRM; DRM is another issue).
Though AirPlay does work on DRM'ed streams, there's little advantage to using that over simply recording from the audio out from your computer and no advantage over using something like Audio Hijack Pro (another Rogue Amoeba product) or Soundflower to record the audio output of your computer.
If an authorized user initiates playing the content, DRM shouldn't prevent it from occurring.
On paper, yes. In practice, "unauthorized people" don't have to deal with it, and only "authorized people" have to struggle.
In other words, it's (disconcertingly) conceivable that Apple is contractually obligated to reject Rogue Amoeba's feature without a good explanation.
Is releasing something you know will get kicked out the best approach to take when you can't provide an approved solution? Maybe, if you think the resulting discussion and PR is your best chance at getting things changed... but then, again, you need to keep your message perfectly focused. Claiming that they didn't violate any agreements feels too defensive to me.
EDIT: and it's not just this response... initially they professed something much closer to ignorance/surprised innocence over the removal, while it now looks like there wasn't much reason for any surprise.
Not letting this issue drop just paints Rogue Amoeba in a bad light and confirms their immaturity to people like me who already thought they were in the wrong. Add to the fact that the feature is still in the app (you just need to upload a plist file) and I won't be surprised if Apple totally bans the app and takes further action with the developers and suspends their account.
The fact that encryption is involved is completely irrelevant.
Apple does not want an unlicensed and unauthorized app to use AirPlay on their app store. Case closed.
AirPlay isn't HTTP so don't compare the 2. Your comment about encryption is moot.
It was at one point. But then The Internets figured out how it worked, and now it's as easy for someone to implement as any other open protocol.
Remember: no particular legal protection applies to protocols. Apple is kicking Rogue Amoeba out of the app store out of pure malice, not because of any law that was violated. ("We'd like to sell you this product, but you figured out how to make it yourself, so you're gone.")
Two things no law broken, no charges filed no lawsuits presented. Pure maliace, hardly more like appropriate response to broken contract.
You're seeing the full power of Apple's control over the app store, though - they can stop distributing apps they don't like for any reason. The same power that Barnes & Noble has over the book market, and your cable provider has over your local TV market.
> "... Reverse engineering is, among other things, largely responsible for the PC revolution and the computing landscape we enjoy today. Should we stop providing users with products that work together simply because other vendors dislike competition?"
We all know Apple loves reverse-engineering of its products, so I'm sure this kind of reasoning helps your case.
The problem here is that Apple's wishes can be and are regularly applied in the app store regardless of whether they're actually good for the users(disallowing malware is good). This is a nasty side effect of the app store model and we'll be seeing more of such issues in the future with the Windows 8 Metro app store.
Imagine you were eating out at KFC one night, and using taste alone, you managed to work out their secret recipe. You then decided you wanted to get into the fried chicken business, but you didn't want the overhead of renting commercial space, or buying the kitchen/service equipment you need to run your own business. So you choose to walk into your local KFC, use their kitchen to fry your chickens, wrap them up in all the KFC packaging and branding, and begin to sell them at their counter. This goes unnoticed for a few hours, but then the manager notices what you're doing, and points you towards the exit.
Surely you'd understand why KFC wouldn't let this behaviour continue. You didn't steal their recipe; you worked it out on your own. You're perfectly within your right to sell chicken based on this recipe, but you'd better do it at your store, and put your own label on it. If KFC don't want you selling products based on their recipe (however legally you discovered it), you can't wrap them in KFC packaging, and you certainly can't sell them at KFC.
*I know someone will bring up jailbreaking. Jailbreaking is not a solution. It's difficult, voids the warranty, and can cause issues with stability and software updates. It's a non-starter for the vast majority of users. By limiting Airfoil to jailbroken phones, Apple kills 90% of Rogue Amoeba's revenue.
> By limiting Airfoil to jailbroken phones, Apple kills 90% of Rogue Amoeba's revenue.
Although you're right in saying this, it's only because 100% of Airfoil's revenue comes from the App Store. If they had revenue streams outside of the App Store (by choosing a different platform or devices), Apple wouldn't be able to block a cent of that income.
You're ignoring the fact that according to your analogy, our hypothetical KFC is already allowing people to make and sell different sorts of food with KFC branding from within their store (as long as you give them some of the proceeds and pay an annual fee, which was the case). In fact, a lot of people come to KFC precisely because they have an unmatched breadth of delicious and affordable dishes, and many people want to sell their wares at KFC because of their large clientele - KFC has successfully transformed into a food-court.
The hero of your post devised a delicious dish that would lose its flavor without the KFC secret sauce, but unfortunately for him, KFC only allows condiment manufacturers to use their secret sauce, and then only after a certification process to make sure they get the unique taste just right. Of course, they could, say, taste the delicious dish, realize that it's providing them with direct revenue, as well as satisfying consumers and increasing the odds they'll return to the food-court and spend more money.
Analogies aside, I understand why Apple does these sorts of things - first of all, they want consistency in UX since there really was no certification process. Also, keeping the ecosystem tightly under their control is much easier when you're very consistent about being draconian from the moment the platform was created (you go to the app-store, you play by their rules).
As a side-note, I'm surprised that there's so much support for Apple with these sorts of things when 15-20 years ago the same crowd would have been up in arms if Microsoft were to, say, send cease & desists to Samba or Wine (and still is criticizing Microsoft for disallowing other OSes in WinRT ARM devices).
Perhaps I got a bit lost when I chose to have the hero sneaking around, using equipment and service counters without the knowledge of the management, as that doesn't exactly parallel the App Store approval process. Although, seeing as Apple regularly approve apps only to pull them at a later date because of undetected features/activities, our hero's actions aren't too far-fetched.
P.S. I love that you played along with the analogy. In hindsight, KFC was a terrible choice, but I'm glad it opened up a bit of discussion.
Certain internal software API's are as much intellectual property as is the physical hardware design.
They may have re-implemented that work, but they did not reverse-engineer.
Until Apple stops their stupid policies and starts communicating openly, they will embarrass themselves again and again.
They don't have a "right" to be on the App Store. It's Apple's store ergo their rules. And everybody knows that the rules are more guidelines and Apple can and will change their mind about them at any time. Especially if you try and undermine them e.g. by using their private encryption key.
Does it suck. Absolutely. Is it unfair. Probably. But this has been the game for the last 3 years and Rogue Amoeba should not act surprised.
FACT: They reverse engineered Apple's proprietary technology and want Apple to help sell their app.
MY POINT: You must be nuts if you think that will happen.
"We have an Airplay licensing program explicitly to assist companies in creating AirPlay capable products. Apple never said that we would pull the rug out from anyone, we in fact worked with this developer to ensure they update their app and remain on the App Store"
The clear implication there is that Apple had procedures available for getting this to work and RA just ignored them. RA's response directly contradicts this.
P.S. thanks for the unexplained downvotes.
In the end it's Apple's store with Apple's rules. The rules have changed without warning in the past and will likely do so countless times in the future. The tradeoff for this is what is likely one of the most lucrative app stores to date for developers.
In fact, the first iOS didn't have third-party apps, and when the API finally appeared, it had very clear restrictions and a $99/year fee attached.
Typical corporate trickery. The reason a lot of people fall for it is because they have an open mind (definitely advocated by Apple) and therefore are gullible (definitely wanted by AAPL).
Having written something somewhere doesn't make you less of an asshole for handling in a dirty, asocial way.
This entire sentence applies to Rogue Amoeba. The Airplay protocol has been reverse engineered years ago: it's basically RTSP with an encrypted stream. Creating an AirPlay audio receiver is currently subject to a license, and requires a private key. This key has been extracted from a dumped AirPort Express ROM. Rogue Amoeba can say what they want about reimplementing the whole AirPlay protocol on their own, the clef-de-voûte is this private key, only available through licensing. When Schiller mentions private APIs, I believe he is not talking about an iPhone private API (which I'm positively sure Rogue Amoeba took great care of not using) but the remote AirPlay API, which they have no right to use without licensing.
The key point here is that there's a key virtually locking the API. I think it's perfectly apt to say now that — thanks to the Google/Oracle case — implementing an API is licit, but you would subsequently have to use your own public/private keys. Yet existing AirPlay sources encrypt the stream with Apple's public key, hence the content is at the sole destination of Apple's private key.
Compare this to the following situation: you publish you PGP public key and someone writes you an email and encrypts it with your public key. If someone steals your private key, that does not entitle him to decrypt and read the message whose sole intended recipient is you. This is, I believe, the crux of Apple's AirPlay licensing.
I generally don't like Apple's silent hammer, and I really like Rogue Amoeba and their software (which I bought multiple times), but — since I knew what was in play technically — when reading the last status report of Rogue Amoeba, it was obvious to me that they were concealing information with the goal of bending the truth to support their side of the argument.
P.S. Who else had to Google clef-de-voûte? FYI: It basically means "most important component" or "key element." (via bab.la)
Without it everything falls appart.
A key is not an API. AirPlay is not an API. Full-stop.
Whether Rogue Amoeba was wrong to do this or whether Apple was right to ban them or whether reasonable observers could have predicted the banhammer is not at issue in this thread.
The issue is--Phil Schiller mislead a customer by describing Rogue Amoeba's behavior in a factually inaccurate way. Rogue Amoeba's blog post picks apart these inaccuracies like shooting fish in a barrel. I studied Phil's e-mail and I found exactly one sentence that I thought was accurate.
Sure, Apple can remove this app from the store. They should either just say that, or not respond to the customer at all. Somebody who has made a decision that he/she feels confident about has no need to slant the facts and make misleading statements. Whether or not Apple was right to do this independent of the fact that they were wrong to discredit Rogue Amoeba in an inaccurate way.
I never said that.
> AirPlay is not an API.
AirPlay is a remote interface allowing a local application to control software on a remote device and stream data to it. I could implement it over HTTP as a RESTful API or whatever way I see fit and however simple and thin it would be†, it is still a way for applications to programmatically interact through an interface, hence, an API.
But again, this is not a problem since we can now safely implement interfaces without fear.
> Rogue Amoeba's blog post picks apart these inaccuracies like shooting fish in a barrel
... and (assuming that one thinks they scored) misses the elephant in the room. encrypted AirPlay audio streams. Rogue Amoeba knows about this. Apple knows about this. The only party concealing that fact is Rogue Amoeba, and they're entirely disingenuous about it. Since the very first developments (and really, since their announcement of the feature upon release) people have been wondering about the inclusion of the Apple private key; yet Rogue Amoeba stayed quiet on the subject. What I expected of them was at some point to directly answer the question "did we use the Apple private key?" with "yes" or "no".
Again, whether I put a license or not to use my PGP private key, no one has the right to pick up content encrypted for me. They basically created an eavesdropping piece of code.
And this is true for any licensing scheme. If there's no license satisfying my will, I have no right to take it anyway. Rogue Amoeba even goes to admit:
> While Apple licenses the ability for hardware manufacturers to play AirPlay audio, there is no such licensing program for software. When we inquired as to the possibility of this type of licensing being available for software manufacturers in the future, we were informed that it was unlikely.
Then they decided that since there's no license covering that case, they have the rights to build something respecting the AirPlay API (they do) and decrypt data with a stolen private key (they don't). And went on to build it and sell it, get kicked out, complain (rightfully so regarding opacity, laconic answers, and delays), and ignore the most critical part in all subsequent communications. How cool is that?
Now the fact that Apple has no explicit licensing scheme for software manufacturers is a blind spot of their part, but who honestly believes that hardware manufacturers implement their AirPlay receiving devices as pure hardware? I bet the licensing terms could apply just as well to pure software endpoints.
> Whether or not Apple was right to do this independent of the fact that they were wrong to discredit Rogue Amoeba in an inaccurate way.
And the same applies to Rogue Amoeba.
† AirTunes has a HTTP control channel used to negotiate details, AES key exchange via RSA encryption, a remote volume knob, metadata transmission, progress information, and a data channel for audio streaming that can be suspended without closing the stream. http://git.zx2c4.com/Airtunes2/about/
The first issue with calling this "using a private API" is that the part of the application under dispute doesn't open a connection to any remote service--but accepts connections from incoming Apple hardware. It is much more correct to say that Apple is "using a private API" in this case.
The second part of the problem is that even if Rogue Amoeba was initiating connections to AirPlay clients (which they are not, at least not the part of the program under dispute), this would not be an "API" as it is usually defined.
For example, OED calls an API:
> a system of tools and resources in an operating system, enabling developers to create software applications.
Wikipedia says:
> In general the difference between an API and a protocol is that the protocol defines a standard way to exchange requests and responses based on a common transport and agreeing on a data/message exchange format, while an API (not implementing a protocol) is usually implemented as a library to be used directly: hence there can be no transport involved (no information physically transferred from/to some remote machine), but rather only simple information exchange via function calls (local to the machine where the elaboration takes place) and data is exchanged in formats expressed in a specific language.
The rest of your post deals with whether Apple is right to do what they did or whether Rogue Amoeba is right to do what they did. Did you even read my reply? In this thread, neither of those two positions are relevant. If Rogue Amoeba had broken into Apple Headquarters and personally tortured Steve Jobs to extract the private key, that would not be relevant. What is relevant is whether Phil Schiller lied and misrepresented Apple's position in a dishonest way.
Let me break down, specifically, the misrepresentations, in numerical form for easy reference:
1. "not accurately recounted on Rogue Amoeba’s website." In what sense exactly is Rogue Amoeba's website inaccurate?
2. "accessed encrypted AirPlay audio streams without using approved APIs" this implies that there exists some approved APIs that RA could have used. Again, whether Apple should or should not provide these APIs is not relevant, what is relevant is that Phil implies that usable APIs exist when they do not
3. "or a proper license" This implies that a proper license exists, see 2. Again, not relevant whether or not Apple should or should not provide a license to RA, only relevant that they imply RA had the option to use it and did not
4. "in violation of Apple’s agreements" This may be in violation of agreements that Apple has with various hardware manufacturers, but this statement implies that RA is bound by these agreements or even knows or can find out what is in them. They cannot. Essentially, Phil is holding RA to a secret standard.
5. "Apple asked Rogue Amoeba to update their app to remain in compliance with our terms and conditions" According to RA, Apple ignored RA's questions for clarification for several weeks.
6. "We have an Airplay licensing program explicitly to assist companies in creating AirPlay capable products." - This implies that RA could have taken advantage of the licensing program and did not. In fact RA could not have taken advantage of the licensing program. Whether this is good or bad is not at issue; the issue is Phil is misleading the customer.
7. "Apple never said that we would pull the rug out from anyone" - iOS guideline 2.20, 3.10, 6.3, 22.7, and others explicitly say that Apple will pull the rug out from under developers. Whether or not these are reasonable or unreasonable guidelines is not at issue in this thread; the issue is that Apple does in fact say they will do it and Phil claims they will not.
8. "we in fact worked with this developer to ensure they update their app and remain on the App Store" For some definition of time elapsed and public outcry; see #5.
I hope this clarifies the issue. Whether RA was right or wrong to extract the private key in the way that they did (or use a private key they got from another source) is not an issue. The issue is: did Phil Schiller lie to a customer? I think I've made a pretty convincing case.
I beg to differ, and consider both definitions you subsequently give as incredibly restrictive as it would exclude some of the most used APIs in the wild. Everyone in the field will call the Twitter API an API, and everyone will agree that StatusNet implements the Twitter API.
That said, the consumer of the API is indeed AirPlay clients while the API is being served by Apple TV, Airport Express and AirFoil Speakers (Touch). But again this does not matter (and even if we called it a protocol, and really here we have multiple protocols at hand) and RA would have every right to implement it (just as Google implements the Java API, or Wine the Windows API, or StatusNet the Twitter API).
1. It is inaccurate in that it misses one of the most critical points of the discussion.
2. I agree that RA (probably) did not use any non-approved iOS API and that they have every right to implement the AirPlay API/Protocol. I maintain though that they can not make their implementation interoperate with existing AirPlay clients that encrypt the stream. Whether that falls under the "approv[able] API" wording is a stretch, but nonetheless possible. Even RA considered that case in their May 29th post. But this does not matter, since the rest of the phrase is linked to this one with "or".
3. No this does not. This says: "you do not have a license to do that". The fact that no such licensing scheme exists is relevant only in implying that they simply can't do that at all.
4. Apple's iOS developer agreement being quite vague, I'm pretty sure they could fit almost anything they want under this agreement, and this is bad.
5. According to RA, Apple rejected the app because they deemed it non compliant, and as such they "asked Rogue Amoeba to update their app to remain in compliance with our terms and conditions". Not detailing what was not compliant, however rough, does not make the previous statement false. The first Apple answer seems like the usual preset, generic and despicable answer. If anyone takes time to analyze and invalidate an application to such levels of detail, they should disclose their full process and reasons to reject the app together with the app rejection.
6. They do have a program, and it appears to exclude software makers. I find it very sad that it comes to such an escalating situation to at least extend the current licensing scheme to software manufacturers.
7. Agreed.
8. Both the part you cite and the point you make are entirely true, and the second part is simply outrageous. Apple definitely has to improve on that front.
So, did Schiller wrote an inaccurately worded letter? Sure it did. And while they handled the case in a heavy handed and awkward manner, can we call those purposeful lies? It might be, but I'm really not convinced. In the meantime Rogue Amoeba recognizes they "inquired as to the possibility of this type of licensing being available for software manufacturers in the future, [and being] informed that it was unlikely" yet still trying to push the update through approval.
What's more they go on to say, regarding accessing the encrypted content:
> "Quite simply, it is not. While there are multiple layers of encryption involved in the AirPlay audio streaming protocol, their primary purpose appears to be preventing third parties from building applications which interoperate with AirPlay."
In a word, they assumed they had the right to circumvent a mechanism protecting Apple's licensing scheme (however vile we think it is WRT interoperability), made a run for it, were caught red handed, and called out the web regarding the injustice. Maybe they genuinely believe they're right, but that does not make them the good guys.
To sum this up, I believe both sides are at fault, but I'm much more inclined to say that they are all acting in good faith, and that such matters would resolve with much less friction if there was not so much tension (mainly due to delay and opacity, which only increase the uneasy feeling that things are arbitrary) around the review process.
You'll have to take that up with OED and Wikipedia. I think it's fair to say that at the point that they agree with each other and disagree with us that we're the ones using the words wrong rather than them, and it's us who need to invent new words rather than they. That's what it means to be a language authority.
#1 seems like an overall summary statement so my response is implied by the below
#2 I can't detect any disagreement
#3 - "you do not have a license to do that" - They also don't have a license to rent a bouncy castle. Phil isn't listing things that they don't have a license to do, he's (attempting to) explain why Apple rejected the application. He's implying that a license exists.
4. The word "violation" has a specific legal meaning. In this case, I can tell you for sure that he's specifically referring to agreements that Apple has with hardware manufacturers (which actually say you cannot do this explicitly), which RA has never read
5. I will concede that Phil's statement is technically correct, but when you consider how the average customer would interpret this statement, it leads them to an incorrect conclusion.
6 & 7 - No point of disagreement that I can detect.
8. No point of disagreement that I can detect.
> can we call those purposeful lies?
Phil is on the board of directors of a publicly traded company and society holds such people to an extremely high standard of honesty. I'm not sure why the word purposeful is of any relevance, but they're certainly misleading statements and Phil Schiller is not employed by Apple to blab whatever he thinks of to say to random customers.
> In a word, they assumed they had the right to circumvent a mechanism protecting Apple's licensing scheme (however vile we think it is WRT interoperability), made a run for it, were caught red handed, and called out the web regarding the injustice. Maybe they genuinely believe they're right, but that does not make them the good guys.
The following set of words: {right, vile, made a run for it, red handed, called out, injustice, good guys} ascribe a certain moral narrative to this situation that I do not subscribe to at all. There are a lot of very worldviewish questions in here (e.g. what it means for a software company to be moral, whether morality can be meaningfully ascribed to a company, etc.)
I don't mean to dissuade you of these views, because I imagine that if we take the time to wade through it, we will discover that each other's positions are pretty reasonable. But that would require us to wade through a lot of psychology, philosophy, religion and ethics to arrive at that point, and so in the interests of time I would recommend steering clear of ascribing particular ethical conclusions to the actions of actors except in the narrow cases where it is actually important, in which case we must be willing to defend it at some length.
One such area (of valuable exploration) is whether, assuming Phil made misstatements in his e-mail, it was morally correct to send. I think we agree on enough of the points to conclude that these misstatements did exist, and so the problem reduces to whether a corporate director sending misstatements to a customer is immoral. From your reply, the operative test seems to be whether they constituted a purposeful lie which is, at the very least, an interesting test.
Subject to the rule of law, of course.
Adding in support for AirPlay to an app and selling that won't void your or my iPhone's Warranty if we were to install it, but it can void the contract put in place between Rogue Amoeba and Apple, if even just for that singular app. Here is the real reason Apple threw this app out of the store: http://news.ycombinator.com/item?id=4087666 RA was using a private key derived from a firmware update for the Apple Airport Basestations in order to encrypt the audio stream in accordance of the AirPlay protocol.
Want a custom stereo in your new car with a fancy center stack setup with a non-standard-size stereo and possibly even integrated AC/heater controls? You're going to have to jump through a lot of hoops. Want software with more functionality than Apple exposes to developers? There's always jailbreaking...
In neither case has there been a substantial consumer backlash.
And I don't know any manufacturer that will sell you someone else's head unit as an aftermarket piece. It's up to you to find out how to take everything apart and fit something else in there on your own, or to find someone who knows—basically, jailbreaking your dashboard. Except you generally lose stuff (like steering wheel controls), while I hear jailbreaking is pretty painless these days.
Edit: Apple's app store isn't some third party stereo store, it's a store owned by the manufacturer itself. And car manufacturers are famous for having highly priced proprietary replacement parts, especially when it comes to electronics like stereos, if you aren't willing to deal with an outside store/brand. I really don't see any way Apple's less flexible with the iPhone than a car manufacturer is with their cars.
It's one thing to make the center console non-standard, it's another to prevent the installation through warranty restrictions.