Component Licenses FAQ

Key Takeaways

• Almost all open-source software is distributed with a license that governs how you’re allowed to use it.
• Open Source Software is distributed with a variety of different licenses. Some are more permissive than others.
• Failing to meet the terms and conditions of a license can result in legal consequences.
• You should know the licenses for the open-source software you’re using to ensure you’re not at risk.

Introduction

If you’re a developer, you’re aware of what a software license is and how it affects your team as you code and build applications. You know that some licenses are more restrictive, some are more permissive, and some make your legal team sweat. If you’re passionate about code, then you may have submitted a few pull requests to an open-source project you like and noticed the license at the top of the repo’s directory.

But licensing is a complex issue. 95% of the components in Maven Central are split across 17 different licenses, and the remaining 5% of components are split across a whopping 307 other licenses. What those numbers should tell you is that component licensing issues are just as thorny as component security issues, with just as much opportunity for risk.

Getting a holistic understanding of what component licenses are, why they matter, and their risks is a vital part of reducing the overall risk of your applications. Read through this FAQ to prime yourself on some of the complexities of component licenses.

This is not legal advice. We are not lawyers, and we are not your lawyers. This guide is for educational purposes only.

If you have concerns that your organization is not in compliance with the terms of a license, reach out to your legal team.

The Basics

What is a software license?

Put very simply, a software license is a binding agreement between the software’s author and the user that explains how the software may be used. Typically, the license permits the user to read, modify, and use the component as long as they follow some rules.

What is an open-source software license?

An open-source license is a license that declares the software is open-source. When software is “open source”, it means that the source code is made available for others to see and read.

What sort of components can have an open-source license?

Any component can be released as open-source and have an open-source license, and that includes the components that you’re using to build your applications, pulled from repositories like Maven Central and PyPi. In fact, you’re able to freely pull those components because they have open-source licenses.

Why do authors license their components?

Authors license their components to protect themselves, their code, their projects, and their business. In the context of open source, authors apply a license in order to ensure their component remains open-source.

Authors pick a license based on their goals. For example, a developer who wants to sell their code will release their code with a commercial license, which requires payment to use, whereas a developer who wants to contribute to the community will select an open-source license.

What does “derivative” mean in the context of component licenses?

That’s a complicated question. But in this context, we can consider software to be derivative of a component if the software contains that component at the time of the software’s deployment.

For example, a tool that helps you write or build an application, like an IDE or package manager, doesn’t appear in the software, so your software isn’t derivative in that way. But a framework component that you package with your application does make your component derivative.

Licensing Complexities

How do software licenses interact with copyright?

Full copyright control is automatically granted to individual software authors, even if the author doesn’t explicitly claim it. In this sense, a license is how you know that it’s okay to use the software even though the author holds the copyright. If there’s no license, then the author can freely disallow its use, issue take-down demands, or shakedown users, regardless of how the software is being used.

From a community standpoint, an open-source license also helps prevent a single contributor from controlling the use of the software. Imagine a component that is being jointly developed by many individuals. Each contributor has a “piece” of the copyright. So who’s in control? An open-source license says that all contributors have an equal claim to copyright, so long as they follow the rules laid out in the license.

What open-source licenses can authors choose from?

There are too many to list, and they each have their own complexities and histories. You can see a snapshot of some of the more popular licenses here.

Are all open-source component licenses the same?

No. Some licenses are more complex and place some big requirements on the user. Others are very simple and don’t have many requirements.

As a consumer of open-source components, the primary license categories you should be concerned with are Copyleft and Liberal. An open-source license that requires derivative work to be released under the same license is called a Copyleft License. An open-source license without that requirement is called a Liberal or Permissive License.

Do all open-source components carry equal risk?

No. Some licenses, like the GNU General Public License, put steep requirements on the user, including the stipulation that all derivative software be made open-source. Because this requirement could potentially put proprietary code in peril, the level of risk is high. As previously mentioned, a license that requires derivative software to be released under the same license is called a Copyleft License.

Other licenses, like the MIT License, are extremely simple and permissive, placing almost no requirements on the user. Since there are very few requirements, the risk is low. As previously mentioned, a license that doesn’t require derivative software to be released under the same license is called a Liberal License.

Still other licenses, like the WTFPL and so-called Beerware licenses carry risks that are difficult to define. As a general rule, consumers of open-source software should be wary of licenses like these. Their terms may seem straightforward, but a lawyer or judge might disagree. Because the terms of these licenses are difficult to predict in a legal context, their risk level is very high.

When does a component license “take effect”?

The simple answer is that license terms “take effect” when the software is distributed. However, in today’s ultra-fast software development environment, distribution is a complicated subject.

If you have concerns that your organization’s software isn’t complying with the terms of a license, reach out to your legal team.

Component License Risks

Why is it important to be aware of the requirements of component licenses?

If you’re not complying with the terms of a license, you’re opening your organization to significant risk. The component’s author can sue, issue take-down demands, request payment, and much more.

It’s important to note that, while Copyleft licenses can require applications to be released under the same license, there is currently no legal remedy wherein a closed-source application can be forced to become open-source. However, the license holder can still take legal action.

How seriously should I take component licenses?

Open-source licenses have a long history of being upheld in court as being legally binding and fully enforceable. In the past, even huge entities like Cisco, via its subsidiary Linksys, have been sued for failing to comply with the terms of open-source licenses in the components they were using.

