AuthorMaracke, Catharina

ABSRACT 53 I. INTRODUCTION 53 II. THE SOFTWARE PATENT DEBATE 56 A. Theoretical Background 58 B. Software Patents in the United States 60 C. Software Patents in Europe and Germany 62 D. Summary 64 III. OPEN SOURCE SOFTWARE AND PATENT LITIGATION 64 A. Patent Thickets and the Risk of (Unintentional) Patent Infringement 66 B. Case Law 67 a. Jacobsen v. Katzer 68 b. Twin Peaks Software Inc. v. Red Hat Inc 69 c. Red Hat Inc. v. Firestar Software Inc. and DataTern Inc 69 d. Microsoft Corp. v. TomTom Inc 70 e. Lodsys LLC 71 f. XimpleWare v. Versata 72 g. OLG Dusseldorf--"Primare Verschlusselungslogik" 72 h. Summary 73 C. Risk Assessment 75 a. Patent Infringement 75 b. Motivations Behind Patent Infringement Claims 81 c. Other Legal Risks for Individual Developers 85 D. Patent Strategies 87 a. Patent Defense Strategies 87 b. Patent Grants in Open Source Software Licenses 88 IV. CONCLUSION AND THOUGHTS 90 In the context of the ongoing software patent debate, commentators have stressed the risk for Open Source software development of being targeted with patent infringement suits. While one widely-held view suggests that the Open Source development model and especially individual developers are the most vulnerable participants in the narrative of how patents threaten the Open Source ecosystem, very little case law can be found to support this opinion. The goal of this Article to provide an overview of the different arguments and concerns surrounding patent risks for Open Source software development and to shed some light on the current debate by analyzing relevant risks.


    More than 30 years after the launch of the Free Software Foundation and 25 years after the start of Linux, Open Source software (1) and related licensing models are not only relevant for computer nerds or activists, they are business for everyone: Companies worldwide are looking to hire Linux professionals, making the Linux job market more attractive through increased salaries and flexible work hours. (2) Even beyond Linux, growing market shares of Android and other technologies clearly demonstrate that the Open Source development model has become mainstream for today's IT industry. A 2015 survey shows that 78% of all companies run part or all of their operations on Open Source software. (3) Today, successful companies have taken one step further. They don't just use Open Source software in their commercial products, they actively engage in their industry's Open Source projects; a recent McKinsey & Company report found that the biggest differentiator for top-quartile companies in an industry vertical was "open-source adoption" whereby "adoption" meant that they shifted from the use of Open Source software in their commercial products to becoming Open Source contributors. (4)

    At the same time, the business of software patents has received a great deal of attention in various jurisdictions around the world, and many scholars and commentators have entered the ideological battle between Open Source software development and the software patent business. (5) While a lot of time and energy has been devoted to the legal question of whether and to what extent software is or should be patentable subject matter, much less work has been done to analyze the actual patent risks for the Open Source development model and to discuss and evaluate possible defense strategies. As so often in heated debates, the current discussion about "software patentability" has become strongly polarized and has moved from a legal question to a political one. However, in order to understand the different arguments and various positions it seems sensible to reflect on the actual and practical effects of software patents on Open Source software development.

    The goal of this Article is to provide an overview of the current battle between Open Source development and the software patent business and to analyze some of the concerns expressed by the Open Source community. One specific point to be considered is the alleged patent risks for independent Open Source projects and for individual developers. (6) Individual developers are often quoted as being the most vulnerable participants in the narrative of how patents threaten the Open Source community; without the financial backing that most companies have, individual developers are willing to contribute talent, time, and energy to software innovation--and society wins. Threatened with patent suits, the developer is at risk of insolvency and/or being forced to shut down any activities and contributions--and society loses. (7) But does this narrative correspond to reality? What are the actual patent risks for individual developers?

    The following paragraphs (II.) will explore the current debate around software patents and infringement and (III.) study potential patent risks as well as patent defense strategies for individual developers in the context of this debate.

    Since innovation and especially software development has become increasingly global, questions of patentability, patent licensing, and patent enforcement easily extend beyond national boundaries. Consequently, this Article will not only look into the current debate taking place in the United States but also look into the European system. Within the European system, Germany has turned out to be the preferred battle ground for patent litigation, (8) so the analysis will focus on Germany as one important jurisdiction in the context of the software patent debate. (9) In addition, Germany has been a forerunner in enforcement of Open Source software licenses, (10) which makes a comparative analysis between the United States and Germany even more relevant.


    The United States, the European Union, and the international community consider two methods of legal protection for software: Copyright and patents. While copyright protection is commonly accepted (11) and harmonized for all countries that have signed the Berne Convention, the question of software patents is still controversial.

    Part of the problem may result from the fact that software cannot be seen as a monolithic work. (12) To date, there is no official definition of the term "software." Instead, computer scientists and software engineers have drafted different quasi-official definitions, one of which can be found at the Institute of Electrical and Electronics Engineers (IEEE). According to the IEEE, software includes "computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system." (13) Similarly, software has been defined as "a set of statements or instructions which is capable of causing a machine, having information processing capabilities (a computer) to perform a set of functions to achieve a result." (14) These definitions indicate that software is usually expressed in a written form (e.g. the set of instructions, initially expressed as source code), which can be subject to copyright protection as a literary work. (15) However, they also reveal that software is not only source code alone. In order to operate within a computer and achieve certain results, software has to be translated into object code by means of compilation. (16) Even if the object code can be seen as a direct result of the source code and should therefore be linked to it, and arguably be subject to copyright protection, software is not merely a literary expression; the lines of code have a function that is independent from the expression and/or construction of the lines of the code. (17) Consequently, source code written for one program, while completely different from that of another program, may have the same functions and achieve similar results. (18)

    Against this background, many commentators have argued that copyright protection hardly meets the concern associated with exploitation of the functional idea behind the software. (19) Copyright, the common argument, may only protect against mere copying of the literal expression represented in the source code but may not protect against the exploitation of the functional idea represented in the software. (20) In order to address the functional idea, patent law has come into play (21) and opened the door for a heated and emotional debate as to whether there is a need for patentability of software.

    1. Theoretical Background

      Do patents promote innovation? The most conventional theory of patent law, often referred to as the "utilitarian" or "economic incentives" theory, argues that patent law's only purpose is to spur innovative activities and promote technical progress by rewarding inventors with an exclusive market position through exclusive rights for a limited number of years, (22) In other words, a potential inventor will not develop an invention without the promise of a patent. (23) While exclusive rights impose significant costs on society, according to this theory, it is the necessary tradeoff to incentivize inventors to create and make their inventions available to the public. (24)

      Many have challenged this theory, especially in the context of software innovation. (25) Software innovation, so the critics argue, is different from innovation in the biotechnology or pharmaceutical industry, because the software industry evolves through frequent but incremental innovation. Change in software innovation is so rapid that "entire product life cycles sometimes pass before patents can be issued." (26) In addition, critics of software patents argue that "software innovation comes from programmers solving problems while developing software, not from projects whose specific purpose is to make inventions and obtain patents." (27) Usually, the software development process is referred to as a "research" process, whereby programmers "throw away more inventions each week than other people develop in a year." (28) This is especially true with regards to the Open Source development model. In fact, the very...

To continue reading

Request your trial

VLEX uses login cookies to provide you with a better browsing experience. If you click on 'Accept' or continue browsing this site we consider that you accept our cookie policy. ACCEPT