Implementing IT Standards in Software: challenges and recommendations for organisations planning software development covering IT standards

Implementing IT Standards in Software: Challenges and Recommendations for Organisations Planning Software Development Covering IT Standards

Björn Lundell, Jonas Gamalielsson and Andrew Katz [1]

Abstract

To develop software based on standards, developers will often require patent licences for the patents which impinge on those standards. This paper reports on an investigation into acquiring patent licences required to implement three specific formal standards in software, namely ISO 32000-1 (a standard based on PDF 1.7), ISO/IEC 29500 (Office Open XML), and ISO 20022 (a standard for international financial business communication). In particular, the licences were requested in the context of implementation of those standards in open source software. We elaborate on the challenges of seeking to obtain those rights, providing examples. Findings show evidence of significant practical difficulty of obtaining the necessary licences, and we examine the implications of that evidence. We make specific recommendations both in terms of the steps which an organisation should take into account prior to considering implementing such a standard in software, as well as recommendations to changes in policy and practice aimed at reducing friction in implementing such standards in open source software.

1. Introduction

There are a number of challenges related to obtaining patent licences required to implement various IT standards in software. The paper identifies a number of such challenges and presents a set of recommendations which may aid organisations in their analysis and review of patent licence conditions necessary for implementation of a specific standard in software. Related to each recommendation, illustrative examples are presented by drawing from observations related to the process of trying to obtain patent licences.

In several countries use of specific standards is promoted through region-wide and nation-wide policies (e.g. OTD, 2011; Geradin, 2013; Choung et al., 2012; EU, 2017a; Liu et al., 2018) and there is research addressing IT standards which elaborates different motivations, challenges, and implications from implementation of IT standards in software (e.g. Ghosh, 2005; Lundell et al., 2015; Kesan and Hayes, 2014). Previous research reports on different motivations for implementation of IT standards in software and elaborates a number of undesirable and desirable effects. Such motivations and effects include strategies and risks related to different types of lock-in (e.g. Chia, 2012; Geradin, 2013; Kesan and Hayes, 2014; Lundell et al., 2017; Miller, 2007), challenges concerning interoperability (e.g. Aliprandi, 2011; Ghosh, 2005; Kesan and Hayes, 2014; Larouche and Van Overwalle, 2014; Shah and Kesan, 2012), and opportunities for addressing longevity of systems (e.g. Blondelle et al., 2012; Fanning, 2008; Lundell et al., 2011; Lundell et al., 2017; Rothenberg, 1999). Further, in acknowledging that different views and experiences have been reported concerning how patents impact (and impinge) on IT standards, it seems clear that many practitioners and scholars would tend to agree with the view that the role of patents related to standards has caused significant controversy and many disputes amongst stakeholders involved in (and affected by) the broader standardisation ecosystems. For example, as observed by Graham et al. (2013, p. 31): ‘Most IP issues arising from technical standards concern patents. It is obvious that technical standards are likely to comprise features that are the subject of patents, and there is little point developing a standard if its implementation can be blocked by a patent holder.’

To promote interoperability and competition, some countries mandate use of open standards as part of national policy (e.g. Netherlands, 2007; UK, 2015). Further, the framework agreements established by the Swedish National Procurement Services (NPS, 2016) require that when an organisation includes a reference to a standard when expressing a mandatory requirement in a public procurement project, the standard referenced must fulfil the definition of an open standard as defined by the EU (2004). In addition, it should be noted that the United States Department of Defense refers to the same definition when stressing that adopted open standards should ‘at least’ meet the definition of an open standard as defined in the European Interoperability Framework version 1.0 (OTD, 2011, p. 20). At the same time, the view that ICT standardisation needs an IPR policy which is ‘based on FRAND licensing terms’ (EC, 2016, p. 13) has been stressed in the EU amongst policy makers, even though there are also seven EU members which express concerns and instead emphasise the importance of Open Standards ‘relying on Royalty Free intellectual property models in regard to software’ (Permanent Representatives Committee, 2016, p. 2). Use of different IPR models and licensing terms (e.g. Royalty Free or different FRAND[2] terms) for provision of standards in the IT field has been an issue which has triggered extensive discussions and controversy amongst policy makers, practitioners and researchers over the years (e.g. Contreras, 2015; EC, 2012; Kappos, 2017; Kesan and Hayes, 2014; Li, 2018; Lindberg, 2019; Lundell et al., 2015; Phipps, 2019).

During the 21st century, the number of standard essential patents has increased and for all patents (i.e. both standard essential patents and non-essential patents) ‘patent applications and litigation has risen exponentially’ (Heiden, 2016, p. 871). Further, concerning patents disclosed to standards setting organisations (SSOs) over technology standards, previous research finds ‘very high litigation rates among disclosed patents’ (Simcoe et al., 2009, p. 807). For these reasons, it may be unsurprising that the Vice President of the European Commission responsible for Competition Policy claimed publicly that the European Commission has ‘received many complaints related to standards-essential patents’ (Almunia, 2012, p. 6).

Research shows that it may be impossible to clarify conditions and obtain patent licences for standard essential patents (and all necessary rights) for use of specific ISO standards that are provided on FRAND-terms (Lundell et al., 2015). Further, previous research concerning development and use of IT standards shows that different organisations use a number of different strategies (Bekkers and Updegrove, 2013) and it is clear that the role of patents is at the core of many discussions and controversies related to standards in the IT sector (e.g. Bekkers and Updegrove, 2013; Geradin, 2013; Graham et al., 2013; Pentheroudakis and Baron, 2017). For example, in ‘a Dutch case concerning alleged infringement of a patent that was essential to the JPEG standard, The Hague District Court suspended a previously granted injunction on the grounds that the patentee had abused its patent rights and was estopped from enforcement as a result of having failed to disclose its patent when participating in the standard-setting process.’ (Graham et al., 2013, p. 40). Similarly, it has been recognised in the Internet of Things (IoT) domain that limited interoperability is one of the ‘key challenges for IoT’ and found that ‘many industry software systems are a legacy, closed-box system that prevents machines from communicating with each other’ (Trappey et al., 2017, p. 221). In addition, based on an analysis of a court case in the context of telecommunication standards concerning the viability of FRAND, findings reveal ‘a lack of theoretical and empirical knowledge necessary to adequately inform courts and policy makers as to the nature and extent of the challenges facing the development and implementation of technology standards.’ (Heiden, 2016, p. 885) Further, the study concludes that ‘extreme caution is advised to policy makers considering changes to legislation, competition regulations, and SSO policies without a robust understanding of both the challenges and the dynamic consequences of the proposed changes from a holistic, system perspective.’ (Heiden, 2016, pp. 885-886)

For all these reasons, and irrespectively of different views regarding appropriate policy and preferences concerning under which conditions IT standards are and should be provided, it is clear that many organisations need to have a comprehensive understanding of the standard essential patents which affect the IT systems that they implement, develop or procure, and particularly, the conditions (such as patent licences) which apply to them.

The study addresses the following main research question: How can, and by which strategies should, an organisation determine and assess the conditions for implementation of a specific IT standard in software?

The rest of this paper is organised as follows. First, we provide a background on standards, software, and challenges related to implementation of standards in different types of software (2) followed by our research approach (3). Thereafter we characterise different challenges related to implementation of IT standards in software and identify factors and associated issues which evolved as an outcome from the study (4). We then elaborate on and present analyses of outcomes from the investigation concerning the availability of standards (5) and factors affecting SEP licensing (6). Further, we present strategies for how an organisation can effectively address the identified challenges (7). Finally, we present conclusions from the study (8).

2. On IT standards and barriers to their implementation in software

There is significant confusion concerning use of the term ‘standard’ amongst decision makers involved with various IT projects and previous research shows that practitioners may regard products and applications as standards (e.g. Lundell, 2011; Lundell et al., 2016). Further, the fundamental difference between a technical specification of a specific standard, as opposed to an implementation of the same specification in a software application and its distribution from a software project is commonly misunderstood (Lundell et al., 2016). To provide a basis for the contribution of this paper, this section considers factors inhibiting market access for different types of standards and issues related to implementation of standards in software under different conditions. Specifically, barriers to implementation of standards in open source software projects are addressed.

2.1 IT standards and market access

Development and use of IT standards in the broader standardisation ecosystems involves a range of different stakeholders in a number of different contexts which engage with specific standards under different motivations (de Vries, 2006). To promote wide deployment of developed IT standards, some contributors stress the importance of avoiding the inclusion of patented technologies that are only available to some parties. For example, a long-term contributor to the MPEG-2 standard stresses the following: ‘For any MPEG standard, it is essential not to apply patented technology that is not available to all parties: any interested party should be permitted to use an MPEG standard.’ (van der Meer, 2014, p. 135)

In some cases, conflicting motivations amongst stakeholders involved with specific IT standards have caused tension amongst competitors which seek to achieve different and conflicting goals (e.g. Contreras, 2016; Glader, 2010; Kesan and Hayes, 2014). Related to specific IT standards, stark tension between conflicting business interests amongst stakeholders involved has caused legal disputes (e.g. Carrier, 2012; Chappatte, 2009; Contreras, 2016; Geradin, 2013; Graham et al., 2013; Kesan and Hayes, 2014; Knable Gotts and Sheer, 2012; Maldonado, 2012; Pentheroudakis and Baron, 2017; Treacy and Lawrance, 2008) and disputes concerning standards have even been referred to as ‘standards wars’ (e.g. Shapiro and Varian, 1999; de Vries, 2006). In addition, research shows that some SEP holders cannot be reached or decline to respond (e.g. Lundell et al., 2015) and in some cases ‘the SEP holder might outright refuse to grant a license’ (Larouche and Van Overwalle, 2014). In fact, it has been argued that standards battles can have an ‘enormous impact on the competitive position of (groups of) companies or countries’ (de Vries, 2006, p. 131)

Use of an IT standard for implementation in a software project presupposes access to the complete technical specification of the standard under terms which allow for implementation and deployment of software from the software project in anticipated usage contexts. For these reasons, several policy initiatives aimed to promote competition have been presented. For example, to allow for competition and broad market access for all potential users of IT standards the European Commission has published guidelines on the applicability of Article 101 of the EU Treaty:

‘In order to ensure effective access to the standard, the IPR policy would need to require participants wishing to have their IPR included in the standard to provide an irrevocable commitment in writing to offer to license their essential IPR to all third parties on fair, reasonable and non-discriminatory terms (“FRAND commitment”)’ (EC, 2011, par. 285)

Further, the same guidelines state: ‘FRAND commitments are designed to ensure that essential IPR protected technology incorporated in a standard is accessible to the users of that standard on fair, reasonable and non-discriminatory terms and conditions. In particular, FRAND commitments can prevent IPR holders from making the implementation of a standard difficult by refusing to license or by requesting unfair or unreasonable fees (in other words excessive fees) after the industry has been locked-in to the standard or by charging discriminatory royalty fees.’ (EC, 2011, par. 287)

However, despite adoption of IPR policies by SSOs and the publication of the guidelines by the European Commission (EC, 2011) which seek to promote competition and provide broad market access to IT standards through various IPR policies, research shows that the anticipated effects of FRAND commitments as envisaged by the European Commission (EC, 2011) may be unfulfilled in practice (e.g. Lundell et al., 2015, 2018). For some formal IT standards, it has been shown that there are significant costs involved in obtaining the complete technical specifications (including all those relating to normatively referenced standards) which may cause significant barriers for use of such IT standards. These may, in practice, inhibit organisations (and in particular small companies) from submitting bids in public procurement scenarios when tenders include mandatory requirements for such standards (e.g. Lundell et al., 2015, 2018). Further, for some formal IT standards it has been shown that it may be impossible to obtain all necessary rights for clarifying conditions for use of formal IT standards that are provided under FRAND-terms (e.g. Lundell et al., 2015, 2018).

2.2 On provision and use of different types of IT standards

The term ‘standard’ has been attributed a number of different meanings over the years (see, for example, de Vries, 2006). For example, the British Standards Institution (BSI) expresses that a standard ‘is an agreed, repeatable way of doing something. It’s a published document that contains a technical specification or other precise criteria designed to be used consistently as a rule, guideline, or definition.’ (BSI, 2012, p. 2) This paper focuses on IT standards.

There are many organisations involved in the development and provision of IT standards (Bekkers and Updegrove, 2012, 2013). Standards setting organisations (SSOs) differ one from another in several ways, such as scope, technology area, and geographical focus. Some SSOs are recognised as national standards bodies: for example the British Standards Institution (BSI) is the recognized UK National Standards Body that was established in 1901 (ISO, 2019a). Amongst global SSOs, some such as the International Organization for Standardization (ISO) and the International Telecommunication Union (ITU), are both formally recognised SSOs. These organisations provide formal IT standards, which implies that it is the status of these standards that makes it possible to explicitly refer to such standards in legislation and public procurement (Lundell, 2011). Further, IT standards are also developed and maintained by many other types of organisations. For example, the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C) are two SSOs which develop and provide many IT standards that are important for the Internet and the web (Bekkers and Updegrove, 2013).

A technical specification of an IT standard may be published in several parts and different editions as the standard evolves over time. When IT standards are developed it is increasingly common to ‘make use of existing standards (or parts thereof) as building blocks’ (Bekkers and Updegrove, 2012, p. 41) which are included in the standard as dependencies (known as ‘normative references’). The rules related to use of normative references when developing standards differ between standards organisations and one difference concerns the observation that several[3] ‘IPR policies make no mention of whether normatively referenced standards are to be covered by IPR policy obligations’ (Bekkers and Updegrove, 2012, p. 42). By way of example, the principles and rules for drafting ISO documents clarify that an ISO standard can refer to normative references ‘which are cited in the text in such a way that some or all of their content constitutes requirements of the document’ (ISO, 2018, p. 30). In addition, ISO states that normatively ‘referenced documents shall be documents published by ISO or IEC.’ (ISO, 2018, p. 30) However, it is clarified that in ‘the absence of appropriate ISO or IEC documents, those published by other bodies may be listed as normative references’ provided that certain conditions are fulfilled (ISO, 2018, p. 30). In addition to providing an IT standard in different parts and editions, there is often a need to publish corrections and amendments to a specific edition and part of an IT standard. Further, on a regular basis standards are reviewed and a possible outcome may be that a standard is withdrawn. For example, ISO standards are typically reviewed every fifth year. It should be noted that withdrawn ISO standards ‘can be purchased in paper version only’ from ISO (2019b).

Investigations from practice in public sector organisations show that it is far from uncommon that practitioners refer to specific products, services, and technologies (e.g. proprietary file formats) that are developed and controlled by a single (or a few) proprietary specifications (Lundell, 2011; Lundell et al., 2016). This widespread practice inhibits competition and reuse of software. Further, it has been found that practitioners involved with development and procurement of IT-systems commonly associate the term ‘standard’ with specific products, trademarks, and companies (Lundell et al., 2016).

2.3 On policy recommendations and challenges for use of different IT standards

