I am old enough to remember when organizations developed software in-house – all of it. I also clearly remember my information systems college professor teaching it is almost always less expensive and better to use code/programs already written and adapting them for your use than to recreate the wheel from scratch. 

It is a different world now – software is built on a foundation of other programs, libraries, and code bases. Free and open source software (FOSS) is key to this because it is so easy to pickup, use, share, and create code. What an opportunity to speed development and focus innovation on the next thing rather than creating what already exists. This is part of the value of open source software – collaborate on the building blocks and innovate and differentiate on top of that. 

However, there are also challenges in this space, with a good example being the question of how to address licensing. There are A LOT of types of licenses that can apply to a piece of software/code. Each license needs to be understood and tracked with each piece of software it is included in for an organization to ensure nothing is missed. This can quickly multiply into a significant catalog that requires lots of manual work. On top of that, you also need to provide that license information to each of your customers, and they will have their own system and/or processes for providing that information to them and making sure it is up-to-date with each new version of the software. 

You can see where this can quickly consume valuable staff resources and open doors to mistakes. Imagine the possibility of a standard way to track and report the licenses so your teams don’t need to worry about all of the digital paperwork and can instead focus on innovation and adding value to you and your customers.

This is exactly the problem a team of lawyers and governance experts sought to fix back in 2016 and created the OpenChain Project to do just that. They asked, what are the key things for open source compliance that everyone needs, and how do we unify the systems and processes. They envisioned an internationally accepted standard to track and report all of the licenses applicable to a software project. The end result is a more trustable supply chain where organizations don’t need to spend tons of time checking compliance again and again and then remediating. 

The result – a ISO standard  (ISO/IEC 5230) was approved in Q4 2020. The OpenChain Project also hosts a library of 1,000 different reference documents in a wide variety of languages – some are official and many more are community documents, like workflow examples, FAQs, etc.

How are organizations benefiting from OpenChain? I find it encouraging that Toyota is one of the leaders in this. As anyone who has had at least one business class in college knows, Toyota is a leader in innovations for manufacturing over several decades. In the 1970s they pioneered supply chain management techniques with the Toyota Production System (please tell me they had to do TPS reports) – adopted externally as Just in Time manufacturing. They are also known for adopting the philosophy of Kaizen, or continuous improvement. So, as they looked at how to manage software supply chains and all of the licensing, they adopted the OpenChain Specification. They implemented it, in part, with a governance structure and an official group to manage OSS risks and community contributions.

Toyota’s OSS governance structure

diagram of toyota's open source software governance structure - OSS Developer; Security Specialist; IP Specialist over R&D over Developing OSS Culture and Handling OSS Risks

They are also an active participant in the OpenChain Japan Working Group to help identify bottlenecks across the supply chain, and the group enabled Toyota to develop information sharing guidelines to address licensing challenges with Tier 1 suppliers. They now see reduced bottlenecks, more data for better decision making, and decreased patent and licensing risks. Read more.

PwC is a global auditing, assurance, tax, and consulting firm. As an auditor, much of their business revolves around building trust in society. They also develop software solutions for thousands of clients around the world and receive software from providers of all sizes and maturity levels, making OSS compliance difficult. It was a tremendous effort and caused time delays for them and their clients. Now, PwC is able to provide clients with an Open Source Software compliance assessment based on the latest OpenChain specification. Their clients can share an internationally-recognized PwC audit report to verify OSS compliance. Read more.

And just last month, SAP, a market leader in enterprise application software, announced they are adopting the OpenChain ISO/IEC 5230 standard. It marks the first time that an enterprise application software company has undergone a whole entity conformance. Their reach across the global supply chain is massive – its customers are involved in almost 90% of global trade.

As the ISO/IEC standard is done, what is next for OpenChain? They are looking at security, export control, and more. 

If you or your organization are interested in learning more about OpenChain, adopting the standard, or getting involved in what is next, head over to https://www.openchainproject.org/. We also host an online training course when you are ready to dig in: Introduction to Open Source License Compliance Management

