3

Open Source License and IP Management

One of my favorite slides regarding open source license and IP management comes from my colleague Mike Dolan of the Linux Foundation:

Figure 3.1 – Comparing good and poor IP management using illustrations in garage organization

I like this slide not only because of the stark contrast but also the focus it places on the importance of the details. The floor colors carry over to the stripe on the wall. The gas pump hose has space to bend around in a nearly perfect circle. The toolboxes all match. Even someone who might not notice that level of detail would certainly recognize the garage on the right as more appealing than the chaos on the left.

A good software developer will obsess about similar details in their code, such as indentations, spacing inside of statements, positioning of brackets, comments, and variable naming. Here, it’s not a case of obsession, but it’s because they view putting a bit of extra work upfront saves them time later in tracking down bugs or refactoring. This is similar to license and IP management; the aim is to add clarity, consistency, and documentation regarding all the details of how code can and can’t be used, the expectations and obligations of that contributing code, and clarity on brand usage. Where code styling guidelines look to save time for both downstream users looking to extend the code as well as project maintainers down the road, it is the same for licensing and IP management, which both save time for those same constituents, making it easier for the code to be used downstream of the project.

Important note

Before we dig too much into this chapter, I want to add one disclaimer. While there are many things I am – a husband, father, author, and open source expert – one thing I certainly am not is a lawyer. Please do not constitute anything I am saying as legal advice; if you need legal advice, I would suggest contacting an attorney, preferably one with experience in open source licensing.

In this chapter, we will discuss licensing and intellectual property management for open source projects. We will cover the following topics:

• Permissive versus non-permissive licensing – why and what to pick?
• Copyrights and contribution sign-off
• Brand and marks management

By the end of this chapter, you will have a good sense of the areas of focus for open source projects concerning licensing and intellectual property management.

Permissive versus non-permissive licensing – why and what to pick?

If we boil down all the licenses out there, there is a general spectrum for the restrictions and responsibilities of the user of the open source code that spans from permissive usage to non-permissive or what is known as copyleft. More on what copyleft is can be found at https://copyleft.org/.

Richard Stallman, in defining what free software is, came up with several freedoms that were the cornerstone of defining the expectations of what free software is. After some evolution over time, the following four freedoms were established (starting its numbering from 0). The following work was adapted and modified from, under the CC BY-ND 4.0 license, https://www.gnu.org/philosophy/free-sw.html#four-freedoms:

1. The freedom to run the program as you wish, for any purpose (freedom 0).
2. The freedom to study how the program works and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
3. The freedom to redistribute copies so you can help your neighbor (freedom 2).
4. The freedom to distribute copies of your modified versions to others (freedom 3). By doing this, you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

So much of how both free software and open source licensing philosophically build from those freedoms. These freedoms establish a general set of expectations you should have from open source.

From there, we get into a lot of nuanced details, which has led to extensive license proliferation. The Open Source Initiative, which is an organization created out of the meeting in 1998 discussed in Chapter 1, The Whats and Whys of Open Source, and is the steward of the definition of open source, has approved over 110 different licenses as of this writing [1], as does the Free Software Foundation [2]. The Software Package Data Exchange (SPDX) project has license identifiers for over 450 licenses [3] as of this writing. This doesn’t consider the many variations of an existing license for a specific project. Choice in open source like this is a good thing, but with too many choices comes confusion. This confusion can come in a myriad of ways but generally falls into one of a few categories:

• Obligations of the license chosen. When we look at non-permissive or copyleft licenses in the following section, you’ll see the many obligations that can be unclear on how to best stay in compliance.
• How the code under one license can be leveraged or used by code under another project with a different license. Depending on the license, this could result in code needing to be relicensed to be compliant.
• Differences in license variation and why you would pick one versus the other. The family of BSD licenses is a good example, with four different official variations and then numerous derivates from there. Each has different minor stipulations created to address different situations, but how important is each for a project?

Most organizations who use open source code in their internal tooling or projects have adopted guidelines that align with the most common licenses to avoid constant legal reviews, resulting in more open source code being able to be used. I’ll dig more into this as we talk about getting your organization to let you launch an open source project in Chapter 4, Aligning the Business Value of Open Source for Your Employer.

