The COVID-19 pandemic has reminded us of the importance of (highly efficient and reliable) connectivity. Despite not being able to travel, we have continued most of the activities related to education and work, while keeping in touch with our loving ones.¹ Even in the face of lockdowns, we are free of physical boundaries thanks to standards. Standards allow products and services to be compatible and to inter- operate with each other. In particular formal (or de jure) standards are set and developed in a joint collaborative effort of companies willing to share with others cutting-edge technologies resulting from costly R&D investments under the umbrella of Standard Development Organisations (SDOs).² In SDOs, stakeholders typically develop standards following principles established for international standardisation, i.e., transparency, openness, impartiality and consensus, effectiveness and relevance, coherence, and consideration to countries’ interest.³ In this context open stands for the accessibility of all interested parties to the standardisation process (including the decision-making).

Cellular standards especially are growing exponentially. It took humans 100 years to connect one million places,⁴ 10 years to connect one million people (mobile phone)⁵ and only one year to connect one million things (the Internet of Things, known as the IoT).⁶ Currently, there are significantly more smartphone subscriptions than people on the planet⁷ and, with the 5G standard, consumers are experiencing drastic changes in sectors such as transportation, agriculture, health and security, to name but a few.

Despite its undeniable success, the standardisation process constantly faces the challenges of a fast-changing environment, common in the information and communication technology (ICT) field. As a result, cellular standardisation may benefit from co-existing with or even adopting potentially more flexible and faster mechanisms. One option suggested is the open source software (OSS),⁸ under which the intellectual property rights (IPRs) remain open, meaning that everyone can freely use, distribute or modify the source as long as that person respects the conditions established in the licence under which it is distributed.

The flexibility of OSS projects permits the user to expand its technological knowledge by contributing to an existing project or by starting new projects. Also, OSS is said to increase the rapid development of highly innovative implementations and reduce the costs in negotiation.⁹

Traditionally, several open-source initiatives have focused on the implementation of standards.¹⁰ Thus, formal standardisation and OSS are strongly interrelated. Despite their often-different governance and Intellectual Property Right policies, both share the same goals: innovation through collaboration. Hence, the interaction between OSS and formal standardisation has the potential to deliver high-quality standards in a timely manner and under reasonable terms, enhancing consumer welfare.

This paper identifies and scrutinizes possible ways of collaboration between open source and open standardisation. The structure is as follows: It begins with an overview of the formal standardisation (Section 2) and continues with an analysis of the origin of the open source, the revenues that can produce and the functioning of some open-source foundations (Section 3). This is followed by an analysis of the compatibility of both approaches and their market and network effects (Section 4.1). Finally, this paper explains the most viable solutions to achieve compatible policies for a win-win situation (Section 4.2).

A standard is a set of technical rules or guidelines aimed at ensuring interoperability between products and services. In the ICT sector, the most relevant example is cellular standards: 2G (GSM), 3G (UMTS), 4G (LTE), and currently 5G standard, where each generation (G) offers a massive improvement compared to the earlier one. For example, the data transfer with a 4G standard is 12,000 times faster than with 2G.¹¹ Cellular standards are set and developed by the consortium 3GPP, which develops technical specifications. ¹² These are then transposed into standards by the seven regional SDOs that are part of 3GPP. In Europe, the regional SDO is the European Telecommunication Standards Institute (ETSI).¹³

Setting and developing cellular standards is a very complex and costly process. For instance, just to develop the 4G standard, SDO members submitted a total of 23,235 technical contributions. ¹⁴ As the technologies contributed are often the result of massive R&D investments, companies generally protect them with patents. When patented technology is selected to be part of the standard, the patent may become essential to the standard, meaning that it is necessarily infringed when implementing the standard in a product or service. The owners of the so-called standard essential patents (SEPs) are encouraged by the SDO to make them available on Fair, Reasonable and Non-discriminatory (FRAND) terms and conditions. FRAND is typically determined in good faith licensing negotiations amongst the parties (SEP holder and SEP user).¹⁵ As a result, SDO policies can reach a balance between wide access to the standard and a fair and adequate compensation to innovators.¹⁶

Standards boost the overall economic flow, as market players can enjoy lower trading costs, more easily introduce innovative products to the market (due to interoperability), be ahead of technical requirements, improve the safety of consumers, and achieve a higher productivity and efficiency, amongst other benefits.¹⁷