My hope is that you now spend less time on compliance and more time on innovation.

One of the greatest strengths of open source development is how it enables collaboration across the entire world. However, because open source development is a global activity, it necessarily involves making available software across national boundaries. Some countries’ export control regulations, such as the United States, may require taking additional steps to ensure that an open source project is satisfying obligations under local laws.

In July of 2020, The Linux Foundation published a whitepaper on how to address these issues in detail, which can be downloaded here. In 2021, the primary update in the paper is to reflect a change in the US Export Administration Regulations.

  • Previously, in order for publicly available encryption software under ECCN 5D002 to be not subject to the EAR, email notifications were required regardless of whether or not the cryptography it implemented was standardized.
  • Following the change, email notifications are only required for software that implements “non-standard cryptography”.

Please see the updated paper and the EAR for more specific details about this change.

Jason Perlow, Director of Project Insights and Editorial Content at the Linux Foundation, spoke with Daniel Scales about the importance of protecting trademarks in open source projects.

JP: It’s great to have you here today, and also, welcome to the Linux Foundation. First, can you tell me a bit about yourself, where you are from, and your interests outside work?

DS: Thanks, Jason! It is great to be here. I grew up in Upstate New York, lived in Washington and London for a few years after college, and have been in Boston for the last 20+ years. Outside of work, I coach my daughter’s soccer team, I like to cook and play my bass guitar, and I am really looking forward to getting back to some live music and sporting events. 

JP: And from what organization are you joining us?

DS: I have been with the Boston law firm Choate, Hall & Stewart since 2011. In addition to advising The Linux Foundation and other clients on trademark matters, I helped clients with open source license questions, technology licenses, and IP-focused transactions.  Before Choate, I worked as IP Counsel at Avid Technology, where I managed their trademark portfolio through a global rebranding and supported the engineering team on technology licenses. 

JP: So, how did you get into Intellectual Property law?

DS: Great question.  I studied economics in college and took a fantastic senior seminar on the economics of intellectual property.  After graduation, I worked in the economics consulting group at Ernst & Young.  A big part of my job there was determining the value of a company’s intangible property, which in many cases were its brands. I went to law school intending to study trademarks and the new field of “internet law” (this term probably dates me) and started my legal career at Testa, Hurwitz & Thibeault, which had a cutting-edge trademark and open source group.

JP: We typically think of IP and Trademark law as it applies to consumer products and commercial entities. What is the difference between those and when open source projects and organizations use brands?

DS:  On one level, there really isn’t a difference.  A trademark signifies the unique source of a good or service. Trademarks help consumers, developers, and users distinguish various offerings, and they communicate the specific source and quality of those offerings.  Software developers and users need to understand what code they have and where it came from. Trademarks help communicate that information.  Of course, the specific issues that every brand and brand owner faces and how they address them are different, but many of the core principles are the same.

JP: What are some of the trademark issues you’ve seen come up in open source communities?

DS: While it happens in every industry, I see many “helpful” people apply to register projects’ trademarks when they are not the rightful owner.  Sometimes they have good intentions, sometimes not, but it can be a lot of work to sort it out either way.  I’ve also had the opportunity to work with many different people and companies on project branding. It is amazing how many different philosophies there are regarding branding, even within the software industry.  Much of what we do is to bring these folks together to determine the best approach for the specific project.  I also spend a lot of time debating the scope of trademark rights with opposing counsel, but that isn’t really unique to open source:  one lawyer tried to convince me that his client had the exclusive right to use a picture of a hop flower on a beer label. 

Other common issues are helping companies register a mark for their company or product and then used the same mark for an open source project. The neutrality of those situations is imbalanced, and the Linux Foundation has worked with organizations making this transition. Sometimes it involves rebranding the open source project, and we assist in finding and clearing a new name for the community to use independent of the company that started it.

JP: Why is the Linux Foundation a good place for open source projects to protect their brands?

