Intellectual property licensing tensions: utilising open source software in the formal standard-setting context

Jingze Li[1]


Open source software (OSS) is playing an increasing role in information and communication technology (ICT) standards. Many standard development organisations (SDOs) are exploring approaches to incorporating OSS into their standard-setting context. How to address intellectual property rights (IPRs) represents one of the challenges they are facing. This paper depicts the difference between open source licenses and IPR policies of SDOs in addressing copyright and patent right. We found that the current IPR frameworks, including the FRAND license commitment for patented technologies and copyright rules for software in standard specifications of the three SDOs (ITU, ETSI, and IEEE), show gaps in avoiding tensions in their interaction scenarios such as implementing standards in open source projects and utilising open source projects for standardisation activities. Some of these concerns might currently be hypothetical, but their significance will likely increase. We suggest that SDOs could change some of the existing rules and design a model utilising OSS according to their specific goals.

Keywords - open source software, ICT standardisation, IP licenses, ETSI

1. Introduction

Future technologies present a unique opportunity for new forms of innovation and collaboration in standardisation activities. Open source software (OSS) is one of the candidates that has been increasingly active in shaping information and communication technology (ICT) standards. For instance, both cloud computing [2] and internet of things (IoT) technologies[3] have many open source implementations and have functions driven by open source innovation. With an increasing number of functions realised by software, areas that were traditionally dominated by hardware are also finding approaches to utilise open source. For instance, the telecommunication sector is developing 5G technology, in which open source is deemed to play a role in defining many of the architectures. [4] The European Commission (EC) has been supporting open source solutions, e.g., through R&I projects funded under Horizon 2020. In 2017, by recognising the dynamic role of open source in ICT standards, the European Commission announced that it would continue to promote flexible and effective interactions and collaboration between standardisation and open source communities. [5]

Despite the prosperity of widespread open source, legal questions around intellectual property in the interplay remain an unsolved puzzle. Both academic and industry works have enquired how intellectual property rights (IPRs) in the interplay will be addressed, who will own the copyright and whether patent licence commitments by standard setting organisations (SSOs) and OSS are compatible.[6] Previous research has addressed the compatibility issue between fair, reasonable and non-discriminatory (FRAND) licensing commitment on standard essential patents (SEPs) and open source licences (open source licences). [7] An empirical work by Lundell et al. has tested the legal compatibilities of open source implementation based on ISO standards. [8] Although less attention has been focussed on copyright issues, a piece in a work from Contreras in 2016 talked concisely on copyright licence issues concerning open source in the standardisation context. [9] However, a discussion about the whole picture is lacking, given the evolving reality that new technologies keep creating new scenarios and issues. Debates about the interplay exist in major standardisation development organisations (SDOs) [10] such as the International Telecommunication Union (ITU), [11] the European Telecommunications Standards Institute (ETSI) [12] and the American National Standards Institute (ANSI); [13] IPR issues have often been positioned as one of the main challenges in their discussions.

Against this background, this research endeavours to provide an overview of the IPR issues in formal SDO utilisation of OSS. We wish to address the following questions: "What are the differences between SDO IPR policy and open source licences in addressing IPRs?"; "Whether the current IPR framework of formal SDOs is adequate to embrace OSS?"; and "What frictions may arise from such differences?" To explore the answers, we must first understand the differences in addressing intellectual property rights between the policies of SDOs and open source licences (Part 2). The comparisons will be followed by an analysis of frictions in conceptualised scenarios in which SDO and OSS meet, with the help of reference to existing intellectual property (IP) laws, legal discussions and court cases (Part 3). The last part concludes.

In this preliminary piece, we limit our research by adopting the perspective of three formal standard development organisations (SDOs), namely the ITU, the ETSI and the IEEE. They are worth noticing for the characteristics of their organisations. ITU is the United Nations specialised agency and represents the international standard body. ETSI is one of the three European standardisation organisations (ESOs) recognised by Regulation EU No 1025/2012 of the European Parliament and of the Council on European Standardisation (the Regulation) to develop European Union (EU) standards. IEEE was accredited by ANSI to develop US standards, and many of its standards have international influence, e.g., WIFI. Policies of other SSOs will only be mentioned if necessary. Similarly, it is not possible to present exhaustive discussions on all open source licences here. We will focus on some typical features represented by the ten licences [14] that are "popular and widely used or with strong communities" identified by the Open Source Initiative (OSI).[15] Appendix A illustrates some of their main features.

2. Standards and IPR arrangements in SDOs

Technical standards developed by these bodies generally refer to "the establishment of norms and requirements for technical systems, specifying standard engineering criteria, methodologies or processes." [16] They are key to enabling interoperability and compatibility in the ICT industry, in which the continued emergence of new services, applications and products fuels the need for more interoperability between systems. Many of these technical standards that we have today are developed by SDOs that are formed by players from the industry. For example, the GSM standard developed and maintained by the ETSI formed the telecommunication system that we have today.

Technical features for implementations to comply with a standard are documented in specifications. They can have different names in different SDOs. In the ITU, they are called "ITU recommendations". The IEEE uses the term "IEEE standards". The ETSI differentiates between different deliverables that can be produced by the organisation. Both terms, "standards" and "specifications", are used; the difference is that the latter indicate a fast procedure that leads to the deliverable. To make things simple, we use the term "standards" or "specifications" interchangeably to only refer to these documents. They are relatively stable and establish a common base for implementation. Technologies embedded therein are separate from technical specifications. Other than the fact that they are mentioned in the specifications, they are as normal as any other technologies owned by companies, and can be protected by patent law, copyright law or trade secret, depending upon each case. If a technology is considered necessary to comply with a standard, it is considered an "essential" technology.

IPRs in the SDOs can be complicated. Fortunately, most SDOs now have detailed IPR policies that specify many of the rights and conditions to operate.[17] In the following text, we will discuss what copyrights and patent rights can be relevant for our research, and how they have been structured and made available in the three SDOs: ITU, IEEE and the ETSI.

2.1 Copyright

A "literary work" is entitled to copyright protection when it is the author's own intellectual creation. The right arises automatically when a work is created and recorded in a tangible form or electronic device. A specification produced by SDOs can constitute a literal work that is protected by copyright law. It is the common practice for SDOs to claim the ownership of such copyright. [18] This practice is also characteristic of the three organisations we are examining, namely the ITU,[19] ETSI[20] and IEEE. [21]

Recently, the copyright ownership of a standard specification has been subject to debate in the EU. As early as March 2015, a judgment of the Landgericht (Regional Court) Hamburg confirmed the copyrightability of standards maintained by the German Institute for Standardisation (DIN). [22] However, a case in 2016 before the European Court of Justice (ECJ), James Elliott Construction Limited v. Irish Asphalt Limited raised the question of whether the European Standardisation Organisations (ESOs) can be the right owner for EU standards, if a standard developed by an ESO can be part of the EU law as the judgment suggested. [23] Such debates have decreased in intensity to some extent because the European Parliament adopted a resolution in its plenary sitting of 4 July 2017 stating that standards produced by ESOs cannot be treated as a part of EU law. [24]

Copyright grants an SDO many exclusive rights, such as the right to enjoin others from having access to, using, modifying and distributing a copyrighted specification. First, as the copyright owner, an SDO can charge firms or third parties for their access to and use of technical standards. Different business models have been developed among SDOs. The ETSI and ITU have made their specifications available for free, whereas others adopted a model to sell standards, e.g., the IEEE.

