Sorry for the lack of posting, but exams have been killer. One more exam today and then I’m done for the summer! While you wait with bated breath for my next post, I thought I would point you to this post on Slashdot that says that Apple is facing an antitrust inquiry from the DOJ. While other people were claiming that Adobe was going to sue Apple because of its new developer license, I stated that Adobe didn’t really have a claim, but that this new license might be enough to get the DOJ looking into antitrust issues over at Apple. Just like I suspected, people at major corporations, as well as the government, look to this site to determine the best legal course of action.
Browsing Posts in Apple
Recently Apple announced its newest iPhone, iPod Touch, and iPad operating system and software development kit. With the new development kit, however, comes new developer restrictions. The restriction that is causing the most controversy relates to what programming language the developer must use to develop the application. In this article, the writer alludes to the fact that Adobe is getting ready to sue Apple over these restrictions. So how does this restriction affect Adobe and what cause of action could it possibly have?
I’ll start with the technical aspects of issue. Companies like Apple and Google, when creating operating systems, create library calls that developers can use to access the underlying system hardware. They act as an intermediary between the hardware and the applications. For example, they can provide library calls that allow a developer to access the GPS, accelerometer or keyboard. The languages that are used for iPhone development are C, C++, and Objective C. These languages are not the most simple languages to use and all have a very steep learning curve. This is where Adobe and some others come in. Adobe created a type of application called Flash that is used in many web applications, including YouTube. Flash applications are developed using Action Script, a programming language that is much less technical to use than the C type languages. Adobe has added a feature to their Flash development suite that allows a developer to create a Flash application in Action Script and export it to an iPhone application. This dramatically lowers the learning curve necessary for people to develop iPhone applications. The new restriction by Apple will prevent applications developed using tools like Adobe’s from being submitted to Apple’s App Store. In its defense, Apple’s CEO Steve Jobs pointed to this article to explain the business and technical reasons why it added the new restrictions. The arguments center around the quality of applications created this way and the effect that these applications would have on Apple’s ability to add new features.
So now we know how this restriction affects Adobe, but what legal action could it have against Apple? I don’t really see any. Commenters on the article seem to believe that there will be some sort of antitrust action. From what I know of antitrust law, I don’t think Adobe has much of a claim. The first determination that needs to be made when looking at an antitrust claim is what is the relevant market. The market that Adobe’s application is trying to compete in is the mobile application development environment (tools that developers use to create new applications). Apple doesn’t even come close to having a monopoly in that market. If Adobe’s plan is suing Apple for antitrust violations, it has a rough road ahead because Apple’s monopoly doesn’t affect its business.
But Adobe doesn’t have to be the one to bring suit. Antitrust claims can be brought by the U.S. Government via the Department of Justice or the Federal Trade Commission. While Apple may not have a monopoly of development environments, Apple may have a monopoly over the mobile application store market. According to engadget, Apple’s App Store accounts for 99.4% of all mobile application sales. If I recall correctly, that represents a monopoly in all U.S. jurisdictions. However, having a monopoly is not per se illegal if it is obtained by using good business acumen. The illegality comes in when a company with a monopoly uses it as leverage to expand its monopoly or to prevent competition.
Do these restrictions either expand Apple’s App Store monopoly or prevent competition? They most definitely do both, and the article Steve Jobs pointed to as a defense of his new restrictions admits as much. Imagine that you are a mobile device developer. You have to determine what mobile platform you want to write your application for. Apple’s platform constitutes 99.4% of all sales so the smart money is on you developing your application for Apple. When the application is finished, you have a choice: you can re-write your application for other platforms or you can begin work on another Apple application. Your time would probably be better spent creating another Apple application because it has most of the market. However, if you could write your application in one language that runs on multiple platforms, to the exclusion of Apple, and then export that application to Apple’s platform using an automated tool, you could put your one application, written in one language, in multiple market places with minimal effort. Apple’s restrictions serve to leverage its monopoly to reduce both the developer and application pools for other mobile platforms.
The U.S. Government could bring an antitrust claim against Apple. Previously, I have discussed other antitrust issues with regards to Apple’s App Store and its Developer Agreement. Adobe’s complaining might be enough of an incentive for the DOJ or FTC to take action, most likely trying to force Apple to open up its App Store and eliminate the developer restrictions. Will this happen? I don’t know, but I do know that the Government is in the best position to take on Apple and its anti-competitive practices. Apple’s closed system was never a big deal when it only controlled a small percentage of the market, but now that it has a monopoly over mobile application sales, it cannot continue to act in the same way. Apple’s closed system allowed it to control exactly how its devices were created and helped it to achieve the success it now enjoys. But now that success may end up costing it the control that it holds so dear. Like a great philosopher once said, “Hold on loosely, but don’t let go. If you cling too tight babe, you’re gonna lose control.” Truer words have never been spoken.
Stephen Burch
Two issues need to be addressed with regards to software patents. First are the requirements to get a process patented. The second is the length of time that the patent is valid.
Patents have two requirements that are relevant to this discussion, they must be both non-obvious and novel. How do we ensure that only patents that meet these requirements are accepted by the patent office? Furthermore, how do we ensure that prior art doesn’t exist and that the proposed solution isn’t obvious to a skilled person in the field? The patent office recently completed a peer-to-patent project. This research project allowed anybody to comment on a patent application, show prior art, or help clarify any aspect of the potential patent. This project relied on Wikipedia-esque help, where people who care about the industry will volunteer their time to ensure that bad patents won’t get through. I believe that this a step in the right direction and I hope that the project will be adopted and become mandatory as part of the approval process for any software or business method patent. However, it doesn’t solve the entire problem. This process does not help with the non-obvious requirement of the patent. As I have previously stated, everything is obvious when someone shows you the answer. In the peer-to-patent project, the reviewers see the patent application. I think for the non-obvious type of analysis, a blind study would better serve this purpose. The patent office should create a pool of programmers and keep a database of their related skills. When a software patent is submitted, the patent office searches the database for programmers with skills in those related areas, then selects three to five programmers to perform the blind study. The study would involve giving the selected programmers the problem that the patent seeks to solve and some amount of time (24-48 hours or varying based on complexity) to outline or pseudo-code a solution. If none of the selected programmers are able to determine the solution described in the patent, then the non-obvious prong of the patent would be met. This would prevent patents that do obvious things with new technologies from being granted. Take Apple for example. Apple creates some new technology, say a touch-screen smart phone, that is rightfully protected by patents. Then it goes on to patent the software that interfaces with this technology. The problem with these second patents is that they are obvious. Apple has basically patented doing something with a finger on a touch-screen that people have been doing for years with a mouse on standard computers. I don’t believe that just because the technology is patentable, various ways of interfacing with that technology are de facto patentable. A proposed blind study approach, using programmers willing to work for free just to ensure the quality of software patents, would prevent such obvious patents from being granted.
The second major issue is the length of software patents. Patents currently have a potential life of twenty years. I don’t think that patents were meant to grant a monopoly to the holder for the entire life of the invention. They should only be granted for a limited time, long enough to recoup research and development and get a head start on the competition. This is just long enough to encourage innovation. Twenty years in the software world is equivalent to two eternities in the physical world. The problem with the current patent duration is that by the time the patent is no longer enforceable, the technology is outdated and irrelevant. For all intents and purposes, this prevents other companies from ever using the technology (without licensing agreements) and creates a permanent monopoly over the process. The patent system walks a tightrope between the anti-competitive effects of monopolies and the anti-innovation effects of not allowing ownership of intellectual property. Allowing the monopoly for some portion of the inventions usefulness is good for innovation and competition because it gives incentives for innovation without suffering the full effects of a permanent monopoly. Allowing the patent length to exceed the usefulness of the patent, however, hurts innovation and competition. Even worse, the current length of software patents disproportionately effects small companies and start-ups. As I have discussed before, large companies have patent “war-chests” that protect them from patent litigation. Small companies and start-ups, however, do not. I believe a more reasonable time frame would be better for software patents, something along the lines of five to eight years. This would give inventors time to market their product, without fear of copying for a period of time long enough to build a brand and recoup investments, while preventing a per se permanent monopoly over the invention.
So there it is, my thoughts and feeling on software patents. While I most certainly do not believe that software shouldn’t be patentable (see the proposition in New Zealand), I do think that the patent office should do more to ensure that only deserving inventions get patent protection. Much of the backlash against software patents stems from the patent office approving patents that are obvious or non-novel and that hamper the ability of programmers to create new software. If the patent office were to take greater precautions to ensure that this didn’t happen, I believe much of the opposition to software patents would disappear.
Stephen Burch
This is a quick final post on the Apple iPhone developer license agreement regarding the FCC’s investigation into Apple’s rejection of the Google Voice application. According to the FCC chairman, the FCC “has a mission to foster a competitive wireless marketplace, protect and empower consumers, and promote innovation and investment.” (link) So to further this mission, the FCC requested that AT&T, Apple, and Google all respond with their version of the events with respect to the rejection of the Google Voice application. Their responses can be read here.
Everything that can be said about this has already been said by others when the event was ongoing, but did the investigation yield any results? Well, it did help one of my favorite apps, Sling Player. For those of you that don’t know, Sling Player is a box that hooks up to a cable box and the Internet and allows users to watch and control their television anywhere they can get an Internet connection. When Sling Player submitted their iPhone app to Apple, it was initially rejected. Sling was told that their app could not work over the AT&T cellular network. So Sling resubmitted the app with a modification that only allowed it to work over wireless connections and not the cellular connections.
Then the FCC investigation happened. So in February, AT&T announced that they had been working with the Sling Player developers to optimize the app for their cellular network and were pleased that Sling Player would now be allowed to work over the cellular network. Sounds all well and good right? Except for that Sling stated that they made no technical changes to their application and that AT&T never discussed any specific requirements with them.
So, did the FCC’s investigation have any impact? Maybe. Maybe not. But it does show that regulatory agencies are looking at Apple and AT&T’s conduct. And more importantly, I can now watch my TV anywhere I go. And in the end, isn’t that what is really important?
Stephen Burch
In my previous two posts (here and here), I discussed the Apple iPhone Developer license agreement and its effect on developers. I also discussed how some of its provisions might not be enforceable. Since Google has been on the receiving end of some of Apple’s onerous terms, why didn’t it make any challenges?
First, let me talk about a happier time. When the iPhone first came out, Apple looked to Google as its default search engine provider and its sole Maps provider. Google’s Voice Search even violates
So if I’m right and Apple’s developer license terms aren’t enforceable, why didn’t Google challenge Apple in court over Voice’s rejection? I have a couple of ideas, one is legally based and the other is business based. The legal argument is pretty simple. When a court tries to determine if a contract term is unconscionable, it looks to the disparity in the bargaining power of the parties. While most app developers don’t have equal bargaining power with Apple, it is hard to argue that Google, which is a larger company than Apple, has less bargaining power. Although one could argue that there is a big disparity when it comes to Google’s bargaining power with Apple in relation to iPhone apps, I don’t think Google even wants to challenge Apple on this issue.
Google makes its money by getting people to do things on the web instead of in separate applications. When Apple rejected Google Voice, Google recreated the application as a web app, eliminating an iPhone lock in. Google cannot and does not want to compete with Apple or Microsoft on the operating system market. It wants people to treat the browser as the operating system. Google Maps revolutionized what people thought was possible in the browser by using AJAX. It continues to bring applications that were once thought of as exclusively desktop applications to the web (just look at Picasa and Docs). And it has done so by providing all of the tools for free, furthering its core business, advertising. Even more importantly, Google’s Android is now competing with the iPhone.
Google Voice is an awesome application. Apple’s exclusion of the application doesn’t hurt Google, it hurts Apple. Android has a much more open development environment and is just more developer-friendly all around than the iPhone. The only real difference between the two is the audience. The iPhone can still earn the developer more money than any other phone platform, and at the end of the day, Google wants to see the iPhone’s popularity decline. The harder it is for developers to work with Apple, the easier it will be to get them to develop for Google’s Android. Spending precious Google time and money to force Apple to be more open works against its long term goal. And besides, the FCC has decided to review Apple and AT&T (Apple’s exclusive iPhone provider in the US) all on their own. More on this tomorrow.
Stephen Burch
In my previous post, I discussed Apple’s iPhone Developer license agreement which was obtained by the Electronic Frontier Foundation (EFF) and the effects that it has on developers who have had their app rejected by Apple. Now I turn to the other part of the license agreement that really bothers me: Apple holding developers liable for any breach while simultaneously disclaiming any liability for its own actions.
Section 2.6 of the license agreement is entitled “No Other Permitted Uses.” Before I discuss some of these prohibited uses, let’s look at the legal repercussions for breaching this section. “If You breach any of the foregoing restrictions, You may be subject to prosecution and damages.” Good to know. Be sure to notice that: 1) there is no limit to the damages and 2) elsewhere in the contract they reserve the right to seek an injunction. So what can you do that is so awful that Apple will seek to sue and enjoin you? Well, if a developer owns a computer from Pystar, a company that used to sell computers that run the Mac OS (OS X), he wouldn’t want Apple to find out. In fact, anyone who tries to run this software on any non-Apple branded computer is in breach of this agreement. Basically, if a developer wants to write software for Apple’s iPhone, then he must buy and use an Apple computer as well. Or Apple will sue you. It’s the Apple way. For non-developers, I don’t know if I can convey the absurdity of this. You develop a piece of software. You submit that completed application to Apple. As long as it is compiled with the same OS and processor, the company that packaged that hardware makes absolutely no difference. But Apple knows that the iPhone has a huge app market and developers want in. So why not get the developers to buy a Mac along with an iPhone if they want the privilege to work with Apple? To be fair, the rest of the other prohibited uses don’t seem as arbitrary or onerous as this one. But let me be clear- if you break any of these provisions you are subject to “prosecution and damages.”
Is Apple really so wrong? It is Apple’s software, after all. Why can’t it control the terms of the sale? It can, to an extent. But Section 14 – “Limitation of Liability” seems a little over the top considering the liability that developers can face:
“IN NO EVENT WILL APPLE BE LIABLE FOR [pretty much anything you can think of] NOTWITHSTANDING THE FAILURE OF ESSENTIAL PURPOSE OF
ANY REMEDY.”
I read this a few times and each time the failure of essential purpose clause makes me laugh. For those who don’t know, “failure of essential purpose” relates to warranties. For example, imagine if someone buys a new car with a 50,000 mile power-train warranty. Then, 10 miles into the ownership of the car, something on the power-train breaks. She then takes it to a dealer who agrees that, yes, the car is covered under warranty – BUT only up to $10. This warranty suffers from a failure of essential purpose. But at least it covers $10. Apple basically says that it can even breach the contract and you have no claim under contract law for any amount. I still am not sure what warranty it thinks could fail at its essential purpose, as it warrants nothing. But the best part is the next line:
“IN NO EVENT SHALL APPLE’S TOTAL LIABILITY TO YOU UNDER THIS
AGREEMENT FOR ALL DAMAGES (OTHER THAN AS MAY BE REQUIRED BY APPLICABLE
LAW IN CASES INVOLVING PERSONAL INJURY) EXCEED THE AMOUNT OF FIFTY
DOLLARS ($50.00).”
If Apple actually believed their disclaimer to be valid, this clause would be pointless. But just in case, it goes ahead and limits its liability to $50. Liability for what you ask? Beats me. It just stated it isn’t liable for anything.
What bothers me the most about this is the disparity of liability between the parties (Apple and the potential developer). Not too long ago, there was a discussion about App Store apps ‘racing to the bottom’, in regards to most of the top selling apps costing only $.99. But how many independent developers want to invest lots of time and money developing a large, complex app only to be at Apple’s mercy when it comes to being accepted at the App Store and the potential target of Apple’s lawyers if the attempt to sell it elsewhere. They have no recourse with Apple and they can’t sell it anywhere else. They just have to just suck up the losses.
I could rant about this for hours. If I taught a Commercial Law (UCC) course, these two sections of the license agreement would be the subject of my entire exam. I would image most students would have a hard time discussing all of the legal implications in the three hours allotted for the exam. But that’s enough for now. Monday I will continue the discussion with my thoughts on Apple and Google.
Stephen Burch
The Electronic Frontier Foundation has obtained a copy of the secretive Apple iPhone Developer Program license (link). They made a Freedom of Information Act request to NASA after NASA created an iPhone app. It was pretty ingenious really. But why go through all the trouble to get it? Why not just sign up or ask a friend who has? Well, part of the agreement is – the agreement is secret. I have many problems with the way Apple does business (as I type this on my MacBook), but they do have a right to do business as they see fit as long as it’s not unconscionable.
While this license is very one-sided (and what adhesion contract isn’t), there are two things that stand out to me as bordering on unconscionable. There may be more, but these two things bother me the most as a developer. First is the inability to sell your application elsewhere, even if Apple rejects it. The second is Apple’s willingness to hold the developer liable for any damages resulting from improper use while at the same time disclaiming any liability themselves.
I just finished Commercial Law last semester, so I feel the need to determine if the UCC is applicable or not. What you get from Apple is a software product. Software sales are usually governed by the UCC. However, you only get the software for the length of the license (1 year), unless you renew. This is more like a lease, which is also governed by the UCC. So I would think the UCC would apply. Ok, I feel better now.
The inability to sell your application on other markets, even if Apple rejects it, seems overly harsh. The only reason a developer would enter into this agreement is to develop an application for the iPhone or iPod Touch (from now on referred to collectively as ‘iPhone’). While there is only one Apple-approved method of selling apps for these products, Cydia is another application store that allows users of jailbroken iPhones to install software that is not Apple-approved. Cydia doesn’t have nearly the user base that Apple’s App Store has, but if a developer spent hundreds of hours writing an app only to have Apple reject it, I would imagine any user base looks better than none. In this license, Apple can reject an app for any or no reason. Even worse, they can just never approve nor reject an app (link – of course, that seems to have earned them an FCC investigation – more on Google later). The rejection part of the license is fine by me. Steve Jobs is a perfectionist. He doesn’t want apps on the App Store that he doesn’t like. And Jobs’ judgment on whether something is good or not has earned Apple billions. But what about a developer, who purchases this software for the sole purpose of writing an iPhone app, and who follows all of the development guidelines only to have his app rejected because it’s too cookie-cutter? Or to have it approved only for Apple to remove it months later because they changed their policy as to what is acceptable? He acted in good faith. He followed the rules. He relied on Apple as the sole retailer of his software and they rejected him based on their subjective feelings. But, according to this license, if the developer then tries to market his product on Cydia, Apple can obtain an injunction forcing them to stop. I’m no lawyer, but something about this seems unconscionable. No one would voluntarily pay money to have these restrictions imposed upon him. In my opinion, one of these terms would have to give. And I also believe that Apple feels the same way. The PdaNet app was rejected by Apple for inclusion in the App Store. None the less, it is available on Cydia. Apple isn’t exactly known for letting things slide. But they let PdnNet slide. Why? My conclusion is that they don’t really want to push this for fear of losing in court and word leaking out that these terms are unenforceable, but that’s just my opinion. Don’t get me wrong, I do not want to test it out with one of my applications. And I also think, that with the App Store’s large market share of downloaded mobile applications, 97.5% according to engadget, Apple may worry that an antitrust lawsuit would force them to accept more apps rather than just letting developers choose an alternate outlet. Should Jobs lose his grip over anything, it would most likely drive him insane. Next thing you know he would be living here and plotting to put frikin’ laser beams on sharks.
This post is getting pretty long. I’ll continue the next part tomorrow about the disclaimer portion and follow that up with my thoughts on Google and Apple.
Stephen Burch