DS: We have worked with many open source projects on their trademarks, and we learn something with every new experience.  We can help them name the project at the beginning, take steps to protect their trademarks across the globe, and show them how trademarks can be a tool to build their communities and increase participation and adoption.  We also recognize the importance of our neutral position in the industries we serve and how that is fundamental to open governance.

Also Read: Open Source Communities and Trademarks: A Reprise

JP: Trademark conformance can also protect a project from technical drift. How can a trademark conformance program be used to encourage conformance with a project’s code base or interfaces? 

DS: Great point. As in most areas of trademarks, clarity and consistency are key. Trademarks used in a conformance program can be a great tool to communicate quickly and accurately to the target community.  Projects can develop specific and transparent criteria so that users understand exactly what the conformance trademark symbolizes.  This can be much more effective and efficient for projects and users alike than everyone deciding for themselves what a term like “compatible” might mean.  

Also Read: Driving Compatibility with Code and Specifications through Conformance Trademark Programs

JP: Do projects at the Linux Foundation give up all control of their trademark? How do you decide what enforcement to pursue or not pursue?

DS: On the contrary — we work very closely with project leadership throughout the lifecycle of their trademarks.  This includes trademark enforcement.  Typically, the first step is to figure out whether the situation requires enforcement (in the traditional legal sense) or if it is simply a matter of educating another party.  More often than not, we can reach out to the other party, discuss our project and our trademarks, discuss our concerns, and work out a solution that works for everyone and strengthens our brands.  But like any brand owner, we do sometimes have to take other action to protect our projects’ trademarks, and we work closely with our projects in those situations, too.

JP: Thanks, Daniel. It’s been great talking to you today!

The Linux Foundation would like to reiterate its statements and analysis of the application of US Export Control regulations to public, open collaboration projects (for example, open source software, open standards, open hardware, and open data) and the importance of open collaboration in the successful, global development of the world’s most important technologies.

Today’s announcement of prohibited transactions by the Department of Commerce regarding WeChat and TikTok in the United States confirms our initial impact analysis for open source collaboration. Nothing in the orders prevents or impacts our communities’ ability to openly collaborate with two valued members of our open source ecosystem, Tencent and ByteDance. From around the world, our members and participants engage in open collaboration because it is open and transparent, and those participants are clear that they desire to continue collaborating with their peers around the world.

As a reminder, we would like to point anyone with questions to our prior blog post on US export regulations, which links to our more detailed analysis of the topic. Both are available in English and Simplified Chinese for the convenience of our audiences.

Linux Foundation Blog Post Abstract Graphic

The Linux Foundation would like to reiterate its statements and analysis of the application of US Export Control regulations to public, open collaboration projects (e.g. open source software, open standards, open hardware, and open data) and the importance of open collaboration in the successful, global development of the world’s most important technologies. At this time, we have no information to believe recent Executive Orders regarding WeChat and TikTok will impact our analysis for open source collaboration. Our members and other participants in our project communities, which span many countries, are clear that they desire to continue collaborating with their peers around the world.

As a reminder, we would like to point anyone with questions to our prior blog post on US export regulations, which also links to our more detailed analysis of the topic. Both are available in English and Simplified Chinese for the convenience of our audiences.

Read blog post on open source and export controls

Open Source Communities and Trademarks: A Reprise

Intellectual property and how it is shared have been the cornerstone of open source. Although it is more common to discuss “code” or “copyright,” there are other IP concerns around patents and trademarks that must be considered before investing time and effort in a major open-source project. There are long-established practices that govern these matters. Companies and lawyers involved in open source have been working on and evolving open source project trademark matters for decades.

Neutral control of trademarks is a key prerequisite for open source projects that operate under open governance. When trademarks of an open source project are owned by a single company within a community, there is an imbalance of control.  The use of any trademark must be actively controlled by its owner or the owner will lose the right to control its use. The reservation of this exclusive right to exercise such control necessarily undermines the level playing field that is the basis for open governance. This is especially the case where the trademark is used in association with commercial products or solutions. 