With respect to the right to distribute and modify, almost no SDOs allow free distribution and modification without any authorisation. Specifically, distribution of any modified version as a standard is generally prohibited. [25] Arguably, SDOs value stability over distribution. Free modification and distribution can lower the stability of a standard, which is an important feature of standardisation work and brings benefits. Standardisation work provides the agreed and stable common bases for downstream implementations. It also benefits the industry by setting a benchmark and avoids duplicated work so that R&D can focus on implementation or another area. This point does not deny the updating work of a standard. However, if a technical specification were not able to keep basic stability and could be changed constantly, industry implementers might be hesitant to make conformed products because the requirement might change before it was placed into production at large scale. Many of the benefits of standards, such as positive network effects, [26] are also attributable to the stability that a standard could bring to the industry.

A typical specification would be "normative" as a set of descriptions of functions that an implementation should fulfil. Following the guidance, implementers can have different technical solutions to the issue. Software code is not "normative", but it can be more "direct". It not only tells a direction but also can give more-detailed instructions because the code has already been written. For instance, an application programming interface (API) would have the same code in the connection part for every component. When there is a trend that software is included in specifications (for utilities such as testing, referencing and even for essential functions), questions have been raised whether the code in such cases should be treated differently from the rest of the specification in terms of copyright. [27]

Some SDOs have addressed this question by having ad hoc rules for it. For instance, both the ITU and ETSI have introduced software guidelines (rules), according to which additional licences are demanded from contributors for any code that has been included. The ITU has three detailed licensing approaches that contributors (members) can choose from, ranging from waiving the copyright to royalty free (RF) licence and to licence with reasonable monetary compensation. [28] The one written in the ETSI IPR policy is more concise, requiring software contribution to be subject to an "irrevocable, non-exclusive, worldwide, royalty-free, sub-licensable copyright license" and to derivative works, unless the member makes it explicitly for a FRAND commitment on implementation use. [29] All of these software licences are only granted for limited usages, such as evaluation and implementation of the software. Moreover, software included in specifications is generally not considered "essential for implementation". [30] The idea in both ITU and ETSI is to include software code for technical facilitations, such as explaining functions or referencing. [31] When SDO bylaws are silent on this issue (e.g., IEEE), software in standard specifications is arguably treated the same as the other literary part of a specification. In fact, lack of specific rules exists in most SDOs that are certified by the American National Standards Institute (ANSI), [32] because ANSI has explicitly expressed its preference on not including copyrighted software in standards.[33]

The abovementioned copyright issues in SDOs have not aroused as much attention as patent rights thus far. However, as we have been emphasising, many future technologies will be software-driven, and copyright is commonly used in protecting software. [34] As we will discuss in the following sections, open source licences are basically copyright licences, and copyright issues play more than an equal role compared with patent rights therein. Therefore, if SDOs are considering exploring means to utilise OSS, copyright issues should arguably be on their agenda in the near future.

2.2 Patent licences

A patent is an exclusive right granted for an invention of a new way of doing something. Unlike copyright, which emphasises originality, a patent right goes a step further to control the idea behind new inventions. It is stronger in terms of exclusivity. Recent years have witnessed a surge in disputes around patents in standards, particularly on SEPs, with litigation involving many large firms. [35]

Patented technologies embedded in standards are usually not licensed by the SDO that developed the standards. [36] Patent holders (usually also members of the SDO [37]) remain right owners. They are the ones that potential implementers should seek to negotiate with about how to obtain a licence for the patented technologies. However, SSO IPR rules usually ask patent owners to disclose patents or commit to license SEPs on FRAND/Royalty Free (RF) terms if they want the technologies to be embedded in standards. IPR rules can mention the obligation to search for relevant patents, the obligation to disclose patents and licence commitment on patents, depending upon different SSOs. [38]

Licence commitment on SEPs plays an important role among others. A licence commitment is generally considered to constrain arbitrary bargaining power of an IPR owner,[39] because it is said that the value of a patent might increase after it has been embedded in a standard, thereby enhancing the bargaining power of the patent holder.[40] Members might abuse their patent right after the technology has been included and hold up potential implementers by demanding higher royalties than the intrinsic value of the patent had it not been included in a standard. [41] This risk is particularly an issue in cases in which such a patent is essential for compliance with the standard (SEPs). SDOs have developed a practice to require members to license SEPs on Fair Reasonable and Non-discrimination (FRAND) terms. What terms constitute a FRAND licence will be negotiated outside of the standard setting between licensors and licensees in a business setting. The Court can be invited to decide a royalty and assess the licence when negotiation fails and disputes arise. [42]

The FRAND commitment is the most widely used patent rule in SDOs. [43] It has also been adopted by the ITU, IEEE and ETSI. Annex 2 of the Guidelines for Implementation of the Common Patent Policy for ITU-T/ITU-R/ISO/IEC (ITU Patent Policy) gives patent holders the choice to select licence commitment from RF to FRAND and to be unwilling to license. [44] A patent holder's unwillingness to license a patent will substantially decrease the possibility of having the patent embedded in the standard. The IEEE-SA Standards Board Bylaws (IEEE bylaws) offer two options for submitted essential patent claims: the submitter can either assure not to enforce the patent or commit to license it under FRAND terms. [45] Similarly, the ETSI IPR policy requires licences for essential IPRs to be licensed under FRAND terms.[46] The FRAND commitment gives right holders more power in terms of exclusivity over their patents. They could negotiate on terms and royalty fees under it, whereas they will lose more exclusivity of their patents under RF (not be able to collect royalty) or NAC (not be able to exclude others from use, thus not be able to collect royalty).

The fact that FRAND leaves room for negotiation is a balance between access to technologies and the interests of patent holders. On the one hand, FRAND allows patent holders to collect their royalties, which can be an incentive for them to submit technologies to an SDO. On the other hand, the commitment to license the SEP on FRAND terms ensures that they will not abuse their bargaining power and will offer their SEPs to implementers on fair royalties and terms. As the United States Patent and Trademark Office (USPTO) has stated, FRAND is an effort from SDOs to "reduce the occurrences of opportunistic conduct in the adoption of voluntary consensus standards, while encouraging participants to include the best available technology in standards".[47]

What FRAND actually means and what licence terms fulfil the principle are not clear. There are some general elements around the discussion. [48] For instance, according to the Guidelines on the Applicability of Article 101 of the Treaty on the Functioning of the European Union to Horizontal Co-Operation Agreement (the Horizontal Guidelines), the fees should "bear a reasonable relationship to economic value of the IPR", which should reflect the value of the patent ex ante standardisation. [49] The non-discrimination element does not mean all royalties should be set at the same amount in all circumstances, but the royalty rate should be paid by every licensee when all differences have been considered, e.g., some licensees might have concluded a cross-license with the SEP-holder, whereas others do not. [50] In addition, a licence is not only about royalties but also can contain other terms such as a patent validation challenge prohibition that must be assessed. [51] The IEEE took further steps in 2015 to enrich the meaning of FRAND. For example, it adopted the smallest saleable unit principle (SSUP), which specifies that a reasonable royalty calculation should consider the value of the smallest saleable compliant implementation that practices that patent claim. [52]

3. Open source licenses and IPRs

The term OSS is now broadly used to encompass licences maintained by the Free Software Foundation (FSF) and licences accredited by the Open Source Initiative (OSI). The early free software movement started in 1983 with the launch of the GNU project maintained by FSF, as a response to over-privatising software via copyright protection. [53] Later, the OSI was established in 1998. The OSI certifies open source licences. To be qualified as a free software licence (by FSF) and as an open source licence (by OSI), licences must fulfil the requirements listed on the two websites. They might be slightly different from each other, but some basic values are shared, such as the freedom to run the software, the freedom to study how the software works, and the freedom to distribute the code and any modified version. Making source available is at the core of both. The "copyleft" feature created by Richard Stallman is at the core of FSF free software; it requires all modified and extended versions of the programme to be licensed under the same licence and made free. [54] The family of General Public Licences (GPL) maintained by FSF includes GPL v.2, GPL v.3, and LGPL, and they all have a "copyleft" clause. [55] They are all certified by OSI in the Open Source licences strand. However, "copyleft" is not a required element for accreditation by OSI.

