Imagine finding out that 90 percent of the software in your products is protected by third-party intellectual property (IP). You are relieved when you learn that such IP is licensed to your company. However, as soon as you start reading the agreements, you realize some of them contain terms you are not familiar with or have never even heard of before such as “source code,” “binary,” “object code,” and “system libraries.” Moreover, you cannot find any basic contractual provisions such as “governing law” or “jurisdiction” in the agreements. The reason, you are being told, is that your company had no chance to negotiate the terms, but was rather presented with “take it or leave it” standard template licenses, which differ from each other.

After this unsettling discovery, your journey may look similar to the five stages of grief: Firstly, you tell yourself that the above cannot be true (denial). Later on, you rightly become angry; “Surely someone must be responsible for this.” So, you take the elevator down to the software development team to read them the riot act (anger). Once there, you promise to put a good word to their managers if they—please!—stop bringing in all this third-party IP under these strange software licenses (bargaining). If you are not outright laughed out of the room, they will reply that “this is not going to happen if the company wants to continue to ship any products at all. Our management is actually telling us to use even more of this stuff!” You go back to your office, perhaps passing by the coffee machine, dejectedly thinking that at least the coffee machine people do not have to deal with this issue (depression). You would be wrong though since the coffee machine uses the same kind of third-party IP under the same kind of licenses as whatever product your company develops. Hopefully, you will eventually come out on the other side, realizing that you must manage this strange third-party IP dependency. You can do it, you just need to be smart about it and come up with the right tools, processes, and strategies to do so (acceptance)! We are here of course talking about open source, and you have just passed the five stages of open source grief. In this article we would like to make the case that open-source management is a necessary part of IP management and provide you with a good starting point for a systematic approach to open source management.

More than 10 years ago, Marc Andreessen commented that software is eating up the world.¹ The intervening period has proven him right. Nowadays one could even say that it is a particular flavor of software, i.e., “open source,” which is playing that role. If you think about it, you and I use open source every day. For instance, we wrote this article with the help of open source. And, unless you are holding the hardcopy version of les Nouvelles, you are also most likely using open source to read this. As you will soon discover, there are many other examples.

The term “open source” refers to software available under an open source license, usually without monetary compensation for its distribution, use, modification and re-distribution. Most of the applications that run in our smartphone or computer contain some open source.² For example, the Google Chrome browser— used by approximately 65 percent of internet browser users³ —makes everyone an open source user because it is based on the Chromium open source project.⁴ Similarly, the popular Android operating system⁵ is also based on an open source project. Even things we do not think about as being particularly “open,” such as our smart washing machines, our home automation systems, or for that matter, parts of the telecom infrastructure equipment handled by carriers, are built upon open source software.

Telecommunication standards such as 4G and 5G allow us, amongst others, to communicate, play games, order our favorite meal with just a few clicks, attend a virtual doctor’s appointment and work remotely. Every year billions of devices are becoming interconnected and part of the Internet of Things (IoT).⁶ It is expected that between 2023 and 2024, an additional five billion devices will become IoT-connected.⁷ There is little doubt that many will be using open source. In reality, the availability and combination of open standards, such as 4G and 5G, with open source will be necessary for these five billion new devices to become connected and part of the Internet of Things. This may support the estimation of the Linux Foundation⁸ (a non-profit organization that assists open source communities and facilitates the creation and management of open source projects) that the value of annual working hours contributed to open source projects it hosts globally is more than $26 billion USD.⁹

In the meantime, companies have realized the relevant implications of open source for IP management, with the current industry trend of high accumulation of software in general and open source components in particular, in any given product. More often than not, open source gets entangled with IP rights such as copyright, trade secrets, trademarks, and patents. Companies indeed face major dependencies on third-party IP for their use of open source in their products. The reason is that, regardless of the industry they are active in, there are only a few products or value chains that do not incorporate any software elements.

Consequently, to succeed in the market, companies must address their open source dependency, not only from technology, security and trade compliance perspectives, but also from an IP management angle. Surprisingly, companies are oftentimes neither prepared nor well positioned to do so. Thus, the fulfillment of their license obligations and/or their deployment of products and/or services may be negatively impacted.

Against this background, this article describes the significance of IP management in the context of open source, and why it should be considered as an essential part of any quality IP management program. With this in mind, we would like to introduce you to the OpenChain Specification 2.1 (ISO/IEC 5230:2020)¹⁰ on open source license compliance, and the benefits of implementing such a program in a corporate environment.