Let’s dig into what each end of the licensing spectrum looks like.

Permissive

Permissive licenses, as written, tend to be the simplest type of open source license, giving the user not only the four freedoms outlined previously but also the ability to use the code generally with minimal obligations on the user. Permissive licenses are typically quite short, for example, the MIT License [4] stated as follows:

Copyright <YEAR> <COPYRIGHT HOLDER>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF, OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Typically, permissive licenses try to steer clear of any liabilities on the project itself, granted software patents, and any other guarantees. The idea is that the project or author of the code just wants to get the code out there and for people to use it.

The Apache License, Version 2.0 [5] falls in the general family of permissive licenses but adds a bit more in terms of guarantees to the downstream user. First off, it is an explicit copyright license from the contributors to the project to each downstream user; licenses such as the MIT license referenced previously more implicitly grant this. Additionally, the Apache License, Version 2.0 ensures that any software patents that the contributors have are granted a license to the downstream user, which often helps resolve concerns around adding explicit language for this in a contributor agreement (which we will discuss in the next chapter) or another document. For those two reasons, generally in open source areas, the Apache License, Version 2.0 has become incredibly popular as it is viewed as more corporate-friendly.

Non-permissive or copyleft

Where permissive licenses generally stay out of the space of defining specific responsibilities on the downstream user, non-permissive or copyleft licenses more explicitly set these expectations. Probably the most well-known license in this category is the GNU General Public License [6], which is the license used by the Linux Kernel project and many of the desktop applications built as open source, such as Blender, Inkscape, LibreOffice, and more.

Copyleft licenses are designed with the intent to ensure the code in the project, as well as any improvements made downstream, remain under the same license as the project. If you go back to the 1980s when free software was coming of age, as we talked about in Chapter 1, The Whats and Whys of Open Source, free software was a counter to the proprietary models dominating the software industry, and there were major concerns of free software effectively being absorbed by vendors and moved into becoming proprietary software. This licensing model was certainly critical as projects such as the Linux Kernel project, GNU toolchain, and others were becoming more popular.

The concerns about copyleft licensed open source code come down to the ability to incorporate it into other proprietary software. Depending on how that is done, there are arguments to state that the entire work (both the open source project and the proprietary software) is required to be licensed under the project license. This has generally driven product vendors to stay away from copyleft software – both in terms of incorporating it into the proprietary software they are building but also sometimes from using it altogether. This continues to be an evolving legal area.

With some copyleft licenses, such as the GNU General Public License, Version 2, there was a fair amount of creativity in how to use such licensed code in a proprietary offering. Tivo was one example, where the software for Tivo set-top boxes incorporated code from the Linux Kernel and the GNU toolchain into the software used. While Tivo complied with the terms of the GNU General Public License, Version 2, their hardware had Digital Rights Management (DRM) incorporated, which made it impossible to run modified code on the hardware. This was called Tivoization [7] and was permissive by the letter of the license, but not the spirit of the license, and drove most of the intentions in version 3 of the GPL.

Another case was around the use of open source by cloud providers. In these cases, the software wasn’t distributed at all but used by a user on a shared system, which was a concept not popularized until the early 2000s. At that time, copyleft licenses didn’t address this concept, but later, licenses such as the GNU Affero General Public License [8] and the Commons Clause [9] were developed to address this, requiring access to the open source licensed software running on those systems.

Which type of license makes sense for my project?

Here is the area where, once again, I will emphasize that I am not a lawyer and can’t provide legal advice.

When I generally talk with projects about licensing, there are a few considerations that are part of the discussion:

• Who is the user, and how do you expect the user to use the code?
• Is there a need to set expectations of pushing code and development upstream (meaning to the primary code base of the project), or is that already in the culture of the community?
• Do you expect commercial usage, and how do you as a project maintainer feel about that?
• What type of project is this? A library? A ready-to-use application? A framework?