3.1 Copyright licences

When the free software movement started, Richard Stallman deliberately created the term "copyleft" as opposed to the idea of massively having software code protected solely by proprietary copyright in the 1980s. [56] It is a general method for licensing a programme (or other work) under the same open source licence. This requirement extends to all modified versions in GPL licences. Apart from the GPL family licences run by FSF, among the most popular ten open source licences, the Mozilla Public License (MPL) and the Eclipse Public License (EPL) have similar features. The difference is that the "copyleft" clause is considered "weaker" in terms of the scope of the notion. To the extent that GPL family licences have and would require modification to be licensed back "as a whole", the latter two are limited to modifications on contributions. [57]

The term copyleft might have caused the impression that some open source developers are hostile to the concept of intellectual property rights, but it is now commonly recognised that open source code is subject to the same copyright protection that other software is. [58] Open source developers do not simply place their code in the public domain and renounce copyright and allow anyone to do anything with it without any restrictions. Open source collaboration nevertheless depends upon an explicit intellectual property regime (copyright and later also patent) that is different from the mainstream thinking of intellectual property rights, codified in a series of open source licences. [59]

"The essence of open source software is that source code is free." [60] The source code is open and the contributor remains the copyright owner of the software. [61] Such ownership does not lead to seeking of royalties as other proprietary software ownership would normally do. A particular open-source licence chosen by the contributor will define how those exclusive rights granted by copyright law, such as the right to have access, to use, to distribute, and to modify the programme will be "given away" when a recipient of the software agrees to the licence. A recipient will be free [62] to use the code if he or she agrees to the licence.

By no means is the freedom granted for no cost. Recipients must comply with the norms and obligations of an open source licence. For instance, apart from the basic features mandated by the open source definition, [63] other additional requirements can accompany a licence. As mentioned, a "copyleft" requirement appears in some open source licences. Others requirements, such as the patent retaliation clauses included in licences such as Apache v.2,[64] GPL v.3[65] and MPL v.2, [66] are also common. Copyright is defensively reserved to ensure that these norms valued by an open source licence are obeyed. In other words, once a recipient violates the obligations of a particular open source licence, the exclusive rights granted to him will be terminated, and a copyright infringement case could follow.

The right to free distribution is highly valued among open source communities. The freedom to distribute the source code or a modified version were embedded in the original four essential freedoms by FSF. [67] Correspondingly, the Open Source Definition required that

- "The licence shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources…"

- …The licence must allow modifications and derived works, and must allow them to be distributed under the same terms as the licence of the original software…

- … The licence may restrict source-code from being distributed in modified form only if the licence allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time…"[68]

It also contributed to the success of an open source project. Wide distribution leads to more participation and contributions to an open source project, which is key to the success of a peer-production innovation process.[69]

However, freedom of distribution, particularly of distribution of modified versions, can lead to the situation that is often termed "forking", when developers make changes to the source code and distribute it under the same name; in some cases, the modified version is generally recognised as having blurred or forked the original. Forking can occur constantly, thus making it difficult to stabilise a single practice. This problem has led to the main suspicion of open source code as a technical solution model (without further documentation) for general practice or even a standard. [70] Thus, an open source project generally cannot reach the same stability as a technical solution that a standard provides.

3.2 Patent right in open source software

Unlike IPR rules in SDOs that have given much attention to patent rights, copyright-based open source licences did not have patent grant clauses in their early generations. However, with the growing number of software-related patents being issued by patent offices worldwide, patents are now common in the software innovation industry. [71] Many open source licences today have included a patent provision with respect to patent licensing. Six of the ten most popular open source licences have an explicit patent clause.[72] All of them have adopted a licence mode to grant a patent right on an RF basis.[73] Similar to the freedom of using copyrighted work, RF patent granting does not simply mean no restrictions. It cannot be separated from the entire licence and other terms and conditions that should be satisfied and obeyed to enjoy the rightful use of the RF patent granting. Accompanied features apply. In particular, the so-called "patent retaliation" clause is the most relevant. The granted RF patent right terminates once the recipient initiates patent litigation against the patent right or the work delivered together with the patent right, depending upon the exact wording of the licence. After all, there is no such thing as a free lunch.

Therefore, the RF patent granting licence in open source licences cannot simply mirror the RF commitment practice in standard settings. The former requires compliance within the integrated open source licence, whereas the terms and conditions of an RF licence for SEPs were usually not specified when the commitment was made. However, interpretation of these norms in open source licences can cause disagreement; thus, one cannot say that the RF patent granting in open source licences appears to be clearer than a random commercial patent licence for embedded standards.

4. Perceived frictions

Having noted the different values and means of making copyright works and patent inventions available, note also that these differences do not necessitate conflicts. Both licence agreements relate to standards and open source licences have co-existed in business practice for many years. Nevertheless, the ICT landscape is changing in a way that will make the two have more interactions than previously. Future technologies will likely be software-driven. Moreover, OSS practice appears to be growing at a large scale and pervading the whole ICT market; whereas, SDOs used to be an arena in which proprietary technologies played the main role, the ubiquity of OSS in ICT has procured it a role in shaping future ICT standards. [74] In November 2017, the EU announced in its latest communication on "setting out the EU approach to Standard Essential Patents" that it would continue working on facilitating dialogues between these two systems. SDOs take a leading role. Major formal SDOs such as the ITU, ETSI and ANSI have recognised the need to explore approaches to utilise OSS. Workshops have been held in these SDOs. For instance, ETSI had two workshops in 2015 and 2016, respectively, to have invited members to come and discuss. [75] Particularly in the workshop of 2016, legal issues such as patent licensing and open source licences were identified as main considerations of the participants. Similar events in which stakeholders come and talk were also held at the ITU and ANSI in 2016, respectively. [76] These movements are also driven by industry players who support OSS and participate in SDOs or other activities in the standardisation landscape. [77] On the technical and business levels, standards and OSS encounter each other frequently. Licences addressing IPRs from both ecosystems currently have a much higher chance of meeting each other. A clear picture in their possible interactions on IPR issues will facilitate the process.

The current research will consider this issue in the context of different scenarios. A recent study by Lundell and Gamelielsson (2017) has depicted three basic scenarios based on the sequence of standards and open source, namely "standard first", 'software implementation first' and "standard and implementation of standard in parallel". [78] From an SSO's point of view, the question is whether the standards are out before utilising the open source approach and whether OSS has contributed to any of the standardisation work. Therefore, we categorised two major clusters from SDOs' perspective according to the time when an SSO is utilising OSS: one is in the implementation phase (including pre-standardisation activities that will influence the standardisation work), and the other one is in the standardisation phase. Such simplification is only for the explanation of the current paper; we admit that variations can occur in the real world.

4.1 Implementing SDOs standards in OSS

The first cluster in which an SSO can utilise OSS is to encourage open source implementation on a standard that has been produced by the SSO. SSO standards can benefit from open source implementation in several ways. As with every other implementation using other proprietary software, implementing on a standard is a means to help standards win market adoption. Open source communities are ubiquitous, which can increase the influence of the standard. In addition, open source communities are places in which innovation occurs; they are very likely to produce high-quality implementations that can help the standard to gain a leading market position.