3.1. Definition and Type of Licences

Open source is a software collaborative innovation and development model whereby software can be freely accessed, used, modified, and distributed while respecting the terms of the open-source licence.¹⁸ Although practically all open-source software is free software, OSS and free software are different concepts. The free software movement, which emerged in 1988, uses the term “free” to describe the software that respects the “user’s essential freedoms,” i.e., “to run [the software], to study and change it, and to redistribute copies with or without changes.”¹⁹ In turn, open source applies “free” within the context of licensing terms of the IPR Policy, meaning “royalty-free.”

There is not an official definition of the term “opensource,” but most of the community supports the definition proposed by the Open Source Initiative (OSI), according to which each licence must comply with 10 criteria: free redistribution, source code, derive works, integrity of the author’s source code, no discrimination against persons or groups, no discrimination against fields of endeavor, distribution of licence, licence must not be specific to a product, licence must not restrict other software and licence must be technology- neutral.²⁰ The vast majority of the OSI-approved licences, implicitly or explicitly, include a royalty-free (RF) patent grant.

Open-source licences implement what is called dissuasive exclusion, which implies that if licensees do not comply with the terms of the licence, they lose the benefit of using the software and thus the licence of the IP rights involved.²¹ There are two types of OSS licences, restrictive and permissive. Both of them allow users to freely copy, distribute and modify the software.

Restrictive licences, on the one hand, require that the licenced software and any modifications are to be redistributed under the same licence terms. Therefore, the distribution of the code and any modified version cannot be integrated in programs licenced under other OSS or proprietary licences if the terms among the licences vary. Restrictive licences can, thus, hinder one of the main goals of formal standardisation: the wide adoption and dissemination of the standard.²² The most well-known example is the General Public Licence (GPL).²³

Permissive licences, on the other hand, do not impose restrictive conditions on the redistribution of the software. Therefore, they are well suited for projects aiming to be widely adopted, since they allow the software to be sublicenced under different licence terms and incorporated into proprietary applications.²⁴ Some of the most popular permissive licences are BSD clause 2²⁵ and 3,²⁶ MIT,²⁷ and Apache 2.0.²⁸

3.2. Monetization

The main goal of the Open Source Community is to disseminate the code, involving as many contributors to the development of the technology as possible,²⁹ thanks to a multi-stakeholder cooperation.³⁰ However, the decision to use open source goes typically beyond the altruistic or philosophical belief in open science. In relation to the specific objectives, the interests of the collaborators can be very diverse, from educational to financial and/ or marketing, depending on the project, impacting the way the OSS is monetized.³¹ Corporations can obtain a return on investment in OSS by (1) charging fees for technical support (e.g., RedHat), or updated (premium) versions (Oracle), (2) leveraging OSS for other (complimentary) products and data (Google and Facebook), (3) getting access to all the IPR of other companies (even IPR not related to the OSS) and protect their own IP (Tesla), (4) improving own products (Google Translate), (5) creating de facto standards and ecosystems around it (Google and Android), and (6) keeping the user in the ecosystem (Google translation to remain using the Google search machine).

3.3. OSS Foundations

OSS projects may be supported by a separate legal entity, but this is not compulsory. The entities formed to manage open-source projects are often referred to as “foundations,” such as the Apache Software Foundation, ³² the Eclipse Foundation,³³ and the Mozilla Foundation.³⁴ These are non-profit organizations whose mission is to provide the necessary basis for open and collaborative software development, as well as a legal framework for individual volunteers.³⁵ While some foundations are created to drive an OSS project, some others emerge out of a mature OSS project, such as the Linux Foundation. ³⁶ On the other hand, foundations can “either serve a specific project, a set of projects, or serve as an umbrella for a number of smaller foundations that use it to simplify their own creation, management, and legal processes.”³⁷ There is no harmonization in terms of their management strategy despite sharing the same goal, i.e., the dissemination of the code through a cooperative model.³⁸ Finally, foundations generally deviate from the default rule in OSS, which is that individual developers retain ownership of copyrights and patents. They do so by centralising the copyright and patent permissions of their members, asking their collaborators to sign a “contributory licence agreement.”³⁹ According to such agreement, the signatory generally grants an irrevocable licence to the project maintainer, allowing him to use the contribution. In those cases where the copyright is transferred, the agreement is known as a “copyright transfer agreement.”