We live in a world dominated by the knowledge economy, where innovations translated into intangible assets are the drivers of economic and societal development. In this regard, the success of a business is often linked with its ability to create and exploit IP for the purposes of generating income.¹¹ As important as it is for a company to commercialize its own IP, it also needs to utilize IP generated by others, such as partners and competitors. One of the powerful aspects of capturing innovation in the form of IP is the ability to share it with others through licensing agreements, effectively controlling access to it. That being the case, IP is considered an invaluable resource for innovation- oriented stakeholders regardless of their area of business, growth or method of operation. Despite the incremental economic relevance of IP, many companies have not yet adopted systematic and reliable IP management processes.

Each company creates its own individual business strategy that corresponds to its objectives. Such a strategy should include IP, meaning, among other things, the manner according to which the IP assets of the company are created and managed. There should be two foundations to this end: (i) the establishment of processes for adhering to regulatory and/or contractual obligations (e.g., through the operation of a system for IP screening and archiving) and (ii) the establishment of training programs to improve IP awareness within an organization. The aim of an IP management program is better served following a high-level set of requirements that are implemented in a manner suitable for the needs of each company.

In short, IP management is a set of structured processes designed to handle the IP that is part of a company’s product or research and development (R&D) flow. Its goal is to maximize the capture and utilization of one’s own IP and mitigate the risks associated with the use of third-party IP.¹²

1. Risk Management
A structured IP management process can generate multiple positive effects for a business. Firstly, it increases the certainty within the organization in a two-fold manner: (i) its own IP rights can be precisely defined and adequately protected; and (ii) third-party IP is successfully identified so that the necessary rights of use can be secured. Moreover, efficient risk management often leads to reduced liability, minimization of future errors and increased efficiencies in terms of IP handling.

A case in point: it is standard practice in technology transfer licenses for the licensee to be subject to annual (or even biannual) audits to ensure compliance with the conditions of the license. In the case of such audits, a company with successful management procedures in place should respond swiftly and efficiently. Similarly, such management procedures could be of benefit, for example, during supplier audits. Additionally, good IP management mechanisms can be vital in a merger and acquisition (M&A) framework, both for the buyer and the target company. The due diligence process is expected to run much more smoothly when the IP-related risks are reduced or are easily diagnosed and resolved.

2. Housekeeping
In addition, the implementation of comprehensive processes for managing business input and output with respect to IP should be considered as best practice for corporate-level housekeeping. Independent of the company’s size, automated and well-established procedures can optimize the day-to-day handling of IP-related issues. Thorough documenting and recordkeeping of such processes would also facilitate the automatization and streamlining of workflow. These benefits are particularly crucial for start-ups and small and medium enterprises (SMEs) that lack expertise and resources to keep track of their own, or third-party IP, especially in technology-intensive industries. To phrase it slightly differently, one needs to understand the IP in their possession in order to utilize it properly (e.g., through cross-licensing). Similarly, one requires understanding the third-party IP they rely on so as to be able to exploit it effectively and secure the necessary access and use rights.

3. Education
For an IP management system to become an integral part of a business, it is important to invest in educating the employees about the significance of IP and the merits of IP management, as well as the relevant company processes. Employees with a legal background might indeed be receptive towards IP and its many benefits; but IP management is interdisciplinary. Therefore, supplying continuous training to all relevant employees is expected to raise IP awareness as well as build an innovation- oriented mindset, helping the organization to capture and harness its innovations.¹³

4. Impact in External Relations
We only get one chance to make a first impression. For this reason, the adoption of a well-structured IP management program will naturally impact how the organization’s partners, clients, investors, and other industry participants (even potential buyers) view the company. A balanced and effective management system will likely increase productivity and provide certainty within an organization. This in turn is expected to lead to better results in collaboration with third parties. Building trust is the quintessential requirement for any company that engages in open innovation and aims to reap the advantages of R&D collaboration. Respectively, this is expected to enhance the organization’s position and reputation within the industry as a dependable partner and a company that values IP. Likewise, the valuation of the intangibles—including IP—becomes easier if the company has a structured approach to the management and capture of IP in an established framework.

5. Innovation Management
Lastly, IP management is fundamental to being able to measure the innovation output of an organization. Without an IP management system, it is very hard to adequately track the results of R&D investments in terms of IP generated. Having an established IP management program enables a company to extract and follow metrics and key performance indicators to better steer IP generation.