We have witnessed several examples of OSS implementations on standards. Normally, these implementations occur in sectors that are closely connected to the internet. The standards addressed here are software standards, that is, standards that can be implemented by software programming. These standards range from formal standards to standards developed by informal fora. For example, the ISO 32000-1 standard, which defines the PDF format, has become a commonly used format that is "widely deployed in different types of innovative OSS projects including: PDF viewers (e.g., Evince), web browsers (e.g., Mozilla Firefox), office suites (e.g., LibreOffice) and business intelligence systems (e.g., Pentaho)". [79] Another example is the OpenBSC, an open source project for research purposes for learning and experimenting with the GSM standard maintained by ETSI. A less formal standard example is the UBL standard that that has generated many open source tools.[80]

However, some scholars have argued in the literature that IPR policies of SSOs in technologies that are related to these technical standards might impede such interactions. Concerns have been mostly expressed in the open source community about the FRAND commitment or any other royalty-bearing commitment SEP reading on standards and is known in the wider community as spreading "FUD" (fear, uncertainty and doubt). Those expressing this concern believe that "any royalty-bearing licence discriminates [against] open source implementations" because it threatens the viability of the upstream/downstream model of OSS. [81] First, it appears to be against the culture of open source developers to give much attention to any proprietary patents or to negotiate with a licensor and pay royalties. The open source culture is to some extent against strong protection on proprietary rights and more values collaboration and shared peer production. Some open source proponents even went further to say that, because the automatic sub-licensing practice is allowed in OSS, any patent licence, even when the royalty is zero, will place a significant burden on an open source developer because the existence of an SEP might impede the fluid flow of innovation in an open source project. [82]

Second and more importantly, research has been done to discover whether SEP licences subject to FRAND commitment (which is the implied choice of the ITU, ETSI and the IEEE) are compatible with all types of open source licences. Several previous studies have addressed the compatibility of FRAND licences with open source licences. Mitchell QC and Mason classified the open source licences accredited by OSI into three categories and concluded that only projects using GPL family licences would have uncertainties when implementing on standards with SEPs under FRAND. [83] A similar conclusion was made in Kesan's work. [84] Such a conclusion gives the impression that SEPs with a FRAND commitment will only be incompatible with terms and conditions stipulated by GPL licences. This position has been adopted by some SSOs, such as the ETSI. [85] Despite the impression given, it remains uncertain whether conclusions can be made at a theoretical level, because other reasons such as different business models might also influence the theoretical result. What the exact terms and conditions of an RF/FRAND patent licence are for SEPs is subject to the specific licence in practice. For example, a dispute once occurred between the Apache community and an RF licence offered by Microsoft. The community claimed that the latter was incompatible with the Apache v.2 licence. [86]

In the three SDOs, FRAND commitment is the licence commitment by default. Therefore, based on previous work, we now explore whether the features of open source licences are compatible with a FRAND-committed licence. [87] Three dimensions can be differentiated according to how an open source licence addresses copyright and patent right: (non)copyleft, patent clause and other norms. The following graph depicts the landscape in terms of patent grant and the copyleft feature. We have included the nine most popular licences in the graph.[88] Actually, for any other open source licence, a place can be found on the graph.


For the first category, an open source licence can go from non-copyleft (e.g., MIT) to weak copyleft (e.g., MPL), and to strong copyleft (e.g., GPL v.2). The copyleft feature was created by Richard Stallman, which requires any modification to the software to be licensed under the same licence. It creates reciprocity conditions for developers who join the technology pool. GPL family licences are all copyleft licences. There is a range between strong copyleft (such as GPLv.2 and v.3 licences) and the so-called weak copyleft licences. The difference lies in the scope that such reciprocity can reach. With strong copyleft, all derived works should be licensed back under the same licence. This may extend to SEP with FRAND commitment. It might render the technology sub-licensable via the same copyleft licence while forgoing a FRAND license. It may happen in cases when the open source licence itself does (e.g., GPL v.3) or does not (e.g., GPL v.2) contain a patent grant clause. However, for licences with weak copyleft or without copyleft, the open source licence is normally not likely to affect the patented technology already subject to a FRAND licence. Therefore, when we placed a licence on the graph, the ones close to the right side are very likely to be incompatible with a FRAND licence.

The second cluster concerns the patent grant clause in open source licences. Although royalty-free patent granting sounds very different from a usually royalty-bearing FRAND, it does not necessitate incompatibility with a FRAND licence. Suppose there is an open source project under the EPL, which contains an RF patent granting clause. If a developer wants to develop a technical solution but comply with a standard (from any of the three SDOs) that has an SEP X, he or she must seek a FRAND licence from the SEP holder and combine it with the source code from the EPL project. However, the licence of the SEP does not belong to the developer; he essentially need not license it under the EPL. Nor has he the right to do so, because he is not the right owner. If he combines his work with the patented technology, what he nonetheless must do is license his contributions under the RF patent licence, which does not extend to the original SEP. Therefore, the patent grant clause itself is not definitely incompatible with the FRAND commitment as the first impression gives. However, as we said, there are other features (e.g., the so-called patent retaliation clause in Apache v.2) in many of these open source licences that might cause other rights and obligations among licensors and users that must be analysed on a case by case basis, which cannot be presented exhaustively in this preliminary study.

Apart from compatibility issues with FRAND conditions, for certain standards, it can also be true that it is difficult to clarify other information, such as the clarity of the patent database for use of a specific standard, which implies significant risks for an organisation that implements such a standard in software. [89] For instance, a case study focussing on ISO standards (including PNG, JPEG 2000, and TIFF/EP) shows that organisations that voluntarily declared to have controlled essential patents embedded in standards are occasionally not easy to reach when researchers try to write letters asking for clarification on conditions concerning these patents. [90]

It follows that these uncertainties for implementation in software can cause litigation risks.[91] These risks remain in all types of implementation. However, compared with proprietary implementations, OSS might be more vulnerable to patent litigation.[92] An open source developer is more likely to be deterred from implementing a standard embedded with unclear IPR terms because they might lack time, incentives or financial support to address such a risk of litigation. [93] Such uncertainties impede open source communities' enthusiasm to endorse and implement the standard. A famous example was the breakup between the SenderID standard and the Apache community, in which the Apache community identified that the RF licence offered by Microsoft had several incompatibilities with the Apache v.2 licence. The ultimate result was the dissolution of the MARID Working Group on the standard in IETF at that time. [94]

Despite the importance of open source implementations and the uncertainties the current FRAND commitment entails, at the organisational level, few SSOs have special rules for open source implementations. In the ITU, IEEE and ETSI, open source implementations have been recognised as a source to promote their standards, but this recognition can only be traced in some policy documents. However, in some situations, ad hoc measures have been taken individually by companies to reduce such uncertainty for open source implementers. These measures include adding a patent disclaimer (e.g., patent disclaimer in OpenBSC project) or a "covenant not to sue" committed to by the patent owners (who are normally members of the SSO that has an interest in promoting the use of the standard/technology). A good example of such a "covenant not to use" is Microsoft's amended version of its Royalty-Free Sender ID Patent Licence Agreement provided to open source users of the SenderID standard to address the concerns that lead to the dissolution of the MARID Working Group. [95] Other examples are the Open Specification Promise (OSP) made by Microsoft, Interoperability Specifications Pledge (ISP) from IBM and OpenDocument Patent Statement of Sun Microsystems.

