Component Licenses FAQ

Educational Foundations | Reading time: 12 minutes

Is this article helpful?

DevOps Building Blocks logo

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?

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

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 choose licenses based on their goals. For example, if a software author wants to generate revenue, they’ll pick a commercial license, which requires payment. But for open-source components specifically, authors pick an open-source license that protects the component and ensures it stays open-source.

Here’s an example. Imagine that a company uses an open-source component in software that they package and sell. In order to protect their proprietary code, the finished software is closed-source, meaning that customers can’t access or read the source code.

Though the company’s intentions are only to protect their proprietary code, they’ve essentially turned the open-source component into a closed-source component. That scenario could be undesirable to the author. To prevent it, the author can choose a license that requires derivative software to also be open-source. However, if the author isn’t concerned about scenarios like this one, they can choose a more permissive open-source license that makes no demands about derivative software.

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

In today’s software development environment, 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.

That means that tools you use to help you build software, including package managers like Maven and PyPM, and IDEs like Eclipse, don’t make your software derivative.

Licensing Complexities

Full copyright control is automatically granted to individual software authors, even if the author doesn’t explicitly claim it. As previously stated, a license is an agreement between the author and the user that permits the user to read, modify, and use the component as long as they follow some rules. 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 shake-down users.

Open-source projects are typically intended to foster contributions from developers everywhere. Even though the original author holds copyright, each new contributor to the project becomes an author who also holds copyright. In this situation, an open-source license ensures that contributors to open-source software can continue to reap the benefits of its use, even if multiple authors hold copyright.

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. Also mentioned above, 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 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.

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 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. Lifecycle can identify possible issues as soon as components enter an application, and Firewall can block components 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 a 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 with your legal team.

However, open-source licenses are meant to be easy to understand and to follow. Licenses usually have their own websites. Visit them to learn more.

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 Guide 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.