Over the years, policy makers, organisations and researchers have made a number of different recommendations related to use of different IT standards. Some are specific to certain usage scenarios or market sectors (e.g. companies in the automotive sector). Other recommendations address public sector organisations in specific countries and may constitute mandatory requirements (e.g. UK, 2015) or recommendations that are mandatory requirements in specific scenarios (e.g. NPS, 2016).

As part of a Commission Recommendation (EU) 2017/1805 of 3 October 2017 on the professionalisation of public procurement (EC, 2017) the EU (DG Grow) has presented an overview of national guidelines for which ICT standards are to be used in different countries in the form of an online catalogue of ICT standards (EU, 2017b). On 6 November 2017 the catalogue contained a set of recommended ICT standards for 20 different European countries (EU, 2017b). From a review of the content in the catalogue it follows that there is scope for significant improvement for a number of reasons. First, it is apparent that there are countries which include (according to ICT standards publication as at 6 November 2017, and also in more recent versions) some, potentially very problematic, closed file format standards in their national recommendations. For example, some countries include JPEG 2000 in their national recommendations, despite the fact that previous research shows that it may be impossible to clarify conditions for use of the 14 different parts of this ISO/IEC standard (see, for example, Lundell et al., 2015). Similarly, some countries include several or all parts of the, potentially problematic, file format standards: ‘MPEG’, ‘AVC’, ‘MPEG-1’, ‘MPEG-2’, ‘MPEG-4’, ‘ISO/IEC 14496’, and ‘H.265’. Second, several countries include technical specifications of proprietary file formats that are not recognised by a SSO (e.g. seven countries include the proprietary file format ‘TIFF’ in their national recommendations. TIFF is a file format developed and maintained by a specific company). Third, the content of the catalogue is somewhat confusing in that the same standard is referred to in different ways. For example, 17 of the 20 countries refer to one (or several of) the following parts and editions of the PDF family of standards as follows: ‘PDF’; ‘PDF/A’; ‘PDF/A-1’; ‘ISO 19005-1’ (i.e. this refers to part 1 of the PDF/A standard irrespectively of edition); ‘ISO/IEC 19005-1:2005’; ‘ISO/IEC 19005-2:2011’ (note: this is also a typo as there is no such thing as an ISO/IEC 19005-1:2005 standard); ‘ISO/IEC 32000-1:2008’; ‘PDF A1’; ‘PDF A2’; ‘PDF Signature’; ‘PDF/A-2’; ‘PDF/A (ISO 19005)’; and ‘PDF/A-3’. Hence, it follows that the remaining three countries do not include a recommendation for any part, edition, and version of PDF. Further, it should be noted that ‘ISO/IEC 19005-1:2005’, ‘ISO/IEC 19005-2:2011’, and ‘ISO/IEC 32000-1:2008’ are typos since no such standards have even been published. Instead, the catalogue should most likely have included references to ‘ISO 19005-1:2005’, ‘ISO 19005-2:2011’, and ‘ISO 32000-1:2008’.

There are policy initiatives (e.g. EC, 2016, 2018a, 2018b) and previous research (e.g. Baron et al., 2016; Brooks and Geradin, 2011; Contreras, 2015; Farrell et al., 2007; Fitzgerald and Pappalardo, 2009; Kappos, 2017; Kesan and Hayes, 2014; Li, 2018; Lindberg, 2019; Treacy and Lawrance, 2008) which elaborate a number of different challenges related to provision of standards under various FRAND-terms. In essence, ‘a FRAND undertaking is a private contract between a patent-holder and an SSO.’ (Brooks and Geradin, 2011, p. 1) Hence, FRAND-terms allow a rights holder that controls standard-essential patents (SEPs) which impinge on IT standards to collect a royalty. It should be noted that ‘FRAND commitments are made voluntarily by participants in standards-development activities, among other things, to induce others to adopt their patented technology in a standard’ (Contreras, 2015, p. 45). Further, previous research has identified ‘standards hold-up’ as a possible implication of such FRAND commitments (Farrell et al., 2007). A situation with ‘standards hold-up’ has been recognised as ‘both a private problem facing industry participants and a public policy problem.’ (Farrell et al., 2007, p. 608) In addition, it has been claimed that IT standards and ‘their implementation may necessarily involve hundreds, if not thousands, of essential patents owned by many different parties. Given such a diversity of SEPs and SEP owners (let alone the diversity of standards that, for example, a single smartphone or computer might implement), patent holdup can have far-reaching consequences.’ (Ratliff and Rubinfeld, 2013, p. 2)

When projects are conducted by public sector organisations there is a widespread practice of explicitly (or implicitly) referring to closed standards which are subject to SEPs (Lundell et al., 2016). Research has identified that patents which impinge on standards as a major issue for concern when trying to obtain patent licences for specific ISO standards (Lundell et al., 2015). Further, challenges related to standards-essential patents have also been recognised by a minister with responsibility for competition issues in the European Commission (Almunia, 2012).

2.4 On implementation of IT standards in software under different terms

Organisations develop and adopt software that is provided in a number of different modes. These include distributing the software by licensing it under open source software or proprietary licences, or making its functionality available on software-as-a-service (SaaS) terms. For all these, there are several different variations and it should be noted that different types of licences and agreements have different effects. For this reason, it may be unsurprising that different individuals, organisations, and policy makers may find different terms of supply appropriate (and inappropriate) in different situations.

Open Source Software (OSS) is software which complies with the Open Source Definition (OSD, 2019). OSS is usually provided under a small set of software licences which has been approved by the Open Source Initiative (OSI, 2019). This set of licences can be subdivided into permissive licences and copyleft licences. Essentially, OSS provided under a permissive licence can be distributed as part of a larger software product under almost any other licence (including a proprietary non-OSS licence) as long as the original authors are attributed. Further, a ‘copyleft license is one that requires, as a condition of distribution of software binaries, that the distributor make the corresponding source code available under the same licensing terms.’ (Meeker, 2017, p. 8)

There are a several different copyleft licences (also referred to as ‘reciprocal licences’) which differ in the scope of the copyleft effect. One of the most prevalent is the GNU General Public License (GPL) which has been described as ‘project-scoped’ by a director (and sometime President) of the Open Source Initiative (Phipps, 2017). This means that all components of any software project which contains any GPL-licensed code must be released as a whole under the GPL. GPL is, accordingly, referred to as ‘strong copyleft’. A related licence, the LGPL (‘Lesser GPL’) is described as ‘weak copyleft’ which Phipps describes as ‘file-scoped’. This means that if any modifications to the LGPL-licensed file are made and distributed, then the modified file itself must be distributed as LGPL, and the corresponding source made available, but, in contrast to the GPL, the remainder of the project may be released under a different licence. There are also some licences which exert a copyleft effect when the functionality of the software is accessed over a network (for example, through a web browser). An example is the Affero General Public License (AGPL).

In contrast, so-called permissive licences allow code to be used in almost any context (the code can be ‘closed’). Reciprocal licences are intended to ensure that code released under them, and any modifications of that code, when distributed, remain under the same licence (the code remains ‘open’).

Results from an investigation of 200 OSS projects providing widely-used software ‘find that strong copyleft licenses are most common amongst the investigated widely used open source projects’ (Gamalielsson and Lundell, 2017, p. 10) Further, the same study finds that 60% of all widely used OSS projects ‘are provided under the GPL-family of licenses (including different versions of AGPL, GPL, and LGPL)’ (Gamalielsson and Lundell, 2017, p. 7).

Most OSS projects implement a range of different IT-standards. Amongst widely deployed OSS projects provided under strong copyleft licences we find the GNU Compiler Collection (GCC) project [4] (provided under the GPL 3.0+ licence) and the Linux kernel project [5] (provided under the GPL 2.0 licence). Further, amongst widely deployed OSS projects provided under permissive licences we find Apache CloudStack [6] (a cloud computing software project which is provided under the Apache 2.0 licence), FreeBSD [7] (an operating system project which is provided under the BSD 2-Clause licence), and Bouncy Castle[8] (a cryptographic library project which is provided under the MIT licence). Some licences recognised by the Open Source Initiative as OSS licences have explicit patent licence clauses (e.g. GPL 3.0 and Apache 2.0), whereas other OSS licences are either silent as to patents (in which case a patent licence may be able to be implied), or are formulated in such a way that the patent licence grant can be interpreted from the general licence grant clause, albeit one without containing the word ‘patent’. For example, from an analysis of rights granted by the MIT licence under the law in the United States it is concluded as follows: ‘There is an express license. Does that express license grant patent rights? Indeed, with permission granted “to deal in the Software without restriction,” it does. And there is no need to arrive at that conclusion via anything more than a direct reading of the words that grant the license.’ (Peterson, 2018)

There is wide consensus amongst scholars that a standard which is provided on royalty-free terms and fulfils the definition of an open standard (EU, 2004; Lundell, 2012; Lundell et al., 2015) must be able to be implemented in software provided under all OSS licences without restriction. For example, open file format standards can be implemented and provided in software that is provided under the BSD 3-Clause licence (a permissive OSS licence) that lacks explicit patent clauses, and also in software that is implemented and provided in software that is provided under the GPL 3.0, a (copyleft) licence that contains strong patent clauses, including an explicit patent licence grant, which allow for redistribution of OSS (in a cascade). Provision and redistribution of OSS under GPL 3.0 presupposes that no additional restrictions are imposed on the distributed OSS, either contractually by the licensor, or because the licensor is unable to pass on to the licensee the benefits the licensor may have under a patent licence from a third party.

The Open Source Definition (hereafter referred to as OSD) constitutes the foundation for assessing if a proposed licence is recognised by the Open Source Initiative as an OSS licence. However, closed standards (Lundell et al., 2015) that are provided on FRAND (or other) terms are broadly considered as inherently problematic [9] (both from a community and legal basis) for OSS projects (Lindberg, 2019; Lundell et al., 2015; Phipps, 2019) and findings show that in practice it may be impossible to clarify conditions for use of specific closed file format standards (that are provided on FRAND-terms) in order to allow for implementation in software (Lundell et al., 2015, 2018). Hence, findings show that there are significant risks associated with use of closed standards provided on FRAND-terms as ‘conditions for use are unclear’ (Lundell et al., 2015, 2018).

Previous research shows that it is not uncommon for companies to declare that they own essential patents without specifying any details about these patents (Bekkers and West, 2009, p. 83). For the dynamic IT domain, such company practices that imply limited transparency concerning under which conditions an IT standard can used for implementation in software may (intentionally or unintentionally) inhibit complementary innovation. In fact, it has been argued that patents ‘may be desirable to encourage innovation in a static world, but they are less important in a sequential setting, where they may actually inhibit complementary innovation.’ (Bessen and Maskin, 2009, p. 628)

Several organisations that develop and provide ICT standards provide information concerning declarations from organisations that control patents which are declared as SEPs. For example, the standards-setting organisations (SSOs) ISO, IEC, ITU-T, ITU-R, and ETSI all make patent databases available which contain information from organisations that have declared to them that that they control SEPs related to specific standards. Many standards for the Internet and the web are provided on royalty-free terms (for example the SSOs IETF and W3C publish many standards under such terms), and these SSOs also provide patent information related to their standards. In fact, OASIS, IETF, and W3C all provide mechanisms aimed at supporting to clarify IPR issues related to their standards.

However, SSOs do not, in general, guarantee completeness of the database or that it is up to date (Lundell et al., 2015). For example, ISO (2019c) states that ‘ISO does not verify the veracity or accuracy of the information nor the relevance of the identified patents/patent applications to ISO Standards.’ Further, the IPR policy used by ISO, IEC, ITU-T, and ITU-R (ITU, 2018) encourages organisations which control patents that may impinge on a specific standard to make declarations to the relevant SSOs in order to clarify under which conditions they may be willing to negotiate any of their SEPs they may control. However, it should be noted that ISO, IEC, ITU-T, and ITU-R can only demand that organisations which have participated in the standardisation process to make such declarations, whereas for other organisations which have not participated, this is not the case. In addition, the common patent policy for ITU-T/ITU-R/ISO/IEC (ISO, 2015, p. 9; ITU, 2018, p. 9) clarifies that ‘a patent embodied fully or partly in a Recommendation | Deliverable must be accessible to everybody without undue constraints’ and also that the ‘detailed arrangements arising from patents (licensing, royalties, etc.) are left to the parties concerned, as these arrangements might differ from case to case.’ (p. 9)

It should be noted that SSOs’ patent databases may contain incomplete and misleading information. For example, there may be SEPs that have not been declared to the relevant SSO. One reason for this may be that the organisation that controls the patent has not engaged with the relevant SSO and may have no interest in declaring the patent. In addition, organisations may (intentionally or unintentionally) have made misleading declarations to the SSO. In addition, it is possible that an organisation may declare SEPs by means of applying for an entry in an SSO’s database, even if those patents are only peripherally connected with the standard, if at all. Further, there is little incentive for organisations to amend the database when the patents in question expire or are declared invalid. For these reasons the term ‘apparent SEP holder’ more appropriately describes the entities associated with a particular standard maintained by an SSO.

Note that there is no obligation to provide details of the patent number or jurisdiction of any patent in the application for entry into the SSOs’ databases. For these reasons, it is important to consider the content of patent databases in light of these challenges and an SSO may seek to clarify the uncertainty under which content in a patent database should be assessed.

Previous research has found that declarations of SEPs that companies make to SSOs contribute to disputes and it is claimed that many of ‘the critical assertions in these disputes relate to the commitments that firms have made to standard-setting bodies during the standard-setting process.’ (Lerner and Tirole, 2015, p. 548) For these reasons, it may be unsurprising to find that a member of the Intellectual Property Rights Committee in the Telecommunication Technology Committee expresses the following related to the common patent guidelines for ITU/ISO/IEC: ‘It is dangerous to believe that there are no problems concerning patents related to a Standard merely because the Standard’s specifications have already been approved and published by an SDO. We need to recognize that a Standard may become unimplementable in order to avoid patent infringement even after it has already been published and spread throughout the world.’ (Yoshimatsu, 2012, p. 2)

The relationships between the documentation of a technical specification of a specific standard, and its implementation in software imply major complexity. Deliberate (or unintentional) deviations between the technical specification as documented as opposed to its implementation in software can impose a number of technical, economic, and legal challenges. For example, two different implementations of a technical specification may deviate with a resulting lack of interoperability between software applications. Such deviations may also cause lock-in with potentially significant additional costs.

By way of illustration, the United States Department of Defense expresses concern over implementations of standards which go beyond a technical specification of a standard as it is noted that ‘being locked into a proprietary extension can be a problem, particularly if it is only implemented by a proprietary program (since this effectively eliminates competition, raising costs long-term).’ (OTD, 2011, p. 25) Further, IPR conditions for implementation of a technical specification of a specific standard may inhibit the implementation of a subset of the technical specification. Similarly, it may be impossible to obtain all necessary rights for creating an implementation that goes beyond the technical specification of a standard (perhaps intended to achieve interoperability with another software application that is known to deviate from the standard) as such an implementation may impinge on other patents. Also, a patent licence that has been made available for a SEP will most likely not cover a non-compliant implementation, even if that non-compliance is necessary for interoperability. In addition, organisations that have made declarations of SEPs to the relevant SSO concerning their IPR which impinge on a specific standard are most likely only bound by such commitments concerning the standard and anything that goes beyond would fall outside such agreements.