4.1. Phases of Interaction: Advantages and Disadvantages

Lundell and Gamelielsson formulate three scenarios, further developed by Husovec, in which standards and OSS interact, namely “standard first” (also known as “late implementor”), “software implementation first” (or “early implementor”), and “standard and implementation of standard in parallel” (or “standard and software in parallel”).⁴⁰

In the “standard first” scenario, which is the most frequent one, the OSS implementation is only one of the several means for implementing the standard, and will therefore have to compete with other implementations available on the market.⁴¹ On the other hand, it has the benefit that the FRAND patent policy of the SDO remains unaffected. Even if some permissive licences of the OSS contain a royalty-free patent grant, the patent clauses would only apply to the open-source work or contribution.⁴² This can happen even in those cases where FRAND terms and open source are not compatible but rather complementary. ⁴³ While in this scenario it is not possible to change the specification, specification remains stable, and the project is easy to implement when there is a demand in the market.⁴⁴

In the “software implementation first” scenario, an OSS project develops a technological design which is then codified through specifications in the actual standard.⁴⁵ In this scenario the specification as well as the code will change.⁴⁶ Moreover, as the standardisation has already started, should the OSS project licence include a royalty-free patent grant, the newly added SEPs would be covered by it. Consequently, contributors relying on FRAND terms to recoup and continue their R&D investments may choose not to join or stop contributing their (best) technologies into the standard, thus reducing its quality to the detriment of consumers. This outcome could be avoided if the OSS project chooses a licence compatible with the IPR Policy of the SDO.

Ultimately, the “standard and implementation of standard in parallel” takes place when standardisation and implementation work are conducted simultaneously but in different organisations. In this case, while the standardisation work is in progress, an OSS reference implementation work is undertaken for exploring the functioning of the specifications under development.⁴⁷ This last modality is the most complex one because of two factors. The first one is that if a SDO provides a reference implementation of one of its standards it will probably be deemed in practice as a mandatory interpretation of the standard.⁴⁸ The second one is that the reference implementation may become the standard if customers feel that other implementations are not fully compliant with the standard of the SDO.⁴⁹ The benefit of this third scenario is that specifications and implementations are exchanged in both ways and much more quickly. The IPR policies should be consistent though, in order to achieve a successful standardisation.⁵⁰

4.2. Integration and Antitrust Concerns

Companies conventionally cooperate on specifications through standardisation, creating a level playing field, and then compete on the product implementations. The test and implementation of their specifications are commonly done in an OSS foundation, such as Linux. In the last few years, however, several SDOs have decided to host pilot OSS projects for such test and implementation, such as the MANO project in ETSI.⁵¹ Nevertheless, the integration of two organisations that follow a diverse, eventually incompatible IPR policy model, and with a different understanding of the term “openness,” has proved to present a major challenge.⁵²

That said, given that both formal standardisation and open source can boost innovation and competitiveness, it is considered that their alliance could be a “win-win” situation.⁵³ Reason being that, by introducing OSS projects, SDOs could be able to adapt their traditional standardisation process and render it more dynamic. At the same time, open source software implementations could enjoy the interoperability that standards provide.⁵⁴

In some cases, an SDO may choose to integrate an OSS project in the development of specifications. In such a scenario, if certain OSS licences are selected, discrepancies in patent grant obligations may arise.

On the one hand, if the OSS licence does not contain a patent clause, the patent grant will be governed by the SDO’s IPR policy (e.g., FRAND) and will therefore be subject to those conditions. On the other hand, if the selected OSS licence has an RF patent clause, and the implementation effectively becomes the standard, then the SEP holder involved in the development of that implementation will be required to grant the patent under RF terms, even when the SDO’s IPR policy foresees a FRAND licensing for SEPs.⁵⁵ In this context, where “a particular treatment of IPR” that is “inconsistent with the interests of all stakeholders” is imposed, some antitrust issues may emerge.⁵⁶ By using an OSS licence with an RF patent clause in the SDO, so-called “standard innovators”⁵⁷ that contributed to the standard relying on a FRAND licence, would be forced to licence their patents on an RF basis to participate in the implementation of the standard. In contrast, socalled product innovators⁵⁸ would benefit from the standard innovators’ contributions to the specification for free by subsequently developing a compliant implementation adapted to their products and services in the SDO’s OSS project on a RF basis. To the extent that an SDO and its product innovators manipulate the process to exclude standard innovators and reduce or evade the licensing fees, they could become the subject of an antitrust investigation for collusion.⁵⁹