I have left out the question of a maintainer’s personal view on software freedom intentionally. While there will be those biases that will be incorporated into the decision-making process, I generally advise that they not be part of the considerations. A good open source project put its users first.

What I generally see is open source projects and code that are part of the building blocks of an application, such as libraries, frameworks, and integration layers, work best under a permissive license. The reason for this is the intention of the code usage; it’s going to be mixed with propriety code, so the copyleft obligations are going to be a major concern. Generally, we also see the primary users of projects such as these are software developers, and within that culture, there is a desire to upstream, mostly because of pragmatism – who wants to have to patch a dependency every time the upstream project makes a new release?

For more end user applications, such as desktop or web applications, the general trend is to go with a copyleft license. This is primarily to encourage development upstream and have a more consistent version and release cadence, as well as direct vendors looking to build a business model to focus less on selling a version and more on providing ancillary services such as support and training. There is also the argument that using copyleft is helpful when the software is encroaching on a highly competitive space with multiple commercial offerings exist. An example here is MySQL, which came to be when the market was dominated by commercial solutions. I would argue that this approach, if development is primarily done by one organization, can lead to the Open Core model described in Chapter 2, What Makes a Good Open Source Project?

If your project doesn’t fit in either category, then start thinking from the perspective of your user – what expectations do you have of them and how much of a community are you looking to build? If you sense the culture of your community will naturally be more collaborative, and more software engineering focuses on open source leans this way, the additions of copyleft obligations might not be worth it. If that’s not the case, then a copyleft license could be a better option.

One thing I will say is that once you pick a license, it’s a lot of work to change it. The biggest factor that makes it hard is that to change a license, every contributor who owns the contribution made to the project (unless there is an agreement in place that provides a copyright license – this is something we will cover in the next section) must agree to relicense the code they contributed to. If there are only 3-4 contributors – it’s fairly easy. But let’s say there are 50 or 100 contributors, and some of them haven’t contributed in quite some time and are hard to contact – that becomes a painful challenge. In the case that a contributor’s agreement to relicense the code isn’t granted, the project has to remove that code and potentially rewrite it. So, yes, pick your license wisely.

Now that we’ve discussed licensing, let’s start to look into the next key part of intellectual property management – how to manage incoming contributions to an open source project and copyrights.

Copyrights and contribution sign-off

When people think about license and IP management, the conversation often focuses on outbound licensing – that is, what license the code from the project uses. But just as important (or even more important) are the terms that the code comes into the project under, because if it doesn’t come in under the license and/or terms that will work with the license the code is released under, it makes it difficult on downstream users to use the code.

In smaller projects, this is often overlooked, as you often will only see a few contributors to the code base, so project maintainers tend not to pay much attention to contribution sign-off. But this can quickly get out of control, especially if you have someone come to the project and say, “Hey, that code looks like something someone pulled from my commercial product.” It gets awkward quickly here at this point, as the project is suddenly scrambling to see who added the code, hoping that someone knows the person and it’s not just someone with a random GitHub user account. Remember that picture at the start of this chapter? Don’t be that project ;-).

There are generally two approaches seen in open source for a contributor to indicate their sign-off or approval for code to come into a project, and they, in some cases, are used in conjunction with each other. They are the Contributor License Agreement (CLA) and the Developer Certificate of Origin (DCO). Let’s look at them now.

Contributor License Agreement (CLA)

A CLA is a legal document executed by a contributor that provides an agreement between the project and the contributor on the terms and conditions for the contributions that the contributor makes to the project. CLAs can be agreements with either an individual or an organization, referred to as an Individual Contributor License Agreement (ICLA) or Corporate Contributor License Agreement (CCLA), respectively.

For CCLAs, these will typically cover a set of named individuals from an organization or all employees and contractors for an organization. These agreements typically only have to be executed once to cover all contributions for a given individual or organization. However, if the terms in the CLA change, the individual or organization would need to re-execute the agreement before making future contributions.

A project will typically use a CLA for project contributors to specifically address the rights and obligations of contributors. Some examples of those situations include the following:

• Allowing organizations to provide a license to any software patents they own that are used in the project
• Letting an organization specifically identify individuals who may contribute on their behalf
• Requiring the contributor to provide a copyright or IP license to the project, or in some cases, entirely assigning copyright and IP rights to the project

CLAs terms tend to be a bit all over the place, and unless a standard template is used (such as the Apache CLA [11]), they will often require legal reviews for organizations to be comfortable with contributing to the project. Because of that, CLAs can add some friction to contributors, even on projects where there’s a CLA with very lightweight terms. Some contributors will even refuse to contribute to a project with a CLA; sometimes, this is more idealistic, but other times, there can be a bit of fear and lack of trust in a project that implements a CLA.

We’ve also seen CLAs used in conjunction with the Open Core model described in Chapter 2, What Makes a Good Open Source Project?. This is because the organization needs to have the right to relicense the code under a commercial license for their non-open source products. But we’ve also seen this as a way an open source project could be taken to become a proprietary product or have added more restrictive licensing. Examples of projects where this has happened include the following:

• MongoDB, which changed from the GNU Affero General Public License version 3 (AGPL v3) [12] to the then new Server Side Public License (SSPL) [13] after concerns with cloud providers monetizing their customers using MongoDB without MongoDB, Inc. gaining revenue from that [14]
• Redis Labs added the Commons Clause [15] to its open source code due to similar concerns with cloud providers ]16]
• SugarCRM initially provided its community edition under its own SugarCRM Public License [17], later moving to the AGPL v3 and finally moving to an entirely proprietary product

I know I’ve presented CLAs in a bit of a negative light, but that is not always the case. For some organizations, using a CLA helps address some of the ambiguities the license of an open source project might have. An example would be an open source project using the BSD 3-Clause license [18], which doesn’t address an organization giving a license to any software patents they might own. Depending on the industries and circumstances in which the code is to be used, a CLA can cover gaps like these while enabling a project to use a more permissive license that might not address those gaps directly. On the other side, licenses such as the Apache License, Version 2.0 [19] have provisions that often can make a CLA redundant and eliminate the need for one, which has been a factor in its popularity in open source projects driven by commercial vendors.

Developer Certificate of Origin (DCO)

At the height of the lawsuit where the company Santa Cruz Operation (which many will recognize by its acronym, SCO) was disputing copyright claims on code within the Linux kernel project [20], there was discussion on how to streamline the contribution signoff process without adding the perceived friction that implementing a CLA would bring. There was a culture within the Linux kernel project where contributions were owned collectively rather than by one group. Naturally, this made the Linux kernel project copyright ownership situation a bit of a spider web – but that is by design, as it ensured that the technology could progress openly and without any specific vendor taking the project in one direction without the consent of all the contributors. Think of it as making the project a commons of sorts.

While much of the legal basis for the SCO allegations was dismissed over two decades, the concept of making this model more streamlined into the contribution workflow was necessary for that community. Thus was borne the Developer Certificate of Origin [21], a simple declaration a contributor makes by adding a Signed-off-by: line to their source code commit message. This sign-off asserts the following:

Developer Certificate of Origin

Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Developer’s Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I

have the right to submit it under the open source license

indicated in the file; or

(b) The contribution is based upon previous work that, to the best

of my knowledge, is covered under an appropriate open source

license and I have the right under that license to submit that

work with modifications, whether created in whole or in part

by me, under the same open source license (unless I am

permitted to submit under a different license), as indicated

in the file; or

(c) The contribution was provided directly to me by some other

person who certified (a), (b), or (c) and I have not modified it.

(d) I understand and agree that this project and the contribution

are public and that a record of the contribution (including all

personal information I submit with it, including my sign-off) is

maintained indefinitely and may be redistributed consistent with

this project or the open source license(s) involved.

In effect, the contributor asserts they’re allowed to contribute the code to the project because either they created it, or they created it with someone or got the code from someone, and it’s under the same license (or they have the right to put it under the license being used by the contribution). Additionally, they indicate that the personally indefinable information they submit along with the contribution will be maintained indefinitely with the project and redistributed with the project as any contributor information would be – something very important to address with the many data privacy regulations commonplace globally.