Open source licenses enable anyone to fork the code and distribute and modify their own version. Trademarks, however, operate differently. Trademarks identify a specific source of the code. For example, we all know MariaDB is not the same as MySQL. They’ve each developed their own brand, albeit they’re derived from a common codebase. The key question is who decides when a company should be allowed to associate its product or solution with the brand of the community?

A trademark is a word, phrase or design that denotes a “brand” that distinguishes one source of product or solution from another. The USPTO describes the usage of trademarks “to identify and distinguish the goods/services of one seller or provider from those of others, and to indicate the source of the goods/services.” Under US trademark law you are not able to effectively separate ownership of a project mark from control of the underlying open source project. While some may create elaborate structures around this, at the end of the day an important principle to follow is that the project community should be in control of what happens to their brand, the trademark they collectively built up as their brand in parallel with building up the functionality of their code. 

For this reason, in communities that deem their brand important, we also file registrations for trademark protection to reserve the rights in the mark for the project, commonly in the United States, China, European Union, Japan, and other countries around the world. Registered marks will often have a ® symbol. This is different from a common law trademark right where you often see a ™ symbol with the mark. Having a registered trademark is often important because it enables us to better protect the community against misrepresentation, misuse, and confusion in the ecosystem between what is actually the community-built project, and what is not. This is often based on specific benefits that arise from the registration, which may vary from country to country.

The Linux Foundation started hosting projects outside of Linux a decade ago. From the outset, the brand of a project community we host has been an important asset that we have been asked to protect for our communities. The communities’ goals and motivations are always different, but, in general, the organization contributing a trademark usually wants to ensure it denotes the community they’re helping to establish at the LF, and the other participants in the ecosystem want the confidence that one company can’t tell them what they can or cannot do with a project we host because they retained ownership of the trademark.

This neutrality is the very essence of what we try to establish at the Linux Foundation with our projects. Our projects are set up to be neutral – the Linux Foundation or our project entities own the mark. We then put the control over decisions about the mark into the hands of our project communities, to be determined by them in an open and transparent manner to achieve their collective goals.

For example, in March of 2017, we participated in a meeting hosted at a KubeCon in Berlin, where the organizations involved in Kubernetes sat down in a packed room to discuss what they wanted to do with the Kubernetes brand as it related to companies using Kubernetes in conjunction with their commercial products or solutions. When drafting the governance for CNCF, Google had insisted it was important for the Linux Foundation to also own the Kubernetes mark as part of CNCF—so that branding control would go hand in hand with neutral, community-driven governance. 

However, the LF was not in a position to determine when one company should or should not be able to say their solution was a “Kubernetes”-based product. We needed a program to allow companies and other organizations to use the trademark commercially to denote their distribution or compatibility with the community’s Kubernetes releases. That initial group worked for months to define what it means to have a conformant Kubernetes distribution. That’s also why the promise of portability amongst cloud providers actually works today. Those technical experts from the community as a whole defined exactly what it would take to deliver on the promise of portability. And then the definition of conformance that they established has been backed up by the neutral ownership of the Kubernetes trademark, in the Linux Foundation. What’s even more important is that the community remains in control of the program. In fact, the definition of conformance is controlled by Kubernetes’s SIG Architecture and changes in a carefully controlled process in each release as new APIs become stable and obsolete ones are deprecated. 

This same story has played out in other communities we have hosted. We’ve had many communities build consensus around what it means to be compatible or conformant with the releases coming from our project communities. So many that we recently wrote an entire blog just about the topic.

What these examples show is that a community can neutrally manage a trademark within the LF’s structure. We tend to refer to these as “community-managed trademark” programs. The marks are owned by the LF entity for the project, and we work with the communities we serve to establish the rules around usage of our marks.

Recently there has been a new round of conversations about open source projects and ownership of trademarks. Understandably there has even been concern that open source hasn’t addressed issues of trademarks as it relates to major OSS projects. This is not the case. While the motivations vary, one aspect remains constant: trademark law. 