2.5 On challenges for implementation of IT standards in OSS projects

A standard that is provided on royalty-free terms which fulfils the definition of an open standard (EU, 2004; NPS, 2016) can be implemented in software provided under all OSS licences (OSI, 2019). For example, an open file format standard (EU, 2004; NPS, 2016) can be implemented and provided in software that is provided under the BSD 3-Clause licence (a permissive OSS licence) that lacks specific patent licence clauses, and also in software that is implemented and provided in software that is provided under the GPL 3.0 (a copyleft) licence that contains strong patent licence clauses (and prevents additional restrictions from being imposed).

However, it has been found that projects undertaken amongst public sector organisations commonly refer to closed standards that are provided on FRAND (or other) terms which can inhibit implementation in software (Lundell et al., 2015, 2018). Further, findings show that such closed standards can also cause unequal treatment in public procurement as conditions for use may only be clarified (during the tender) to those which already control the relevant SEPs (Lundell et al., 2015, 2018). In addition, a study commissioned by the Swedish Competition Authority ‘found that many IT-projects in the Swedish public sector refer to closed standards which cannot be implemented in open source software’ (Lundell et al., 2017, p. 82).

Further, legal analyses of OSS licences have also presented different views concerning FRAND. For example, by drawing from a legal analysis of OSS licences undertaken by Kesan (2011), it has been argued that permissive licences ‘are fully compatible with FRAND licensing’ (Kappos, 2017, p. 264). Similarly, another study (with the same author as one co-author) which also addresses permissive OSS licences claims that ‘most are fully compatible with RAND licensing if they do not require royalty-free patent licensing by contributors or redistributors’ (Atlass et al., 2017, p. 52). However, the legal analyses (Atlass et al., 2017; Kappos, 2017; Kesan, 2011) show that the FRAND licensing is incompatible with licences used by widely used OSS projects, as reported by 200 widely used OSS projects (Gamalielsson and Lundell, 2017, p. 7). In addition, the legal inability to implement royalty-bearing interoperability standards has been elaborated in previous studies (e.g. Atlass et al., 2017; Kappos, 2017; Kesan, 2011; Lindberg, 2019; Mair, 2012). For example, previous research finds that ‘the GNU General Public License (GPL) family of licenses are incompatible with any royalty-bearing conditions which attach to interoperability standards.’ (Mair, 2012, p. 58)

Further, previous studies show that standards provided on FRAND-terms can inhibit implementation in software (e.g. Lundell et al., 2015, 2018) and expose users to risk of patent infringement if such standards are implemented and provided in software. For example, a legal expert has argued that ‘if open source software implements a royalty-bearing or non-free standard, notwithstanding the royalty-free grant of copyright under the open source license, users would be at risk of patent infringement claims when using the software.’ (Meeker, 2017, p. 254)

IT standards can be implemented in software under a number of different terms and there are a number of different OSS licences which can be used when establishing an OSS project. Figure 1 presents a characterisation amongst two orthogonal dimensions with examples of commonly used licences in each quadrant. In addition to a choice between copyleft and non-copyleft (permissive) licences (see the vertical dimension in Figure 1), there is also an additional choice concerning whether or not a specific licence contains an explicit patent licence clause (see the horizontal dimension in Figure 1).

lundell-fig-1

Figure 1: Different types of OSS licences (with illustrative examples)

Previous research shows that a number of different OSS licences have been used for implementation of IT standards in OSS projects. In different contexts there may be a number of different motivations for selection and use of a specific OSS licence when implementing IT standards in OSS. For example, van der Linden et al. (2009) reports that in 2005 two companies (Philips and Agfa) made an OSS toolkit which implements the DICOM (Digital Imaging and Communications in Medicine Standard) standard available under a copyleft licence (LGPL) on an open collaborative platform. Specifically, in 2005 the decision was made to provide the OSS project ‘under the GNU Lesser General Public License (LGPL v2) and the Open Source project is hosted on the SourceForge.net platform.’ (Lundell and van der Linden, 2013). Further, several SSOs have expressed requirements and articulated different recommendations concerning preferences for OSS licences with respect to IT standards. For example, the IETF articulates preference for permissive licences that lack explicit patent clauses and (in addition to the provision of licences to the IETF documents) states that ‘Code Components are also licensed to each person who wishes to receive such a license on the terms of the “Simplified BSD License”’ (TLP, 2015, p. 3). In fact, the IETF document (TLP, 2015) instead includes an explicit reference to a different licence – the ‘New BSD License’[10] (OSI, 2019) – despite the explicit reference to the ‘Simplified BSD License’[11] (OSI, 2019). Further, it is stated that the explicitly referenced ‘BSD Licence is intended to be compatible with the Simplified BSD License template published at http://opensource.org/licenses/bsd-license.php.’ (TLP, 2015, p. 4). In addition, other SSOs have taken different initiatives for promoting and establishing OSS projects which implement IT standards in OSS projects; one example being ETSI that initiated the OSS project MANO which implements an ETSI standard under the permissive Apache 2.0 licence (ETSI, 2019a). ETSI’s goal is to deliver ‘an open source Management and Orchestration (MANO) stack aligned with ETSI NFV Information Models’ (ETSI, 2019b). Finally, there are also initiatives which aim to implement technical specifications of IT standards under copyleft licences that contain explicit patent licence clauses (e.g. LGPL 3.0 or GPL 3.0), see for example an analysis of software provided by commissioned companies in the context of an EU-funded (EU FP7) project (Lundell and Gamalielsson, 2017).

3. Research approach

The study addresses challenges related to managing risks associated with implementation of IT standards in software through investigation of a purposefully selected set of file format standards that are provided by different SSOs, including ISO and ITU-T. Two widely referenced document file format standards, ISO/IEC 29500 and ISO 32000-1:2008, were initially purposefully selected (with their normatively referenced standards) for investigation. This set of formal standards was supplemented with the ISO 20022 standard, which is referenced in national regulations in Finland (2018). The systematic data collection and analysis draws from previous research that analysed conditions for implementation of IT standards in software (NPS, 2016; Lundell et al., 2015, 2018). For the purposefully selected set of file format standards (and for normatively referenced standards in the initially selected standards) several organisations have declared (to relevant SSOs) that they control standard essential patents which impinge on conditions for use of a specific standard that various organisations may have declared to the specific SSO that provides the standard. So far, investigation in the study has considered the following standards: ISO/IEC 11172-1; ISO/IEC 11172-2; ISO/IEC 11172-3; ISO/IEC 13818-1; ISO/IEC 13818-2; ISO/IEC 13818-3; ISO/IEC 13818-7; ISO/IEC 14496-1; ISO/IEC 14496-2; ISO/IEC 14496-3; ISO/IEC 14496-10; ISO/IEC 14496-11; ISO/IEC 14496-15; ISO/IEC 14496-18; ISO/IEC 14496-22; ISO/IEC 15444-2; ISO 20022; ISO/IEC 29500; and ISO 32000-1.

Specifically, the study utilises a research method that encompasses an action-case research approach (Braa and Vidgen, 1999) for investigation of how an organisation can, and by which strategies an organisation should, determine and assess the conditions for implementation of a specific IT standard in software. This approach involves an iterative process of systematic data collection and review of legal conditions for implementation of the selected set of IT standards in software which is to be provided as an OSS project. The research method used is supplemented with a review of existing documentation from standardisation organisations, documented policies and strategies at various levels (including EU, national and regional levels), and previous research in order to inform the analysis which constitutes the basis for presentation of results.

Through conduct of an action-case research approach for each investigated IT standard, the study seeks to obtain patent licences that can be used by OSS projects for all standard essential patents which relate to all declarations in the specific patent database. The request for patent licences explicitly requests conditions which are compatible with establishing OSS projects under one (or several) of the three specific OSS licences: GPL 3.0[12], MPL 2.0[13], and Apache 2.0 [14].

The decision to request patent licences which allow for establishing OSS projects under the three specific OSS licences was informed by previous research, and was primarily motivated by a desire to establish long-term sustainable OSS projects under widely used and well understood licences that may be attractive to different stakeholders.

For each investigated standard (say the X-standard), the conduct of the research has for each declaration of standard essential patents requested expressed the following request: For all patents your organisation control which impinge on the technical specification(s) of the ISO X-standard I would like to obtain (‘free of charge’) patent licences for all these patents which allow for implementation of the technical specification(s) of the ISO X-standard in open source software. Specifically, I wish to obtain (‘free of charge’) patent licences for our collaborative research project which allow for implementation of the technical specification(s) of the ISO X- standard in software which is to be provided under one (or several) of the three specific open source licences GPL 3.0, MPL 2.0 and Apache 2.0. Can you please provide copies of the relevant draft licences for my consideration?

Related to each standard the data collection process implied an extensive dialogue over a long time-window, in many case involving several reminders and clarifications provided in subsequent dialogues with different representatives for organisations which have declared SEPs in patent databases[15] related to the standard being investigated.

For investigation of standards that are provided by SSOs which maintain a patent database (such as formal standards organisations ISO and ITU-T, and also the informal standards organisations IETF and W3C) the research method used for investigation has involved investigations via data collection from a number of different, and supplementary, types of sources. Since this paper is focused on experiences related to ISO standards (and since illustrative findings from our investigations of ISO standards are included as supporting evidence to motivate the recommendations presented) we detail the research method used for investigation of ISO standards [16].

Specifically, the method used for investigation of each specific ISO standard has involved data collection from several different types of sources. First, for each investigated ISO standard that is to be implemented in a software project, all information provided in the ISO patent database has been collected in order to establish details concerning which (if any) organisations have declared that they control SEPs that impinge on the specific standard. For each such declaration, contact details for the organisation that has made the declaration has been obtained together with all details provided concerning the declaration. Information obtained, for most declarations, for a given declaration include details concerning under which conditions the declaration is made (i.e. option 1, 2 or 3 under the ISO rules) and in most cases a postal address and in some cases an email address.

It became clear during data collection that undertaking an effective search of the ISO patent database (and, similarly, patent databases maintained by ITU-T and other SSOs) presented particular difficulties regarding normative references (a normative reference being a standard which is referenced as being part of an another standard). A standard may contain normatively referenced standards, each of which may itself contain normatively referenced standards, and so-on, through potentially multiple levels. Even though a standard is deemed to include the standards normatively referenced within it, a search against the top level standard will only reveal declarations against the standard itself, and not against standards normatively referenced within it. For this reason, it is necessary to perform a search against those standards which are normatively referenced, which may be standards administered by other SSOs, and which will therefore require a search of those SSOs’ databases, which may themselves be governed by different rules as to how normatively referenced standards are addressed, and so on. Our systematic investigation therefore included data collection and analysis at several levels but it was disproportionate, in relation to the standards relevant to this study, to undertake an exhaustive analysis which sought to investigate all standards normatively referenced within the selected standards, through all levels.

Concerning ethical aspects, the intent and purpose of the requests has been transparently communicated to apparent SEP holders. Specifically, it has been communicated that the context is a collaborative research project involving an iterative process through use of an action-case research approach (Braa and Vidgen, 1999). The communications included clarifying the initial goal of identifying and obtaining necessary rights for implementation and, if successful, the intention, during a subsequent phase, to implement the standards in software under three specified OSS licences.

Further information was also provided to apparent SEP holders as and when requested. Note also that data collection and structuring of data for the reporting has been performed by researchers at the University of Skövde, which is a Swedish non-profit public sector organisation that is bound by ‘offentlighetsprincipen’ (Eng. ‘the principle of public access to official documents’). The study investigates publicly available data that is made available in patent databases that are provided by ISO and ITU-T. Even if personal information is provided in those publicly available data sources (contact details for individuals at apparent SEP holders as disclosed in the patent databases, or through subsequent correspondence), the study reports no personal information derived from those sources. Feedback obtained from apparent SEP holders in correspondence and during telephone conversations that has been used in the reporting of results has been anonymised and abstracted to a level where the knowledge contribution is still maintained. A legal expert has contributed to the analysis of the results.

4. Overview of results

This section presents a conceptualisation of results, in the form of a set of factors with associated issues, which evolved during the conduct of the study. The evolved factors and issues which relate to availability of standards (table 1) and SEP licensing (table 2) constitute a basis for subsequent presentations of results, which are further detailed in relation to availability of standards (section 5) and SEP licensing (section 6). The presentation of results include selective illustrative examples in order to highlight observations and results obtained during conduct of the study.

Table 1: Availability of Standards

Factors affecting an organisation’s ability to obtain and make use of the complete technical specification(s) of an IT standard which the organisation wishes to implement in software, in the context of a software project undertaken by that organisation.

Factors

Issues include ...

1. Availability of the IT standard.

Are complete technical specification(s) of the IT standard, including updates and amendments available throughout the period of each project?

Are complete technical specification(s) of the IT standard publicly available at reasonable or zero cost (e.g. by a formal SSO)?

Do the licensing terms for the complete technical specification(s) allow for the specification(s) to be provided and made available to the entire project team, throughout the period of the project?

2. Availability of all normatively referenced standards which are directly or indirectly included in the IT standard.

Are all normatively referenced standards available, considering in each case the issues referred to in factor 1?

Are the complete technical specification(s) of all normatively referenced standards included in the IT standard provided by a specific organisation (e.g. by a formal SSO) available from the same organisation under the same licensing terms?

3. Relationship between the IT standard and any existing implementations of the IT standard.

Is there an existing implementation (possibly pre-dating the IT standard) which is regarded as a de facto standard?

Have complete technical specification(s) of the IT standard, including complete technical specification(s) of all its normative references (whether referenced directly or indirectly), been implemented in software that is provided in a software application that is made available as a service (SaaS) or on-premise under a proprietary licence?

Have complete technical specification(s) of the IT standard, including complete technical specification(s) of all its normative references (whether referenced directly or indirectly), been implemented in multiple software projects (including at least one OSS project) that are made available on-premise?

Have complete technical specification(s) of the IT standard, including complete technical specification(s) of all its normative references (whether referenced directly or indirectly), been implemented in multiple software projects (including at least one OSS project) that are made available on open collaborative platforms?

For the purpose of this study, we define an ‘apparent SEP holder’ as an organisation which fulfils at least one of the following criteria:

1. An organisation that is explicitly mentioned in patent declarations related to a specific standard included in a patent database, including organisations which have subsequently changed their name but are still the same legal entity as was mentioned in the database.

2. An organisation that has responded to a request addressed to the organisation concerning a specific standard is included in a patent database for which there is one (or several) declaration(s) that this company controls SEPs related to the specific standard.