Version control systems such as git make it trivial to do a sign-off with a commit by issuing the git commit -s command when doing a commit. GitHub also has tools to automate adding the signoff as part of contributions made through its web-based interface. DCOs are quite popular with open source projects, with thousands using the DCO due to the simplicity of the mechanism.

All that said, because of its simplicity, this means some gaps are not directly addressed, which can cause concerns for organizations looking to contribute to a project, such as the software patent concern shared in the previous section. Sometimes, organizations see the actual open source license used as able to address the gaps. Other times, using the DCO in combination with a more lightweight CLA works. The latter approach was used by several of the open source projects hosted by the Academy Software Foundation until they shifted to using the Apache CLA [22].

Choosing the right approach that makes sense for your project lies in understanding the downstream users and organizations. We’ve seen the importance of code providence in the last several years – meaning organizations want to understand where the code they are using is coming from. Software supply chain attacks, as of this writing, are sharply on the rise. If a project cannot attest to where a line of code comes from, it poses a risk to every user of the code. On top of that, continued sensitivities on software patents, as we’ve talked about, add another dimension to the right level of rigor relative to risk management; in other words, you want to strike a balance between how much work it is for a new contributor to contribute and the right amount of legal protection in place for the project and its users.

Some good questions that can help guide you as a project maintainer on which path to go down include the following:

• Who are the users of the project? What industry are they in? What regulatory or other considerations are there?
• Who are the contributors to the project? Larger enterprises? Start-ups? Individuals?
• What license is the project using? Does the license have specific language around copyright or patent licensing?
• What are your intentions for the code to be used in a project? (the same question that was asked regarding picking a license ;-))

Generally, as a project, it’s advisable to lean toward the lightest way for contributions to come in. Even CLAs, when used, can be executed using automated tools such as LFX EasyCLA [23], and sticking to a standard template keeps the friction low.

Managing intellectual property for a project is more than just the code since the brand, project name, and other assets are very important to an open source project’s success. Let’s look at best practices for brand and marks management.

Brand and marks management

One of the last considerations (you could argue it’s one of the most critical for a project) is managing the brand. For a smaller project, this might not seem like such a big deal, but for a bigger project, this can be critical to its success.

We’ve seen examples of this many times in open source. One that comes to mind immediately is the PHP project, which in the early 2000s took off as the go-to web development language. From there, all sorts of projects were built using PHP. One such project was named phpMyAdmin, which is still a popular web application for managing MySQL databases. We saw all sorts of projects taking the same approach, naming themselves PHP, which could mean anything from a developer tool, end user application, or library. The only common thread was they were written in PHP.

On the one hand, that sort of publicity made PHP more popular. But on the other hand, it added confusion; for example, is phpMyAdmin from the PHP project itself? If this were a product company, a good product marketer would immediately recognize this as brand confusion. But as an open source project, this momentum can get away from the maintainers and, in some cases, is outside of their skill sets.

So, what should a project maintainer think about in the scope of brand management? Let’s explore some areas.

Determining your project’s name

A project should determine exactly what its brand is. Much of this is thinking about its distinctiveness to the user; namely, does the name connect to the project’s purpose? A project such as OpenEXR makes that clear – it provides the specification and reference implementation of the .exr file format. Sometimes, projects use a name that, through a story, relates to the domain or the time and place the project was created. Debian’s name is described as a portmanteau, combining the first name of the project founder Ian Murdock’s then-girlfriend, Debra Lynn, with his name, Ian [24]. Apache HTTP Server was named as it was a patch (or rather a set of patches) to the original NCSA web server.

A project can get too clever here too. While researching for this book, I came across an article [25] talking about the open source project Twisted, which is an event-driven networking engine written in Python. While the space and problem being solved by the project made the naming appropriate, it did lead to some bad jokes (that is, Twisted is so twisted), metaphors that only make sense in a certain region (that is, naming a package twisted.spread.jelly), and a fun copyright infringement with a popular heavy metal band (twisted.sister).