Companies need to attend to IP management in a methodical way to reap its many benefits. This demand for a systematic approach, together with the extensive digitalization of the business and innovation landscape, have ignited an interest in a more uniform handling of IP at an international level. Nevertheless, initiatives limited in terms of geography or content might not have the desired impact due to lack of consistency. Moreover, resorting exclusively to legally binding measures does not address the need for prompt global action.

For this reason, soft law instruments such as standards and norms are ideal for the promotion of IP management on a voluntary basis. Several IP and innovation management standards have been developed in recent years within national and international standard development organizations and consortia. For the purpose of helping businesses overcome the modern IP challenges, the International Organization for Standardization¹⁴ has introduced a family of standards that create the necessary framework applicable to innovation management (ISO 5600X).¹⁵ This framework expands from the creation and acquisition of IP to cover commercialization and risk management, introducing a full-scale innovation and IP management system.

For technology-intensive industries, successful IP management would not only have a tremendous impact on an organization’s output, but also on the protection of its own and any third-party IP. The establishment of structured and well-functioning management procedures stems from a conscious business decision that an organization wishes to be an active IP owner. Specifically, deploying its resources and staff to manage its own and third-party IP will most likely generate benefits in terms of IP commercialization. Leveraging IP assets is facilitated, because they are now both easier to handle in the course of commercial transactions and they can even become the basis of such transactions. Conversely, when there is no IP management system or process, a company becomes a passive owner of IP and misses opportunities to exploit the full potential of these rights. The lack of an IP management program would also result in a suboptimal use of third-party IP where available, including potential security vulnerabilities and unfavorable access terms to such rights.

In the knowledge economy, the information and communication technology (ICT) industry holds a prominent role in driving innovation, responding to the need for ubiquitous connectivity of economies and people worldwide. Although ICT products and services traditionally depended almost exclusively on proprietary technologies, today this is no longer the case.

In its 2022 OSSRA report, Synopsis¹⁶ found that of the 2.409 codebases¹⁷ it audited for the purposes of the report, 97 percent contained open source.¹⁸ In the same report, it was revealed that among 17 industry sectors, such as energy and computer hardware, the presence of open source in their codebases was between 93 percent and 100 percent. Due to the undeniable value and usefulness of open source solutions, their uncontrollable diffusion raises concerns regarding security and license compliance. A recent example is the Apache log4j vulnerability;¹⁹ almost no one in the IT industry could have avoided its impact in the security space, due to the wide-spread use of the log4j library by a variety of software applications and online services. As a result, many systems were vulnerable to log4j attacks, allowing an attacker to inject malicious code into the system.

“Escaping” the use of ready-made open source components is neither possible nor desirable. To accomplish such an endeavor, a company would need to develop proprietary software solutions with the corresponding immense amount of time and money and no additional value. Meanwhile such a strategy would halt further innovation and market differentiation, since each company would dedicate disproportionate resources for developing software that already exists instead of striving for new and cutting-edge components.

The logic behind applying open source solutions is identical to the one around collaborative standards: an organization could, e.g., develop a proprietary communication technology similar to 3G, but the ultimate question is whether this would make business sense at all. The development of a proprietary technology by one stakeholder requires vast resources and does not guarantee the network externalities offered by a stand ardized technology,²⁰ preferable to consumers. Moreover, the quality would most probably be far lower than the one created by hundreds of stakeholders (which is the case of 3G to 5G). By analogy, using open source as an alternative to proprietary software appears as the best possible solution; not re-inventing the wheel while also saving money and time. When organizations consume open source, it is of utmost importance that they take steps towards structured open source management within their organization and supply chain to ensure the secure, compliant, and strategic deployment of open source to avoid or mitigate potential risks associated with the use of third-party IP.

We described above what we consider necessary for an all-encompassing IP management system. In a similar fashion, an open source management program deals with open source which is protected by copyright, making it an IP asset. Open source management, as a subcategory of IP management, needs to cover the same four important aspects: (i) risk management/compliance; (ii) housekeeping, (iii) education/training; and (iv) external relations. The operation of an open source compliance program has the potential to facilitate the productive use of open source solutions in the products of an organization and—if intended—allow the organization to participate and make contributions in open source communities. As a result, the organization will be more likely to fully capture the added value of open source adopted internally, bringing about enhanced efficiencies in its operational activities.

