Ilkka Rahnasto: Open Source Licensing – Challenges and Opportunities
Open Source Licensing – Challenges and Opportunities for Intellectual Property Rights
By Ilkka Rahnasto1
1.
Mikko Välimäki has written an interesting thesis on ” The Rise of Open Source Licensing – A Challenge to the Use of Intellectual Property in the Software Industry.2 This paper discusses three themes of the thesis:
(a) (b) (c)
Economics of Software Innovation and Patents Open Source License terms (such as GPL) as Governance Model, and Open Source as Socio-Economic phenomena.
2.
“ The hallmark of a great company is an ability to realize the game has changed and to
3 adapt.” Mikko Välimäki argues that Open Source is causing the game to change, and he
attributes the change to technical, business and social policy issues. Whether “ Open Source highlights the negative effects from both the continuous expansion of intellectual
4 property right legislation and actual use of those rights” is a matter of viewpoint, but it is
certainly a fact that Open Source is one of the areas in which intellectual property rights have been put into the middle of global discussion.
3.
Economic arguments are an integrated part of the discussion involving Open Source and patents. The arguments may be formal (patents form important incentives for innovation vs. patents are legal monopolies), based on property theory (innovation is managed effectively as a private property vs. software innovation needs to be commons property to enable further development), or depending on the source of innovation (patents are not effective in the hands of individual software developers vs. it is difficult to build large scale business without patents). Välimäki takes a critical view on the need of patents in Open Source environment by highlighting the exclusionary nature of patents and the risk of anticommons: If there are too many exclusive rights, and it is perceived to be difficult to clear them with acceptable costs, the development of software industry may slow down.5
1
The ideas and opinions of this paper are solely those of the author’ expressed in connection with public s policy discussion, and do not necessarily reflect the view of Nokia Corporation. 2 Turre Publishing 2005. 3 Prof. David B. Yoffie, Harvard Business School. 4 Välimäki p. 221. 5 Välimäki p. 109.
Ilkka Rahnasto: Open Source Licensing – Challenges and Opportunities 4. The key argument favouring copyright over patents in Open Source environment simply states that copyright is enough to protect innovation, and there is no evidence that patents would have the same effect. There is also an alternative view. One may say that patents and copyrights have a different role: Copyright protects expression, and in software context expression means that software expresses a desired functionality in a chosen programming language. In other words, innovation in software world means new ways to express functionality in a program. The functionality may be one that has already been expressed by others in software form, or it may be an expression of a functionality that has never been expressed in a software form before. The controversy around software patents relates to the fact that an increasing number of patented functionalities are expressed in a software form. The traditional requirement of a patent being granted for a technical solution to a technical problem does not address the fact whether the patented feature is implemented in software or hardware form (or combinations thereof). The European patent laws just say that no patent may be granted to the expression method itself, i.e. one of the multiple ways to express the functionality in software form. This has been the traditional interpretation of “ such”limitation in EPC Art. 52. as
5.
A lot of controversy around patentability relates to the development in which an increasing number of technical functionalities are expressed in software form. That means that a software product implementing a technical feature may infringe patent(s). It is the decision to implement a technical functionality that may infringe a patent – not the expression of the functionality in the chosen programming language. How should one approach the issue from regulatory point of view? It is easy to share the view in Välimäki’ s thesis that the programmer expressing the technical functionality in his program does not benefit from the patentability. This is assuming that he implements a functionality developed by others. From his point of view, any cost of having access to new functionalities is likely to reduce output in particular if he is coding software himself, and not doing it for a commercial software developer.
6.
The analysis becomes more complicated if one takes a view of a technology inventor developing new functionalities. The inventor is not typically the same person or company that implements the invention in the software form. If one assumes, that it costs 5 MUSD to develop a new advanced technology to package music files resulting into a solution that reduces the size of a typical file by 50%. As soon as the new technology is made available, a number of software developers may consider it attractive to implement it in their software products. Should the inventor of a new technology be granted a patent (as a matter of principle)? Can he collect royalties from software developers that implement the invention by using their unique expression in programming language, perhaps even
Ilkka Rahnasto: Open Source Licensing – Challenges and Opportunities creating new innovative combinations with other functionalities? Isn’ this a matter of t conflicting interests between the inventor of the new algorithm, and a software developer? Would it make sense to invest a significant amount of money into developing new technologies if they may be implemented by software developers without compensation?
7.
The issue of patents in software context may also be seen as a challenge for the use of patents. Isn’ it really a matter of the price for the software developer, and not the principle t existence of a patent that is of economic concern? One way to look into patents is to see them as a threat primarily because the price and availability of a license is not known, and therefore it is difficult to estimate the cost of IPR component.
8.
One of the most interesting parts of Mikko Välimäki’ thesis relates to his analysis of s different Open Source licensing terms, and the reciprocity requirements they contain. Välimäki categorizes Open Source license terms to those requiring
(a)
standard reciprocity (meaning that distribution of the code is allowed only if the distributor keeps the distribution terms of the original code untouched, such as Mozilla),
(b)
strong reciprocity, (meaning that in addition to the original code, even adaptations and derivative works are allowed only if the distributor keeps distribution terms untouched, such as GNU GPL), and to those that are
(c)
permissive (meaning that the terms allow free distribution, copying and modifications, such as Apache).
9.
The uncertainty in respect of application and interpretation of license terms relate primary to GPL terms that require strong reciprocity.
According to GPL Section 2 (b), “ you must cause any work you distribute… that… is derived from the Program to be licensed at no charge… under the terms of this License” .
Välimäki asks the important question of the extent of such requirement. If interpreted broadly the term “ derived” may cause the obligation to distribute at no charge any is software into which the Open Source component is integrated. This is sometimes called “ viral”effect of GPL terms. In his thesis, Välimäki points out the diversity of the opinions, and the potential challenges the unsettled interpretation of this concept may cause to the success of GPL-based programs in corporate environment. He also points out the differences between component-based view (emphasizing the issues whether the original code has been mixed with new code to derive a combined work), and communication-
Ilkka Rahnasto: Open Source Licensing – Challenges and Opportunities based view (emphasizing the functional relationship between original code and the new code). The practical difference is that communication-based view (as promoted by Free Software Foundation) extends the concept of derivation (and the resulting coverage of GPL) to program code that is functionally linked to the original code, resulting to a significantly broader scope for reciprocity requirements.
10. The communication-based view is not based on copyright law. Copyright law protects only expression, i.e. the form of code, and not any functional aspect of a program. So an argument that copyright of the original work would cover also functionally linked derivatives is not generally sustainable. Rather the enforceability (if any) of any requirements in respect of functionality must be based on contract law, and on the assumption that there is a valid contract, and that there are no legal rules that would limit the enforceability of such covenant. In this respect, the argumentation may serve further study.
11. There are two doctrines that potentially limit the enforceability of terms that (allegedly) extend the concept of derivation to functionally linked elements: Competition law doctrines and patent law doctrines. Under the competition law doctrines, a requirement by a licensor to waive the enforcement of one’ Intellectual Property Rights (“ s IPRs” may be considered ) as a restriction of competition. Without going into the details of the doctrines, a requirement in the license terms that go beyond specific subject matter of copyright protection may be held as copyright misuse (U.S.) and fall under the general analyses of Article 81 and 82 in Europe (without benefiting from immunity granted to acts related to “ specific subject matter” In particular, if Open Source software will gain market power, ). competition laws may create a challenge against the broad interpretation. There are wellknown cases against Microsoft and Intel, establishing the use of terms having similar impact as communication-based view of GPL as unlawful and unenforceable. The primary reason for such a limitation is that it discourages the development of independent but interoperable extensions. In other words, should one be entitle to make proprietary code that interoperates with Open Source software distributed under GPL?
12. Patent law limitations provide another potentially interesting topic for further study. One view is that to extend the concept of derivation to any functionalities of which Open Source component is an functionally integrated part (because of functional link), is the same as extending the scope to those technical solutions of technical problems in which Open Source component is a part of. In other words, assume A=b+c+d, in which A is a software product performing a desired functionality, and b, c and d integrated functional elements to achieve the result, and c is an Open Source component. If the component-
Ilkka Rahnasto: Open Source Licensing – Challenges and Opportunities based view assumes that GPL terms extend to A, if components b and d are functionally linked to Open Source component c, the patent law doctrines may be triggered.
13. The patent law doctrines may be triggered because the above argument is exactly what patents are intended for, i.e. exclusivity over functional solution to a technical problem. One may argue that patent laws pre-empt contract law. In other words, one cannot protect by the means of contract anything that may be covered by a patent. Is this happening if one approves the communication-based approach? Always or just in some
circumstances? Turning it around, a proponent of software patents may say that GPL terms (if interpreted broadly) may be unenforceable because software developer should have applied for a patent if it were important to control functionally connected programs. Or in other words again, if one accepts the argument that software patents should not be granted (for subject matters that involve software algorithms), doesn’ that mean that a t legislator is taking a view that nobody should exercise control over functional relationship between pieces of software code, and broad GPL interpretation would go against that?
14. Finally, Mikko Välimäki concludes his thesis with an optimistic view about the expansion of Open Source as a community-based method of creating software goods. It would be an interesting topic of further study to discuss the socio-economic model of such an expansion. In particular, is Open Source community something more than other community involvement groups? A number of charity organizations and sport organizations rely on volunteers that spend their time for the benefit of communities. At the same time, a number of them struggle because they are lacking volunteers, or the most volunteers join only the best-known groups and the most popular sports, and there is an increasing pressure to rely on regular salaried work force. Those interest groups are actively looking for ways to combine community involvement and commercial activities. What is the future of Open Source in that respect? Can it learn from other interest groups? Is there a limit to the expansion because at some point there will be a lack of volunteers?