We’ve been asked, “can we have the LF manage our trademark too?” The answer is yes. Let us know what project you’re managing and we’re happy to help you understand what’s involved in setting up a community-managed trademark program for your project. To date, we have successfully done this for the most important open source projects in the world and projects that are the most important to a few people. We can probably help support you as well.

Driving Compatibility with Code and Specifications through Conformance Trademark Programs

A key goal of some open collaboration efforts — whether source code or specification oriented — is to prevent technical ‘drift’ away from a core set of functions or interfaces. Projects seek a means to communicate — and know — that if a downstream product or open source project is held out as compatible with the project’s deliverable, that product or component is, in fact, compatible. Such compatibility strengthens the ecosystem by providing end-users with confidence that data and solutions from one environment can work in another conformant environment with minimal friction. It also provides product and solution providers a stable set of known interfaces they can depend on for their commercially supported offerings. 

A trademark conformance program, which is one supporting program that the LF offers its projects, can be used to encourage conformance with the project’s code base or interfaces. Anyone can use the open source project code however they want — subject to the applicable open source license — but if a downstream solution wants to describe itself as conformant using the project’s conformance trademark, it must meet the project’s definition of “conformant.” Some communities choose to use words other than “conformant” including “certified”, “ready”, or “powered by” in association with commercial uses of the open source codebase. This is the approach that some Linux Foundation projects take to maintain compatibility and reduce fragmentation of code and interfaces. 