However, regardless of these similarities, open source is inherently different from any other form of IP-protected technology asset. That makes its management more challenging and, in some respects, more sophisticated. During an open source compliance review, it is crucial to identify the open source components as well as the licenses they carry. The open source user is expected to identify the rights and obligations corresponding to each license to avoid unwanted mistakes. While checking these dependencies, security concerns may arise as well. That is why vulnerability management,²¹ i.e., examining the code quality and detecting for vulnerabilities and exposures in the used code, plays a pivotal role for open source management in general.

Creating an open source management system within each individual company from scratch can lead to complications in terms of scope, objectives and structure that each company might not be able to overcome. In addition, should this individual approach be followed, companies would not be able to perform a uniform assessment of their maturity and compliance level. On the other hand, the adoption of a standardized approach in open source management is expected to increase the likelihood of generating a consistent and qualitative result throughout the industry.

This is important when looking at the software supply ecosystem, where even “commercial” software contains open source. The benefits of consistent high-quality management programs thus propagate in the entire software supply chain, meaning the users will not have to “waste” time and resources managing the “commercial” software they consume.

Responding to the challenge of bringing global industry solutions in the open source compliance realm, the OpenChain Project²² developed the OpenChain Specification version 2.1 on open source license compliance.²³ The OpenChain Project is an international community of companies hosted by the Linux Foundation, dedicated to optimizing open source compliance and reinforcing trust in the open source supply chain. The Open- Chain Specification has also been recognized as an ISO standard (ISO/IEC 5230:2020).²⁴

The development of this specification was the result of an open and collaborative initiative involving over 100 corporate contributors with the goal of creating a cross-industry standard on how to manage open source in an organization. The community members that participated in the development process were given the freedom to offer feedback and build the specification from the ground up.²⁵ Consequently, the specification contains the minimum requirements considered essential in the industry for an organization to establish and maintain a high-quality open source license compliance program.

The two main axes of the specification are documentation and awareness. Firstly, the implementing companies are requested to produce the necessary documen tation and to create documented procedures to form a fully-fledged compliance management system. Therefore, the need for documentation and record-keeping covers a variety of open source software management processes and tasks. For example, each organization is expected to have set down its process for responding to any third-party open source license compliance query (e.g., identifying the legal experts to address these matters, identifying the process for handling non-compliance cases, etc.) (Section 3.2.1).²⁶ As for raising awareness, the specification recognizes the significance of critical employees being educated on open source and on the company’s compliance management processes. To that end, the organization’s written open source policy and open source contribution policy need to be accessible to the employees as part of their education (Sections 3.1.1 and 3.5.1).²⁷

Additional pivotal action points of the OpenChain Specification relating to open source compliance and management are:

• Identification of roles and responsibilities for the employees working with or being responsible for open source in the organization (Section 3.1.2);²⁸
• Establishment of procedures for reviewing the obligations, restrictions and rights of open source licenses identified in the inbound software (Section 3.3);²⁹
• Creation and management of a ‘Software Bill of Materials’ (SBOM)³⁰ (Section 3.3);
• Management of different use cases (e.g., in source or binary form, containing modified open source, etc.) (Section 3.3);
• Setting up a process for preparation and distribution of the required compliance artifacts according to the identified licenses (Section 3.4);³¹ and
• Setting up review processes for open source to be contributed “upstream,”³² ensuring that the intended contribution does not impact the organization’s IP rights, such as patents (Section 3.5).³³

The OpenChain Project supplies a questionnaire that assists the implementers with the conformance assessment and serves as a self-certification (with commercial certifiers offering third-party certification as well).³⁴ The specification functions as a tool that accommodates three major items: (1) gauging the maturity of open source software management and compliance within an organization, (2) identifying potential weak points, and (3) pinpointing recommended actions for achieving the desired level of maturity. On a larger scale, the specification aspires to set the industry’s minimum requirements for open source compliance and management, accomplishing a certain level of trust between implementing organizations. Ultimately, the intention of the specification is to reduce the burden of compliance in the entire value chain.

The omnipresent nature of open source creates complications both in terms of managing the software itself as well as managing the IP rights it is intertwined with. For this reason, the OpenChain Specification offers an effective and industry-approved way of receiving and handling a variety of IP and technology assets, mainly, consumed open source.