4.3. Potential Solutions When Integrating OSS in Standardisation

In order to preserve the balance between the interests of implementers and patent holders, when integrating OSS in standardisation, it would be advisable that OSS projects adopt OSS licences compatible with the IPR policy of the corresponding SDO. Copyleft licences, under which successive modifications done by a licensee must be distributed under a compatible licence,⁶⁰ cannot be used for integrating standards and OSS, since some of their clauses, such as the liberty or death one,⁶¹ directly conflict with FRAND terms.⁶²

Also, permissive licences, like Apache 2.0, approved by OSI do not appear to be suitable for the SDO development of reference implementations of their specifications. For example, Apache 2.0, despite being a flexible licence compatible with proprietary and open source software, requires each contributor to agree to a RF patent licence covering its contribution to the specific OSS project.⁶³ As the ETSI MANO project shows,⁶⁴ integrating Apache 2.0 in SDOs for implementing their standards leads to incompatibility issues.⁶⁵ When a company contributes a code in an open-source project under the umbrella of a SDO and following the Apache 2.0 licence, it automatically grants a royalty-free licence to the patents connected to that code. As a result, there is limited incentive to contribute for those who have patents that wish to licence under FRAND terms and conditions.

Other OSI-approved licences, like the BSD or MIT, are ambiguous about which IP rights are covered. There is disagreement with academia as to whether those licences are copyright-only licences or whether they contain an implied RF patent clause.⁶⁶ Consequently, if they are to be used, it is desirable to include a clause to the BSD and MIT policy specifying that they refer only to copyright.⁶⁷

Furthermore, OSI interprets OSS licences in a way that makes them generally incompatible with SDOs with a FRAND IPR policy, forcing an RF licence to SEPs developed under the umbrella of such SDO. Therefore, a solution would be that those SDOs that wish to integrate OSS projects into the standards development process adopt an OSS licence that meets a broader definition of open source than the one adopted by OSI.⁶⁸

A successful example of interaction is that of Open- Air Interface, which although not being an open-source licence, creates the OAI Public Licence V1.1. This licence allows the licence of patents incorporated for “study, testing and research purposes” to be RF. However, when patents are incorporated for “purposes other than study and research,” they should be licenced under FRAND terms, so that contributors can get a fair return on investment and continue to invest in research and development for the next generation of standards.⁶⁹

Another potential way to collaborate would be to create an information feedback loop, as the Linux Foundation proposes with its Technical Advisory Council (TAC). The TAC serves as a reference point for any collaboration between the open source and SDO communities. Each party appoints a representative and selects the input they desire to get from this collaboration. The TAC then serves as a communicator and makes recommendations when necessary, provides updates on the process, oversees the functioning of the collaboration, and evaluates the plan established by the parties. Thus, the TAC aims to ensure that the collaboration turns into results. ⁷⁰

Formal standardisation and open-source projects normally differ in their governance, IPR policies and application of the term “openness.” However, both aim to create innovation through collaboration and can boost innovation and competitiveness. Accordingly, it is considered that their alliance could be equally beneficial to both parties.

There are different scenarios in which standards and OSS can interact, where OSS policies can be incorporated without overruling the IPR of the corresponding SDO. One challenge may occur when SDOs form their own OSS projects and use an OSS licence for reference implementations of their standards. If the open-source licence selected for this purpose does not contain a patent clause, the granting of the patent should generally be governed by the SDO’s IPR policy and will therefore be subject to the terms of the SDO (in cellular standardisation, this means generally FRAND terms and conditions). Nevertheless, if the selected SDO licence has a RF patent clause, and the implementation becomes the standard, then any party involved in the development of that implementation will be required to grant RF patent licences. This could discourage some stakeholders from participating in the standardisation process, or encourage contributing lower-quality technology to the standards, to the detriment of consumers. It could also cause some antitrust issues to the extent that the SDO and its “product innovators” are able to manipulate the process to exclude “standards innovators” and reduce or avoid licensing fees, imposing IPR terms inconsistent with the interests of all stakeholders.