What, specifically, do I need to be aware of when I investigate component licenses?

Keep these four things in mind as you think about the risks that come with component licenses.

• Distribution: As stated above, license terms “take effect” when the software is distributed, and distribution is a thorny subject. Think about whether or not your organization’s software will ever be distributed, or if it will merely be hosted or deployed in the Software-as-a-Service model. If it will be distributed, try and determine the exact moment in your development lifecycle this occurs.
• Patent Rights: When an organization decides to release software under an open-source license, or when they decide to use an open-source component in proprietary commercial software, they may be granting certain patent rights to the recipients of the software. It’s a complicated subject, but put simply, open-source licenses grant users privileges that may not be in line with your organization’s goals. Read more about the subject in this excellent paper by Laura Majerus.
• Notice Requirements: Some open-source licenses require that you notify users or customers about the license, their rights, your obligations, and other matters. Complying with this requirement is often as simple as copy/pasting a text file into your software but can occasionally be more complex, like in the case of consumer goods.
• Derivative works: As mentioned previously, applications that contain a component with a copyleft license must be released under the same license. This could be incompatible with your organization’s goals.

Check out our eLearning course about this topic to hear Sonatype’s Jerry Gergel discuss some of these topics in detail. Much of the information in this Guide is reviewed throughout the course.

What’s the risk if a license requires derivative works to be released under the same license?

The risk is that your organization will be required to release a lot of source code to users. Your organization’s applications are made unique, and have a place in the market, because of their proprietary code. If that code is released in a human-readable form, your organization may lose a key market advantage.

What about components that don’t have licenses? Do those exist?

They do, but consumers of open-source components should be wary. As mentioned previously, authors retain full copyright control over their work. Also mentioned previously, a license can be thought of as a contract between the author and the user, where the author promises to allow the use of the component so long as the user follows certain rules. This means that a component that doesn’t have a license is very risky because the author can disallow its use at any time, without warning, regardless of how the component is being used.

As a general rule, you should not use components that don’t have a license.

Do I have to follow requirement X if I’m only hosting the software?

Possibly. When it comes to component licenses, context is very important. As stated above, licenses “take effect” when your application is distributed. If the application you’re building will be hosted but never distributed, then some requirements may not apply. And if the application will only ever be used internally, as in the case of innersource components, then some other requirements may not apply.

Read through the license carefully, discuss it with your legal team, and be sure that you’re aware of the context of the application. Lifecycle and Firewall are contextual solutions that allow you to block or permit components based on the application they appear in.

Choosing Components and Investigating Licenses

How should I be handling the risk that comes with open-source component licenses?

The key strategies for handling the risk that comes with open-source component licenses are to review regularly, consider early, and get context.

• Review regularly. Automated reports about the component licenses, like the ones that Lifecycle generates, let you regularly assess the risks in your applications and make plans to remediate them.
• Consider early. Ideally, you and your development team should be addressing component license risks as you’re selecting components. Nexus Lifecycle can identify possible issues as soon as components enter an application, and Nexus Firewall can block components with risky licenses from ever entering your environment.
• Get context. If your application is internal or will only be hosted, then some requirements may not apply to you, which might reduce your risk and broaden the number of components that are compatible with your organization’s goals. Lifecycle and Firewall both allow you to set flagging rules that are contextual to the application being scanned.

When should I be investigating licenses on the components I want to use?

Ideally, you should be investigating component licenses as you’re selecting components. Identifying components with licenses that are risky or incompatible with your organization’s goals early will prevent them from entering your environment. If those components don’t enter your environment, there’s no risk.

How can I learn more about the licenses in the components I want to use?

As mentioned above, some licenses require notification and/or the full text of the license to be included with the component. In these cases, it’s as simple as opening a text file and reviewing it with your legal team.

However, most major licenses usually have their own websites. Visit them to learn more.

Remember, in order to encourage their uses, open-source licenses are meant to be easy to read and comprehend.

How can I get visibility into the components in my application?

In large applications, determining exactly what components are present can be a complex challenge. Regular reviews are critical, but if you’re starting from square one, think about the following:

• Can I automatically generate a list of components in my application? Nexus Lifecycle is built for this task. If you’re not a Sonatype customer yet, try the Nexus Vulnerability Scanner to get a quick snapshot of your application.
• Categorize your risks by their severity. Lifecycle and the Nexus Vulnerability Scanner do this for you automatically. Think about the consequences of falling out of compliance with each license.
• Categorize your licenses by type. If you have dozens of components with liberal licenses and no components with copyleft licenses, then your risk profile is fundamentally different than if the opposite were true. Again, Lifecycle and the Vulnerability Scanner make categorizing easy.
• Look for remediation strategies. Can components be upgraded, removed, or replaced? Does a similar component exist with a more permissive license? Do your research and target the worst offenders first. Lifecycle can help compare components and identify ones with less or no risk.

Additional Resources

Check out our eLearning course about this topic to hear Sonatype’s Jerry Gergel discuss some of these topics in detail. Much of the information in this Guide is reviewed throughout the course.

Also, read more about the subject in this excellent essay by Laura Majerus.

To learn more about the Advanced Legal Pack, an add-on for Lifecycle that helps make sense of licensing risks, visit our documentation on the topic here.

Talk to Us

Have more questions or comments? Learn more at help.sonatype.com, join us in the Sonatype Community, and view our course catalog at learn.sonatype.com.

And visit my.sonatype.com for all things Sonatype.