3. An organisation which the investigator is informed by the organisation included in the patent database concerning a specific standard as declarant for particular SEPs controls those SEPs.

Table 2: Factors affecting SEP licensing

Factors affecting an organisation’s ability to determine and assess the licence conditions under which it is able to implement an IT standard in software in the context of a software project undertaken by that organisation.

Factors

Issues include ...

1. The ability to reach all organisations behind declarations of SEPs which impinge on the IT standard.

Are contact details (email and postal addresses) of apparent SEP holders which are included in patent databases (or contact details provided via equivalent resources) sufficient to enable effective contact with the relevant apparent SEP holders?

Are contact details (email and postal addresses) of apparent SEP holders for which declaration of SEPs are publicly included in patent databases (or via equivalent resources) correct and up-to-date (e.g. SEPs may change owners and apparent SEP holders may change their addresses)?

2. The ability to obtain responses to requests for patent licences from apparent SEP holders.

Do apparent SEP holders ignore requests for patent licences?

Do apparent SEP holders claim that they do not control SEPs (e.g. where the respondent states that their organisation no longer controls an SEP or where a declaration has been made in error)?

3. Knowledge and clear documentation of all SEPs which impinge on the IT standard are known and documented in patent declarations that are maintained by SSOs in patent databases.

Does the declaration within the SSO’s patent database (or equivalent resource) contain details of specific SEPs (or is it a general statement making no reference to patents)?

Are apparent SEP holders missing from patent databases (or equivalent resources) provided by relevant SSOs?

Are there apparently inconsistent SEP declarations in the patent databases of SSOs which provide equivalent IT standards (thus requiring review of the content in the database for all relevant SSOs which provide those equivalent standards)?

4. Provision of patent licences on terms that allow for implementation of the IT standard in OSS projects?

Do apparent SEP holders provide patent licences that are compatible with the specific terms under which the implementing organisation aims to provide the software project?

Are apparent SEP holders willing to provide patent licences that allow for complete implementation of the IT standard, including all standards which are normatively referenced (directly or indirectly) within that standard?

Are apparent SEP holders willing to provide patent licences that are compatible with OSS licences, including those which contain explicit patent clauses?

Are apparent SEP holders willing to provide patent licences that allow for implementation of a subset of the IT standard?

Are apparent SEP holders willing to provide patent licences that allow for implementation of a (minor) superset of the IT standard (to the extent that such deviations from the standard allow for interoperability with other software applications that have deviated from the standard in their implementations)?

5. Availability of the technical specification of standards to allow implementation in software

Before implementing an IT standard in software, an organisation will require access to a copy of the technical specification of that standard. Standards change over time, may be expensive to obtain, and contain normative references (references to other standards), access to which is also required to implement the standard. Each of these issues has been investigated as part of the study, and this section presents our findings relating to the availability of IT standards.

5.1 Availability of the technical specification of a standard

The key component of each standard is a technical specification, which is a document or set of documents available (in the case of formal standards) from the relevant standards setting organisation. Standards are subject to correction, extension and amendment over time, and accordingly any organisation wishing to implement a standard in software will require access to each such correction, extension and update, at a minimum throughout the duration of the project from inception through to release.

The standard, as embodied in the technical specification, will typically be available for purchase at a cost. This cost may be significant and therefore presents a barrier to an organisation seeking to implement the standard. This is amplified because of the requirement for an implementing organisation to obtain copies of all corrections, extensions and amendments to the standard that arise throughout the duration of the project. Because the technical specification is subject to copyright, typically that of the standards setting organisation, its reproduction will require a licence from the copyright holder, which means that it may be necessary for the implementing organisation either to purchase multiple copies of the technical specification as required by the team, or acquire a site licence to enable to copies to be made internally, in each case adding to the cost.

As a specific example, to implement ISO 32000-1:2008, there is a need to obtain 17 standards which are included as normative references (of which several also contain normative references to further standards, and so-on). The cost of obtaining the top-level standard ISO 32000-1:2008 itself is 198 CHF and the total cumulative costs of obtaining all standards normatively referenced directly in ISO 32000-1:2008 (second-level standards) will, at least, be 1100 CHF. This figure does not include any standards which are indirectly normatively referenced (i.e. those which are normatively referenced in the second-level standards). By way of a single example, the standard ISO/IEC 15444-2:2004 is a normatively-referenced standard in ISO 32000-1:2008 and itself contains 36 normative references, of which some can be obtained from ISO or other organisations for, at least [17], 6478 CHF. It becomes clear that the total cost of obtaining all standards normatively referenced (that are still available) at all levels under ISO 32000-1:2008 becomes very significant.

Further, if a new edition, part, modification, correction, amendment or version of a standard is published during the conduct of analysis, it is necessary to undertake a completely fresh analysis of all standards which are normatively referenced within it. This applies not only to the top-level standard, but to any change occurring to any directly or indirectly normatively referenced standards. For example, the ISO/IEC 15444-2:2004 standard includes the undated multi-part ISO/IEC 15983 standard (MPEG 7) as one of its normative references. Since 2004 the MPEG 7 standard has evolved with the publication of several new parts, amendments, and editions which implies that the set of specifications included as normative references in the ISO/IEC 15444-2:2004 standard have changed since it was first published (over time several of these normatively referenced standards have also been withdrawn by ISO). Setting aside for a moment the cost of acquiring the updates, the time involved in such analysis will itself be significant, as is the time involved in monitoring all standards referenced to determine if such changes have been published.

We have also observed that some standards include references to sources maintained on external websites and referenced by way of specific URLs. For example the technical specification of part 1 of the first edition of the ISO 29500-1:2008 standard contains several references (web links) to external websites which are unavailable, including websites maintained by different companies (including apple.com and microsoft.com).

As a further example, the QuickTime File Format Specification (2007-09-04 version) is one of the normatively referenced specifications in (the first edition of part 1 and part 4 of) the ISO/IEC 29500 standard (i.e. ISO/IEC 29500-1:2008 and ISO/IEC 29500-4:2008) for which the status concerning availability of the 2007-09-04 version of the QuickTime File Format Specification is unclear. The normative reference refers directly to a file that is no longer maintained on the Apple website (i.e. developer.apple.com/documentation/QuickTime/QTFF/qtff.pdf).

5.2 Availability of the technical specification of normatively referenced standards

As we have seen, to fully implement a specific standard, it will also be necessary to implement the standards normatively referenced within it, which in turn means that the text of those normatively referenced standards must be available. Further, there may be a significant number of levels of normative references (in other words, a standard may reference other standards, which may in turn reference other standards, and so on). An organisation wishing to implement a specific standard will require access to all of the standards normatively referenced within that standard, both directly and indirectly. Accordingly, the issues identified in Table 1 and described in paragraph 5.1 will apply to each and every standard normatively referenced, both directly and indirectly.

In addition, standards which are referenced normatively may be standards which are developed by another standards setting organisation, or even by a private organisation. This will add another level of complexity to procurement of those further standards, assuming that those further standards are even available.

Unavailability of standards may arise because of the way that the chronology of normative referencing works. A normative reference may explicitly state the specific date or edition of the standard referenced. In that case, the standard referenced would be taken to be the standard as it existed at the date specified. However, if the normative reference is given without a date, then the ISO rules [18] state that for ‘undated references, the latest edition of the referenced document (including any amendments) applies.’ (ISO, 2018, p. 31) Further, the set of normative references included in an ISO standard shall not include ‘documents which are not publicly available (in this context, ‘publicly available’ means published documents which are available free of charge, or available commercially under reasonable and non-discriminatory terms to any user)’ (ISO, 2018, p. 21).

It is not clear what happens where a standard makes a normative reference to a dated standard, which itself makes an undated normative reference to a third standard. Is the third level standard to be taken as fixed at the date specified as the relevant one for the second-level standard, or should it be taken to have been updated up to the point at which the software implementing the first-level standard is implemented?

For example, the ISO/IEC 29500-1:2008 standard (i.e. part one of the first edition of this standard) includes 57 direct normative references. One of those 57, ISO/IEC 14496-22:2007 itself contains four normative references, of which one is ISO/IEC 14496-18 (undated – at the time of publication of the first edition of ISO/IEC 295000:2008 it referred to ISO/IEC 14496-18:2004 being the most recent at the time). ISO/IEC 14496-18 contains three normative references, and so on through several further levels. This portfolio of normative standards includes standards other than those administered by ISO/IEC: they include for example a standard provided by a private company (The QuickTime File Format Specification – 2007-09-04 version) and standards from other standards organisations such as IETF and W3C.

Further, part one of the fourth edition of the same standard (ISO/IEC 29500-1:2008) contains different normative references. For example, the reference to ISO/IEC 14496-22:2007 in the first edition becomes a reference to ISO/IEC 14496-22:2009 in the fourth edition.

The reference to ISO/IEC 14496-18 above is undated, meaning that as a normative reference, it will refer to the most recent version of that standard available at the time the standard is implemented.

As a further example, the ISO 32000-1:2008 standard includes 79 normative references, and is itself a normative reference (one of 17) included in the ISO 19005-2:2011 standard, and also a normative reference (one of 18) included in the ISO 19005-3:2012 standard.

5.3 Relationship between an IT standard and existing implementation(s) of that IT standard

Rather than being created from a clean sheet of paper, standards may arise from an existing proprietary implementation which is made available to a standards setting organisation to form the basis of a formal (or informal) standard. An example of this is PDF, which was a proprietary implementation of a page description language and implemented in Adobe’s proprietary software, and more specifically, in the various components of the Adobe Acrobat suite. In 2007, ISO adopted Adobe’s file format PDF 1.7 as a basis for the ISO 32000-1:2008 standard.

Any organisation implementing the standard in software will wish to be aware of any proprietary implementations of the software (in case any other practical deviations from the standard should be accommodated to facilitate interoperability with that implementation), and also any implementation of the standard distributed by an OSS project (for the same reason, and also so that the source code of the implementation can be scrutinised, and, if permitted by the relevant OSS licence, used, to facilitate development of the software by the organisation in question).

6. Ability to determine and assess the licence conditions for SEPs impinging on an IT standard

To lawfully implement an IT standard in software and to make use of or distribute that software, an organisation will require licences to each of the patents (standards essential patents – SEPs) which impinge on that implementation. The SSOs provide publicly-accessible databases which contain declarations by patent holders claiming to hold SEPs impinging on each standard. Each declaration summarises the basis on which the patent-holder has declared a willingness (or unwillingness) to grant a licence. This is intended to assist any organisation wishing to become involved in the implementation of the standard, by providing them with the information sufficient for them to enter into dialogue with the organisation behind the declaration in the database with a view to obtaining an appropriate patent licence. However, our findings have shown that there are a number of issues which arise with this process, including the ability to locate, communicate with, and enter into meaningful communication with each of the apparent holders of SEPs.

Each of these issues has been investigated as part of the study, and this section presents our findings relating to the availability of IT standards.

6.1 Outcomes from attempting to reach apparent SEP holders

A significant number of attempts to write to the entities listed as declaring SEPs in the patent database of ISO and IEC covering the standards in question, primarily by postal mail (but also by email where email addresses were available), led to no response, or returned postal mail or email non-delivery notification.

A number of addresses listed in the database were no longer (or had possibly never been) current, as evidenced by the letter being returned. Categories include declarants which no longer exist (possibly because of mergers and acquisitions, or group restructurings: for example, Deutsche Thomson-Brandt GmbH, Lucent Technologies Inc., Thomson Multimedia S.A. and Victor Company of Japan Limited), or because declarants had changed address without updating the database, for example AT&T, BBC and Hitachi. A number of email addresses and postal addresses listed on the database were insufficient. For example one postal address was listed in its entirety as ‘Experts registered in United Kingdom, GB-London’.

In some cases, we received a response from an organisation which had not been contacted. The initial request was presumably forwarded by the addressee organisation to the company which responded, sometimes with an explanation. For example, we sent a request to CSELT which triggered a response from Telecom Italia SpA. The response contained an explanation that CSELT changed its name to Telecom Italia Lab SpA (also known as TILAB SpA), which was subsequently merged into Telecom Italia SpA. Another example is a response from Orange, which opened with the clarification that the respondent received the request from TDF (one of the organisations to which we sent a request).

In some cases, an individual’s email address was listed (causing any email to be undelivered presumably because the individual no longer worked at the organisation), or an individual was named as part of the postal address (causing the letter to be returned by the postal service, because the letter had not been forwarded internally, the individual presumably not working for that organisation or at that address any more). One example of an organisation for which information in the patent database was insufficient or outdated was Hyundai Electronics Industries.

In many cases, where a delivery attempt failed (either email or postal address) an effort was made using online databases (a web search, company registries, and annual returns/reports) to find an appropriate address for that declarant.

6.2 Results of attempts to obtain responses from apparent SEP holders

We received a number of responses which presumably attempted to be helpful but which did not help to progress our quest for a meaningful, legally effective licence to the relevant SEPs. For example, one company stated ‘we have no intention to assert out patents relating to such standards’, rather than providing the requested draft patent licence. We followed this correspondence up by requesting for a draft licence, but the addressee failed to respond.

In some cases, we were referred to other organisations to which the addressee had delegated licensing authority (for example, patent pools or licence administrators): for example MPEG LA and VIA Licensing Corporation.

In other cases, the process became convoluted and complex, for example because of internal changes of personnel within the addressee company, or because the addressee asked for telephone communication where the time zones in question meant that there was no mutually convenient overlapping business hours, thus creating a barrier to effective communication.

In one case the declarant was unable to find out which patents against which they themselves had made the declaration. In their response, they asked us which patents we requested licences for: ‘can I please ask if you are able to provide further details [of the patents]’.

In one case one organisation told us that they had made a declaration in error. This being an unusual entry in which the relevant PCT application had been listed, they were able to undertake a search against the specific patent application, causing them to respond that the patent had never been owned by them, but by a completely separate organisation (which interestingly had not itself made any declaration).

In some cases we were told by the addressee that they had made no declaration, even though one existed in the relevant database. For example, the patent database for ISO 15076-1 contained a declaration from a specific company which responded by saying ‘[The company] has not declared any patents relevant to ISO 15076-1’.

6.3 Observations concerning completeness and consistency in the documentation of all SEPs

An important issue, which is beyond the scope of this study, is that the content of the patent database provided by SSOs is guaranteed to be neither accurate nor complete. As regards completeness, the SSO has no power to compel anyone not involved in the standards-setting process to disclose patents). Further there is no verification that entries which are in the database necessarily relate to patents which do impinge on the standard in question. Searching for patents covering a particular implementation is a notoriously complex, expensive and unreliable process (which necessarily creates expense and risk for those implementing a standard which may impinge on a patent).

Some of the standards investigated in this study are developed in joint working groups and are provided by both ISO and ITU-T. For example, ITU-T H.264 and ISO/IEC 14496-10 were developed through a joint working group established by agreement between the two SSOs, and the standards can therefore for most practical purposes be considered identical.