As with all IP management implementations, a crucial point is to understand what IP is being used by the company and securing adequate access and control thereto, regardless of whether that IP was generated in the R&D lab or by a third party. The OpenChain Specification contains useful check points on how to, in a consistent and risk-minimizing way, bring third-party IP (in this case, in the form of open source) into an organization.

Furthermore, the specification assists with a primary concern in IP management, i.e., compliance with legal and contractual obligations for the purpose of avoiding potential legal risks. Should an organization implement this specification, it helps mitigate risks related to inbound and outbound open source. The specification provides the necessary safeguards and processes in place from the moment the code is introduced into the company and throughout the life cycle of the product in which this code is used.

A further complication in an open source setting is the very real risk of the organization losing its “reputation” as a good open source citizen. Such an impact on its credibility is not a mere write-down of goodwill, but directly impacts an organization in multiple ways. For example, it might be harder to recruit talent, obtain support from the open source community and, ultimately, get its contributions accepted into open source projects (meaning it cannot steer their direction).

The OpenChain Specification spells out multiple requirements and action points that eventually aim to ensure the much-needed evaluation of the open source introduced for consumption in the company, and the conformance with their respective licenses. As we keep returning to in this article, it is key to understand what is being introduced as well as where, how and by whom it is being used within the organization. Only with that understanding is it possible to guarantee compliance with third-party IP, track vulnerabilities, and make sure that open source is introduced and consumed in accordance with the organization’s policies.

The layout of the specification is simple, its main outline being the following:

• What do you need? Identification of an organization’s open source responsibilities (Section 3.1 of the OpenChain Specification);³⁵
• Who do you need? Resources and responsibilities assignment for open source compliance (Section 3.2);³⁶
• What should they do? Review and approval of inbound open source content (Section 3.3);³⁷
• How do you show it? Compliance artifacts (Section 3.4);³⁸
• How do you manage contributions? (Section 3.5);³⁹ and
• Are you compliant? Adherence to the specification requirements (Section 3.6).⁴⁰

In the following part, we will provide a brief description of the main requirements and examine in more detail how they assist in reducing potential risks and how they translate to a quality IP management program.

1. Risk Management—Compliance
Risk management and compliance in the context of open source appear to be two sides of the same coin; on the one hand, organizations manage the risk of losing their own IP rights while, on the other hand, avoid infringing third-party IP by breaching the obligations set by each open source license that covers each open source component. Risks can be averted and legal obligations can be safely and confidently met when a company adopts a comprehensive open source management program, like the one described in the Open- Chain Specification.

The first ‘order of business’ is to consider and document the organization’s open source policy. A policy document usually includes guidelines, recommendations, or instructions on how an organization approaches or should approach a certain matter. Thus, an open source policy entails the high-level ‘dos and don’ts’ concerning open source consumption and contribution in an organization as well as general directions on the same topics. Establishing and making available an open source policy (Section 3.1.1)⁴¹ is the first step towards a successful open source compliance management program.

Through official written processes regarding the response to internal or external license compliance queries (Section 3.2.1)⁴² and through the articulation of the rights and obligations of the identified licenses (Section 3.1.5),⁴³ the organization guarantees compliance therewith as well as full exploitation of its IP. It is of great importance to make sure that a business complies with its licensing obligations without “infecting” its own intangible assets. The “infection” of an organization’s intangible assets refers to the inadvertently granting royalty-free licenses of its IP (e.g., copyright on proprietary code or patented inventions) by signing an open source license. For example, the establishment of a Software Bill Of Materials, so called SBOMs (Section 3.3.1)⁴⁴ allows the organization to have a clear overview of the open source components it is introducing and using commercially.

Relatedly, an open source management program pays special attention to the open source contribution policy of each organization and the need for, e.g., developers participating in open source projects to be fully aware of the dos and don’ts of their organization when it comes to contributing code upstream (Section 3.5.1).⁴⁵ By following this policy, no IP rights of the company will likely be jeopardized from said contributions.

Another crucial element of the OpenChain Specification is the maintenance of open source “hygiene” within an organization. This implies having procedures in place so that when code is introduced, it is additionally scanned to ensure that the software components are adequately secure. Such procedures have the beneficial side effect of being particularly useful for vulnerability management of the inbound software, which occurs in a consistent and detailed manner throughout the product life cycle.