As a project is considering a name, it’s really important to make sure no one else is using it – if so, you run into not just confusion but potential trademark infringement. A good place to start is searching Google and GitHub for the term and seeing what comes up – if you see a few projects or commercial products, it’s usually a bad idea to proceed with that name. The next step would be checking the various trademark databases, both with the US Patent and Trademark Office (USPTO) [26], as well as with the European Union Intellectual Property Office (EUIPO) [27]. If this comes back with no results, or none in the goods and services related to your project, generally, things are fairly safe. If not, either find a new name or discuss more with a trademark lawyer.

Brand consistency

Once you have a name, the next step is establishing its brand. A brand will usually have a few different aspects, such as the project name itself, a logo, and maybe a saying or descriptor. The big thing at this stage is ensuring you are consistent; let’s take the example of a fictional project named Zeus:

• Is the project name Zeus or ZEUS or zeus (notice the difference in capitalization)?
• Is it Zeus Project? Zeus Framework? Zeus Suite?
• Is there a logo for Zeus? Is it distinctive, or just the word Zeus spelled out?

The importance at this stage is consistency across the board. Having one person call it Zeus and another Zeus Framework makes it confusing if they are the same project or something different.

The same is true for a logo; it should be the same colors, scale, and design. Take this example from the Linux Foundation Trademark Usage guidelines [28] as a guide – it speaks about the correct usage of the Kubernetes logo:

Figure 3.2 – Examples of correct and incorrect usage of the Kubernetes logo (source: https://www.linuxfoundation.org/legal/trademark-usage)

These might seem like minor details, but they are critical in brand management, not just to help decrease confusion but also to showcase the project as a professional, well-run project.

Protecting the brand

In general, the best way to protect your brand is to use it consistently. Even if a project goes down the path of registering trademarks or logo marks, they become incredibly hard to defend if used inconsistently. This is a classic example of the adage that an ounce of prevention is worth a pound of cure; being intentional in how the project uses its name and logo set it up for success.

After that, the next level of protection is trademark registration. 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.” By default, a project using its mark effectively gives it the protection known as a common law trademark, which is generally considered a valid owner of a mark by trademark offices globally. The next step up from there is registering a trademark, which, depending upon the term used, the popularity of the project, and the industry in which the project is used, can be an advisable step. All that said, it can get costly, both for registration and maintenance. This is often an area where we see projects look to move toward a vendor-neutral entity, such as the Linux Foundation, the Apache Foundation, or The Software Freedom Conservancy, all of which have deep experience and expertise in managing trademarks. We will discuss this a bit more in a later chapter when we talk about the role of foundations in open source governance.

Enabling others to use your brand

Apache Hadoop was a huge technology that gave birth to the entire big data industry in the 2010s, with billions of dollars of venture and product investment and many downstream products leveraging the project. With that, we saw the term Hadoop being thrown into the product naming for several offerings, with the term Hadoop Distribution becoming commonplace. There was one problem that end users had with this situation – what does being a Hadoop Distribution mean? Does it mean a certain version of Hadoop? Certain configuration? Does one Hadoop Distribution work with another? Does a product designed to work with Hadoop work with any Hadoop Distribution? Details like these seem minor, but in the realm of enterprise software, they are critical for growing an ecosystem.

Just like the PHP example earlier in this chapter, making sure your brand is used in such a way that communicates clearly with downstream users is critical to a project being able to grow an ecosystem. It’s something to get ahead of, too; many projects start building trademark and branding guides to help clarify this. One example is the Open Mainframe Project, which has branding guidelines [29] to help make it clear how its projects can be referenced, including how an organization’s role in a project should be established.

But coming back to the Hadoop example, there is value in a project establishing its downstream ecosystem and what it means to be compatible with the upstream project. This is an area where establishing a conformance program can be valuable. These programs let the project community set standards for products and offerings based on or leveraging the project in such a way as to develop an ecosystem. Some examples include the following:

• Certified Kubernetes [30], which ensures that every vendor’s version of Kubernetes supports the required APIs, as do open source community versions
• Zowe Conformance Program [31], which aims to give users the confidence that when they use a product, app, or distribution that leverages Zowe they can expect a high level of common functionality, interoperability, and user experience

By being part of such a program, a project will grant the use of a special set of marks to the product or offering to indicate its alignment. Programs are managed using objective criteria, and often a third party will be involved in the evaluation process to ensure there is no vendor bias.

Note that conformance programs don’t infringe on the ability of others to use the code – the code is still available under the project’s license. This would just add a way to solve the end user concerns that a product using the term Hadoop Distribution would have had; now, there are both specific criteria of what that means, but also clarity on the project’s brand.

Summary

This chapter scratched the surface of license and IP management in terms of open source but aimed to give you enough insight and knowledge so that you can start down the path of understanding this concept.

There are several resources to help guide you on this topic, namely FOSSMarks [32], some of the legal articles coming out of the Linux Foundation [33], and the Software Freedom Law Center [34]. For a lot of the basic needs of a project, this chapter is helpful, but I always encourage projects to seek legal advice as they get into more broad concerns and questions. As I stated at the beginning of this chapter, I am not a lawyer and cannot provide legal advice.

One thing you will note that I didn’t speak about is license enforcement – and that was intentional. While there are some narrow cases where taking legal action against a license violator is advisable, in the vast majority of cases, reaching out to them is a much better solution. One comment I’ve heard that resonates here is “The best way to ensure a person no longer contributes to your project is by sending them a cease and desist letter.”

Additionally, license enforcement is something that the project maintainers and/or authors should be the center point of; after all, they are the people that this directly impacts. I don’t often post on social media, but I did on this topic several years ago:

I see this article that covers Linus’s thoughts as an insightful counterpoint...

https://www.zdnet.com/article/linus-torvaldss-love-hate-relationship-with-the-gpl/

Net-net, I struggle to get more worked up about GPL compliance than the author of the affected open source compliance.

Now that we’ve covered licensing and IP management, you are well equipped to be able to take the knowledge you’ve learned up to this point and get your company to start working in open source. In the next chapter, we will help you get your company to start or contribute to an open source project, and how best to measure the investment and recognize contributions.

Further reading

To learn more about the topics that were covered in this chapter, take a look at the following resources:

[1] https://opensource.org/licenses/alphabetical

[2] https://www.gnu.org/licenses/license-list.html#SoftwareLicenses

[3] https://spdx.org/licenses/

[4] https://opensource.org/licenses/MIT

[5] https://www.apache.org/licenses/LICENSE-2.0

[6] https://www.gnu.org/licenses/gpl-3.0.en.html

[7] https://en.wikipedia.org/wiki/Tivoization

[8] https://www.gnu.org/licenses/agpl-3.0.txt

[9] https://commonsclause.com/

[10] https://www.apache.org/licenses/contributor-agreements.html

[11] https://www.gnu.org/licenses/agpl.txt

[12] https://lwn.net/Articles/768670/

[13] https://www.mongodb.com/licensing/server-side-public-license

[14] https://commonsclause.com/

[15] https://lwn.net/Articles/763179/

[16] https://spdx.org/licenses/SugarCRM-1.1.3.html

[17] https://spdx.org/licenses/BSD-3-Clause.html

[18] https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes

[19] https://developercertificate.org/

[20] https://tac.aswf.io/process/contributing.html#contributor-license-agreement-cla

[21] https://lfx.linuxfoundation.org/tools/easycla

[22] https://opensource.com/article/18/3/how-11-open-source-projects-got-their-names

[23] https://codewithoutrules.com/2017/06/14/how-to-name-your-software/

[24] http://www.uspto.gov/trademarks-application-process/search-trademark-database

[25] https://euipo.europa.eu

[26] https://opensource.com/article/18/3/how-11-open-source-projects-got-their-names

[27] https://www.openmainframeproject.org/branding-guidelines

[28] https://www.cncf.io/certification/software-conformance/

[29] https://www.openmainframeproject.org/projects/zowe/conformance

[30] https://fossmarks.org/

[31] https://www.linuxfoundation.org/blog/tag/legal

[32] https://softwarefreedom.org/

[33] https://en.wikipedia.org/wiki/Tivoization