We have found some examples of inconsistencies between the content of the two databases for these investigated standards. Where an inconsistency was found (for example a declaration was found against a specific standard in one database but not the other), in every case investigated, we would request a patent licence, even if the organisation only provided a declaration in one database.

6.4 Outcomes from attempts to obtain appropriate patent licences

In some cases, the declarant was unwilling to provide a free-of-charge licence compatible with the OSS licences under which the project was stated to be licensed to users and recipients of the developed software. For example, one respondent representing an organisation for which SEPs are declared said ‘I understand what you are trying to accomplish’, but then went on to ask questions about unit price and sales volume, presumably intended at determining a royalty structure (which would be incompatible with the OSS project proposed in the study). The respondent concluded by saying ‘...please indicate if you would like to pay annually or a one-time fully paid license’.

Where reasoned refusals were provided, the reasons given were typically either that royalty payments would be required to fund further development, or that to give a royalty-free licence would be unfair to existing holders of royalty-bearing FRAND licences. For example, one respondent gave their reasons for not fulfilling their request, stating ‘We cannot agree to the use of our technology under the conditions you mention without remuneration that fuels our further research and development’.

We received one response which stated that the respondent was prepared to provide a free-of-charge licence for research purposes, but that should the use be commercial, a paid licence agreement would have to be entered into (which would be incompatible with the OSS licences under which the planned software would be used).

Having sent a particular respondent requests for patent licences for ten different standards the respondent stated in the response ‘we do not usually offer a royalty-free license for such patents unless the circumstances are exceptional’. They also referred us to licensing administrators (MPEG LA, LCC and Via Licensing Corporation). However, the listed administrators cover only a subset of the standards for which we requested patent licences, and some of these do not respond to requests. In any event, the terms offered, for example, by MPEG LA do not fulfil all the requirements for a licence which is compatible with the requested OSS licences.

In two cases, the respondents were prepared to provide restricted free-of-charge patent licences covering the relevant standards. However, these licences contained further restrictions which prevented them from being compatible with the requested OSS licences. In one of those cases, we provided the respondent with a markup of the relevant licence which would have brought it into compatibility, but the respondent declined to accept the terms: ‘we cannot accept your proposed revisions’. In the other case, we received a proposed modified version of the respondent’s published public patent licence. That version we expressed by the respondent to address our stated concerns, but in fact failed to do so. We amended the draft accordingly, but the modified draft was rejected. A salient issue was that the respondent did not accept that in order to be compatible with the stated OSS licences, the patent licence was required to be irrevocable.

In contrast, Monotype Corporation, after explaining some of the complexities of FRAND licensing, went on to state that the patented technology owned by it and incorporated in ISO/IEC 14496-18 and ISO/IEC 14496-22 are offered under a ‘free unrestricted license’.

7. Analysis and Implications

7.1 Observations concerning practices of SSOs and holders of SEPs

From the extensive analysis of availability of formal IT standards, which includes dialogues with SSOs, we find that organisations may face major challenges when trying to obtain and make use of complete technical specification(s) of IT standards that are provided by formal SSOs. We elaborate on three specific observations (see observation one to three below).