Therefore, it is highly advisable that SDOs adopt OSS licences that are compatible with their IPR policies to preserve the balance between the interests of implementers and patent holders. Copyleft licences and some other OSI-approved permissive licences containing a RF patent clause, such as Apache 2.0, do not seem suitable. It should be noted that OSI interprets OSS licences in a way that makes them generally incompatible when applied to the same patents committed under FRAND terms. A possible solution would be for SDOs that wish to integrate OSS projects into the standards development process to adopt a licence that meets a broader definition of open source than the one adopted by OSI. There have been examples of fruitful interaction between OSS and de jure standardisation, such as Open-Air Interface, which created the OAI V1.1 public licence. This shows that the two models can work successfully together as long as there is a will.

On the other hand, the SDO should also consider whether the benefits of using OSS for testing and reference implementation—i.e., stability, interoperability, competition in the implementation—outweigh the benefit of mandating a specific code, which is that there is only one implementation. This analysis would need to be made on a case-by-case basis. ■

Available at Social Science Research Network (SSRN): https://ssrn.com/abstract=3946580.

* Jesús Alonso works in Policy at the Motion Picture Association (MPA-EMEA). This paper resulted from the research conducted in his earlier job as a Researcher at Ericsson. The views expressed herein are those of the author alone and do not necessarily represent MPA-EMEA or Ericsson’s views.