One SSO, the Organisation for the Advancement of Structured Information Standards (OASIS), has integrated such a practice at an organisational level, providing NAC as a track of choice for a technical committee to choose. Some argue that it has great application in the context of software-oriented standardisation (the main work of OASIS) but not for the telecommunications or consumer electronics industries, in which large patent portfolios combine with R&D-intensive hardware. Nevertheless, with the growing role of software in the standardisation work (as we are discussing in the current research context) of the ITU, IEEE and ETSI, whether there will be any changes remains to be seen.

4.2 Usage of OSS in developing SDOs standards

Compared with the OSS implementation scenarios, perhaps the more complex situation is when SDOs try to utilise open source in their standardisation processes. This trend has been driven by internet of things (IoT) technology development, in which many devices are interconnected to perform in a connected ecosystem. Many of these technologies are realised through software. Aiming for more efficient and quick standardisation activities in these areas, SDOs have begun exploring incorporating open source software into the standardisation process. For instance, as the key coordinator for standardisation work in the ICT, the ITU organised several workshops to facilitate discussions in the area. Discussions about this issue have been associated with the ETSI since 2005. [96] In 2016, the ETSI launched an open source project called the Open Source MANO, which is in alignment with the ETSI NFV standardisation work, as a first large step in utilising open source. The IEEE has defined a project that is using open source - IEEE P2413™, Draft IEEE Standard for an Architectural Framework for the Internet of Things (IoT). [97] The essence of this approach is that an SDO's specifications do not definitely come out before any (open source) implementations. The iterative approach of open software architectures helps SDOs to renew the focus on implementation rather than exclusively on specification development. After implementations (primarily from an open source project) have been developed (or are under development), specifications are used to stabilise key functions. As has been noted elsewhere, the utilisation of open source in SDOs occurs in two simplified sub-scenarios: using source code in specifications directly, and specifications of adopted functions that build on an open source project.

4.2.1 Direct use of running code