First, findings from the study show that complete technical specifications of formal standards may be purchased from SSOs for significant costs, especially when considering costs for purchasing all standard documents for all parts, versions, and editions of the complex standards being investigated in the study. Some of the investigated ISO standards are complex multi-part standards that have been published in several editions. Further, findings show that some standards lack complete technical specifications, something which confirms and extends previous results concerning a standard investigated in the present study. For example, in a previous study commissioned by the European Commission it has been reported that the ISO/IEC 29500 standard lacks a complete technical specification. Specifically, that study claims that the ‘technical specifications of this ISO standard include references to proprietary technology and brand names of specific products. Further, the specification of this ISO standard is not complete (i.e. the technical specification contains references to an external web site (www.microsoft.com) which refers to web pages that are not currently available.’ (Europe Economics, 2012, s. 16 (in footnote 32))

Second, for investigated ISO standards we find that the set of normative references included (either directly or indirectly via other ISO standards) in a standard may, for different reasons, over time become unavailable or change the complete technical specification of a given standard due to use of undated references. This causes uncertainty concerning availability and uncertainty concerning precisely what constitutes a complete technical specification of a specific standard at any given point in time, since the complete specification of a standard, in essence, becomes a moving target. For example, several new parts, editions, and amendments of the ISO/IEC 15938 standard (MPEG 7) have been published since it was included as an undated normative reference in the first edition of the ISO/IEC 15444-2:2004 standard. Further, several ISO standards included as dated normative references in the ISO/IEC 15444-2 standard have been withdrawn and are currently unavailable from the ISO website. Similarly, the publication of the ISO 19005-3:2012 standard includes a normative reference which describes ‘extensions to the PDF specification’ that Adobe has submitted to ISO (Adobe, 2009). These extensions are made available via the website provided by Adobe Corporation and contains detail concerning ‘the next version of the ISO 32000 specification’ (Adobe, 2009).

Third, in light of unavailability of normatively referenced standards (e.g. when normatively referenced standards have been withdrawn) and technical specifications which are moving targets (e.g. due to use of undated normative references which causes the top level standard to change) it follows that implementations become more complex and that a specific version of a software implementation of a standard, over time, will deviate from the standard (since its undated normatively referenced standards, over time, will change) even if it previously was considered a ‘perfect’ implementation of a specific standard. Further, there may be several reasons for why an organisation (intentionally or unintentionally) has implemented a technical specification of a standard in a way which deviates from the specification of the standard, and for reasons of interoperability (e.g. with other non-conforming implementations) there may be good reasons for why an organisation wishes to provide software which intentionally deviates from the specification. For example, a large number of files may have been produced by a specific version of a specific software that has features which deviate from the technical specification of a file format standard. In this interoperability scenario, it may be more important to develop an implementation of the standard which (intentionally) deviates from the standard and therefore implements the file format standard in a way that conforms to how other software works (even if their implementation deviates from the standard) and perhaps also to the way by which existing legacy files have been (and are being) produced by other software. Lack of precision in specifications of a standard may also contribute to incorrect and non-conforming implementations of standards. Results from the present study concerning lack of precision in specifications and its implications for implementation of the standard in software extend and are in line with previously reported results. For example, concerning the ISO/IEC 10918 standard it has been claimed by a representative for the technical working group involved with development of the standard that more than 20 years after the publication of the standard there is still no proper reference implementation of the standard and that there is a desire to develop such: ‘it may seem surprising that ISO/IEC never provided a reference software demonstrating a proper implementation of the standard, and as such, has given rise to third party implementations of ISO/IEC 10918 that, however, often implement the JPEG standard only incompletely, or sometimes even deviate from it. Given the market dominance of ISO/IEC 10918, it seems desirable to guide implementations to the correct implementation’ of this standard (ISO, 2017, p. 2) In addition, an analysis of the JPEG standard as defined in ITU T.81 and ISO/IEC 10918-1, ‘reveals that the way [in which] JPEG is used today deviates slightly from the original specification; it particularly goes beyond the specification, and – to a much larger degree – remains behind the possibilities of the old standard.’ (Richter and Clark, 2018, p. 1) For these reasons, it seems apparent that a transparent interpretation of the technical specification of a standard through establishment of an OSS project under the direction of the relevant SSO would contribute to conforming implementations and interoperability.

Further, from the extensive dialogues with a number of apparent SEP holders we find that the process of clarifying conditions for use of a formal standard to be notoriously complex. We elaborate on four specific observations (see observations four to seven below).

Fourth, from analysis of the dialogues with several organisations, we note that some organisations are very reluctant to assist in clarifying conditions for use of their asserted patent which may impinge on specific standards. We find that most organisations have failed to keep contact details and patent information up-to-date in patent databases. For these reasons, many requests sent by air mail to organisations have been returned, typically several months after a request has been sent. In some cases, letters sent by air mail have been returned more than six months after initially sent.

Fifth, findings from the study show that several organisations are reluctant to disclose the conditions under which they would be willing to provide a licence for their patents which allows for implementation of specific IT standards in software that is to be provided as an OSS project.

Sixth, the investigation of patent declarations for specific standards developed in joint working groups and provided by both SSOs involved (ISO and ITU-T) shows that there are inconsistencies between the patent databases that are maintained by ISO and ITU-T. Hence, some patent declarations that exist in the ISO patent database do not exist in the ITU-T patent database (and vice versa) for the same standard (e.g. ITU-T H.264 and ISO/IEC 14496-10) that has been developed in the joint working group. Similarly, for several standards we find that the content in the patent database contains inaccurate, outdated, and incomplete information, which contributes to uncertainty in any analysis. Further, even if an analysis of whether specific patents declared for the investigated standards actually impinge on the standards is out of scope for this study, from previous research it is clear that such analysis involves significant complexity. We find that these observations from the present study may have serious implications for any organisation attempting to implement a standard in software, something which has been noted in previous studies. For example, for patent declarations submitted to ISO concerning ISO/IEC 13817-7 and ISO/IEC 14496-3 for MPEG Audio technologies (i.e. two standards being analysed in the present study), a previous study ‘found that fewer than thirty patent declarations were submitted for the former and fewer than 200 were submitted for the latter.’ (Merges and Mattioli, 2017, p. 306) Further, the same study also found that ‘an outside law firm charged $7,500 per patent’ (as part of a bulk discounted rate) for evaluating the essentiality of proposed SEPs (Merges and Mattioli, 2017, p. 306). In addition, results from the present study show that in many cases the details concerning which specific patents are being declared as standard essential are missing and since non-participating organisations which may control SEPs cannot be forced to make declarations it follows that it is inherently unclear if all relevant declarations have been made for specific standards.

Seventh, in some cases we have observed behaviours amongst respondents which clearly indicate that they lack the willingness to clarify their intentions and the conditions under which they would be willing to provide patent licences. For example, some respondents have expressed clear preference for clarifying their intentions orally (via phone dialogues). During such dialogues with representatives for organisations which have declared that they hold SEPs, representatives respond in a way that makes it clear they are unwilling to clarify the conditions at an early stage, but instead seek to convey the assurance that there will be no issues later since, as claimed by respondents, it will always be possible to fulfil the initial request for patent licences at a later stage. Further, amongst organisations which expressed clear preference for clarifying their position and providing a response via a phone dialogue, one such organisation later also clarified that they found the request for patent licences under the three specific OSS licences is ‘burdened with royalty free patent clauses’ and clarified that the organisation is under no obligation to provide patent licences under a ‘royalty free offer’ that would fulfil the request. In acknowledging that this organisation is under no obligation to offer a licence that would allow for establishing the planned OSS project (as detailed in the initial request) we note that the dialogue with this organisation spanned more than one year before the negative response was received.

In essence, we find that observed practices and behaviour amongst some apparent SEP holders can be characterised as variations of two previously identified disruptive tactics (Merges and Kuhn, 2009). Specifically, these tactics have been characterised as follows: ‘(1) the “snake in the grass,” whereby a patentee intentionally keeps a patent “quiet” while a standard is being designed or adopted, and then later, after the standard is entrenched, asserts the patent widely in an attempt to capitalize on its popularity; (2) the “bait and switch” ploy where a patentee encourages adoption by offering royalty-free use of standard-related patents, and then, after the standard has gone into widespread use, begins to enforce its patents against adopters of the standard.’ (Merges and Kuhn, 2009, p. 4)

7.2 Implications for OSS projects

Organisations that have declared that they control SEPs which may impinge on a specific IT standard may choose to provide general patent licences. Such patent licences may be provided under terms which are inherently incompatible with OSS licences, perhaps due to provision of patent licences which may be revoked. For example, an organisation [19] which has declared to ISO that they control SEPs related to the ISO 32000-1:2008 standard provides a public patent licence for compliant implementations that ‘means the portion of an application, product, or service that reads, writes modifies or processes computer files compliant with the Specification.’ (Adobe, 2008) Further, the same patent licence states that the licence is only valid for compliant implementations of the specific version of the standard and the patent licence clarifies that ‘Specification means ISO 32000-1:2008 – PDF 1.7 published by the International Organization for Standardization (ISO). By way of example only, any updated version of ISO 32000-1 and any specification that incorporates ISO 32000-1:2008 by reference is not the Specification for purposes of this license.’ Hence, this particular patent licence is provided under terms which may be revoked and it seems that the licence is not applicable for a situation in which the ISO 32000-1:2008 standard is included as a normative reference in some other standard.

Failure to obtain all necessary rights for use and implementation of file formats and standards in software may have significant consequences. Previous research shows that patent infringement related to file format standards may attract significant damages. For example, as shown for the MP3 file format: ‘a district court awarded $1.52 billion in patent damages, the largest patent award in history, over infringement of the proprietary MP3 music format.’ (Merges and Kuhn, 2009, p. 49).

Findings from the study show that some declarations have been made in error and several declarations lack details. Further, since this study has not performed any analysis of the validity of specific patents related to specific standards we acknowledge that some requests for patent licences may have been sent to organisations that have declared that they control SEPs to ISO and ITU-T which may not actually qualify as standard essential at a detailed inspection. We consider such an analysis to be further work. We note that different stakeholders may have different motivations, as identified in previous research: ‘Implementers are unanimous in their opinions that too many patents are declared as standard essential. Indeed, many patent-holders also agree, explaining that this behaviour is dictated both by the desire to avoid charges of patent ambush and by the need to “stake out” a sufficient share of the total royalty stack that licensees end up agreeing to pay.’ (Régibeau et al., 2016, p. 62)

Previous research has identified risks related to changed strategies amongst organisations that control SEPs for widely deployed file formats and standards, which cause specific risks related to file formats and standards when all necessary rights cannot be obtained for implementation in OSS projects. For example, as elaborated by Merges and Kuhn (2009): ‘Suppose that Adobe suffered financial difficulty or bankruptcy and opted to modify its patent strategy. Seeking to cash in quickly on its market position, Adobe could drastically increase the price of its PDF-related software and pursue an aggressive patent enforcement strategy against others in the computer software industry. Large companies with millions of documents in PDF format that rely upon the full range of PDF features could have little choice but to pay whatever price Adobe charged, at least in the short term.’ (Merges and Kuhn, 2009, p. 2)

In light of current practice amongst apparent SEP holders, with the identified obstacles for clarifying conditions and obtaining patent licences, we find that for OSS projects it may be impossible to implement some formal standards in the current situation. Therefore, if SSOs and all apparent SEP holders would (legally) commit to the suggested practice of ‘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.’ (Li, 2018) However, we conjecture that for this to work in practice for OSS projects, it would require that SSOs and SEP holders are legally bound by such principles, perhaps under rules outlined as ‘option zero’ in previous research (Lundell et al., 2015).

7.3 Implications for standardisation

Findings show that there are mutual relationships and influences between technical specifications of standards and their implementation in software, which may include temporal complexity. For example, because Adobe’s implementation of early versions of the PDF file format pre-dated the standardisation of PDF by ISO, there is a natural tendency to assume that Adobe’s products embody a reference implementation, and that any third party software which adheres to a formal ISO standard (e.g. PDF 32000-1:2008), but which demonstrates incompatibilities with Adobe’s products is in itself defective. Therefore, it is, in practice, necessary not only implement the standard as specified in the technical specification, but also to ensure that the implementation also deals with any incompatibilities which arise because of the way in which Adobe’s software, as the widely-regarded reference implementation, deviates from the standard. This creates a further potential issue in that implementing technical deviations from the standard to accommodate the practicalities of the ecosystem in which the software is intended to operate means that the software developed will fall outside the strict specification, and therefore may no longer benefit from patent licences which only cover implementations of the standard.

Findings from the study primarily draw from an investigation which seeks to clarify conditions for implementing ISO and ITU-T standards in OSS projects. In light of the ample evidence from the study which identifies major inhibitors for obtaining patent licences that would allow for implementation of standards in OSS projects it should be noted that findings from the study, most likely, are more broadly applicable also for standards provided under FRAND-terms by other SSOs. For example, previous research shows that most SEPs are declared over ETSI (European Telecommunication Standards Institute) standards with ‘over 70% of all worldwide SEP declarations’ (Pohlmann and Blind, 2016, p. 11). Hence, it may be unsurprising that ‘early cases of tension between patents and standards’ (Bekkers et al., 2011) evolved in the late 1980s when ETSI developed GSM: it was reported that ‘the first major clash had occurred in the telecommunications sector’ (Bekkers et al., 2011).

Related to the investigated formal standards, findings from the study show that contact details provided in patent databases are outdated or incomplete for several apparent SEP holders. In some cases, it has been possible to obtain correct contact details by other means, but in several cases efforts have been unsuccessful and it has been impossible to obtain responses from several apparent SEP holders. Based on this, we find that it is an open question what an organisation that seeks to contact apparent SEP holders related to a formal standard can (and should) do?

Further, related to several investigated standards, findings from the study show that:

· patent details are missing for several declarations.

· some apparent SEP holders decline to respond to requests for patent licences.

· some apparent SEP holders (related to several investigated standards) are unwilling to negotiate and provide a patent licence related to their declaration.

Each of these findings presents a potential problem for the relevant SSO, and, by extension, potentially undermines the integrity of the standards system as a whole. If, for example, an organisation is unable to clarify the conditions under which it can implement a standard in software, this is a clear inhibitor to the effectiveness of the standard overall. This raises open questions as to what can an SSO do, and what should it do? Further, are SSOs even in a position to rectify these issues themselves, or is additional support (by means of legislation or treaty, for example) required?

Each of these findings also raises the open question of what can an organisation seeking to implement a standard in these circumstances do, and, further, what should it do?

Based on the identified inability for an organisation that seeks to clarify conditions for use of several formal IT standards for implementation in OSS projects, it is clear that there is stark tension between different interests and stakeholder roles. It is clear that different stakeholders have different preferences concerning the role of patents in standards and different SSOs have adopted different strategies for how to deal with patent issues. Hence, findings from our study are in line with earlier observations by Egyedi (2001): ‘The inclusion of patents is seen to be foremost in the interest of the IPR owners themselves (i.e., a standard results that makes the company’s R&D investment worthwhile and gives it a head start vis-a-vis competitors).’ (Egyedi, 2001, p. 110)

7.4 Implications for public procurement

Several of the investigated ISO standards are rather complex and some include normative references which are unavailable or withdrawn. This includes some normatively referenced ISO standards which have been withdrawn (and therefore are unavailable from the ISO online website). When ISO standards are withdrawn or unavailable it may be impossible to obtain a complete technical specification (at least in a short time-window) for an organisation that wishes to prepare a bid in a public procurement. This observation confirms previous results from a study commissioned by the European Commission which claims that requirements for a standard in a public procurement tender might restrict competition and reports that standards set through formal SSOs ‘may still contain barriers to implementation by all interested parties, may not be widely implemented by the market, or may not be implemented accurately according to the specifications.’ (Europe Economics, 2012, s. 16) Such observations may significantly inhibit implementation and distribution of this formal standard in software.

Further, findings show that in many cases it has been impossible to obtain responses from a number of apparent SEP holders, and that even if a response has been obtained, in some further cases, apparent SEP holders have declined to provide patent licences which would fulfil the requirement of the study (to enable the implementation of the standard under commonly used OSS licences). Our study allowed a period of over 12 months from the initial request to the apparent SEP holder, followed, by a series of reminders, and, where, possible, engagement with apparent SEP holders. Considering the findings from a potential public procurement perspective, it would therefore be impossible for most potential suppliers to a public sector body requesting bids for a project involving the implementation of a standard to be able to obtain the necessary patent licences within the limited time-window (rarely longer than 12 weeks) available to prepare a bid.

In addition to identified inhibitors for obtaining all patent licences for all SEPs which are declared in patent databases related to a specific IT standard it is critical to realise that there may also be SEPs which impinge on an IT standard that are not included in patent databases that are maintained by SSOs. Therefore, for any IT standard (including all its normative references) there is a need to also investigate, assess, and obtain all patent licences for all SEPs that are not included in patent databases[20].

Considering the challenges for obtaining all necessary rights for standards provided on FRAND-terms that have been identified in this study it may be unsurprising that one of the recommendations presented in a previous study commissioned by the Swedish competition authority concerning standard lock-in specifically addresses this challenge. The previous study recommends that a public sector organisation which needs to manage data and documents in closed file formats and closed standards (i.e. standards provided on FRAND-terms for which there exist apparent SEP holders), for whatever reason, needs to take proactive actions and ‘acquire before procurement all necessary rights (including all necessary patent licences) for these closed file formats so that they can be implemented in software that can be used and distributed under different licences (including all licences for open source software).’ (Lundell et al., 2016, p. 12) It should be noted that a public sector organisation may need to express requirements for standards provided under FRAND-terms in public procurement projects (e.g. in a scenario when files represented in closed file formats are received from other organisations).

7.5 Recommendations for improved licensing practices

It is clear that for any organisation, implementing a standard in software can be a lengthy and costly process. Where the standard is to be implemented in software to be distributed under OSS licences, this creates additional issues, not least because additional criteria imposed both by the licences, and by adherence to the OSD, are commonly incompatible with the patent licences which are offered by SEP holders. Findings from this study clearly show that the overwhelming majority of SEP holders would only be willing to provide patent licences which contain terms that are clearly incompatible with the OSD and it is clear that for all of the investigated formal standards it is impossible to obtain all necessary patent rights which would allow for implementation of any of the standards in an OSS project.

In an ideal world, from a procurement perspective, organisations would have access to an implementation of a standard which fulfils all the following: it is a faithful implementation, it is fast, efficient, of high quality, free-of-charge and it is updated reliably in response to reported bugs, security issues and updates to the standard, and it is maintained by a project structure with an open participation model and which is likely to subsist over time. Use of the implementation in its reference form (as updated from time to time) would automatically mean that the users would benefit from a licence offered by all SEP holders on a free-of-charge basis.

It has been observed (Perens, 2005) that open source development is best suited to projects which do not implement functionality which an organisation uses as a key differentiator in the marketplace. This means that OSS is suited to those areas of common interest to the participants in a market, but for which the reduced costs and associated benefits of collaborating in development are a more significant factor to the organisation than providing an advantage to competitors through the results of the collaboration. A standard may be regarded as a way of trying prevent differentiation, and for this reason, implementation of a standard is probably as far away from being a key differentiator as it is possible to get, and thus, following Perens (2005), collaborative development of an implementation of that standard would be a highly appropriate use of OSS.

We propose, therefore, that for each of the standards which have been the subject of this study, that an OSS project is established, potentially with the involvement of the SSO, to implement the standard in a reference implementation library. Those SEP holders which have declared a willingness to be involved in the project should then declare that they will automatically grant an appropriate royalty-free patent licence covering their SEPs to all users and implementers of the standard. This licence would cover the use of the then-current and any previous version of the reference implementation library. Holders of the SEPs for technical specifications which were normatively referenced within the standard would also be encouraged to grant an appropriate similar licence. This would automatically protect users of the reference implementation against claims that the reference implementation was somehow not completely compliant with the standard, as any use of the specific reference implementation would be covered. Any independent implementation which faithfully implements the standard would also be covered.

We recommend that a reference implementation itself be licensed under a copyleft licence, potentially one of the versions of LGPL or GPL. Implementation of a standard in an OSS project under a copyleft licence promotes continued compliance with the standard since contributions to the project’s code base (once accepted by the project managers) will become part of the project’s official release. This, in turn, supports clarity in interpretation of the documented technical specification of the standard, which in turn supports interoperability and conformant implementations of the standard.

Use of LGPL would ensure that those wishing to implement a standard in a proprietary product would not be discriminated against, in that they would not be required, when linking the library to their proprietary code, to release the source code of that code, or to license it in its entirety under the same licence. Their obligation would be limited to ensuring that a recipient of the software was able to re-link it to a modified version of the library if they wished to do so (provided that it had the same interface). Technically, this is generally quite straightforward (in many operating system implementations it is simply a case of making sure that the amended compiled library file – for MS Windows, this could be a ‘.DLL’ file – is placed in the same directory as the original). Alternatively, use of GPL would promote an entire standard conformant ecosystem when solutions are distributed, since when implementations of standards are provided under GPL it implies that associated applications would need to be provided under GPL when solutions are distributed. For public sector organisations, such policies may be desirable as it would tend to promote a commonly expressed public policy aim that works developed through public spending should remain a public good and accessible to all. In contrast, for companies which distribute proprietary software as part of their business offerings, this would challenge existing business models since it would require them to release their own code under the GPL (and provide the source code). In circumstances where the technical requirements cannot be fulfilled, there is nothing preventing the supplier from implementing the standard in software independently, albeit in this case it would have to approach the SEP holders for an appropriate licence.

One issue which would need clarifying is the so-called ‘Liberty or Death’ clause in the GPL family of licences (section 7 in the GPLv2, section 11 in LGPLv2.1, and section 12 in GPL and LGPL v3). This, coupled with the patent grant (implicit or explicit depending on GPL version), would potentially cause problems with SEP holders wanting to make their own modifications to the library, and distribute it, while at the same time wanting to limit the licence grant covering their SEPs to only cover the standard in question, and the specific ‘official’ reference implementation.

There are SEPs which insist on a licensing model which requires payment of royalties, usually on a FRAND basis. There is an inherent tension between those requirements, and the OSS licensing model. The model suggested would not be appropriate for them, but, in extremis, a failure to grant a licence on a royalty-free basis would prevent the standard in question from being validly regarded as a competition neutral open standard which requires equal treatment in public procurement practices and policy.

With reference to patent pools, such as MPEG LA, we note that the patent licences we have been referred to only cover a subset of all apparent SEPs and that their terms in no case allow for implementation in OSS projects as requested in this study.

7.6 Recommendations for policy

Findings from the study show that there are significant obstacles for organisations that seek to use formal standards which are provided under FRAND-terms. This may have significant implications when formal standards provided under FRAND-terms are included in national implementations of EU directives. For example, the study shows that it has been impossible to obtain patent licences from apparent SEP holders for the ISO 20022 standard despite the fact that this ISO standard is referenced in the Finnish implementation of an EU directive (Finland, 2018).

Hence, findings from the study suggest that public policy should promote use of open standards which allow for implementation in OSS projects. Such policy would be in line with a recommendation presented in a study commissioned by the Swedish competition authorities which focused on standard lock-in. Therefore, it may be unsurprising that a recommendation states that to ‘allow for interoperability and long-term digital preservation, use only open standards and open file formats which have been implemented in software and thus are possible to provide and distribute under different licences (including all licences for open source software).’ (Lundell and Gamalielsson, 2018, p. 6)

It should be noted that some scholars consider IPR issues and SEPs related to standards to constitute a ‘hypothetical problem’ (e.g. Kappos, 2018). However, in light of the significant obstacles identified when trying to clarify conditions and obtaining patent licences that would allow for implementation of ISO standards in OSS projects in this study, we find results from this study provide ample evidence which extends previous findings (Lundell et al., 2015, 2018). Specifically, we find that when SEPs impinge on ISO standards it is, in practice, impossible to implement such standards in OSS projects under any reasonable time-frame. In particular, in the context of a public procurement project results from this study show that when ISO standards are provided on FRAND-terms such cannot be implemented and provided as OSS projects and the consequence is that competition in such procurement projects will be limited to those potential suppliers that already had obtained all necessary rights and patent licences (or are willing to take a significant risk for patent infringement).

For these reasons, findings from the study provide ample evidence which suggests that there is a need to reconsider current regulations and policies related to use of standards provided under FRAND-terms in public procurement. Specifically, findings show that in order to avoid inhibiting competition in public procurement it should not be allowed for public sector organisations to undertake development and procurement projects which explicitly (or implicitly) express mandatory requirements for standards that are provided under FRAND-terms without first having obtained all necessary rights that allow for implementation of those standards in OSS projects that are to be distributed under any OSS licence on an open collaborative platform. Further, related to the competition aspect, and in light of identified obstacles concerning use of standards provided under FRAND-terms it should be noted that previous research (e.g. Bessen and Maskin, 2009) shows that the nature of innovation in the software industry may be inhibited by use of strong patents.

Further, based on experiences from previous commissioned research undertaken for a Swedish governmental agency by the researchers we have observed that such investigations can identify additional SEPs that have not been declared in patent databases maintained by SSOs. From this experience, we recommend that such an extended investigation needs to account for the fact that the IPR rules for SSOs lack an effective mechanism for obtaining all relevant information concerning patents which may impinge on specific standards from organisations that are not involved in the standardisation and the specific SSO. Further, it should be noted that ISO[21] (and other SSOs) acknowledge that the content in their patent database may be incomplete and that the information provided via the patent databases is ‘made available for information purposes only’. In addition, for conduct of such an investigation we also recommend to review publicly available information provided by SSOs and via other sources. This should include reported experiences from organisations involved with various projects (including standardisation projects and OSS projects) that implement technical specifications of standards in software projects from which software is distributed.

We also recommend that consideration is given to a framework for establishing the availability of a reference implementation of a standard by means of a library developed through an OSS project, possibly under an LGPL licence (as referred to in sub-section 7.5).

From the perspective of this study, it is anticipated that different individuals and organisations will engage with the planned OSS project for a number of reasons over time. When OSS will be distributed from an OSS project (for example, by making the source code publicly available on a repository such as GitHub) it is impossible to restrict and keep track of the number of copies being distributed (as an inherent property of the OSS licensing model implies that software will be distributed and redistributed in a cascade). The nature of this licensing model needs to be considered in any project planning to implement standards in an OSS project.

Findings from the study show that there are a number of factors which affect an organisation’s ability to obtain and make use of the complete technical specification of an IT standard (including all its normative references) and also the organisation’s ability to determine and assess the licence conditions under which it is able to implement an IT standard in a software project.

These findings highlight challenges for EU law for public procurement which for a number of years has aimed to achieve procurement practices that stimulate a fair and competitive market based on the important principles of transparency, non-discrimination and equal treatment (Directives 2004/17/EC and 2004/18/EC). These (and subsequent versions of these) EU directives clarify the public procurement process and how technical specifications can and shall be used in such processes. A key factor is that technical specifications ‘shall afford equal access for tenderers and not have the effect of creating unjustified obstacles to the opening up of public procurement to competition’. Further, these directives also clarify that a technical specification ‘shall not refer to a specific make or source, or to a particular process, or to trade marks, patents, types or a specific origin or production with the effect of favouring or eliminating certain undertakings or certain products.’ (Directive 2004/17/EC (Article 34) and Directive 2004/18/EC (Article 23)). There is, however, an exception and it is clarified that only on an ‘exceptional basis’ (e.g. when functional requirements cannot be described and for a subject-matter for which there is no international standard) public procurement may refer to specific trade marks and products. However, we stress that procurement of formal file format standards does not qualify as such an exception. Consequently, if a public procurement process refers to an ISO standard for which apparent SEP holders are unwilling to provide patent licences such practice inhibits competition in a way that fails to fulfil these public procurement principles and also the fundamental principle of equal treatment which applies to all public procurement projects undertaken in the EU.

8. Conclusions

The study reports from an investigation of formal standards which include (as normative references) a number of other file formats and standards that are provided under FRAND-terms. The study shows inaccurate and incomplete content in the patent databases maintained by SSOs, which is a significant inhibitor for clarifying conditions for use of specific IT standards. Consequently, this causes significant problems for any organisation that seeks to use standards provided under FRAND-terms.

Findings from the study show that formal standards provided under FRAND-terms cause significant obstacles for organisations that seek to implement such standards in software. This is particularly problematic for software which is to be developed as an open source software project and distributed under commonly-used open source software licences. When trying to obtain all necessary patent licences for a number of file format IT standards that would allow for implementation in software the study found that it was impossible to obtain all declared patent licences that would allow for implementation of investigated standards in open source software projects. This finding causes decision makers representing different stakeholders to worry since current practice amongst apparent SEP holders inhibits equal treatment in public procurement processes.

In a situation when an organisation that wishes to provide a bid in a public procurement project becomes excluded from doing so, perhaps because the organisation is unable to obtain all necessary patent licences for a closed formal standard provided under FRAND-terms which is referenced to as a mandatory requirement in the requirements for the public procurement, it follows that this organisation will be exposed to unequal treatment that is unlawful according to the fundamental principles for public procurement in the EU. On the other hand, it should be noted that this risk for unequal treatment in public procurement projects would be avoided if the requirements only express mandatory requirements for open IT-standards that are provided under Royalty-Free terms.

In conclusion, findings from the study suggest that policy makers need to reconsider current policies and legislation which allow for expressing (explicit or implicit) requirements for standards which are provided under FRAND-terms when public sector organisations undertake projects. Specifically, when a public sector organisation expresses a mandatory requirement for a formal (ISO) standard that is provided under FRAND-terms in a public procurement project it follows that the public sector organisation contributes to unequal treatment which inhibits competition since many potential suppliers will be excluded from providing a bid in the procurement. Results from the study clearly show that it is impossible, at least for all investigated formal standards provided under FRAND-terms, to obtain all necessary rights for use of required formal standards during the time-frame for any public procurement project.

Acknowledgements

This research has been financially supported by the Swedish Knowledge Foundation (KK-stiftelsen) and participating partner organisations in the LIM-IT project. The authors are grateful for the stimulating collaboration and support from colleagues and partner organisations.

References

Adobe (2008), ‘Adobe Systems Incorporated Public Patent License ISO 32000-1: 2008 – PDF 1.7’, Adobe Corporation, https://www.adobe.com/pdf/pdfs/ISO32000-1PublicPatentLicense.pdf

Adobe (2009), ‘Adobe Supplement to ISO 32000-1:2008, BaseVersion 1.7, ExtensionLevel 5’, Edition 2.0, June, http://www.adobe.com/devnet/acrobat/pdfs/adobe_supplement_iso32000_1.pdf

Aliprandi, S (2011), ‘Interoperability And Open Standards: The Key To True Openness And Innovation’, International Free and Open Source Software Law Review, Vol. 3(1), pp. 5-24.

Almunia, J (2012), ‘Competition enforcement in the knowledge economy’, Speech/12/929, Vice President of the European Commission responsible for Competition Policy, European Commission, 20 September.

Atlass, M, Kappos, D and Bassey, P (2017), ‘Interoperating Standards: Formal, Informal and Open Source Development Model Ecosystems in Transition’, IEEE Communications Standards Magazine, Vol. 1(4), pp. 49-53.

Baron, J, Pohlmann, T and Blind, K (2016), ‘Essential patents and standard dynamics’, Research Policy, Vol. 45(9), pp. 1762-1773.

Bekkers, R, Bongard, R and Nuvolari, A (2011), ‘An empirical study on the determinants of essential patent claims in compatibility standards’, Research Policy, Vol. 40(7), pp. 1001-1015.

Bekkers, R and Updegrove, A (2012), ‘A study of IPR policies and practices of a representative group of Standards Setting Organizations world’, Commissioned by the US National Academies of Science, Board of Science, Technology, and Economic Policy (STEP), Project on Intellectual Property Management in standard-setting processes, 17 September.

Bekkers, R and Updegrove, A (2013), ‘IPR Policies and Practices of a Representative Group of Standards-Setting Organizations Worldwide’, Commissioned by the Committee on Intellectual Property Management in Standard-Setting Processes, National Research Council, Washington, May.

Bekkers, R and West, J (2009), ‘The limits to IPR standardization policies as evidenced by strategic patenting in UMTS’, Telecommunications Policy, Vol. 33(1-2), pp. 80-97.

Bessen, J and Maskin, E (2009), ‘Sequential innovation, patents, and imitation’, RAND Journal of Economics, Vol. 40(4), pp. 611-635.

Blondelle, G, Arbaret, P, Rossignol, A, Lundell, B, Labezin, C, Berrendonner, R, Gaufillet, P, Faudou, R, Langlois, B, Maisonobe, L, Moro, P, Rodriguez, J, Puerta Pena, J-M, Bonnafous, E, Toupin, D and Mueller, R (2012), ‘Polarsys Industry Working Group (Formerly known as OPEES): Using Open Source strategies to tackle very long term support issues for Embedded Software’, In Embedded World 2012, 28 February-1 March.

Braa, K and Vidgen, R (1999), ‘Interpretation, intervention, and reduction in the organizational laboratory: a framework for in-context information system research’, Accounting, Management

& Information Technology, Vol. 9(1), pp. 25-47.

Brooks, R G and Geradin, D (2011), ‘Interpreting and Enforcing the Voluntary FRAND Commitment’, International Journal of IT Standards and Standardization Research, Vol. 9(1), pp. 1-

23.

BSI (2012), Pocket Guide to Standards Development, BSI Standards Limited, (London: The British Standards Institution).

Carrier, M A (2012), ‘A Roadmap to the Smartphone Patent Wars and FRAND Licensing’, CPI Antitrust Chronicle, Competition Policy International, April.

Chappatte, P (2009), ‘Frand Commitments–The Case for Antitrust Intervention’, European Competition Journal, Vol. 5(2), pp. 319-346.

Chia, T H (2012), ‘Fighting the Smartphone Patent War with RAND-Encumbered Patents lark’, Berkeley Technology Law Journal, Vol. 27(4), Article 3, pp. 209-240.

Choung, J-Y, Hameed, T and Ji, I (2012), ‘Catch-up in ICT standards: Policy, implementation and standards-setting in South Korea’, Technological Forecasting & Social Change, Vol. 79(4), pp. 771-788.

Contreras, J L (2015), ‘A Brief History of FRAND: Analyzing Current Debates in Standard Setting and Antitrust Through a Historical Lens’, Antitrust Law Journal, Vol. 80(1), pp. 39-120.

Contreras, J L (2016), ‘Patents and Internet Standards, Centre for International Governance Innovation and Chatham House’, Paper Series No. 29, April.

EC (2011), ‘Guidelines on the applicability of Article 101 of the Treaty on the Functioning of the European Union to horizontal co-operation agreements’, Official Journal of the European Union, Volume 54 (C 11), European Commission, 14 January.

EC (2012), ‘Implementing FRAND standards in Open Source: Business as usual or mission impossible?’, Report summary from a workshop organised by the European Commission (EC) and the European Patent Office, Brussels, 22 November.

EC (2016), ‘ICT Standardisation Priorities for the Digital Single Market, Communication from the Commission to the European Parliament’, the Council, the European Economic and Social Committee and the Committee of the regions, COM(2016) 176 final, European Commission, 19 April.

EC (2017), Commission Recommendation (EU) 2017/1805 of 3 October 2017 on the professionalisation of public procurement – Building an architecture for the professionalisation of public procurement, 3 October, Official Journal of the European Union, L259/28.

EC (2018a), ‘Rolling Plan for ICT standardisation 2018’, European Commission, Ref. Ares(2018)1616948, 23 March.

EC (2018b), ‘JRC Study on the Interaction between Open Source Software and FRAND licensing in Standardisation’, European Commission, EU Science Hub, 10 July,

Egyedi, T M (2001), ‘IPR Paralysis in Standardization: Is Regulatory Symmetry Desirable?’, IEEE Communications Magazine, Vol. 39(4), pp. 108-114.

ETSI (2019a), ‘OSM License’, The European Telecommunications Standards Institute, https://osm.etsi.org/about/osm-license (accessed 7 May 2019)

ETSI (2019b), ‘Open Source MANO’, The European Telecommunications Standards Institute, https://osm.etsi.org/ (accessed 7 May 2019)

EU (2004), ‘European Interoperability Framework for pan-European eGovernment Services’, Version 1.0, European Commission, ISBN 92-894-8389-X.

EU (2017a), ‘Tallinn Declaration on eGovernment at the ministerial meeting during Estonian Presidency of the Council of the EU on 6 October’, 2017EU2017.EE.

EU (2017b), ‘Online catalogue of ICT standards for procurement’, European Commission, https://joinup.ec.europa.eu/community/european_catalogue/

Europe Economics (2012), ‘Guide for the procurement of standards-based ICT: Elements of Good Practice’, D2 – Overview of Procurement Practices, Final Report, Study for the EU, Action 23, 1 March.

Fanning, B A (2008), ‘Preserving the Data Explosion: Using PDF’, DPC Technology Watch Series Report 08-02, April, Digital Preservation Coalition & AIIM 2008.

Farrell, J, Hayes, J, Shapiro, C and Sullivan, T (2007), ‘Standard setting, patents, and hold-up’, Antitrust Law Journal, Vol. 74(3), pp. 603-670.

Finland (2018), ‘Regeringens proposition till riksdagen med förslag till lag om ett övervakningssystem för bank- och betalkonton och till vissa lagar som har samband med den’, Regeringsproposition, RP 167/2018 rd.

Fitzgerald, A and Pappalardo, K (2009), ‘Moving Towards Open Standards’, SCRIPted, Vol. 6(2), pp. 467-483.

Gamalielsson, J and Lundell, B (2017), ‘On licensing and other conditions for contributing to widely used open source projects: an exploratory analysis’, In Proceedings of the 13th International

Symposium on Open Collaboration (OpenSym ‘17), (New York: ACM), Article 9, 2007, 14p.

Geradin, D (2013), ‘Ten Years of DG Competition Effort to Provide Guidance on the Application of Competition Rules to the Licensing of Standard-Essential Patents: Where Do We Stand?’, Research Roundtable on Innovation and Technology Standards, February 7-8, 2013, Searle Center on Law, Regulation, and Economic Growth, Northwestern University School of Law.

Ghosh, R A (2005), ‘Open Standards and Interoperability Report: An Economic Basis for Open Standards’, FLOSSPOLS, Deliverable D4, MERIT, University of Maastricht, December.

Glader, M (2010), ‘Open Standards: Public Policy Aspects and Competition Law Requirements’, European Competition Journal, Vol. 6(3), pp. 611-648.

Graham, C, Morton, J, Watson, C and Healey, D (2013), ‘Standard setting, competition law and FRAND licensing in Europe and the United States’, In Intellectual Property in Electronics and Software: A Global Guide to Rights and Their Applications, (London: Globe Business Publishing), ISBN: 9781905783960, pp. 31-60.

Heiden, B (2016), ‘The viability of FRAND: How the seminal landmark Microsoft ruling could impact the value of standard essential patents and the future of telecom standards’, Telecommunications Policy, Vol. 40, pp. 870-887.

ISO (2001), ‘Rules for the structure and drafting of International Standards’, ISO/IEC Directives, Part 2, Fourth edition.

ISO (2015), ‘Guidelines for Implementation of the Common Patent Policy for ITU-T/ITU-R/ISO/IEC’, Revision 2, effective 26 June.

ISO (2017), JPEG Reference Software Call for Proposals, ISO/IEC JTC 1/SC29/WG1 N76028, 76th Meeting, Torino, Italy 17-21 July 2017.

ISO (2018), ‘Principles and rules for the structure and drafting of ISO and IEC documents’, ISO/IEC Directives, Part 2, Eight edition.

ISO (2019a), ‘BSI: United Kingdom’, International Organization for Standardization.

https://www.iso.org/member/2064.html (accessed 7 May 2019)

ISO (2019b), ‘ISO Store FAQs’, International Organization for Standardization, https://www.iso.org/shopping-faqs.html (accessed 7 May 2019)

ISO (2019c), ‘ISO Standards and Patents’, ISO, http://www.iso.org/iso/standards_development/patents (accessed 20 May 2019)

ITU (2018), ‘Guidelines for Implementation of the Common Patent Policy for ITU-T/ITU-R/ISO/IEC’, Edition 4.0 (published third revision), 2 November, International Electrotechnical Commission, International Organization for Standardization, International Telecommunication Union.

Kappos, D J (2017), ‘Comment – Open Source Software and Standards Development Organizations: Symbiotic Functions in the Innovation Equation’, The Columbia Science & Technology Law Review, Vol. XVIII, stlr.org, Spring, pp. 259-267.

Kappos, D J (2018), ‘The Antitrust Assault on Intellectual Property’, Harvard Journal of Law & Technology, Vol. 31(2), Spring, pp. 665-686.

Keeler, R D (2013), ‘Why Can’t We Be (F)RANDs?’: The Effect of Reasonable and Non-Discriminatory Commitments on Standard-Essential Patent Licensing, Cardozo Arts & Entertainment Law Journal, Vol. 32(1).

Kesan, J (2011), ‘The Fallacy of OSS Discrimination by FRAND Licensing: An Empirical Analysis’, Illinois Public Law and Legal Theory, Research Papers Series No. 10-14.

Kesan, J P and Hayes, C M (2014), ‘FRAND’s Forever: Standards, Patent Transfers, and Licensing Commitments’, Indiana Law Journal, Vol. 89(1), pp. 231-314.

Knable Gotts, I and Sheer, S (2012), ‘The Particular Antitrust Concerns with Patent Acquisitions’, Competition Law International, August, pp. 30-38.

Larouche, P and Van Overwalle, G (2014), ‘Interoperability standards, patents and competition policy’, TILEC Discussion paper, DP 2014-050, December, ISSN 1572-4042, ISSN 2213-9419.

Lerner, J and Tirole, J (2015), ‘Standard-Essential Patents’, Journal of Political Economy, Vol. 123(3), pp. 547-586.

Li, J (2018), ‘Intellectual property licensing tensions: utilising open source software in the formal standard-setting context’, European Journal of Law and Technology, Vol. 9(2), 2018.

Lindberg, V (2019), ‘Comment – OSS and FRAND: Complementary Models for Innovation and Development’, The Columbia Science & Technology Law Review, Vol. XX, Spring, stlr.org., pp. 251-270.

van der Linden, F, Lundell, B and Marttiin, P (2009), ‘Commodification of Industrial Software: A Case for Open Source’, IEEE Software, Vol. 26(4), pp. 77-83.

Liu, G, Gao, P, Chen, F, Yu, J and Zhang, Y (2018), ‘Technological innovation systems and IT industry sustainability in China: A case study of mobile system innovation’, Telematics and Informatics, Vol. 35(5), pp. 1144-1165.

Lundell, B (2011), ‘e-Governance in public sector ICT procurement: what is shaping practice in Sweden?’, European Journal of ePractice, Vol. 12(4), pp. 66-78.

Lundell, B (2012), ‘Why do we need Open Standards?’, In Orviska, M. and Jakobs, K. (Eds.), Proceedings 17th EURAS Annual Standardisation Conference ‘Standards and Innovation’, (Aachen: The EURAS Board Series), ISBN: 978-3-86130-337-4, pp. 227-240.

Lundell, B and Gamalielsson, J (2017), ‘D8.8 – Monitoring of the Open Source Project implementation’, Revision: version 2.1 (final version), PREFORMA Deliverable D8.8, PREservation FORMAts for culture information/e-archives, European Commission Grant agreement no: 619568, Seventh Framework Programme, 21 February, http://www.preforma-project.eu/uploads/deliverables/PREFORMA_D8.8_Monitoring-of-the-Open-Source-Project-implementation_v2.1.pdf

Lundell, B and Gamalielsson, J (2018), ‘Sustainable digitalisation through different dimensions of

openness: how can lock-in, interoperability, and long-term maintenance of IT systems be addressed?’, In Proceedings of the 14th International Symposium on Open Collaboration (OpenSym ‘18), (New York: ACM), ISBN: 978-1-4503-5936-8, Article 3, 2018, 10p.

Lundell, B, Gamalielsson, J and Katz, A (2015), ‘On implementation of Open Standards in software: To what extent can ISO standards be implemented in open source software?’, International Journal of Standardization Research, Vol. 13(1), pp. 47-73.

Lundell, B, Gamalielsson, J and Katz, A (2018), ‘On Challenges for Implementing ISO Standards in Software: Can Both Open and Closed Standards Be Implemented in Open Source Software?’, In Jakobs, K. (Ed.) Corporate and Global Standardization Initiatives in Contemporary Society, (Hershey: IGI Global), ISBN 9781522553205, pp. 219-251.

Lundell, B, Gamalielsson, J and Tengblad, S (2016), ‘IT-standarder, inlåsning och konkurrens: En

analys av policy och praktik inom svensk förvaltning’, Uppdragsforskningsrapport 2016:2,

Konkurrensverket, ISSN: 1652-8089, 2016 (in Swedish, with an executive summary in English).

Lundell, B, Gamalielsson, J, Tengblad, S, Yousefi, B H, Fischer, T, Johansson, G, Rodung, R, Mattsson, A, Oppmark, J, Gustavsson, T, Feist, J, Landemoo, S and Lönroth, E (2017), ‘Addressing lock-in, interoperability, and long-term maintenance challenges through Open Source: How can companies strategically use Open Source?’, In Balaguer et al. (Eds.) The 13th International Conference on Open Source Systems (OSS 2017), IFIP AICT 496, (Cham: Springer), pp. 80-88.

Lundell, B and van der Linden, F (2013), ‘Open Source Software as Open Innovation: Experiences from the Medical Domain’, In Eriksson Lundström, J.S.Z., Wiberg, M., Hrastinski, S., Edenius, M. & Ågerfalk, P. J., (Eds.) Managing open innovation technologies, (Berlin: Springer), pp. 3-16.

Lundell, B, Lings, B, and Syberfeldt, A (2011), ‘Practitioner Perceptions of Open Source Software in the Embedded Systems Area’, Journal of Systems and Software, Vol. 84(9), pp. 1540-1549.

Mair, C (2012), ‘Openness, Intellectual Property and Standardization in the European ICT Sector’, IP Theory, Vol. 2(2), pp. 52-71.

Maldonado, K (2014), ‘Breaching RAND and Reaching for Reasonable: Microsoft v. Motorola and Standard-Essential Patent Litigation’, Berkeley Technology Law Journal, Vol. 29(4), pp. 419-464.

Meeker, H (2017), Open (Source) for Business: A Practical Guide to Open Source Software Licensing, Second edition, (North Charleston: CreateSpace Independent Publishing Platform), ISBN-13: 978-1544737645.

van der Meer, J (2014), ‘Fundamentals and Evolution of MPEG-2 SYSTEMS: Paving the MPEG Road’, (Chichester: John Wiley & Sons), ISBN: 9780470974339.

Merges, R P and Kuhn, J M (2009), ‘An Estoppel Doctrine for Patented Standards’, California Law Review, Vol. 97(1), pp. 1-50.

Merges, R P and Mattioli, M (2017), ‘Measuring the Costs and Benefits of Patent Pools’, Ohio State Law Journal, Vol. 78(2), pp. 281-347.

Miller, J S (2007), ‘Standard Setting, Patents, and Access Lock-In: Rand Licensing and the Theory of the Firm’, Indiana Law Review, Vol. 40(2), pp. 351-395.

Netherlands (2007), ‘The Netherlands in Open Connection: An action plan for the use of Open Standards and Open Source Software in the public and semi-public sector’, The Ministry of Economic Affairs, The Hague, November.

NPS (2016), ‘Open IT-standards’, National Procurement Services, Kammarkollegiet, 7 March 2016, Dnr 96-38-2014, https://www.avropa.se/globalassets/dokument/open-it-standards.pdf

OSD (2019), ‘The Open Source Definition’, Open Source Initiative, https://opensource.org/osd

OSI (2019), Open Source Initiative, http://opensource.org/

OTD (2011), ‘Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software’, 16 May, Sponsored by the Assistant Secretary of Defense (Networks & Information Integration) (NII) / DoD Chief Information Officer (CIO) and the Under Secretary of Defense for Acquisition, Technology, and Logistics (AT&L).

Perens, B (2005), ‘The emerging economic paradigm of Open Source’, First Monday, Special Issue #2: Open Source, 3 October, https://doi.org/10.5210/fm.v0i0.1470

Phipps, S (2017), ‘Permissive and Copyleft Are Not Antonyms’, Meshed Insights, 4 April.

https://meshedinsights.com/2017/04/04/permissive-and-copyleft-are-not-antonyms/

Phipps, S (2019), ‘Open Source and FRAND: Why Legal Issues Are The Wrong Lens’, OpenForum Academy, Open Forum Europe, March. http://www.openforumeurope.org/wp-content/uploads/2019/03/OFA_-_Opinion_Paper_-_Simon_Phipps_-_OSS_and_FRAND.pdf

Pentheroudakis, C and Baron, J A (2017), ‘Licensing Terms for Standard Essential Patents: A Comprehensive Analysis of Cases’, JRC Science for policy report, European Commission, ISBN 978-92-79-64458-0, ISSN 1831-9424.

Permanent Representatives Committee (Part 1) (2016), ‘Draft Council conclusions on the “Digital Single Market Technologies and Public Services Modernisation” package – Statement by the United Kingdom, Estonia, Belgium, Slovenia, Poland, Latvia and Malta’, 8735/16 ADD 1, 26 May, Brussels.

Peterson, S K (2018), ‘Why so little love for the patent grant in the MIT License?’, 23 March, OpenSource.com, https://opensource.com/article/18/3/patent-grant-mit-license

Pohlmann, T and Blind, K (2016), ‘Landscaping study on Standard Essential Patents (SEPs)’, IPlytics GmbH & Technical University of Berlin, Commissioned by DG GROW Unit F.5 Intellectual Property and Fight Against Counterfeiting, European Commission.

Ratliff, J and Rubinfeld, D L (2013), ‘Use and Threat of Injunctions in the RAND Context’, Journal of Competition Law & Economics, Vol. 9(1), pp. 1-22.

Régibeau, P, De Coninck, R and Zenger, H (2016), ‘Transparency, Predictability, and Efficiency of SSO-based Standardization and SEP Licensing: A Report for the European Commission’, Prepared for the Executive Agency for Small and medium-sized enterprises on behalf of the European Commission as part of Specific Contract No 07/2015 Implementing Framework Contract No MARKT/2011/022/B2/ST/FC, Ref. Ares(2016)6908173 – 12/12/2016, Charles River Associates, June.

Richter, T and Clark, R (2018), ‘Why JPEG is not JPEG – Testing a 25 years old Standard’, In

Proceedings of 2018 Picture Coding Symposium (PCS), (Piscataway: IEEE), ISBN: 978-1-5386-4160-6, 2018, pp. 1-5.

Rothenberg, J (1999), ‘Ensuring the Longevity of Digital Information’, Revision 22 February, an expanded version of the article “Ensuring the Longevity of Digital Documents” that appeared in the January 1995 edition of Scientific American (Vol. 272, Number 1, pp. 42-47).

Shah, R and Kesan, J (2012), ‘Lost in Translation: Interoperability Issues for Open Standards’, I/S: A Journal of Law and Policy for the Information Society, Vol. 8(1), pp. 113-141.

Shapiro, C and Varian, H R (1999), ‘The Art of Standards War’, California Management Review, Vol. 41(2), pp. 8-32.

Simcoe, T S, Graham, S J H and Feldman, M P (2009), ‘Competing on standards? entrepreneurship, intellectual property and platform technologies’, Journal of Economics & Management Strategy, Vol. 18(3), pp. 775-816.

TLP (2015), ‘Legal Provisions Relating to IETF Documents’, IETF Trust, 25 March 2015.

Trappey, A J C, Trappey, C V, Govindarajan, U H, Chuang, A C and Sun, J J (2017), ‘A review of essential standards and patent landscapes for the Internet of Things: A key enabler for Industry 4.0’, Advanced Engineering Informatics, Vol. 33, pp. 208-229.

Treacy, P and Lawrance, S (2008), ‘FRANDly fire: are industry standards doing more harm than good?’, Journal of Intellectual Property Law & Practice, Vol. 3(1), pp. 22-29.

UK (2015), ‘Open Standards Principles’, Updated 7 September 2015, HM Government, UK.

de Vries, H (2006), ‘IT Standards Typology’, In Jakobs, K. (Ed.) Advanced Topics in Information Technology Standards and Standardization Research: Volume 1, (Hershey: Idea Group Publishing), ISBN 1-59140-938-1, pp. 1-26.

Yoshimatsu, I (2012), ‘Global Standardization Activities: Revision of the Common Patent Guidelines for ITU/ISO/IEC’, NTT Technical Review, Vol. 10(11), pp. 1-3.



[1] Björn Lundell (University of Skövde, Sweden), Jonas Gamalielsson (University of Skövde, Sweden) and Andrew Katz (University of Skövde, Sweden, Moorcrofts LLP, UK)

[2] The acronym ‘FRAND’ is commonly referred to as Fair, Reasonable and Non-Discriminatory (Contreras, 2015). In addition to FRAND, the term RAND is also used when referring to ‘Reasonable and Non-Discriminatory’. However, it has been argued that ‘what makes a license RAND is notoriously undefined’ (Keeler, 2013, s. 319). Further, according to Contreras (2015), FRAND and RAND are considered as ‘two competing formulations that do not seem to have a meaningful difference’ (Contreras, 2015, p. 39). For the rest of this paper, we will use ‘FRAND’ when referring to this concept.

[3] Specifically, the study found that ‘eight of the ten examined IPR policies make no mention of whether normatively referenced standards are to be covered by IPR policy obligations.’ (Bekkers and Updegrove, 2012, p. 42)

[4] https://gcc.gnu.org/

[5] https://www.kernel.org/

[6] https://cloudstack.apache.org/

[7] https://www.freebsd.org/

[8] https://www.bouncycastle.org/

[9] It should be noted that some scholars consider standards provided on FRAND-terms as, generally, unproblematic for OSS. For example, Kappos (2017) claims that permissive OSS licences ‘are fully compatible with FRAND licensing’ (p. 264). However, it should noted that FRAND licensing is seen as incompatible with the Apache 2.0 licence (a widely used OSS licence that is considered as a permissible OSS licence amongst most other scholars) by Kappos (2017).

[10] Also referred to as ‘The 3-Clause BSD License’ (OSI, 2019).

[11] Also referred to as ‘The 2-Clause BSD License’ (OSI, 2019).

[12] https://opensource.org/licenses/GPL-3.0

[13] https://opensource.org/licenses/MPL-2.0

[14] https://opensource.org/licenses/Apache-2.0

[15] Some investigated standards (e.g. ISO/IEC 14496-10) are jointly developed and provided by ISO and ITU-T.

[16] It should be noted that the research method used for investigation of standards provided by other SSOs (e.g. ITU-T) that also maintain a patent database have been very similar. For example, since different SSOs have slightly different rules and strategies for maintenance of their patent databases, this obviously impacts on the analysis. However, the level of granularity in the recommendations presented are general enough to also be applicable for investigations of standards from other SSOs.

[17] Since the ISO/IEC 15444-2:2004 standard includes undated normative references it follows that the set of normatively referenced specifications will evolve and be extended over time.

[18] The clarification concerning use of undated references provided in the eighth edition of part 2 of the ISO rules (ISO, 2018, p. 31) has remained the same (in every edition) since the fourth edition (ISO, 2001, p. 20).

[19] The company Adobe Systems International provides a public patent licence which states that ‘Adobe grants every individual and organization in the world the royalty-free right, under all Essential Claims that Adobe owns, to make, have made, use, sell, import and distribute Compliant Implementations.’ (Adobe, 2008)

[20] Based on previous experiences from the researchers’ own work, we acknowledge that such an investigation is critical to undertake for any organisation that aims to implement standards in software. However, such an extended investigation is beyond the scope of the study reported on in this paper.

[21] https://www.iso.org/iso-standards-and-patents.html