Through this approach, we enable our projects to create flexible, custom-tailored conformance programs to meet the needs of their respective communities. In fact, our conformance programs can operate as open source projects themselves (see, for example, https://cncf.io/ck ). They incorporate a balance of interests from vendors, end-users, and contributors to the project and enable the community to define how the commercial ecosystem participants can leverage the use of the community’s mark. 

Products or solutions that meet the requirements of the trademark conformance program can use the conformance program’s trademark. Those that do not meet its requirements, cannot. If the project community learns that someone is misusing a conformance program trademark — say using the mark to show compatibility without achieving all of the requirements of the conformance program — the community could work with the LF to take steps to advise them on how they can come into conformance with the program requirements, or discontinue their use of the trademark.

How Can an Open Project Establish a Conformance Trademark Program?

When our projects establish a conformance program, we recommend that they follow the following basic steps:

  1. Determine what you want the trademark to signify.

Are you interested in showing compatibility with a core segment of project code or interfaces? Do you want this mark to indicate backward compatibility? Do you want the mark to imply a certain level of ‘rigorousness’ of compatibility? How broad or narrow a focus of compatibility are you interested in (e.g., all of the code base, or a key portion)? Does a “compatible” solution necessarily need to use the underlying open source codebase at all, or just present a compatible interface? 

This question is best addressed by involving interested stakeholders across business, marketing, and technical functions including discussions to resolve upon the intended meaning for the mark. Relevant stakeholders will likely include the project developers; downstream vendors who develop products based on the project’s outputs; and potential customers and end-users of those vendors.

A conformance program’s guiding star should be to ensure neutrality and objectivity in the conformance definition’s metrics. In order for an ecosystem to accept that the conformance trademark has relevance, it should be tied to a specific, articulated definition of what it does and doesn’t include. If the definition of conformance includes aspects of subjective evaluations by the project members, the result may be a perception that non-technical considerations such as favoritism were used as factors — and that the mark is not a reliable indicator of technical functionality. Objective criteria that are applied neutrally can help to avoid such a perception. In addition, the process by which the mark or requirements are defined should be specified and made known.

  1. Decide upon the specific requirements of conformance.

Once you have identified what you want the trademark to signify, you can craft a specific set of requirements necessary for a product to be able to use the conformance trademark. These requirements should also be developed within the community, and the development of these requirements is often closely tied to the work in item 1 above.

Additional questions to consider are:

    • How long can a product or solution provider claim compatibility, and against what version(s) of the open source project? How many future versions will that conformance be valid for?
    • Will the community create a test suite to provide an objective “pass / fail” determination for compatibility, or rely on more subjective considerations? (ideally, the answer should be the former)
    • What triggers a requirement for a vendor to re-test and confirm that their solution remains conformant — every time a change is made, or after a set period of time, or only if/when complaints are received from the community, or something else?
  1.   Determine how products and solutions will be qualified as meeting the requirements of the conformance program. 

There are many approaches that our projects take with respect to qualifying products or solutions, and they range in expense from none/nominal to significant. A common approach is to publish the requirements and allow self-certification with the requirements via a registration page. The project would then publish a current list of all registrants so that end-users could — by way of the project’s web site — know that a particular vendor had self-certified their product as meeting the requirements. Depending on the nature of the project and the conformant vendors’ solutions, end-users themselves might be able to run the same set of self-tests on the solutions, to confirm compatibility for themselves. In some cases, end users may use the same tests to keep their internal teams conformant in their internal deployments. Tooling costs are also a consideration for projects in setting up automated testing systems.

Another approach is to engage with third-party test labs that will test whether submitted products or solutions, in fact, meet the conformance program requirements. This model may also be setup by publishing criteria or requirements that a test lab can follow to offer conformance program testing.

As you can imagine, the expense involved in contracting with third-party test labs can be significant. Many of our communities choose to lower barriers to entry for the ecosystem and keeping costs low is often a priority.

  1. Publish the requirements and begin operating the trademark conformance program.

Maintain the program’s requirements in a highly visible manner, and begin accepting registration applications! Keep a list of certified solutions on the project’s website or code repository.

In fact, the development and administration of the conformance program itself can even be run as an open source project (see: https://github.com/cncf/k8s-conformance). 

Keep in mind that these programs will need to be maintained as well, especially as the project evolves and makes significant changes to its modules and interfaces. We often treat these conformance programs as their own open source collaboration that evolve with the project. 

Example Programs Employed by Projects Supported by the Linux Foundation

A number of our projects have trademark conformance programs. These include:

1. Certified Kubernetes®

The Certified Kubernetes program is run by the Cloud Native Computing Foundation (CNCF) and is intended to ensure that open source code and vendor products based on Kubernetes support the core APIs that make up Kubernetes. Vendors that are interested in using the Certified Kubernetes mark are required to submit conformance testing results to CNCF for review and approval. Additional information on the program can be found here: https://www.cncf.io/certification/software-conformance/.

2. ODPi Egeria Conformant

The ODPi Egeria Conformance program is intended to ensure both consistency and alignment with the interfaces developed by the ODPi Egeria project. The participation form and the terms and conditions of the program can be found here: https://www.odpi.org/projects/egeria/conformance.

3. OPNFV Verification Program (OVP)

Created through collaboration between OPNFV and ONAP, two projects within LF Networking, OVP focuses on compliance, validation, performance, and interoperability testing for commercial NFVI (cloud platform infrastructure) implementations and VNFs (telco cloud applications). This conformance program is used to indicate that an OVP-branded product or solution:

    • Supports key behaviors, functions, and related APIs and packaging requirements of the OPNFV and ONAP release
    • Implements defined NFV functions
    • Supports end-to-end life cycle management interoperability among an NFVI/VIM built on the conformant products, applications designed to run on that infrastructure, and ONAP
    • Is a good candidate for internal testing by the operator in their own specific environment

Products or solutions that meet these requirements are then able to use the OPNFV VerifiedTM brand under the appropriate usage guidelines. The program supports both self-certification by vendors and testing via approved third-party labs. Detailed information on OVP can be found here: https://www.lfnetworking.org/ovp/

4. Powered by OpenDaylight®

OpenDaylight is one of the technical code projects within our LF Networking umbrella which has a “Powered by OpenDaylight” conformance trademark program. Products using the mark are required to implement certain core sections of the open source code with the current release of OpenDaylight or the prior two releases. A FAQ on the program can be found here: https://www.opendaylight.org/ecosystem-solutions/for-solution-providers/powered-by-faq-page 

The registration page for a company interested in applying to use the “Powered by…” trademark can be found here: https://www.opendaylight.org/ecosystem-solutions/for-solution-providers/powered-by-reg-form