What Every Engineer Should Know About Open Source Software Licenses and IP

Advocates for open source software tout its benefits, such as how the peer review nature of crowd-sourced development leads to reliability, and that transparent code enables developers to find and correct security flaws. Because many companies choose to use open source software, engineers who become expert in an open source project may find it easier to translate their skills into different working environments.

Beyond these advantages, engineers engaged in open source software development appreciate the camaraderie they find in the communities that form around each project.

The legal dimension of open source software may be a mystery to many engineers. However, the legal rights and obligations, defined typically within one of various open source licenses, define authorized and unauthorized uses of the open source project. Furthermore, the license may impose obligations on certain authorized uses. As discussed below, some of these obligations may be incompatible with a company’s business model.

To get a better understanding of the legal ins and outs of open source, we sat down with three attorneys on Uber’s legal team, Matt Kuipers, Rakesh Michael, and Samantha Hsu, who are overseeing this area of our tech stack. Responsible for paving the way for releasing internally developed software to the public and vetting which open source software we can integrate with our own solutions, this team’s unique engineering background facilitates a collaborative and constructive experience when it comes to navigating this process.

Matt, who works as senior counsel for Uber, holds a Phd. in engineering; Rakesh, also a senior counsel at Uber, earned a bachelor’s degree in engineering; and Sam, counsel for Uber, holds a bachelor’s in engineering. All three attorneys focus on intellectual property (IP) and patent law.

We asked Matt, Rakesh, and Sam what every engineer needs to know about the relationship between IP, patents, and open source:

Intellectual property and how it applies to software

In a general sense, intellectual property (IP) refers to intangible creations of the human mind, including inventions (such as processes or methods), literary works, musical works, designs, symbols, and phrases. IP can be protected under U.S. law via patents, trademarks, copyrights, and trade secrets.

In regards to software, a person or company can copyright written code that it developed, so that no other person or entity can copy that written code without coming to some sort of agreement with the original creator. The creator of the software can also patent the underlying ideas or inventions behind the software. For example, if the code is part of a software application that accomplishes some task, the creator of the software may be able to patent the manner in which the software performs its task, or the processes or operations being performed by the software.

Many companies have IP that they protect in the form of trade secrets. A trade secret can be broadly defined as any secret information that confers value on its holder by virtue of it being kept secret. Thus, a trade secret could be software, a process, or some know-how that provides a competitive advantage and that a company keeps private and secure. Trade secrets enjoy some legal protection, such as legal liability for those that improperly acquire or share another company’s trade secrets. However, a company with trade secrets is required to take concrete steps in order to protect them and maintain their secrecy. This means that if a company were to make its software open source, that software would lose any trade secret protection it might have had.

Open source software licenses

An open source software license is a ready-made means for a copyright owner of software to let other people use their code. Without that license, anybody using the code could be accused of infringing on the IP of the copyright holder. Open source software is generally still protected by copyright, but the license the owner assigns to the code describes how other people can use it.

There are different types of open source software licenses that vary in how they permit people to use the code. The MIT License, for example, lets anyone copy, modify, distribute, and even sell software that makes use of the code, with the sole caveat that a copy of the license, which bears the author’s name, must be included with any distribution. However, the MIT License does not specifically grant the rights to use a patent covering the method or process performed by the open source software, although there is a school of thought that the license implies patent use. Remember, a patent protects a method or process—what an application does. The Apache License, Version 2.0 (“Apache 2.0”) specifically permits both copyright use and patent use. Companies that make use of open source software under this license can take a little more comfort that their use is protected.

One category of open source software license, referred to as copyleft, stipulates that any derivative work, meaning any software that makes use of the original software, must also use its original license. The GNU General Public License and the Mozilla Public License fall under the copyleft category. A company might be less inclined to use software distributed under a copyleft license because it would be obligated to open source the resulting software, even if it contained proprietary code.

It is entirely up to the copyright holder to decide which license to apply.

Open source software is not free

While open source code may be offered at no cost, there are still associated costs with inbounding open source software. For one, there is the engineering cost of relying on third-party software, such as the labor associated with implementing and maintaining it. Engineers understand this cost well. However, there is an analogous cost associated with policing the internal use of open source software to ensure compliance with the licenses. When a user of open source software breaches the license, the user becomes an infringer of the copyrights of the software, and the results can be severe. For example, the user may be forced to pay damages, remove the infringing software, and even open source all of the source code of the product that includes the open source software.

Complicating the situation is the fact that open source software may be imported internally for an initial use that complies with its open source license, but the use of the software may change over time, perhaps without the engineers knowing the restrictions or obligations imposed by the license. Attorneys for a company may use software to monitor how open source code is being used internally, so that software built using open source software remains in compliance with the respective open source licenses.