2. Housekeeping—Innovation Management
Besides being an appropriate IP risk management tool, the OpenChain Specification provides a comprehensive baseline for housekeeping within an organization. The specification requirements introduce processes that function as checks and balances between different departments for the harmonious and effective management of open source solutions. Special emphasis is given to the establishment of multi-layered, automated procedures for coping with a variety of challenges potentially encountered in the use of open source. One example is the establishment of procedures for handling the review and remediation of cases where compliance issues exist regarding certain open source obligations (Section 3.2.2.5).⁴⁶ This essentially means that a company must have a Plan B in case of license breaches (i.e., not complying with an open source license obligation), including how to deal with those and mitigate their fallout.

For the purpose of continuity, consistency and reliability, these procedures are requested to be documented and, oftentimes, made available to the organization’s employees. As a result, the employees can speak ‘the same language’ and have a common understanding when it comes to open source via the homogenous and well-established processes within the company.

‘Running a tight ship’ in terms of open source is imperative for the achievement of compliance targets and for a long-term, holistically higher performance within an organization. Along the same lines, during an M&A process, due diligence could be facilitated and the parties benefited by an efficient open source management program.

What is more, housekeeping is tightly related to innovation management for organizations that heavily rely on ground-breaking technologies for releasing products and generating revenue. The procedures previously discussed in the context of open source compliance management result in the creation of a log that contains all the open source components and related IP brought in and used by the organization. Consequently, the organization can direct its R&D efforts accordingly, as well as manage any commercial contracts involving software.

3. Education
To optimize risk management and housekeeping, it is beneficial to provide the employees with the tools needed to appreciate the benefits and complexities of open source. For this reason, education and awareness are at the forefront for the OpenChain Specification (Sections 3.1.1.1, 3.1.2.3, 3.1.3.1 and 3.5.1.3).⁴⁷ An organization should guarantee that its employees working with open source are competent for their role and are aware of what is expected from them. In addition, all relevant employees should have a fundamental level of knowledge around internal processes for them to be in sync and collaborate seamlessly. For this reason, it is critical to provide training to the professionals within the company on the importance of open source as well as on the policies and procedures covering its management. A key point of emphasis is that developers need to be conscious of the open source policy and open source contribution policy of their organization in order to make informed executive and/or technical decisions, i.e., Sections 3.1.1.1⁴⁸ and 3.5.1.3.⁴⁹

4. External Relations—Contributions
Considering the increasing influence of open source solutions across industries, higher business performance means capitalizing on the incremental value of open source. This can only occur in a secure environment that acknowledges its relevance. The implementation of OpenChain Specification views open source management in an integrated manner. Namely, it focuses on compliance and consumption, without neglecting the need to contribute back to open source projects (Section 3.5).⁵⁰

Being involved in open source communities is not a priority for many organizations since it does not fit all business models. On the other hand, an organized and target-oriented participation can produce shortand long-term benefits for open source users. Firstly, they can actively engage in the ‘give and take’ of the community in terms of code development,⁵¹ bug fixes, ⁵² and support, and secondly, get the opportunity to have a say in future open source projects. Therefore, instead of simply consuming software components for their products and services, implementers of the Open- Chain Specification might optionally elect to give back to open source communities and enhance the value of open source for their business.

Therefore, apart from the need to map out an advisory open source contribution policy (Section 3.5.1.1),⁵³ conformance with the OpenChain Specification means that an organization must establish a documented procedure to advise developers regarding corporate approaches to contributing to open source projects and to guide them through the contribution process (Section 3.5.1.2).⁵⁴ Such procedure also needs to be communicated to all relevant employees (Section 3.5.1.3).⁵⁵

Finally, the implementation of the OpenChain Specification could be advantageous at the macro level as well. Apart from facilitating housekeeping and decision- making, it might act as a springboard for cultivating the open source culture within the company. The possibility to further educate employees on the intricacies of open source will benefit the immediate operations and, gradually, the overall large-scale strategic targets of the company. On an industry level, the more organizations that actively exercise and implement this standard, the closer the industry will get to healthier open source management. Following the objective set out in the specification itself, the establishment of a robust open source license compliance management system plays a seminal role in building trust between organizations across different industries.

In the era of 5G and “smartification,” the all-connected world overflows with new and innovative products and services. Although capturing innovation through IP is key, stakeholders in hi-tech industries need to monetize their IP to get necessary returns on their investment. The innovation circle can only function and generate benefits for a business if supported by a robust IP management system.

