Pervasive Technologies Project Working Document Series: Literature Review on IPR in Mobile app development
This post is literature survey of material exploring and analysing the role of Application Platforms in the Mobile Applications Development ecosystem, albeit from an intellectual property perspective. The document is a work in progress.
1. What are the decisions developers are making within their practice in terms of location of their enterprise and clients, scale of audience, funding, business models and mobile apps marketplace (app stores)? Who is the primary actor in the mobile applications development cycle in India?
1.1. Is the mobile apps marketplace organically developing into a Bazaar model, or a Cathedral model?
1.2. What are the contractual terms between the enterprise and the employee? What is the typical nature of agreements in the mobile apps development industry between enterprise- employee and enterprise- client?
The role of Mobile application developers (“developers”) is critical in the app market, especially when such markets are regarded as the key entry and dissemination point for mobile content. Developers are seen as innovation engines and the fastest route to innovation, so understanding factors that attract and retain third party mobile application developers is of importance to mobile platform providers in order to survive.
Who are the primary actors in the mobile applications development cycle in India?
This chapter of the Pervasive Technologies Project (“Project”) aims to study developers who are key contributors to the mobile applications space within India; and the problems, those being faced by them as they attempt to navigate an emerging and ambiguous ecosystem. The results of our qualitative research give us insight into the characteristics of this new tribe. A majority of the developers do not own the products they innovate and instead assign ownership of their IP over to their clients. Innovating for the purpose of creating and retaining ownership is a key motivation and is reflected in the tendency of developers to move away from the services sector to develop their own products.[1]
As one developer puts it, “unless you're a 1000 man enterprise, there's no economic benefit in services; as competition has driven pricing so low, everyone's struggling to deliver $12-14 per hour.”
Every startup in mobile development, especially, is doing services to stay afloat and would like to move toward a product model.
Further, IAMAI conducted a survey[2] in 2013 and the report presents an analysis in four sections:
a) Who? The App Developer in India
b) What? The Preference of Users and Developers in India
c) Why? The Business of Apps in India
d) How? The Future of Apps in India
The Report states:
“The vast majority of app developers in India are male. In their survey of 454 developers, only 35 respondents were female reflecting the gender bias. On the demand side 80 percent of smartphone users in India are male reinforcing the male dominance. Geographically the respondents were all based in India except one developer of Indian origin residing in Malaysia. The well known and established IT cities in India are attractive for app developers because they provide with easy access to infrastructure, skill and a ready market for products. The survey shows the concentration of app developers in the cities of Bangalore, Mumbai, Delhi NCR, Hyderabad and Ahmedabad. A larger percentage of developers in such IT cities make apps on a full-time basis as compared to developers in other cities. The survey data also shows that Bangalore, Mumbai and NCR have the maximum number of companies (organized business operations) engaged in app development. Cities like Ahmedabad, Hyderabad and Chennai host many small teams of app developersas well as self-employed app professionals. In most of the other cities such as Bhubaneshwar, Cochin, Coimbatore, Gandhinagar and Kota, app development is done primarily on a part-time basis and is not the primary source of income. This could be the result of limited monetization options that make app development an unsustainable livelihood for many.
The popularity of international apps was evident in the survey data. The average download of ‘Indian’ apps was very low. Only 14 of the 454 developers has crossed the hundred thousand download mark, of which only 5 surpassed the one million milestone. These numbers do not pertain to a single app, but to the cumulative number of downloads across all the apps created by each developer, supporting the thesis of low visibility of apps developed domestically.
In their sample of 454 developers, entertainment apps including gaming and social networking are the dominant categories reflecting demand side preference. Utilities, health and education are the other important categories. The survey also below provided the number of apps developed under each category. The list does not include lifestyle and enterprise apps which are exceptions. One forceful result of their survey is the focus of app developers on foreign app demand in preference to producing locally-relevant content - as the latter is less profitable. Each respondent in their sample had developed an average of 38 apps. Of these 13 have developed 100 or more apps and these are the larger professional app companies. After excluding extreme values, the average number of apps developed by each respondent fell to 17.
Skewed revenue sharing models biased against content providers was one of the main reasons why Indian app developers focus on international app stores such as Apple App Store or Google PlayStore that offer a flat 70 percent of the total revenue to developers. This adversely affected development of India-specific apps and even popular apps such as Saavn and Zomato have expanded abroad because of this very reason.
Survey results indicated an Android dominated future for the app economy in India for two apparent reasons. One, Android devices are more affordable and two, the Android ecosystem is open allowing OEMs such as Samsung and HTC to manufacture mobile devices that use the Android OS. The drawback turns out to be the resulting fragmentation in screen sizes, resolution limits and hardware traits. Because of this, “developing apps that work across the whole range of Android devices can be extremely challenging and time-consuming.” Moreover, Indian app developers need to recognise the existence of an active market for used phones and thus the appeal of ‘backward compatibility’ i.e. an app that can work across old devices as well as new ones and also function across both old and new versions of operating systems will stand a better chance of success.
On the whole, app development was not considered to be a remunerative business opportunity. 17 percent of respondents who answered the question on choice of revenue model indicated that they did not have a specific revenue generation plan. While some developers are engaged in contractual development, there are few developers who self finance their project and do not actively market or promote their app. The business of app development in India seems to be at a stage in which it could be characterised as one based on a ‘hit and trial’ philosophy. Self financing is common in the industry. Only 7 and 13 developers approached banks or venture capitalists for financing. Funding an app developer was not an investor’s primary choice. Recognising the market failure and the utility of apps, the Department of Electronics and IT and Department of Telecommunication have both instituted funds to encourage mobile technology ventures
and app development in India.[3] One can argue on the efficacy of the use of limited public resources for app development, but not the fact that app development in India needs a boost. The industry is still very young and ‘unorganized’ and is largely dependent on own and informal sources for financing. The study presents presents the source of financing for app developers.”
Understanding of IP
There is a lack of understanding of IP amongst the developers. During the course of interviews, IP was often thought of as mere content or code. There was also confusion between the terms IP and IPR. The few developers who understood the nuances of IP better, voiced a need for the developer community to deepen their understanding of what parts of their work are IP. Samuel Mani, Founding Partner of Mani Chengappa & Mathur, stressed that developers should recognize the value within not just the product or software itself, but the background business processes. According to Mani, the execution of the idea is the true source of innovation; how one accesses the market, and maybe who the market is as well.[4]
The IAMAI report[5] had some observations on the impact of IP on the apps industry. According to the report, “since the industry thrived on innovation, protection of intellectual property was important to developers. The balance between protection and sharing of innovation was part of a larger and often tendentious debate on open source versus proprietary software development.[6] The survey did not attempt to deconstruct that debate; merely reported that 70 percent of respondents were of the view that intellectual property protection was a concern for app developers. However, not all had taken steps to protect intellectual property. The lack of seriousness could be associated with poor revenue potential from apps. Among those who had, some obtained copyrights/patents, while others worked with individual checks on in-app piracy using code morphing, copy protection, server–based checks, or both etc (The study provides data on different IP protection measures).”
Nature of their clients
Out-sourced 'mobile app services' is marginal as a business model here in India.[7]
Ownership of their product/service:
Often, the lack in understanding can be traced to the developers working in isolation from the legalities involved in assigning the product to the client. Majority of those interviewed developed mobile app products for clients, and in turn assigned ownership of their products to their clients. As previously mentioned, they commonly shared an interest in leaving the services sector to create products of their own, with some of them already having made the transition within their business model.[8]
Contractual clauses most important to mobile app developers: Delving deeper into the aspect of assigning ownership to clients, the most common practice is for developers to enter into a work-for-hire agreement with the client. Typically, a work-for-hire agreement mandates that if a worker is paid to carry out a particular project, whatever is created within the project belongs to the client.[9]
For startups where team players are small in number, it is likely that all will have access to any contract agreements entered into with clients. For larger corporate software developer firms, there may be a specialized department for legal-related matters. In such cases, the mobile app developers themselves would seldom lay eyes on the legalese of contracts, for the primary reason being that it doesn't concern them. Instead, the terms of agreement more familiar to them would be those that they obliged to upon working for their employer. The interviews revealed that the importance of contract agreements was actually underestimated in the country.[10]
Within a work-for-hire agreement, it is commonplace for developers to enter into restrictive agreements that obstruct the freedoms of what they can do with the code created for the client. Problematic areas proved to be those related to the time periods in which the developer was not allowed to take up future work for competing clients (i.e. the non-compete clause), or could not talk about their work for the client at all (the “quiet period”).[11]
Developers are unable to license their work to other interested clients when one client retains ownership. “Clients typically do not want a perpetual license, but complete ownership”, says a website developer. He further explains that, “this means they could make a derivative work or use it for another project. Depending on how bad we want the project, we'll work out some middle ground.” But it does not seem to be so easy for he and his SME to do so: “The thing about contracts is it’s all about a sort of differential bargaining power that the two parties have... you’ll have very little control about what happens once you’ve got paid.”[12]
To have any sort of bargaining power within a work-for-hire arrangement requires a lot of time for negotiating, and the space for communication to begin with. In many cases, contracts may not even be introduced into a work agreement, leaving a lot of intricacies to the unknown.
The problems are further compounded by contract illiteracy, more so in second tier cities.[13]
2. What is the nature of innovation emerging from the mobile app industry? What is the awareness of the "mobile applications developer and its enterprise on rules concerning code, content and design? How does re-use and sharing of code, content and design occur in the mobile application developer ecosystem ? What is the perceived impact of the Indian IPR regime on the aforementioned aspects? Finally, do the emerging trends in re-use and sharing of code run afoul of Indian IP law?
There is a marked shift towards using open source software amongst developers. According to a Gartner study, most software makers will have some open source applications or code in their portfolio by 2016. The study also reaches the conclusion that 99% of Forbes’ Global 2000 companies will be using some form of open source software.[14]
Awareness
The interviews revealed different personal understandings of the meaning of IP. The most common responses were the following[15]:
A : When questioned about IP to developers, they did not know what it meant, because it didn’t have anything to do with what they were doing.
B : Developers often did not know what part of their app was IP... there is was gap in understanding with respect to IP.
For the most part, it seems, IP was considered to refer to content or code across interviews, and was even confused at one point with IPR (IP Rights) within a response referring to an SME's trademark and pending application.
For those who appeared to be better versed in matters related to IP, they emphasised on the need for developers to be better acquainted with what parts of their work are IP. One interviewee stressed on the importance of developers to recognize the value of background business processes, apart from software and the product itself. [16]
In certain cases, it took $1 million in sales for a medium-sized software development enterprise to start paying attention to IP. The enterprise tried to obtain patent protection for their application, but the effort turned out to be futile.[17]
Protection of work (Speaks to awareness also)
When asked, those interviewed responded with a variance in answers. Some simply stated that their work is not protected, while a few mentioned that they acquired trademark or intend to apply for trademark protection. One interviewee had a patent pending in India and the US, as well. In many conversations, developers mentioned that their code for their apps is under open source licenses, and a couple others entailed sharing that the content is under creative commons licenses, “individual licenses,” or joint copyright. Additionally, within one interview, one mentioned the use of encryption tools as a technical means of protection for their work.[18]
“The concept of securing IP is relatively new within the Indian context... it becomes a question of priority between innovation and protection" — Aravind Krishnaswamy, Levitum.
Of the developers interviewed, many exhibited some sort of confusion or misunderstanding related to the protection of their works by means of intellectual property rights (IPR). Those interviewed seemed to either express an interest to acquire IPR in the future for their products in the forms of patent or trademark protection, or expressed their appreciation for openness source licensing—or both! Beneath these immediate responses, however, many repeated patterns, as well as contradictions, are revealed. Conversations that followed within these interviewed entailed the opportunity to hear from personal experiences and opinions on different areas within their practice intersecting IPR.[19]
Across interviews conducted, one particular observation entailed the tendency for developers to have worked in the past for corporate employers that have dealt with cases of infringement or have acquired IP protection. Almost half of those interviewed shared the fact that they worked for a corporate employer and became better familiar with different notions of intellectual property through that experience. It may not be too far-fetched to suggest, then, that for the developer the idea of acquiring IPR protection is one that may be reinforced from previous employers or other successful development companies with IPR of their own.[20]
Impact of law & reasons for IPR Protection
One would assume that if a startup was bootstrapped with minimal cash flow, then it would place a low priority on getting IP protection for its products. Aravind Krishnaswamy of startup, Levitum, also stated that “the concept of securing IP was relatively new within the Indian context.” [21]
Yet, many developers who were interviewed did express an interest in IPR. The main concerns developers believed IP protection would address, were proving ownership over their work or preventing problems in the future. One developer's commented on how the mobile app market is a “new and potentially volatile area for software development.” For this reason, it was imperative that he and his team attempted to avoid trouble in the future, and ensure that they going about mobile app development the right and moral way.[22]
Within another interview, developer, John Paul of mobile app SME, Plackal, explained his motives for seeking to acquire patent protection, the application for which back then was pending in India and the US: "For us, applying for a patent is primarily defensive. And if it does get infringed upon, it would give us a good opportunity to generate revenue from it." For the company's trademark, they sought to be able to enforce their ownership over their product's brand: “As a precautionary, we've trademarked the app so that should there be a situation where the app is pirated, we can claim ownership for that app.”[23]
Do the emerging trends run afoul of Indian law?
Yes. This was evident from the legal practices of mobile app developers and the resulting cases of infringement.
Some instances of infringement (limited to Mobile app content (i.e. logos, pictures, etc.)) are[24]:
• Pirated apps in app stores
• “Dummy apps” or imitations of another's app
• Breaching app stores user agreement
• Violation of License agreements of code created by another
• Violation of Open source licenses
• Breaching of terms of agreement for by commissioning clients
• Breaching of terms of agreement for by those hired
Some of the developers indicated that they weren't a fish big enough to be pursued for infringement. “The big companies do not go after small developers; it depends on how much money they're making.” said a developer. He added,“Patent lawsuits can cost something like millions of dollars, so unless they're going to get more back, they wouldn't go through the trouble of doing so... but that is true even in the US.”
Some added that others who may have been apparently copying you, may have been working on the same content independently. Corporate players are in non-compliance knowingly than not, whereas more SMEs infringe upon others without being aware that they are. Just as well, the degree to which infringement takes place may differ between the two types of industry players: “At the corporate level, where they know they are not in compliance, the degree of non-compliance might be very small or specific, but it still exists.” On the other hand, for startup developers, a substantial amount of their code may not comply with the licenses and agreements they are obliged to—something that could pose problems for them later down the road if left unfixed. [25]
3. The apps marketplace is extremely important since they are the gatekeepers enabling access to apps. What is the nature of the apps marketplace? What are the limitations associated with it ? How do the existing regulatory models intersect with this relatively new marketplace? What is the enforcement carried out by these app stores in terms of IP?
“The app platform is a gatekeeper which provides the consumer and developer a virtual space to buy and sell products (mobile apps). What is the nature of the app platform? What are the limitations associated with it?
An app dealing in pirated content or infringing intellectual property faces the risk of getting barred by the app platform. What is the enforcement carried out by app platforms to protect intellectual property?”
Firstly, what is an app platform?
Iansteti and Levien[26] state that at the core of each innovation network is a focal organization known as platform owner (or keystone) that provides the platform to facilitate contribution by other members in the network.
Hagiu[27] defines a platform as a product, service or technology that provides a foundation for other parties to develop complementary products.
Specifically, I Kouris[28] defines an app platform as a special kind of electronic market which enable software developers to distribute their software applications(apps) among users of mobile devices like smartphones or tablets. An app platform owner dictates the entire infrastructure(like user interface, server space, etc.) and determines the rules for the interaction between the developers and users. They usually provide information about apps and developers and serve as a trusted third party by controlling app quality. Fransman M[29] characterised the app platform as an 'innovation ecosystem incorporating app developers effectively.'
Innovation can happen within the enterprise, or can take a more open route and benefit from external innovation. In order to gain the benefit of external innovation, platform owners must open their platforms up beyond their internal base of developers and provide resources to third party developers.[30]
What is the platform concept in software?
Broadly, Noori[31], discusses the issues about the platform concept in software and attempts to address the subject of platform strategy. Tsai, Phal & Robert[32] further the discussion by stating principles for an effective platform strategy.
In mobile ecosystems building a developer community is one of the niches to attract the developers to join the ecosystem. However, health can mean differing things for different ecosystem members. In order to stimulate innovation[33] the keystone company is often forced to relinquish much of their control over the platform to the development community. This involves a careful balancing act in relinquishing enough control to create a healthy environment for developers, and not stifling innovation while retaining a necessary and desired degree of control.[34]
Baskin[35] examines the problems concerning software patent under the mobile applications platform environment. The scope of the analysis is limited to two mobile applications platforms: Apple's iOS and Google's Android. The analysis throws light on the problems of innovation in software systems like iOS and Android. The note also proposes several changes to both antitrust and patent laws that will make it more difficult for established market players to prevent new competitors from entering high tech markets, thereby promoting greater openness and innovation. The part on software patents discusses the effects of enforcement of patent rights on open and closed systems. The note observes that the US Federal Circuit's decisions (Fonar Corp. v. Gen. Elec. Co., io7 F.3d 1543, 1549 (Fed. Cir. 1997)) have severely curtailed both the enablement and best mode requirements for successful software patents., thereby limiting the disclosure and preventing many of the invention's useful elements from reaching the public domain. Patentability issues have affected open systems such as Android more than Apple, owing to a greater dependency on third parties to run android systems, leading to more patent infringement issues. It recommends, that, intellectual property law should promote open systems above patent protection in high tech fields, allow reverse engineering of software and introduce an 'independent invention' defence in the law for innovators.
A certain paper addresses rejection of apps in the AppStore on three grounds: rejection on content grounds (including some competition-driven restrictions), rejection on development grounds, and the regulation of transactions.
Apple's and Google's foray into building a mobile development platform
Coming from the music and personal computer industry, Apple disrupted the mobile industry by making its mobile development platform available to third party developers and eliminating the barriers between those developers and customers. The main goal of Apple in the mobile world is to increase the cross-sales of its high-margin products by providing a continuous experience roaming (iPhone, iPad, Mac, and Apple TV) using complements such as mobile applications, content, services, and accessories.[36] Google, on the other hand, is an online advertising company which provides an open source mobile operating system, in the shape of Android, on which mobile handset manufacturers can develop smartphones without paying software licensing fees. By commoditizing mobile device production under its unique governance structure and building a large developer community, Google secured a means of reducing the barriers to new users accessing their advertising through smartphones. Microsoft through its Windows Phone is the most recent addition to the leading mobile platform providers. Its motivations lie in trying to protect its core business of software licensing which has been disrupted by falling PC sales linked to the emergence of mobile technology and free cloud technology services provided by companies such as Google which have impacted respectively on its licensing fees for Windows OS and Microsoft Office[37].
Luis H Hestres[38] analyzes Apple’s guidelines and approval process on the App Store, discusses content-based rejections of apps, and outlines the consequences of this process for developers’ and consumers’ freedom of expression. It outlines a set of principles to ensure “app-neutrality” whilie ensuring device quality and safety. The article illustrates challenges faced by app developers working on the iOS platform. Criticisms have come forth about Apple's arbitrary and opaque review process. Apple has a rejection rate of 30% of the 26,000 apps submitted to the app store each week[39]. Van Grove[40] comments that the ambiguity, opaqueness, and susceptibility to outside pressures that seems to characterize Apple’s approval process do a disservice to a democratic online culture. With more than 400 million iOS devices sold worldwide since 2007[41], Apple’s devices and app store have become important online intermediaries for Internet users. The article proposes a few basic guidelines, anchored on widely accepted international laws and treaties, such as the Universal Declaration of Human Rights and the International Covenant on Civil and Political Rights.
Statistics
A Report[42] presents us with some important insights into the growth of Google Play. Following are the highlights of the report: There are now well over 1 million apps available on Google Play App downloads and revenue from Google Play increased dramatically over the past year; Markets such as Brazil, Russia, Mexico, Turkey and Indonesia are driving growth in app downloads from Google Play; Google Play is experiencing rapid expansion of monetization in established markets such as Japan, the United States and South Korea; Games played a major role in the acceleration of Google Play revenue growth, but almost all app categories experienced expansion and accounted for almost 90% of revenue in Q1 2014; The freemium business model advanced its domination of Google Play app revenue, and represents a growing proportion of downloads; Asian markets lead the way in generating freemium revenue. Another report8 reiterates the explosion of gaming apps.
4. How does Indian copyright law and patent law apply to the mobile applications development ecosystem, in respect of the various business models operating in the industry?
4.1. The patent regime is grounded on a laboratory model of innovation. What does the niche mobile applications development industry (working on a micro-creativity model of innovation) require differently from the patent regime to foster growth?
4.2. Similarly, copyright law has a distinct design for digital objects. Examine the design and its suitability to regulate a mobile application.
A. The interviews reveal a dichotomy existing in the mobile app developer space. While some developers argued for strong IPR protections, several of app developers opposed strict IPR protection (patents, especially) and advocated use of open source software.[43]
Open source for future protection (Applicable as literature to Research question 2)
Sometimes developers license for community values primarily, however, the assumption is that dominant reason is to retain the ability to use their own work across clients. A designer from a services enterprise gave a different reason for doing so: to guarantee their ability to use their work again. “Since we use a bunch of templates and things like that, those we license using a non-exclusive license, because we reuse those elements on different bits of code in different projects,” he explains, “so there are bits of it which is used over multiple projects and there are stuff that is built exclusively for the client.”[44]
Here one can gather some insight, that perhaps developers do not necessarily license for community values primarily, but for the ability to use their own work across clients. That being said, we begin to wonder what the possibility that open source code may serve as a loophole for work-for-hire contracts, which require the developer to assign all written intellectual property to whoever is commissioning the project. If the code happened to “already be available by open source,” a developer may still be honouring any restrictive agreements with clients, and ensuring their ability to use their code in this future again.[45]
As a developer suggests, that startups should first and foremost protect themselves by making wiser choices related to code in order to prevent being litigated against by others—such as using an open source equivalent to a piece of code that one does not have the rights to, or instead putting the extra time in to develop it from scratch.[46]
Of those who expressed an interest in the open source movement, not all had said that their products were to be open licensed as well. One developer explicitly stated: “I like the idea of open source, and building upon others' work...but our app is not open source, it's proprietary.” It may be a given, then, that all or most developers within our interview sample rely on open source code within their practice, but not all may contribute their resulting product's source code back.[47]
Vivek Durai, from Humble Paper said that despite the fact that “open source has really taken route... on the smaller levels, people will come to a point when philosophies begin to change the moment you start seeing commercial.”[48]
B. A certain paper[49] examines from various angles the complex relationship between intellectual-property rights and technological innovation. Following are the conclusions:
1) Intellectual property rights are most likely to foster innovation when the following conditions converge in a particular industry: (a) high research-and-development costs; (b) a high degree of uncertainty concerning whether specific lines of research will prove fruitful; (c) the content of technological advances can be ascertained easily by competitors through “reverse engineering”; and (d) technological advances can be mimicked by competitors rapidly and inexpensively.
2) The likelihood that intellectual-property rights will impede more than stimulate innovation increases as more and more of the following factors obtain in a particular field: (a) trade-secret protection or lead-time advantages reduce the ability of competitors to take advantage of technological advances; (b) innovation in the field tends to be highly cumulative; (c) researchers in the field are motivated primarily by non-monetary incentives; (d) the field is characterized by strong network externalities. The last three of these circumstances were all present during the development of the technical infrastructure of the Internet; it is thus not surprising that that development proceeded rapidly and effectively with little reliance upon intellectual-property systems.
3) The following techniques may be employed to mitigate the economic side-effects of intellectual-property systems: (a) compulsory licenses; (b) facilitation of price discrimination; (c) strict enforcement of the “utility” requirement; (d) encouragement of appropriate cross-licensing agreements (provided that cartel behavior can be simultaneously discouraged); (e) narrow interpretations of “similarity”; (f) strict enforcement of “enablement” and “best-mode” requirements; and (g) the affirmative defenses of patent and copyright misuse.
4) In contexts in which reliance upon these mitigating devices is not feasible, the following alternative ways of solving the public-goods problem may be superior to intellectual-property rights as ways of stimulating innovation:government research; government funding for private research; or post-hoc government rewards for private technological advances.
C. In a paper[50], the authors study the determinants of patent quality and volume of patent applications when inventors care about perceived patent quality. They analyze the effects of various policy reforms, specifically, a proposal to establish a two‐tiered patent system. In the two‐tiered system, applicants can choose between a regular patent and a more costly, possibly more thoroughly examined, ‘gold‐plate’ patent. Introducing a second patent‐tier can reduce patent applications, reduce the incidence of bad patents, and sometimes increase social welfare. The gold‐plate tier attracts inventors with high ex‐ante probability of validity, but not necessarily applicants with innovations of high economic value.
D. Copyrights related to apps are still being hashed out in the courts. Oracle, for example, sued Google[51] for copyright infringement regarding the structure of Java APIs in its Android operating system[52], and the case was decided by the U.S. Supreme Court.
E. Policy Levers in Patent Law[53]
The paper argues that some industries should be the subject of patent tailoring – which can make them illustrative of certain policy levers. Use of obviousness and disclosure doctrines to modulate the scope and frequency of patents, as might be necessary where anti-commons to patent thicket theories are applicable.
Nature of software vis-a-vis biological/chemical inventions
Software inventions tend to have a quick, cheap, and fairly straightforward post- invention development cycle. Most of the work in software development occurs in the initial coding, not in development or production. The lead time to market in the software industry tends to be short. Because innovation is less uncertain in software than in industries like biotechnology, Merges’ economic framework suggests that the non-obviousness bar should be rather high.
Implementing a rational software policy obviously requires some significant changes to existing case law. A number of policy levers might be brought to bear on this problem. First, obviousness doctrine needs to be reformed, preferably by way of a more informed application of the level of skill in the art or alternatively by application of new secondary considerations of non-obviousness.
Poor handling of software patents by the Federal Circuit
The paper argued that broad software patents were indeed what the existing Federal Circuit jurisprudence will likely produce. By relaxing the enablement requirement and permitting software inventions defined in broad terms, supported by very little in the way of detailed disclosure, the Federal Circuit has encouraged software patents to be drafted broadly and to be applied to allegedly infringing devices that are far removed from the original patented invention.
By implication, the Federal Circuit’s standard also seems to suggest that many narrower software patents on low- level incremental improvements will be invalid for obviousness in view of earlier, more general disclosures. They may also be invalidated under the on- sale bar, because the Supreme Court’s view that a software invention is “ready for patenting” when it is the subject of a commercial order and when the inventor has described its broad functions, even if it is not clear how the code will be written or that it will work for its intended purpose, means that any patentee who waits until the code is written to file a patent application risks being time-barred for not filing earlier. Unfortunately, the Federal Circuit’s current standard seems to be precisely backwards. Software is an industry characterized by at least to a limited extent by competition theory and to a greater extent by cumulative innovation. Cumulative innovation theory suggests that patent protection for incremental software inventions should be relatively easy to acquire in order to reward incremental improvements, implying a somewhat lower obviousness threshold. It also suggests that the resulting patents should be narrow and, in particular, that they should not generally extend across several product generations for fear of stifling subsequent incremental improvements. This suggests that software patents should be limited in scope.
Second, a higher disclosure requirement and restrictions on the doctrine of equivalents will help reduce patent scope. Additionally, the authors think software patents are the ideal candidate for a new policy lever: reverse engineering. Many commentators have explained the importance of permitting competitors to reverse engineer a product in order to see how it works and to figure out ways to design around it. In the case of copyright, courts have adapted the doctrine of fair use, together sometimes with copyright misuse, to allow competitors to engage in reverse engineering of computer software. Patent law includes no express provision allowing reverse engineering, nor is there any judicially developed exception akin to copyright’s fair use doctrine that might permit it. Indeed, patent law generally lacks provisions akin to fair use or other exceptions that might readily be pressed into the service of reverse engineering, although commentators have suggested that patent law may need such exceptions for precisely this reason.
This does not mean that reverse engineering a patented product is necessarily illegal patent law. Some inventions, such as the paper clip, are readily apparent once embodied in a product. Improvers do not need to reverse engineer the paper clip and figure out how it works in order to improve it; they just need to look at it. Additionally, in many cases, the patentee has done all the work necessary for reverse engineering patented inventions by virtue of disclosing how to make and use the claimed invention in the patent specification. In theory, an express provision authorizing reverse engineering would be superfluous if the enabling disclosures required to secure a patent were sufficiently strong – someone who wanted to learn how a patented device worked would only need to read the patent specification. Patentable inventions in software, however, generally do not have these characteristics. Software devices typically cannot be readily understood by casual inspection, and particularly not without access to human-readable source code or other documentation. Examination of the patent itself is unlikely to yield information equivalent to a reverse engineered inspection because the Federal Circuit does not require would-be patentees of software inventions to disclose the implementing source code or, for that matter, very much at all about their inventions. Accordingly, software patents present unique obstacles to consummation of the patent law’s traditional rights-for-disclosure bargain with the public. The specific reverse engineering techniques commonly used for software, in turn, may raise some infringement problems that are unique to software. The definition of infringement in the patent statute is extremely broad, encompassing anyone who “makes, uses, offers to sell, ... sells..., or imports” a patented product. Reverse engineering a patented computer program by decompiling it likely fits within this broad category of prohibited conduct, at least where the program itself is claimed as an apparatus. Reverse engineering clearly constitutes a “use” of the patented software, though owners of a particular copy of the program surely have the right to use it. More significantly, decompilation may also constitute “making” the patented program by generating a temporary yet functional copy of it in RAM memory and, in certain instances, a longer-term (though still “intermediate”) copy in more permanent memory. Those copies probably constitute patent infringement unless protected by some defense. The result of all of this is that the nominally neutral patent law rule – no defense for reverse engineering – affects software more than other industries.
The need for a reverse engineering exception in patent law militates in favor of adapting the existing doctrines of exhaustion or experimental use to that end. Patent misuse might also be adapted, as it has been in the copyright arena, to prevent patent holders from deterring or prohibiting reverse engineering related to their inventions. The exception might even be created out of whole cloth by reinterpreting the infringement provisions of section 271(a). The resulting patent doctrine would constitute a macro policy lever. As Cohen and Lemley observe, in most industries there is either no need to reverse engineer an invention or reverse engineering can be done without infringing the patent.
The paper concludes by stating, “Only in software is there a need for a particular doctrine to protect the right to reverse engineer —and therefore the ability of improvers to innovate. Thus, a judicially created reverse engineering defense would make sense across the board in software cases but not in other patent cases.”
[1]Samantha Cassar, "App Developers Series: Products-Services Dichotomy & IP (Part I)”, last accessed July 21, 2015
[2]IAMAI, “An inquiry into the impact of India's App economy”, 2015
[3]DoT has set up a 1000 crore app development centre called Application Development Infrastructure and 700 crores under the National E-Governance Plan have been allocated for mobile technology ventures
[4]Supra note 1
[5]Supra note 2
[6]Hippel, Eric von, and Georg von Krogh. "Open source software and the “private-collective” innovation model: Issues for organization science." Organization science 14.2 (2003): 209-223.
[7]Supra note 1
[8]Ibid
[9] Samantha Cassar, “Mobile App Developer Series: Terms of Agreement – Part IV”, last accessed July 21
[10]Ibid
[11]Ibid
[12]Ibid
[13]Ibid
[14]Gartner Data
[15]Supra note 1
[16]Ibid
[17]Samantha Cassar, “Interviews with App Developers: [dis]regard towards IPR vs. Patent Hype – Part II”, last accesed July 21, 2015
[18]Ibid
[19]Ibid
[20]Ibid
[21]Ibid
[22]Ibid
[23]Ibid
[24]Samantha Cassar, “Interviews with App Developers: Name of the Game (Part IV)”, last accessed July 21, 2015
[25]Ibid
[26]"Strategy as Ecology," Harvard Business Review, Vol. 82, No. 3, March 2004.
[27] Evans, D. S., A. Hagiu and R. Schmalensee, 2006, Invisible Engines: How Software Platforms
Drive Innovation and Transform Industries, Cambridge, MA: The MIT Press.
[28]Kouris, Iana and Kleer, Rob, "BUSINESS MODELS IN TWO-SIDED MARKETS: AN ASSESSMENT OF STRATEGIES FOR APP PLATFORMS" (2012). 2012 International Conference on Mobile Business. Paper 22.
http://aisel.aisnet.org/icmb2012/22
[29]Fransman, M. (2014) Models of Innovation in Global ICT Firms: The Emerging Global Innovation Ecosystems. JRC Scientific and Policy Reports –EUR 26774 EN. Seville: JRC-IPTS
[30] Deniz and Kehoe, Factors that attract and retain third party developers in mobile ecosystems, June 2013
[31]Nadea Saad Noori (2009) Managing External Innovation: The case of platform extension, available at http://www3.carleton.ca/tim/theses/2009/Noori2009.pdf
[32]Tsai, Phal & Robert, Industry Platform Construction and Development in a changing environment: Evidence from the ICT Industry, available at http://druid8.sit.aau.dk/acc_papers/6s5aqckmne7ggybu0vfxryrynuog.pdf
[33] Supra note 9
[34] Ibid.
[35]John Baskin, Competitive Regulation of Mobile Software Systems: Promoting Innovation Through Reform of Antitrust and Patent Laws (2013)
[36] Constantinou, 2012b
[37]Ibid.
[38]Luis H Hestres (2013) App Neutrality: Apple’s App Store and Freedom of Expression Online , American University , International Journal of Communication 7 (2013), 1265–1280
[39]Supra note 9
[40]Ibid.
[41] Supra note 9
[42]App Annie Data
[43]Supra note 1
[44]Samantha Cassar, “Interviews with App Developers: Open Source, Community, and Contradictions – Part III”, last accessed July 21
[45]Ibid
[46]Ibid
[47]Ibid
[48]Ibid
[49] William Fisher, INTELLECTUAL PROPERTY AND INNOVATION: THEORETICAL, EMPIRICAL, AND HISTORICAL PERSPECTIVES
[50]Patent Quality and a Two‐Tiered Patent System (Vidya Atal and Talia Brar, 2014)
[51]http://copyrightalliance.org/2014/05/federal_circuit_releases_decision_oracle_v_google
[52]http://copyrightalliance.org/2014/05/federal_circuit_releases_decision_oracle_v_google#.VYf0i9Z5MxB