Furthermore, just like a security vulnerability in an open source project creates a risk for any products using the project, it may be discovered that an open source project has an IP vulnerability (e.g., potential patent infringement) that creates a legal risk for any product incorporating the open source code. This is because most open source licensing has an attribution requirement. People who want to exploit a discovered vulnerability of an open source project need simply only review the product’s attributions list to determine whether they can attack the product using the vulnerability. In contrast, if proprietary software was used instead of open source software, then it may be difficult for attackers to determine the product is vulnerable.

The role of attorneys in open source software licensing and use

In a corporate environment, engineers tend to either make use of open source software for an internal project, or want to make code they have written available as open source software. In either case, a company’s legal department can provide very important assistance. At Uber, we try to involve our attorneys as early as possible in any open source software project.

When making use of external code, an attorney can determine how that code’s license will impact proprietary code within the company. If, for example, software licensed under the GNU General Public License (GPL) was used in a company’s distributed software product, it could mean that the source code of the entire product must be provided under a GPL license. Such a requirement may be incompatible with the user’s business model. However, if there is significant advantages to using source code offered under an incompatible license, in some cases an attorney might be able to help by facilitating discussions with the copyright holder to change the license to a compatible license. We have found in a number of cases that owners of open source projects sometimes are unaware of the negative impact a selected license may have on wider adoption of the project.

As for turning code written within a company over to the open source community, that initially comes down to a business decision: whether the company’s executive leadership decides it would be in their interests to provide access to certain software projects. Attorneys can help perform the cost-benefit analysis. For example, an IP attorney can help evaluate the impact of open sourcing a particular project to the company’s trade secret or patent portfolios.  

Furthermore, once it is decided to open source a project, attorneys can facilitate the transition from proprietary to open source software. In an important role, an attorney can determine the best open source software license to use, taking into account the nature of the company’s business, what the software does, and the compatibility of any licenses of the project’s dependencies.

Engineers at Uber appreciate the fact that the attorneys on the open source team have backgrounds in computer or software engineering. Such attorneys can have a good comprehension of how software released as open source might be used, the practical effects of different licenses in the context of the particular software, and what sort of impact it might have on the reputation of the company.

The open sourcing process from a legal perspective

Once a company has decided to open source software that it has developed, there are a number of issues it will need to address:

Using open source software, from a legal perspective

When considering whether to use an open source software project, attorneys can vet the license under which it is distributed to make sure it poses no risk to a company’s business or existing software. That analysis must include a look at the software’s dependencies, and what licenses they use, which will also impact the company.

Along with considering the licensing, another important question to answer is how the open source software will be used. Is it a component that will be distributed as part of an app? Is it a tool that an engineer will use to build or verify code? Is it a back-end system? Each type of use might involve a different consideration on how it will impact a company’s business. For example, distributing an app with open source software carries different responsibilities and risks than using an open source tool for internal purposes.

More extensive research around using open source software comes in the area of patents. An attorney can research which companies are using the code and what patents they have filed, making sure that the company they represent is not onboarding the code to use in a way that infringes a patent.

Open source software licensing at Uber

Uber has recently switched its default open source license for outbound projects from the MIT license to the Apache 2.0 license. Both MIT and Apache 2.0 licenses are terrific choices for projects with a goal of wide adoption because the licenses are permissive. The fact that Apache 2.0 explicitly calls out patent use rights may make it more attractive for corporate environments. The decision to switch, initiated by our engineers and facilitated by our legal team, came partially from the fact that many of the open source software projects we use are licensed under Apache 2.0. Standardization on this license helps create coherency of community norms and may reduce differences between different codebases used at Uber.

The attorneys at Uber value partnerships and collaboration within the open source community. When an Uber engineer wants to incorporate open source software, our attorneys may reach out to the software’s owner to explore whether the software owner would be interested in Uber using the software. For example, the software may receive more attention and more contributions if a company like Uber used and supported it. If the owner would like Uber to use the software, the attorney and the software owner may work together to find an open source license that is acceptable to both parties.

We would like to give a big thank you to Rakesh Michael, Samantha Hsu, and Matt Kuipers, portrayed in the top photo, for providing all the information offered in this article. Further, we want to acknowledge the help they and their teammates at Uber; Jay Choi, Rafa Gutiérrez,  Stephen Garcia, Bill Harmon, Tiffany Bui LeTourneau, Chris Storm, and the whole IP team; give to our engineers in both open sourcing software and onboarding open source software.

Uber engineers are active in the open source community, having contributed many projects.

If you want to learn about and contribute to Uber’s open source projects, check out our Github page. Our knowledgeable attorneys help us bring these projects to the community, ensuring the quality of the licensing throughout the software and any dependencies. If you are interested in building software and working with our open source efforts, visit the Uber Careers page.

Subscribe to our newsletter to keep up with the latest innovations from Uber Engineering.