IP management is equally decisive when dealing with software, especially in the form of open source compliance management. For this reason, software-driven companies are encouraged to adopt an open source management program to ensure conformance with their legal obligations. It follows that the value of open source within a company will be maximized, and these internal benefits will be externalized by means of improved collaboration with third parties and an enhanced role in the open source community.

This is where the OpenChain Specification comes along. By implementing this specification, which identifies the basic requirements for open source IP management, you might not be able to answer the question of which Linux kernel⁵⁶ distribution is best for your embedded products; that decision will remain in the domain of the Chief Technology Officer of your company (CTO). But you can rest assured that:

• Legal risks are minimized;
• The relevant stakeholders have the right training and the right resources;
• Compliance is done systematically; and
• The organization has increased visibility into security issues that may arise, facilitated through the identification of any third-party IP used.

Should engineers wish to contribute bug fixes or new features upstream, there are processes within the organization to address this. It is all about putting processes in place that guarantee fewer risks and less friction down the line.

Due to these evident advantages of open source management, the OpenChain Specification has so far been adopted by many companies of different sizes and from different industries, i.e., large multinational companies such as ARM, Google, Qualcomm and Toyota, as well as smaller companies.⁵⁷

Perhaps, it is time for your organization to take the plunge, get ahead of the curve and include open source management as part of its IP management practices as well. This way you can make both IP and open source management safe and boring. ■

Disclaimer

The views expressed herein are those of the authors and do not necessarily reflect the opinions of Ericsson. This article was firstly published in IAM on 17 May 2023.