Direct use of software code as part of standard specifications was not common in standardisation work when hardware was the main focus in these three SDOs. For instance, one of ETSI's successful standards was the GSM standard. Specifications related to these standards usually only specify the required functions, leaving implementers to realise these functions. Conversely, in sectors in which software is active, code can be part of the standard. The internet standards have many standards that include code to define interface or performance, e.g., the World Wide Web Consortium's (W3C's) XML 1.0 Specification. Software is defining many emerging technologies. For instance, software-defined networking (SDN) technology is an approach to cloud computing. The direct use of software code in technologies will become more common than previously.

In a situation of a direct use of open source code, copyright issues around standard specifications (as we explained in part 2) become relevant. Based on the understanding of the copyright policy for specifications (ITU, ETSI and IEEE) and the software guidelines (only ITU and ETIS have these), several discrepancies are worth noticing.

Ownership : As we have discussed in part 2, like most SDOs, the three organisations claim ownership of the copyright of specifications. However, in an open source project, developers remain as right holders. It is uncertain whether SDOs can claim the ownership if code is included and constitutes a large part of a specification. In other words, SDOs must choose between maintaining the position of holding the ownership and making changes to adjust to the inclusion of OSS. Which choice to make depends upon many aspects, including for example the technical role of the OSS project in the specifications and the governance structure of the SDO. In an open source project (OSM) launched by the ETSI in 2016, the copyright of any source code is maintained through transfer of copyright to the OSM project. [98] Nevertheless, some also argue that, if open source implementations have specified most of the functions, the utility of a specification appears to be fading away. [99] Therefore, the value of the copyright ownership of a specification might decrease accordingly.

Distribution: Putting aside the ownership issue, once code has been included, how to distribute such specifications also presents frictions. ITU and ETSI Software Guidelines can apply to direct code utilisation. However, its effectiveness relies on contributors' consent to the guidelines. These guidelines give options to contributors to either transfer the ownership or grant a software licence, which could solve the ownership issue, but might not solve the different terms with respect to distribution between the software guidelines and an open source licence. The problem then lies in distribution if the software guideline and the open source license are valid at the same time in a specific situation. First, the distribution of a specification produced by an SDO is permitted, but the modification to the specification and the distribution of such modification is largely limited. However, an open source licence would give the largest freedom for modification and distribution. Any restrictions would be considered contrary to the value of OSS. Second, even when we focus on the code part instead of the whole specification, the right granted by such guidelines to copy, modify and distribute are only limited to specific situations listed in the guidelines. Such restrictions are again contradicting the freedom of distribution guaranteed by an open source licence.

Lack of specific rules: If there is a need for the ITU and ETSI to make clear which might prevail, the software guidelines or a particular open-source licence, the lack of any IPR rules governing embedded software in IEEE poses more uncertainties. Designing specific rules to govern code inclusion might better equip the IEEE for the upcoming revolution brought by software-enabled technologies. In fact, SDOs accredited by American National Standard Institute (ANSI) [100] might all lack particular rules for code ownership and distribution in specifications because the ANSI appears to discourage software from being embedded in specifications in its guidelines. [101] The only applicable rules will be the copyright rules over specifications, by which the distribution of code embedded in the specification will be substantially restricted, largely impeding the utilisation of open source code in the standardisation process.

4.2.2 Code becomes essential

If the open source code included in the specifications becomes an essential copyright, it will become more imperative to address the copyright issue, as we discussed in section 3.2.1.

Lack of specific rules: According to our discussions in Part 2, none of the three SDOs thus far have specific rules with respect to essential copyright. The ETSI explicitly objects to such ideas by emphasising in its IPR policy that software embedded in specifications shall not be made mandatory for compliance.[102] Again, SDOs accredited by ANSI have been discouraged from including software in standards, let alone letting them be essential. Arguably, this position must be updated to keep pace with the virtualisation era, because code becoming an essential part will become more common. In some other SSOs, software code already constitutes almost the entire part of a specification. For instance, in RFC 8072 of IETF, the whole specification contains one long programme, but it is almost the entire main body of the specification.[103]

FRAND commitment: Because essential code can be considered one type of essential intellectual property right, in the absence of specific rules, another approach refers to the same clause for patent rights. For instance, in ETSI, the essential claims subject to FRAND licence terms used the term "intellectual property rights",[104] which is sufficiently broad to encompass both copyright and patent right. The same is true in SEP cases; implementers could seek a FRAND copyright licence - which might bear royalties - to copy the standard (code). Apparently, such licence mode contract includes the copyright licence of an open source licence. If open source code is included as essential code, it already comes with obligations stipulated by a particular open-source licence. Therefore, if it is to be treated as an essential intellectual property right, whether FRAND licence terms or open source licences will prevail is unclear.

4.2.3 Functions built on open source code

If code is not directly used as (part of) technical specifications, functions derived from open source code could be adopted in a standard. An empirical study on RDFa standards and a Drupal open source project has shown that, when standardisation activities are closely connected with an open source project, overlapping functions are very likely to occur in these parallel developing situations due to constant information exchange and overlapping participators. [105] Here, we only discuss extreme cases in which some of these functions actually include patents derived from open source code and in which they become SEPs to implement the standard.

Potential application of RF license to SEPs: When patents are based on open source code or derived from an open source project, how these patents will be licensed depends upon the related open source licence. If an open source licence does not contain any patent clauses, such as the MIT or BSD, the patent issue could only be left to the policies of a standards body. In our case, as has been mentioned several times, the ITU, IEEE and ETSI all require the patent owner to at least commit to granting the SEPs on FRAND terms. However, if a licence contains a patent clause, the patent right is granted subject to the open source licence; usually, it will be an RF licence (as 6 of 10 of the most popular open source licences are [106]). The FRAND patent policy in our three SDOs will then be "forced" to be replaced by an RF patent policy for these SEPs. In the current IPR policies of the three SDOs, such an issue has nonetheless not been considered. Even when an SDO makes the issue explicitly about the application of a FRAND licence to these SEPs, it might not work because if implementers can already have an RF licence once they agree to the open source licence, there will be less incentive for them to seek another FRAND licence from the patent owner.

Difference from OSS implementations : This sub-scenario is different from the OSS implementation scenario we discussed in section 3.1. The FRAND patent policy is not definitely applicable to SEPs in this sub-scenario compared with the open source implementation situation in section 3.1. When FRAND is the rule by default, much has been discussed about the compatibility between a FRAND licence and an open source licence. Here, the issue is more about which patent granting should prevail, the FRAND commitment or the RF granting from open source licences (if one is held). Lacking specific SDO rules, it appears that open source terms will clearly be an applicable rule. However, it has been stated that the FRAND commitment serves as a balance between the benefits of society to have patents and the economic interests of patent holders. [107] FRAND gives room to innovators to collect royalties, which incentivises them to contribute their patented technologies to standards. It is questionable whether such a replacement of RF for these SEPs will be embraced by SSO members.

In addition to the RF granting, another concern is the cascade effects of open source licences. Although enjoying the patent for free, implementers must be bound to other restrictions by an open source licence. Some norms are not aligned with the current practice of SDOs. For instance, open source licences contain a "patent retaliation" clause that generally discourages recipients from bringing patent litigation against the "work" that incorporates the patented contribution; otherwise, the patent right will be terminated. This clause restrains implementers from filing a lawsuit if they find their patents (included in the same work) being infringed.

5. Conclusions

Perhaps a sense of difference could already be perceived when one considers the two abbreviations, SSO and OSS. Raymond used the term "bazaar" to describe the development style of OSS. [108] Krechmer borrowed it and compared SSOs and OSS as "libraries" and "bazaars", [109] indicating the different values and bases underlying the two. The metaphor of "libraries" suggests the value of a standard to society of its vetted and maintained knowledge that is publicly available, whereas the metaphor of "bazaars" represents a marketplace full of new ideas with the freedom to change and evolve.[110] In the digital world, which is mostly software-driven, we have witnessed the libraries taking a liberal form. Standardisation activities are being taken as forms of open source software. [111]

Interactions between open source and standards present both old and new situations and variations that challenge the current IPR framework of these standardisation bodies. We have shown that in the current IPR framework of the ITU, ETSI and IEEE, frictions do exist in different interaction scenarios with OSS, which poses risks and impedes these organisations from fully utilising OSS.

Our preliminary legal analysis shows that FRAND licences do not necessarily conflict with most open source licences (except GPL family licences). However, to encourage OSS implementations, SDOs would benefit from having specific terms at a governance level oriented towards open source implementation. SDOs could learn from many practices that have been performed by companies in the industry and could consider bringing them to a centralised level in their governance structure. For instance, the "Covenant not to sue" made by some SEP holders to remove FRAND license obligations for open source implementations could be a practice to examine.

More importantly, combining the agility of open source with the efficiency and interoperability of standards will be the path forward for the industry.[112] The focus on interactions between open source and standardisation will focus more on utilising open source in standardisation work. SDOs must be prepared for the utilisation of open source, whether including code directly or including functions built on open source code. The essence is that specifications do not necessarily come out before any other implementations. As we have shown, SDOs such as IEEE that do not have a software guideline would benefit from establishing new rules. For those who already have done some work, such as the ITU and ETSI, an attentive update will be appropriate to embrace the open source working process in developing future standards. One precedent that could be learned is from the IETF, in which the SDO specifies that any source code included in a standard must be made available under the BSD open source licence, which applies both to essential and non-essential copyrights in software code.

However, one should not expect a one-size-fits-all answer. Detailed rules should be warily designed in alignment with goals of the SDO and to what extent it would like to embrace OSS. For instance, in April 2016, the ETSI launched an open source project called Open Source MANO (OSM) under the open source licence Apache v.2 to develop an open source management and orchestration software stack aligned with the ETSI NFV Network Function Virtualisation (NFV) standard. This open source project is hosted by an SDO. It defined its goals for the open source project and drew the line between the project and ETSI standards in a document called the Terms of Reference (ToR). According to this document, the OSM focusses on developing implementations and providing testing to ETSI standards, and there will be no code "for direct inclusion into" an ETSI specification. This document at some point excluded one of the scenarios we have discussed, which removes some of the potential issues, possibly because ETSI used to work in telecommunication sectors in which technologies are heavily reliant on hardware. Although the dependency upon hardware is shifting, this shift might take time. Therefore, using direct, running open source code has not been considered in this first move towards open source. We could not find any data from the ETSI explaining the choice, but it surely bears full consideration from the organisation. Nevertheless, what matters for an SDO is to realise the issue, conceive its own goal and design the model to incorporate OSS accordingly.

Appendix A

Ten licenses accredited as "popular" by OSI [113]


Patent granting

Features in a nutshell

Apache License 2.0 (Apache-2.0)


Royalty free

A permissive license contains an RF patent granting clause; it has a patent retaliation clause.

3-clause BSD license (BSD-3-Clause)



A permissive license allows royalty for patent rights appropriation.

2-clause BSD license (BSD-2-Clause)



A permissive license allows royalty for patent rights appropriation.

GNU General Public License 2.0 (GPL 2)



A restrictive license that does not have an explicit patent granting clause. [114]

GNU General Public License 3.0 (GPL 3)


Royalty free

A permissive license contains an RF patent granting; strong copyleft.

GNU Lesser General Public License (LGPL)


Royalty free

Similar to GPL 3, but it has more permissions in the sense that it allows proprietary integration without strong copyleft

MIT license (MIT)



A permissive license allows royalty for patent rights appropriation.

Mozilla Public License 2.0 (MPL-2.0)


Royalty free

A permissive license contains an RF patent granting clause; it has a patent retaliation clause; weak copyleft only extends to rights licensable under the project.

Common Development and Distribution License version 1.0 (CDDL-1.0)


Royalty free

A permissive license contains an RF patent granting clause; weak copyleft only extends to rights licensable under the project.

Eclipse Public License version 2.0 (EPL)


Royalty free

A permissive license contains an RF patent granting clause; weak copyleft only extends to rights licensable under the project.

[1] PhD candidate, Tilburg Institute for Law, Technology, and Society (TILT), Tilburg University in the Netherlands. The PhD project is sponsored by the China Scholarship Council, but all ideas are author's own. The paper was first presented at the "Challenges for a data-driven society" ITU Kaleidoscope academic conference, Nanjing, China, 27-29 November 2017, The author would like to thank the invaluable comments on the first presented paper by Mr. Mostafa Hashem Sherif, Mr. Ken Krechmenr and all the attendees of the ITU Kaleidoscope 2017.

[2] European Telecommunications Standards Institute, 'Cloud Standards Coordination Phase 2 ; Cloud Computing Standards and Open Source ; Optimizing the Relationship between Standards and Open Source in Cloud Computing' (2016) 1 1.

[3] Javan Erfanian and others, 'Network Functions Virtualisation - White Paper on NFV Priorities for 5G Network Functions Virtualisation (NFV)' (2017) < >.

[4] ITU, 'Joint ITU-NGMN Alliance Workshop "Open Source and Standards for 5G"' (2016) < > accessed 27 September 2017.

[5] European Commission, 'COM (2017) 712 Final - Communication from the Commission to the European Parliament, the Council and the European Economic and Social Committee - Setting out the EU Approach to Standard Essential Patents'. Section 5.

[6] Björn Lundell and Jonas Gamalielsson, 'On the Potential for Improved Standardisation through Use of Open Source Work Practices in Different Standardisation Organisations: How Can Open Source-Projects Contribute to Development of IT-Standards?' in Kai Jakobs and Knut Blind (eds), EURAS Proceedings (Aachen: Verlag Mainz 2017) < > accessed 26 September 2017.

[7] Jay P Kesan, 'The Fallacy of OSS Discrimination by FRAND Licensing : An Empirical Analysis' [2011] Illinois Public Law and Legal Theory Research Paper Series. ; Iain G Mitchell QC and Stephen Mason, 'Compatibility Of The Licensing Of Embedded Patents With Open Source Licensing Terms' (2011) 3 International Free and Open Source Software Law Review 25 < >.

[8] Björn Lundell, Jonas Gamalielsson and Andrew Katz, 'On Implementation of Open Standards in Software: To What Extent Can ISO Standards Be Implemented in Open Source Software?' (2016) 13 International Journal of IT Standards & Standardization Research 47 < >.

[9] Jorge L Contreras and Andrew Updegrove, 'A Primer on Intellectual Property Policies of Standards Bodies', Effective Standardization Management in Corporate Settings (IGI Global 2016).

[10] SDOs are SSOs that which refers to organisations that have been officially recognised by a certain authority and have committed to comply with the five founding principles set out by the World Trade Organization (WTO).

[11] ITU, 'Joint ITU-NGMN Alliance Workshop "Open Source and Standards for 5G"' (n 4).

[12] 'ETSI - Workshop on Open Source and Standardization: Legal Interactions' (2016) < > accessed 31 March 2017.

[13] ANSI, 'Open Source, Open Standards, Open Minds: ANSI Announces Free Event on April 15 in Washington, DC' (2016) < > accessed 27 September 2017.

[14] Note that, although in the list, General Public License (GPL) was presented as one type of license, because of the difference between GPL v.2 and GPL v.3 in some key features, we treat them separately. Therefore, although the website only listed nine licenses, we count the number as ten in total.

[15] OSI, 'Open Source Licenses by Category' < > accessed 27 September 2017.

[16] ITU, 'Understanding Patents, Competition & Standardization in an Interconnected World' (2014).

[17] Rudi Bekkers and Andrew S Updegrove, 'A Study of IPR Policies and Practices of a Representative Group of Standards Setting Organizations Worldwide' [2012] SSRN Electronic Journal 1 < >.

[18] Bekkers and Updegrove (n 17).

[19] See ITU, 'Disclaimer and Copyright' < > accessed 24 August 2018.

[20] See ETSI, 'Intellectual Property Rights (IPRs)' < > accessed 24 August 2018. states, "Copyright of our standards belongs to ETSI."

[21] See "The IEEE owns the copyright in all Work Products." Article 7.2, IEEE, 'IEEE-SA Standards Board Bylaws' <>.

[22] DIN, 'Copyright Status of DIN Standards Confirmed' (2015) < > accessed 24 August 2018.

[23] Case C ‑613/14 James Elliott Construction Limited v Irish Asphalt Limited judgement .

[24] European Parliament, 'Resolution of 4 July 2017 on European Standards for the 21st Century (2016/2274(INI))' (2017) < > accessed 24 August 2018.

[25] Bekkers and Updegrove (n 17).

[26] See discussions about network effects: Michael L Katz and Carl Shapiro, 'Systems Competition and Network Effects' (1994) 8 Journal of Economic Perspectives 93 < >.

[27] Lundell, Gamalielsson and Katz (n 8). Also see Contreras and Updegrove (n 9).

[28] Contreras and Updegrove (n 9).

[29] Annex A, ITU Software Copyright Guidelines 2012.

[30] Bekkers and Updegrove (n 17).

[31] Article 2.1 of the ITU Software Copyright Guidelines (n 29) listed several situations in which it is technically appropriate to include software in an ITU Recommendation: "To enhance the description of functionality required to be implemented in products or services for those products or services to conform to the Recommendation; as an example of how required functionality might be achieved - To test an implementation for conformance with the required functionality; to describe data structures, schema, ASN.1, EBNF grammar specifications, etc." None of them relate to compliance with ITU standards. Additionally, the ETSI IPR policy explicitly excluded this possibility by stating that "……where SOFTWARE is included in any element of a STANDARD or TECHNICAL SPECIFICATION, there shall be no requirement to use that SOFTWARE for any purpose in order for an implementation to conform to the STANDARD or TECHNICAL SPECIFICATION", see Article 9.2, ETSI, 'ETSI Intellectual Property Rights Policy' (2016) < > accessed 22 February 2017.

[32] ANSI is the association that certifies SDOs to develop American standards.

[33] ANSI (n 13).

[34] Article 10, WTO, Trade-Related Aspects of Intellectual Property Rights. "1. Computer programs, whether in source or object code, shall be protected as literary works under the Berne Convention (1971)……."

[35] For example, see investigations by the European Commission on Rambus, in which the EC claimed that Rambus had infringed Article 102 TFEU by abusing a dominant position in the market for Dynamic Random Access Memory (DRAM). The EC considered that Rambus has engaged in a "patent ambush" by hiding its SEPs relating to standards produced by a standard setting organisation called JEDEC and sought for royalties thereafter. EC, '"Commission Confirms Sending a Statement of Objections to Rambus", MEMO/07/330' < > accessed 19 September 2018.; also see the Huawei v. ZTE judgement by the ECJ, in which the court was asked to decide whether injunctions was available for Huawei's use of ZTE's SEPs. C-170/13.

[36] Cases can occur when an SSO requests its members to transfer the patent right, or, in standards that are supported by patent pools, the patent rights are granted in a bundle license by the undertaking that operates the pools. See discussions in Bekkers and Updegrove (n 17).

[37] Cases can also occur when a third-party claims patent right after a standard has been adopted. See discussion in Bekkers and Updegrove (n 17).

[38] ITU, 'Understanding Patents, Competition & Standardization in an Interconnected World' (n 16).

[39] Mark A Lemley, 'Intellectual Property Rights and Standard-Setting Organization' (2002) 90 California Law Review 1889.

[40] Joseph Farrell and others, 'Standard Setting, Patents, and Hold-Up' (2007) 74 Antitrust Law Journal 603.

[41] Mark A Lemley and Carl Shapiro, 'Patent Holdup and Royalty Stacking' (2007) 85 Texas Law Review 1991 < >.

[42] C-170/13 (n 35).

[43] Other license commitment adopted by SSOs can be Royalty Free (RF) or Non-Assertion Covenant (NAC). Some empirical studies on SSO patent license rules: Justus Baron and Tim Pohlmann, 'Mapping Standards to Patents Using Databases of Declared Standard-Essential Patents and Systems of Technological Classification' (2015). ; Brad Biddle, Andrew White and Sean Woods, 'How Many Standards in a Laptop? ( And Other Empirical Questions )', Proceedings of the 2010 ITU-T Kaleidoscope Academic Conference < >.; Mark A Lemley, 'Intellectual Property Rights and Standard-Setting Organization' (2002) 90 California Law Review 1889. ;

[44] Annex 2, ITU, 'Guidelines for Implementation of the Common Patent Policy for ITU-T/ITU-R/ISO/IEC'.

[45] Article 6, IEEE (n 21).This approach is equivalent to the "Non-Assertion Covenant (NAC)" term in the academic literature; see Rudi Bekkers, Eric Iversen and Knut Blind, 'Emerging Ways to Address the Reemerging Conflict between Patenting and Technological Standardization' (2012) 21 Industrial and Corporate Change 901.

[46] Article 6, ETSI, 'ETSI Intellectual Property Rights Policy' (n 43).

[47] David McGowan, 'Legal Implications of Open-Source Software' (2000) 2001 University of Illinois Law Review 241 < > accessed 9 July 2017.

[48] See Dennis W Carlton and Allan L Shampine, 'An Economic Interpretation of Frand' (2013) 9 Journal of Competition Law and Economics 531.

[49] EC, 'Guidelines on the Applicability of Article 101 of the Treaty on the Functioning of the European Union to Horizontal Co-Operation Agreement (2011/C 11/01)' 1. Para 289

[50] ITU, 'Understanding Patents, Competition & Standardization in an Interconnected World' (n 16).

[51] ITU, 'Understanding Patents, Competition & Standardization in an Interconnected World' (n 16).

[52] Article 6, IEEE (n 21).

[53] Alessandro Nuvolari, 'Open Source Software Development : Some Historical Perspectives *' [2003] Technology Management.

[54] GUN, 'What Is Copyleft?' < > accessed 31 March 2017.

[55] The GPL v.2 and GPL v.3 are listed in the "popular and widely-used or with strong communities" identified by the OSI.

[56] McGowan (n 47). P 21-22

[57] Steven Weber, The Success of Open Source (Harvard University Press 2004).

[58] McGowan (n 47).

[59] McGowan (n 47).

[60] Weber (n 57). P5

[61] In some cases, an association or a foundation that launched an open source project can claim to own the copyright; legally speaking, the copyright is transferred from contributors to the owner of the project.

[62] "Free" in this context means "freedom" instead of zero price. A fee may occur when transactions of such software occur, although the price is not paid for the copyright per se. See Richard Stallman, 'Why Software Should Not Have Owners - GNU Project - Free Software Foundation (FSF)' < > accessed 17 March 2017.

[63] 'The Open Source Definition | Open Source Initiative' < > accessed 31 March 2017.

[64] Article 3, Apache v.2

[65] Article 11, GPLv.3

[66] Article 5.2, MPL v.2

[67] GUN, 'What Is Free Software' < > accessed 16 March 2017.

[68] Eric Raymond, 'The Cathedral and the Bazaar' (2005) 2 First Monday 1.

[69] Weber (n 57).

[70] Ken Krechmer, 'Cathedrals, Libraries and Bazaars' < > accessed 28 September 2017.

[71] Dan L Burk and Mark A Lemley, The Patent Crisis and How the Courts Can Solve It (University of Chicago Press 2009) < > accessed 8 June 2017.

[72] A debate exists concerning an implied RF patent granting of the GPL v.2, but we do not count the license here because the terms in GPL v.2 did not make this granting explicit, and it may be subject to different interpretations of the license. See Laura Majerus and Adam Pugh, 'Potential Defenses of Implied Patent License Under the GPL' .

[73] See a summary in Annex A.

[74] David Ward, 'Open Standards, Open Source, Open Loop - IETF Journal' (IETF Journal, 2015) < > accessed 4 September 2018.

[75] 'ETSI - ETSI Summit on Standardization and Open Source' (2015) < > accessed 3 April 2017. (2015); 'ETSI - Workshop on Open Source and Standardization: Legal Interactions' (n 12). (2016).

[76] ITU, 'Joint ITU-NGMN Alliance Workshop "Open Source and Standards for 5G"' (n 4). ANSI (n 13).

[77] Faya Ly, 'Carrier Network Virtualization 2016: The Future of 5G and System Integrators' (Radisy, 2016) < > accessed 8 June 2017. Ward (n 74).

[78] Lundell and Gamalielsson (n 6).

[79] Jonas Gamalielsson and Bjorn Lundell, 'Experiences from Implementing PDF in Open Source: Challenges and Opportunities for Standardisation Processes', 2013 8th International Conference on Standardization and Innovation in Information Technology (SIIT) (IEEE 2013) < > accessed 14 August 2017.

[80] Lundell and Gamalielsson (n 6).

[81] The analogy of the upstream/downstream model uses the mental image of a large river that collects the water from many smaller and smaller tributaries (the communities) and delivers it to the ocean (the users). Key tenets of the upstream/downstream model are the non-negotiability of the free software licensing terms and the community governance norm.

[82] Georg CF Greve, 'Analysis on Balance: Standardisation and Patents' (2008) < >.

[83] Mitchell QC and Mason (n 7).

[84] Kesan (n 7).

[85] For instance, a report issued by ETSI in 2005 only mentions the concerns about implementation by open source projects subject to GPL licenses.

[86] See description of the case in ETSI, 'Open Source Impacts on ICT Standardization' (2005).

[87] As has been noted elsewhere, in practice, a FRAND license may differ with respect to different terms and conditions.

[88] See Appendix A for detailed information.

[89] Lundell, Gamalielsson and Katz (n 8).

[90] Lundell, Gamalielsson and Katz (n 8).

[91] Lundell, Gamalielsson and Katz (n 8).

[92] Josh Lerner and Jean Tirole, 'The Economics of Technology Sharing: Open Source and Beyond' (2005) 19 Journal of Economic Perspectives 99.

[93] Lerner and Tirole (n 92).

[94] ETSI, 'Open Source Impacts on ICT Standardization' (n 86). P28-29

[95] ETSI, 'Open Source Impacts on ICT Standardization' (n 86). P28-29

[96] ETSI, 'Open Source Impacts on ICT Standardization' (n 86).

[97] 'What Is Open Source, and Why Is IEEE Involved? - Beyond Standards' < > accessed 21 September 2018.

[98] The project explicitly excluded any inclusion of open source code into specifications. See Article 4, ETSI, 'Terms of Reference of the Open Source Group on "Open Source MANO"' 1.

[99] Ly (n 77).

[100] American National Standards Institute (ANSI) does not produce standards itself, but it serves as an administrator and coordinator of the United States private sector voluntary standardisation system. SDOs meet certain procedural requirements set by ANSI to be accredited as producing American National Standards (ANS).

[101] ANSI (n 13).

[102] Article 9.2, ETSI, 'ETSI Intellectual Property Rights Policy' (n 43).

[104] This general classification is only for theoretical discussions here; as Bekkers and Updegrove have noted, "…patents and copyrights are sufficiently different that using the same language to address both types of IPRs provides a less than ideal result". See Bekkers and Updegrove (n 17).

[105] Jonas Gamalielsson and others, 'On Organisational Influences in Software Standards and Their Open Source Implementations' (2015) 67 Information and Software Technology 30 < >. Mentioning the similar proportions of issues raised by the top raisers in W3C RDFa standards and Drupal open source project of their contribution.

[106] See Appendix A; also, in an empirical research conducted by Kasen in 2011, 42 out of 67 open source licenses contain an RF patent granting clause, see Kesan (n 7).

[107] Lemley (n 39).

[108] Raymond (n 68).

[109] Krechmer (n 70).

[110] Krechmer (n 70).

[111] 'Open Standards, Open Source, Open Loop - IETF Journal' < > accessed 24 August 2018.

[112] Ward (n 74).

[113] See OSI (n 15). Note that only nine license names are listed in OSI's official page, because the GNU General Public License (GPL) is used to encompass both GPL 2 and GPL 3. Here, we separated the two and turned the total number into ten. Key changes were made between GPL 3 and GPL 2, but both are now widely used in open source projects, according to some surveys, e.g., see 'Top Open Source Licenses | Black Duck Software' <> accessed 31 March 2017.

[114] There is an argument that GPL contains an implicit royalty free granting for patent, see Majerus and Pugh (n 72). 2006.