1. The governments of those countries with areas not using the mobile internet face limitations in their ability to “effectively manage the pandemic and its economic fallout.” See GSMA, Connected Society: The State of Mobile Internet Connectivity 2020 <file:///C:/Ericsson%203/Academia/GSMA-Stateof- Mobile-Internet-Connectivity-Report-2020.pdf>.
2. Cellular standards not only offer interoperability but also high performance “in capacity, data rates, latency, reliability and security.” See (2012) White Paper on Economic Impact of the ICT Sector, p. 3 at Haris Tsilikas, “Huawei v. ZTE in Context— EU Competition Policy and Collaborative Standardization in Wireless Telecommunications” (2017) 48(2) IIC—International Review of Intellectual Property and Competition Law 151.
3. WTO, Second Triennial Review of the Operation and Implementation of the Agreement on Technical Barriers to Trade, WTO Doc. G/TBT/9 [Six Principles for International Standardisation] (13 November 2000), Annex 4.
4. Fully 105 years were needed to create the first telephone in the first industrial revolution (1765-1870). Katerina Pouspourika, “The 4 industrial revolutions”(The Institute of Entrepreneurship Development, 30 June 2019) <https://ied.eu/ project-updates/the-4-industrial-revolutions/> accessed 27 November 2020; Mary Bellis, “How the telephone was invented” (ThoughtCo., 27 January 2020) <https://www.thoughtco.com/ history-of-the-telephone-alexander-graham-bell-1991380> accessed 2 March 2021; Katerina Pouspourika, “The 4 industrial revolutions”(The Institute of Entrepreneurship Development, 30 June 2019) < https://ied.eu/project-updates/the-4-industrialrevolutions/>.
5. In 2016 the first mobile phone reached its peak of 1.71 billion connections. Katerina Pouspourika, “The 4 industrial revolutions”(The Institute of Entrepreneurship Development, 30 June 2019) <https://ied.eu/project-updates/the-4-industrialrevolutions/>.
6. As the European Commission (EC) explains, the IoT “represents the next step towards the digitisation of our society and economy, where objects and people are interconnected through communication networks and report about their status and/or the surrounding environment.” See EC, Shaping Europe’s digital future, https://ec.europa.eu/digital-single-market/ en/internet-things.
7. Statista Research Department‚‘4G LTE connections worldwide 2012-2020’ (Statista 2021).
8. The European Commission, e.g., argued in 2017 that the “[i]ntegration between open source projects and standards development processes is a win-win situation: on one side the alignment of open source and standardisation can speed-up the standards development process and the take-up of ICT standards (especially for SMEs), and on the other side standards can provide for interoperability of open source software implementations.” See European Commission’s Communication, Setting out the EU approach to Standard Essential Patents, 29th November 2017, p.12, Open Source and Standards.
9. While in 2004 the risk of litigation was considered low in open source, by 2020 litigation related to OSS licences on contract and copyright was significantly higher. See Open Source Litigation, Open Source Licensing 12, 269-295, June 2004, 269 <Open-Source-Litigation.pdf (rosenlaw.com)>. See Open Source Software: Litigation Windfall or Landmine?, August 2020. <ttps://www.dentons.com/en/insights/articles/2020/august/ 25/open-source-software-litigation-windfall-or-landmine>.
10. Carlos Muñoz Ferrandis and Claudia Tapia, “Integrating Open Source into De Jure Standardization: Beyond a Call for the Appropriate Licence,” (July 23, 2018). les Nouvelles—Journal of the Licensing Executives Society, Volume LIII No. 3, September 2018, https://ssrn.com/abstract=3218558.
11. See Boston Consulting Group, “Related Expertise: Telecommunications Industry Consulting and Strategy, Digital, Technology, and Data, Business Strategy the Mobile Revolution: How Mobile Technologies Drive a Trillion-Dollar Impact,” 15. January 2015. https://www.bcg.com/publications/2015/telecommunications- technology-industries-the-mobile-revolution.
12. A technical specification is “a document that prescribes technical requirements to be fulfilled by a product, process, service or system.” See Article 1 of Regulation (EU) No 1025/2012 of the European Parliament and of the Council of 25 October 2012 on European Standardisation, amending Council Directives 89/686/EEC and 93/15/EEC and Directives 94/9/EC, 94/25/EC, 95/16/EC, 97/23/EC, 98/34/EC, 2004/22/ EC, 2007/23/EC, 2009/23/EC and 2009/105/EC of the European Parliament and of the Council and repealing Council Decision 87/95/EEC and Decision No 1673/2006/EC of the European Parliament and of the Council; See 3GPP, Specifications <https://www.3gpp.org/specifications>.
13. Other SDOs in 3GPP are ATIS (USA), ARIB and TTC (Japan), TTA (South Korea), CCSA (China) and TSDSI (India). On the functioning of 3GPP see, Justus Baron and Kirti Gupta, Journal of Economics & Management Strategy 27(3):433-461, September 2018.
14. Claudia Tapia, “Securing a Competitive Future in Europe,” The Patent Lawyer, January/February 2016.
15. Luis Herranz and Claudia Tapia, “Good and Bad Practices in FRAND Licence Negotiation” (chapter) in Resolving IP Disputes, Zeiler/Zojer (eds), pp. 49 -68, 2018. In the few cases where parties disagree, they may end in litigation, where the SEP holder will typically ask for an injunction and the SEP user will generally raise a FRAND defense (to avoid the injunction). In Europe, the courts in their determination on whether to grant an injunction will analyse the behaviour of parties within the framework established by the Court of Justice of the European Union (CJEU) in its ruling case C170/13 Huawei v ZTE on 16 July 2015. See a summary of the CJEU judgment as well as summaries of national case law interpreting the ruling at 4iP Council’s website. <https://caselaw.4ipcouncil.com/>.
16. See, e.g., “Balancing Innovation & Intellectual Property Rights in a Standards-Setting Context,” ITU News, No. 9 (2012), <https://itunews.itu.int/en/3049-Balancing-innovationand- intellectual-property-rights-in-a-standards-setting-context.note. aspx> and ETSI IPR Policy <ETSI—Intellectual Property Rights policy and IPR online database>.
17. European Commission, Benefits of Standards: European Commission, Internal Market, Industry, Entrepreneurship and SMEs, Benefits of standards <https://ec.europa.eu/growth/single- market/european-standards/policy/benefits_en>.
18. See the Open Source Definition, Open Source Initiative (OSI) <https://opensource.org/osd>.
19. Richard Stallman, “Why Open Source Misses the Point of Free Software,” (GNU, 20 October 2020) <https://www.gnu. org/philosophy/open-source-misses-the-point.en.html>.
20. OSI (n. 19).
21. Carlos Muñoz Ferrandis and Marta Duque Lizarralde, “Open Source for AI Systems: IPR Strategy for Platform Leadership,” (forthcoming 2021).
22. Slava Todavchich, “Understanding open-source and free software licensing,” Noteworthy—The Journal Blog, 24 September 2019 <https://blog.usejournal.com/understandingopen- source-and-free-software-licensing-c0fa600106c9>; David Kappos, “Open Source Software and Standards Development Organizations: Symbiotic Functions in the Innovation Equation” (2017), The Columbia Science & Technology Law Review, Vol. XVIII.
23. See the licence text at: https://opensource.org/licenses/ gpl-license.
24. Slava Todavchich, “Understanding open-source and free software licensing,” Noteworthy—The Journal Blog, 24 September 2019) <https://blog.usejournal.com/understandingopen- source-and-free-software-licensing-c0fa600106c9>.
25. See licence text at: https://opensource.org/licences/BSD- 2-Clause.
26. Ibid., BSD-3-Clause.
27. See licence text at: https://opensource.org/licences/MIT.
28. See licence text at: http://www.apache.org/licences/LICENCE- 2.0.html.
29. Knut Blind and Mirko Böhm, “The Relationship Between Open Source Software and Standard Setting,” Nikolaus Thumm, editor(s), EUR 29867 EN, Publications Office of the European Union, Luxembourg, 2019, ISBN 978-92-76-11593-9 (online),978-92-76-11592-2 (print), doi:10.2760/163594 (online), 10.2760/937637 (print), JRC117836. https://ec.europa. eu/jrc/en/publication/eur-scientific-and-technical-research-reports/ relationship-between-open-source-software-and-standardsetting accessed 3 July 2020, 55.
30. Jimmy Ahlberg, “The implicit patent licence grant in some popular Open Source licences,” (Master’s thesis, University of Göteborgs 2014), 26.
31. Abdulwahhab S, Alabady Y., Sattar Y., Hammouda I. (2016), “The Role of Local Open Source Communities in the Development of Open Source Projects.” In: Crowston K., Hammouda I., Lundell B., Robles G., Gamalielsson J., Lindman J. (eds) Open Source Systems: Integrating Communities. OSS 2016. IFIP Advances in Information and Communication Technology, vol 472. Springer, Cham. https://doi.org/10.1007/978-3- 319-39225-7_1 accessed 03 December 2020, 1.
32. See the Apache Foundation website: https://apache.org/.
33. See the Eclipse Foundation website: https://www.eclipse. org/.
34. See the Mozilla Foundation website: https://foundation. mozilla.org/en/.
35. Javier Luis Cánovas Izquierdo and Jordi Cabot, “A Survey of Software Foundations in Open Source,” 20 May 2020, <https://arxiv.org/abs/2005.1006320/05/20>.
36. See Linux Foundation website: https://www.linuxfoundation. org/.
37. Javier Cánovas, “The Role of Foundations in Open Source Projects,” (Livable Software, 2020) <https://livablesoftware. com/study-open-source-foundations/>.
38. Javier Luis Cánovas Izquierdo and Jordi Cabot (n. 36).
39. Martin Husovec, “Standardization, Open Source, and Innovation: Sketching the Effect of IPR Policies,” (2018) <https:// papers.ssrn.com/sol3/papers.cfm?abstract_id=3215769#>.
40. European Commission (n. 9); See Daniel Veillard’s presentation, Standards, the kernel and Open Source (2012) <http://veillard.com/Talks/CLKBeijing2012.pdf>.
41. Martin Husovec (n. 40).
42. Jay P. Kesan, “The Fallacy of OSS Discrimination by FRAND Licensing: An Empirical Analysis,” (2011), Illinois Public Law Research Paper No. 10-14, 9; Iain G. Mitchell QC and Stephen Mason, “Compatibility Of The Licensing Of Embedded Patents With Open Source Licensing Terms,” (2011) 25(3) International Free and Open Source Software Law Review <http:// www.ifosslr.org/ifosslr/article/view/57/100>; David Kappos (n. 23) 263, 264.
43. Michel Vivant, “Open Source: A Way For A Reasonable Standard Implementation?” (2018) 40(7) E.I.P.R., Van Lindberg, “OSS and FRAND: Complementary Models for Innovation and Development,” (2019) 20 The Columbia Science and Technology Law Review 254.
44. Daniel Veillard (n. 41).
45. Martin Husovec (n. 40); Jingze Li, ‘Intellectual property licensing tensions: in utilizing open source software in the formal standard setting context- the case of Apache v.2. in ETSI as a start’ (2017) https://papers.ssrn.com/sol3/papers. cfm?abstract_id=3083840.
46. Daniel Veillard (n. 41).
47. Martin Husovec (n. 40).
48. Michele Herman and Justus Baron, “Downsides of Using Inadequate Open Source Software Processes and Licences within Standard Development Organizations”(2021) <https:// papers.ssrn.com/sol3/papers.cfm?abstract_id=3790616>.
49. Ibid.
50. Martin Husovec (n. 40).
51. See, e.g., ETSI with the MANO project, <https://osm. etsi.org/>.
52. Jingze Li, “Intellectual Property Licensing Tensions: Utilising Open Source Software in the Formal Standard-Setting Context,” (2018) 9(2) European Journal of Law and Technology, 10.
53. European Commission (n. 9).
54. Communication from the European Commission to the European Parliament, the Council and the European Economic and Social Committee, Setting out the EU approach to Standard Essential Patents, COM (2017) 712 Final, Brussels, 29.11.2017, 12; Jingze Li (n.53); As Muñoz and Tapia explain, “[b]y guiding the continuous software development, which characterizes OSS, into a more rigorous implementation of the standard, proponents of integration seek to avoid constant non-consensual evolution which is one of the risks of OSS projects” Carlos Muñoz Ferrandis and Claudia Tapia (n. 11).
55. Jingze Li (n. 53).
56. Richard Taffet and Michael Zymler, “Open Source Software and Standards Development: Competition Law Implications” (December 4, 2020), 7. <http://dx.doi.org/10.2139/ ssrn.3742791>.
57. Michele Herman and Justus Baron (n. 49): “These stakeholders innovate specifically for purpose of developing new standards and foundational infrastructure and contribute those innovations into the SDO’s standards development process under FRAND patent policies.”
58. Michele Herman and Justus Baron (n. 49): “These stakeholders often participate in the SDO to ensure that whatever standard is ultimately adopted by the SDO will be compatible with products and services they produce.”
59. Michele Herman and Justus Baron (n. 49); See Richard Taffet and Michael Zymler “Open Source Software and Standards Development: Competition Law Implications” (2020) <https://papers.ssrn.com/sol3/papers.cfm?abstract_ id=3742791> who argue that “doubts should be cast on the competition law propriety of any non-consensus proposals or efforts to compel or permit use of particular open source licensing models that would prohibit FRAND royalty bearing licensing or that would otherwise restrict SEP owners’ freedom to negotiate FRAND licences.”
60. Martin Husovec (n. 40).
61. Section 12: “If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this Licence, they do not excuse you from the conditions of this Licence. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this Licence and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this Licence would be to refrain entirely from conveying the Program.”
62. David Kappos (n. 23); Jay P. Kesan (n. 43).
63. Clause 3; See FAQ about Apache Licensing, What is the scope of patent grants made to the ASF?: http://www.apache. org/foundation/licence-faq.html#PatentScope.
64. Li warns that “Without a clear guidance on the priority of FRAND and Apache v.2, there is a chance for making patents embedded in standards free from royalty charges to a “Work” that is too large to be controlled.” Jingze Li (n. 46)
65. Carlos Muñoz Ferrandis and Claudia Tapia (n. 11).
66. Andrew Sinclair, “Licence Profile: BSD,” (2010), 2(1) IFOSS L. Rev., 2,4; Lawrence Rosen, Open Source Licensing (Prentice Hall 2004), 78.
67. Carlos Muñoz Ferrandis and Claudia Tapia (n. 11).
68. Michele Herman and Justus Baron (n. 49); Axel Ferrazzini, “How OSS licensing could coinhabit with standards development organisations” existing IPR policies’ (2018) < IP Research—How OSS licensing could coinhabit with standards IPR policies | 4iP Council>.
69. Carlos Muñoz Ferrandis and Claudia Tapia (n. 11); Axel Ferrazzini (n. 69).
70. Jason Hunt and Prakash Ramchandran, “Cross-Community Collaboration Process,” (lfnetworking, 2020) <https://wiki. lfnetworking.org/display/LN/Cross-Community+Collaboration+ Process> 2021.