1. Marc Andreessen, “Why Software Is Eating the World,” Andreessen.Horowitz, August 20, 2011, https://a16z.com/2011/08/20/why-software-is-eating-the-world/.
2. “Readout of White House Meeting on Software Security,” The White House, accessed 09 May 2023, https://www.whitehouse.gov/briefing-room/statements-releases/2022/01/13/ readout-of-white-house-meeting-on-software-security/.
3. “Browser Market Share Worldwide,” statcounter Global- Stats, accessed 09 May 2023, https://gs.statcounter.com/ browser-market-share#monthly-202205-202210-bar.
4. “Home,” The Chromium Project, accessed 09 May 2023, https://www.chromium.org/chromium-projects/.
5. Android Open Source Project, accessed 09 May 2023, https://source.android.com.
6. “Europe’s Internet of Things Policy,” European Commission, accessed 09 May 2023, https://digital-strategy.ec.europa.eu/en/policies/internet-things-policy.
7. “Internet of Things (IoT) and non-IoT Active Device Connections Worldwide from 2010 to 2025 (in Billions),” statista, accessed 25 April 2023, https://www.statista.com/statistics/ 1101442/iot-number-of-connected-devices-worldwide/.
8. “About the Linux Foundation,” the Linux Foundation, accessed 09 May 2023, https://www.linuxfoundation.org/about.
9. “Open Source Summit Japan 2022,” SCHED, accessed 09 May 2023, https://ossjapan2022.sched.com/event/1D1cG/ keynote-state-of-the-union-jim-zemlin-executive-director-thelinux- foundation.
10. “Learn More About OpenChain ISO/IEC 5230:2020,” OpenChain, accessed 09 May 2023, https://www.openchainproject.org/license-compliance.
11. Alexander J. Wurzer and Stephan Hundertmark, “IP Management—Key Skills in a Knowledge Economy,” Journal of Korean Law 8, no. 1 (December 2008): 186, http://aplaweng.snu.ac.kr/34/?q=YToyOntzOjEyOiJrZXl3b3JkX3R5cGUiO3M6 MzoiYWxsIjtzOjQ6InBhZ2UiO2k6MTM7fQ%3D%3D&bmode =view&idx=3423582&t=board.
12. Wurzer and Hundertmark, “IP Management—Key Skills in a Knowledge Economy,” 195-197.
13. Thomas Bereuter, Adéla Dvořáková, Juergen Graner, Bowman Heiden and Ruud Peters, “People As Enablers: The Role Of The Human Factor In Intellectual Asset Management Of Technology,” Volume LV les Nouvelles—Journal of the Licensing Executives Society, No. 2 (June 2020): 99, https://ssrn.com/ abstract=3582079.
14. “About,” International Standardisation Organisation, accessed 09 May 2023, https://www.iso.org/about-us.html.
15. “ISO 56000:2020—Innovation management—Fundamentals and vocabulary,” International Standardisation Organisation, accessed 09 May 2023, https://www.iso.org/standard/ 69315.html.
16. “About us,” synopsys, accessed 09 May 2023, https:// www.synopsys.com/company.html.
17. Definition of codebase: “An implementation of source code for an operating system or application. The term may be used generically to contrast platforms; for example, a Linux codebase vs. a Windows codebase. It may also refer to a different branch or version of the same software, the implication being that the different versions continue to be developed separately for different purposes.” At “codebase,” PCmag, accessed 09 May 2023, https://www.pcmag.com/encyclopedia/term/codebase.
18. “2023 OSSRA: A deep dive into open source trends,” synopsys, accessed 09 May 2023, https://www.synopsys.com/ blogs/software-security/open-source-trends-ossra-report/.
19. “Log4j vulnerability—what everyone needs to know,” National Cyber Security Centre, accessed 09 May 2023, https:// www.ncsc.gov.uk/information/log4j-vulnerability-what-everyone- needs-to-know.
20. See Joseph Farrell and Garth Saloner, “Standardization, compatibility and innovation,” 16 Rand Journal of Economics, No.1 (Spring 1985): 1-2, http://neconomides.stern.nyu.edu/ networks/phdcourse/Farrell_Saloner_Standardiization_compatibility_ and_innovation.pdf.
21. “Vulnerability Disclosures,” OpenSSF Vulnerability Disclosures Working Group GitHub, accessed 09 May 2023, https:// github.com/ossf/wg-vulnerability-disclosures.
22. “Who We Are,” OpenChain Project, accessed 09 May 2023, https://www.openchainproject.org/community.
23. “OpenChain Specification Version 2.1,” theopenchainproject Github, accessed 09 May 2023, https://github.com/ OpenChain-Project/License-Compliance-Specification/blob/ master/Official/en/2.1/openchainspec-2.1.pdf.
24. “Learn More About OpenChain ISO/IEC 5230:2020,” OpenChain Project, accessed 09 May 2023, https://www.openchainproject.org/license-compliance.
25. Ibid.
26. “OpenChain Specification Version 2.1,” theopenchainproject Github, 4.
27. Ibid, 2 and 6.
28. Ibid, 2-3.
29. Ibid, 5.
30. “Software Bill of Materials,” National Telecommunications and Information Administration, assessed 09 May 2023, https://ntia.gov/page/software-bill-materials.
31. “OpenChain Specification Version 2.1,” theopenchainproject Github, 5-6.
32. Definition of upstream: From the consumer to the provider. At “upstream,” PCmag, accessed 09 May 2023, https:// www.pcmag.com/encyclopedia/term/upstream.
33. “OpenChain Specification Version 2.1,” theopenchainproject Github, 6.
34. “OpenChain Self Certification,” OpenChain Project, accessed 09 May 2023, https://www.openchainproject.org/community.
35. “OpenChain Specification Version 2.1,” theopenchainproject Github, 2-4.
36. Ibid, 4.
37. Ibid, 5.
38. Ibid, 5-6.
39. Ibid, 6.
40. Ibid, 6-7.
41. Ibid, 2.
42. Ibid, 4.
43. Ibid, 3-4.
44. bid, 5.
45. Ibid, 6.
46. Ibid, 4.
47. Ibid, 2, 3, 3 and 6, respectively.
48. Ibid, 2.
49. Ibid, 6.
50. Ibid, 6.
51. Definition of code: A set of machine symbols that represents data or instructions. See data code and machine language. At “code,” PCmag, accessed 09 May 2023, https://www.pcmag.com/encyclopedia/term/code.
52. Definition of bug fix: A revised program file or patch that corrects a software bug. At “bug fix,” PCmag, accessed 09 May
53. Ibid, 6.
54. Ibid, 6.
55. Ibid, 6.
56. Definition of Linux kernel: The nucleus of the Linux operating system. The Linux kernel, which was developed by Linus Torvalds, was integrated with software from the GNU Project and other sources to create the actual Linux operating system. At “Linux Kernel,” PCmag, accessed 09 May 2023, https://www.pcmag.com/encyclopedia/term/linux-kernel.
57. “ISO/IEC 5230 Conformant Programs Announced Via Our Website,” OpenChain Project, accessed 09 May 2023, https://www.openchainproject.org/community-of-conformance.