This article is part of a series of articles about Open Source License Compliance

Disclaimer: A rapidly evolving landscape

While the implications of AI-generated code are global, this discussion centers on the United States, the epicenter of AI development and subsequent legal battles. It’s crucial to remember that legal frameworks in other countries may vary significantly.

We’re not legal experts and this content doesn’t constitute legal advice. Moreover, the AI landscape is in constant flux.Laws, regulations, and court decisions are evolving rapidly, making it challenging to provide definitive answers.

With those caveats in mind, let’s tackle the burning questions developers have about using AI-generated code.

Can I be sued?

Developers who use AI-generated code that is often trained on open source software, face a complex legal landscape. Concerns about copyright infringement and license compliance loom large. While the worst-case scenario involves a restrictive GPL license, even a simple attribution requirement can be challenging. Tracking AI-generated code and identifying its open source origins remains a daunting task without reliable tools. However, a recent announcement from Microsoft offers some relief to GitHub Copilot users, promising legal support for those using the tool responsibly.

According to Microsoft:

“As customers ask whether they can use Microsoft’s Copilot services and the output they generate without worrying about copyright claims, we are providing a straightforward answer: yes, you can, and if you are challenged on copyright grounds, we will assume responsibility for the potential legal risks involved.“

That doesn’t mean the law is guaranteed to settle on Microsoft’s side, but it does signal loudly that they’re confident they have a strong legal case. A lawsuit alleging Microsoft, GitHub, and OpenAI infringed on open source licenses and copyrights when training their models is working its way through the U.S. legal system and likely will be for some time. Microsoft argues that anyone has a right to look over public code on GitHub to understand and learn from it and even write similar — but not outright copied -– code, and that includes their models. OpenAI hasn’t promised to pay legal fees for its users, but if Microsoft’s argument holds up, it will be good news for OpenAI and its users too.

Can I sue?

The legal landscape surrounding AI-generated code is murky. Currently, AI-created content isn’t eligible for copyright in the U.S. While companies like OpenAI claim to transfer ownership to users, the reality is complex.

For software incorporating AI-generated code, copyright protection hinges on human involvement. Substantial human authorship is crucial. However, determining the exact threshold is unclear. The U.S. Copyright Office requires disclosure of AI-generated content, but specific guidelines for software are still evolving.

To mitigate risks, carefully document AI-generated code within your project. This could be crucial for future copyright applications or potential legal disputes. Ultimately, deciding whether to use AI-generated code involves weighing the potential benefits against the legal uncertainties.

There are a lot of open source licenses, over 200 in fact. Luckily, nearly all available open source software falls under just a handful of licenses. Here’s a quick and dirty breakdown of each license to help you make broad decisions for your code. Be sure to follow the links in each section for more in-depth analysis of each license.

Types of software license: copyleft and permissive

Let’s first take a look at the general landscape of open source licenses. There are two main categories of licenses: copyleft and permissive. This division is based on the requirements and restrictions the license places on users.

When an author releases a program under a copyleft license, they make a claim on the copyright of the work and issue a statement that other people have the right to use, modify, and share the work as long as the reciprocity of the obligation is maintained. In short, if they are using a component with this kind of open source license, then they too must make their code open for use by others as well. Whether this applies to all of their code or just the modifications they’ve made to the licensed code depends on the license. A permissive open source license is a non-copyleft open source license that guarantees the freedom to use, modify, and redistribute, while also permitting proprietary derivative works. Permissive licenses place minimal restrictions on how others can use open source components. This type of license allows varying degrees of freedom to use, modify, and redistribute open source code, permitting its use in proprietary derivative works, and requiring nearly nothing in return with regard to obligations moving forward.

Top open source licenses explained

There are no good or bad licenses, and no one license is better than another. Anyone can create an open-source license that suits them, which is the reason that there are so many out there. This can make choosing an open source license a complicated business. To help narrow down the decision and make sense of it all, the Open Source Initiative (OSI) put together a list of approved licenses, consisting of a little over 80 open source licenses that are most commonly used.

GNU General Public License (GPL)

The most ubiquitous copyleft license and one that does sometimes strike fear into the hearts of legal teams, the GPL is a specific implementation of the “copyleft” concept created by Richard Stallman in order to prevent GNU software from becoming proprietary.

Because the GPL is a strong copyleft license, any software that is written based on any GPL component must be itself released as open source under the same license or a later version. Projects that use these components, no matter the percentage of total code, are legally required to release the complete source code plus all of the rights to modify and distribute that code. This includes other components your project might use, such as linked libraries, which means you cannot usually mix GPL’ed code with other copyleft licensed code.

The trigger for this reciprocity obligation is distribution. If you use or modify GPL’ed code but do not distribute it to the public, there is no legal requirement to make that source code available to the public. This creates something of a loophole when using GPL’ed code to create Software as a Service (SaaS) applications that are never actually distributed to the user. In all versions of the GPL up to v3.0, allowing users to interact with your software over a network is not considered distribution, though SaaS providers should still be cautious about using GPL’ed components. The Affero GNU General Public License (AGPL) closes that loophole and explicitly considers users interacting with software over a network to be distribution.

More permissive versions of the GPL exist, including the Lesser GNU Public License (LGPL) and the GPL with an added classpath exception clause. Implemented properly, you can use unmodified versions of software (usually libraries) falling under these weak copyleft licenses without an obligation to release the rest of your code under a GPL.

The Apache License

The Apache 2.0 License is a popular and widely deployed open source software license released by the Apache Software Foundation (ASF).

One of the most permissive open source software licenses, the Apache license allows you to release your modified version of an Apache-licensed product under any license you may choose. You are permitted to freely use, modify, distribute, and sell software under an Apache License whether your use case is personal, internal, or commercial.

Unlike other permissive licenses that are applicable only to copyrights and not patents, the Apache License explicitly grants rights to users that can be applied to both copyrights and patents. The rights given are perpetual, worldwide, and irrevocable, but also non-exclusive, meaning you can use the licensed work and so can anyone else.

To redistribute software with any Apache licensed components, you must include a copy of the license, provide a clear Apache License attribution, and add modification notices to any files you modify.

You can choose to release the modified or derived products under different licenses, but the unmodified parts of the software must retain the Apache License. Another rule is that you cannot name your modified version in any way that suggests that the final product is either endorsed or created by the ASF.

Lastly, if you want to add a copyright statement about all of the modifications you’ve done to any Apache-licensed software, you are free to do so. The Apache License doesn’t require you to release modified code under the same license so you can choose to add specific license terms and conditions that govern how others use, reproduce, or distribute your modified code.

Microsoft Public Licenses (Ms-PL)

The Microsoft Public License is a free and open source software license released by Microsoft for its own open source projects.

The Ms-PL is a short, concise, and straightforwardly written license that allows you to freely reproduce and distribute original or derivative works of any software that it governs. In doing so, however, you may not use any contributors’ names, logos, or trademarks. The Ms-PL also protects software authors by explicitly offering no express warranties or guarantees, meaning authors are not liable if their code doesn’t work well in some cases.

When distributing software under the Ms-PL, modified or unmodified, in whole or in part, you are not obligated to distribute the source code. You are, however, required to retain all copyright, patent, trademark, and attribution notices that were originally present. If you do choose to distribute any portion of the software, modified or unmodified, in its source code form, you must do so only under the Ms-PL by including a complete copy of the license in the distribution. If you instead choose to release the code in a compiled or object code form, you may release it under any compatible license.

 Berkeley Software Distribution (BSD)

BSD Licenses are a family of permissive licenses. A BSD License allows you to freely modify and distribute your software’s code in the source or binary format so long as you retain a copy of the copyright notice, list of conditions, and the disclaimer.

The original 4-clause BSD License contains an advertising clause requiring certain acknowledgement of previous authors in any advertising for software that makes use of BSD licensed code. The most commonly used BSD license, the 3-clause Modified BSD License, removes the advertising clause and the 2-clause FreeBSD License removes both the advertising and non-endorsement clauses.

Common Development and Distribution License (CDDL)

The CDDL is an open source license published by Sun Microsystems (now Oracle) to replace the Sun Public License (SPL) and is considered to be SPL version 2. It is inspired by the Mozilla Public License (MPL). The CDDL is often considered a cleaned-up version of the MPL and was made to facilitate reusability.

You are free to reproduce and distribute any original or derivative works of any software licensed under the CDDL but you must not remove or make any changes to any copyright, patent, or trademark notices present in the software. You must also retain any notices of licensing or any descriptive text that gives attribution to any contributor or the initial author.

When you distribute your software in any form other than source code, you are required to make the source code of any file containing CDDL’ed code, whether modified or in its original form, available under the CDDL and to include a copy of the license in the distribution. The executable form and any project files not containing CDDL’ed code may be released under the CDDL or any compatible licenses.

Additionally, for each modification that you make you must identify yourself as a modifier by including a notice in your modified files.

The CDDL is considered a weak copyleft license as its use does not grant downstream users of the program the same rights you received by requiring your entire code become open source, like with strong copyleft licenses such as the GPL. Only files including CDDL’ed code or modifications to CDDL’ed code are under any copyleft obligations. Other files and the executable of the whole program can be under any license that is compatible with the CDDL.

Eclipse Public License (EPL)

The Eclipse license is a weak copyleft license. If you modify code under the EPL and distribute the source code as part of your program, you’re required to license the modified code under the EPL. If you distribute such a program in its object code form, you’re required to state that the EPL’ed source code is available to the recipient upon request and to share the method for making that request.

The Eclipse Foundation makes it clear that “merely interfacing or interoperating” with an Eclipse plugin does not make your code a derivative work of the plugin. As with all weak copyleft licenses, if you wish to use a different license for the rest of your code, keeping the EPL’ed code in a separate file is the best practice, if not a requirement. The EPL version 1.0 is less clear about this but version 2.0 is explicitly a per-file copyleft license.

The EPL protects the author from possible lawsuits or damages caused if a company used their component in a commercial product. Any warranties made by a commercial contributor to EPL’ed code is theirs alone and not that of previous contributors. Like many other open source licenses, the EPL also includes an explicit patent grant.

 MIT License

The MIT License is one of the most permissive and popular licenses out there. There are actually two variants of the same license that are frequently called “The MIT License”:  the Expat License and the X11 License. Being the shorter and first variation, as well as the one the Software Package Data Exchange (SPDX) identifies as “MIT”, we will refer to the Expat License as the MIT License.

The MIT License includes language expressing that the software is presented as-is and without warranty. As a permissive license, there is no requirement that modifications to MIT Licensed code be also released under the MIT License making it a great choice for proprietary and commercial uses. The license’s only requirement of a user is that the license be included in “all copies or substantial portions of the Software”. At less than 200 words, that’s just a few lines of comments in the code. There’s a reason the MIT License accounts for nearly a third of all uses of open source licenses.

Know your open source licenses, or explain it to the judge

Nearly all software developers rely heavily on open source components, so it’s crucial to understand the basics of open source licensing, and the main differences between the popular open source licenses out there. This is why open source license management tools are a critical element for safeguarding your code, software, and applications, as well as reducing financial and legal risk for your organization. They reinforce the integrity of the components and dependencies you use, and ensure that your use of these components will neither compromise your organization nor the product that you create.

Another thing cybercriminals get is automation. Attacks are up and their rise is expected to continue, in no small part due to the fact that attackers are using automation to scale their criminal enterprises. With automated tools they can locate more victims faster, launch more attacks at once, and reach further along the supply chain than ever before. 

Well that’s just great. What’s to be done about it? The obvious answer is that software vendors must use defensive automation of their own.

The automation revolution in cyberattacks

Automation plays a significant role in the modern business of cyberattacks. Malicious actors use automation to their advantage to lower their costs, streamline their organizations, lend speed and scale to their attacks, and increase their chances of success. 

Here are just a few ways adversaries are using automation:

• Malware and botnets – The creation and management of botnets, networks of compromised computers which can be remotely controlled to perform various malicious activities including the distribution of malware, is largely done through automation.

• Phishing campaigns – Automated phishing kits are readily available for purchase on the dark web. These kits allow adversaries to easily create convincing phishing websites complete with fake login forms which can then be distributed, automatically of course, to a large number of potential victims.

• Credential stuffing attacks – Attackers use automated tools to test large lists of stolen or leaked username-password combinations against various websites and online services to gain unauthorized access. Let this be yet another reminder to not use the same passwords across multiple websites, systems, and services.

• Exploiting vulnerabilities – If you’re not scanning your code and infrastructure for security weaknesses, well you’ll never guess who is. Attackers employ vulnerability scanning tools to automatically identify security weaknesses in target systems, particularly outdated software and misconfigurations.

The race for automation in application security

Even with a generous budget for a large, well trained security team, manual testing cannot reach the scale, completeness, speed, or consistency of coverage that modern automated security tools can. Although manual testing certainly has its merits, it has many limitations that could have severe consequences for your organization.

And let’s face it, most security teams are overworked and understaffed. Here’s a formula that should help: automation plus a shift-left approach to application security equals shift smart. With the right tools, you can put some of the work of securing your code onto your developers and earlier into your software development lifecycle (SDLC) without slowing down releases.

Here are some automated application security testing tools you should be considering.

• Dependency updating tools – Chances are your software relies on a lot of open source components that are constantly releasing updates, many having to do with security. A good dependency health tool like Renovate enables automatic dependency updating by creating pull requests for your team to review and accept or reject. Free as both a GitHub app or self-hosted, Renovate also includes a Merge Confidence score to make decision making even faster and easier.

• Software composition analysis (SCA) – About those open source components… just because you have the latest version, doesn’t mean there aren’t still security concerns. SCA tools scan your open source code, including containers and other artifacts, and give you feedback on vulnerabilities. Advanced SCA tools (like Mend SCA) also give developers automatic alerts about vulnerable open source packages before a pull request is made and the component enters the system.

• Static application security testing (SAST) – For your bespoke code, SAST tools are used in both the coding and testing stages of the SDLC to analyze your code for coding errors and policy or regulation noncompliance that may indicate security concerns. We like Mend SAST, but we would – not just because we made it, but because it features automated remediation which writes the code to fix the security flaw for you.

Security everywhere all the time

Of course it’s not only automation that keeps attackers at bay. You also need to develop a good security culture in your organization that includes training and awareness programs, encourage responsible coding practices, and shift security left (and everywhere) so that it’s part of the fiber of your day to day activities.

But embracing automation in the SDLC with automated code review and continuous security testing must be on your menu if you want to have a robust and mature security program at your organization.

The bad guys are using automation to wreak havoc across the web. It’s time for the good guys to catch up and use automation to stop them.

But even if no one was asking you for an SBOM, knowing exactly which components are in your software is a major benefit to the security of your organization. When the next zero-day vulnerability hits, you won’t be scratching your head wondering where an affected package sits in your codebase, what applications it affects, or whether you even have that package in the first place. Sure, there’s more to staying secure and understanding your code than just generating an SBOM, and an SBOM is not the same as an inventory, but it’s a step in the direction of having clear visibility into your product.

Your customers deserve that clarity, too. Handing over an SBOM, especially in these still-early days of adoption, sends a strong signal that your organization is transparent, responsible, and secure, and it reassures customers and regulators that you are actively managing risks. Here is some advice on how to deliver that message.

Be secure

This one is basic but it has to be said. Simply handing over any SBOM isn’t going to communicate that your company has a serious and mature security program if you have major outstanding security debt. In fact, it will give your customers visibility right into your vulnerabilities, and if things are really bad they may, and rightly so, decide not to buy from you after all. So you need to actually be secure to show that you’re secure. There’s no way around it. Transparency is the whole point.

If you’re a little behind the curve here, the fastest way forward is to implement a software composition analysis (SCA) tool that will make a detailed map of all of your open-source components, give you a scored and prioritized list of your vulnerabilities so you can remediate quickly in a worst-first fashion, and automatically generate an SBOM for you. Again, there’s more to security than any one tool or process, but when it comes to managing vulnerabilities and SBOM generation, SCAs give you a lot of bang for your buck.

Be early

Take the carrot before you get hit with the stick. Get your company’s SBOM program going now, even if it’s not yet required, to show your organization is dedicated to security and compliance and get the kudos you deserve for strong leadership. You’ll spend a lot more money getting that infrastructure in place at the last minute, and you may lose money if customers go to a competitor who is already prepared to demonstrate their transparency.

Do it now, even if you’re not required to, because eventually you will be. And if SBOMs are already required for your industry, maybe you can’t be early but you can at least be on time. And you can go above and beyond by following our next piece of advice.

Don’t send an SBOM alone

By itself, an SBOM is unlikely to give a complete picture of your strengths or the true state of your vulnerabilities. When your customer scans your SBOM for vulnerabilities and licensing issues, they will probably get results that look bad on the surface but aren’t of any actual concern. They don’t know your software like you do, so it’s important that you include other materials that fill in the knowledge gaps. 

One such supplement is a list of your open source licenses, particularly dual licenses that you have purchased the commercial license for. Your customers won’t know that you have commercial rights to use open source licensed components unless you tell them.

Vulnerable doesn’t necessarily mean exploitable. Another document to include is what the NTIA calls a “companion artifact” to the SBOM, the Vulnerability Exploitability eXchange (VEX) file. Created exactly for this purpose, VEX allows you to provide context for the vulnerabilities in your software and communicate that you are aware of them and have investigated whether or not they are actually exploitable.

To sum it all up…

In this age of increasing digital complexity and heightened security concerns, the adoption of SBOMs is not just a trend but a necessity. True, governments and corporations have begun to demand SBOMs, but the advantages they offer extend beyond compliance requirements; they fundamentally enhance the security, transparency, and trustworthiness of your organization.

Moreover, embracing SBOMs sends a powerful message to your customers and signifies that your organization is committed to transparency, responsibility, and security. Being early in adopting SBOMs earns you recognition for strong leadership. Delaying may cost your organization more in the long run, both financially and reputationally.

But again, merely generating an SBOM is not enough; you have to back it up with genuine security. Transparency is meaningful only when it reveals a robust and mature security program. Address your security debt and take proactive measures to secure your software and the SBOM you send will sing your praises.

To navigate this complex landscape, organizations must establish a robust framework. This includes crafting a clear open source policy, conducting a thorough inventory of components, developing a plan for non-compliant code, and creating comprehensive attribution documentation. While daunting, this foundation is essential for long-term success.

Let’s dive deeper into each of these steps and explore tools that can streamline the process.

This article is part of a series of articles about Open Source License Compliance

Open source compliance policy

Navigating the complex world of open source licenses can seem overwhelming. Fortunately, the majority of open source projects are covered by just a handful of licenses.

Your open source compliance policy is your roadmap. It outlines which licenses are acceptable, requires an approval process for others, and establishes how to handle new components. Involve your legal and engineering teams, and consider including security for added protection.

Focus on creating clear allow and deny lists of licenses. While there are over 200 open source licenses, the Open Source Initiative has approved just over 70. Remember, not all copyleft licenses are problematic, and even permissive licenses can have hidden restrictions.

To deepen your understanding of open source licensing, consider taking The Linux Foundation’s free online course.

By following these guidelines, you can establish a solid foundation for open source compliance within your organization.

To gain more understanding on different open source licenses and requirements for adding copyrights and notices, we highly recommend you check out The Linux Foundation’s free online course: Open Source Licensing Basics for Software Developers.

Building Your Open Source Inventory

Once you have a solid open source compliance policy in place, the next step is to identify the open source components within your software. Manual tracking might be feasible for small teams, but for larger organizations, automated solutions are often more efficient.

Your goal is a comprehensive inventory of all components and their associated licenses, including dependencies. These reports are crucial for maintaining compliance.

By creating a detailed inventory, you’ll gain valuable insights into your software’s open source footprint and potential risks.

Addressing Non-Compliant Components

After generating your open source inventory, identify components that violate your policy or lack a license altogether.These require immediate attention.

Develop a comprehensive plan to replace non-compliant components. Prioritize based on risk and impact.

While the complexity of this task varies, it’s essential for maintaining compliance and protecting your organization.

By proactively addressing these issues, you can mitigate legal risks and ensure your software’s long-term viability.

Attribution document

You’re almost there but don’t put your feet up just yet. Once you have taken inventory of all open source components and licenses in your software and processed everything based on your open source license compliance policy, you are likely to need to prepare an attribution document. Most open source licenses contain some kind of an attribution clause. Compliance with these clauses generally takes the form of an attribution document which includes a list of copyrights, notices, and licenses.

Now that you have a policy, an inventory, an attribution document, and your current codebase is compliant with all open source licenses involved, you need an approach for applying your policy to new components added to your software and how to manage your approval process. Below we’ve created a list of open source compliance tools that can help you and your team based on your preferred tracking method.

List of open source compliance tools to help you manage your licenses

#1 The Basic – Spreadsheets & Emails

The most basic approach is to manually track your open source software components with spreadsheets or ticketing software. The attractiveness of this is that it takes practically no work to set up and requires no overhead or customizing of additional tools.

If you decide to use this method you will need to be diligent and have policies in place for how license information about new open source code will be added to your inventory list as your project grows and who is responsible for making sure that information is added.

If you are using a very small number of open source libraries then it’s probably sufficient for tracking your usage, but it won’t scale easily as your software and the open source code within it grows. Although still a popular approach, due to increased awareness of scaleable, affordable automated solutions, like Mend.io’s, many companies are moving away from this method.

#2 FOSSology

A step above a spreadsheet, several open source tools exist to help to automate a part of the process of manually tracking and the best known and most advanced is FOSSology, a project started by Hewlett-Packard and now hosted by The Linux Foundation.

FOSSology scans the headers of files in your project and detects text from open source licenses. This offers significant automation over basic manual tracking and can find open source components that were not tracked by developers. The main drawback to using FOSSology is that it is likely to suffer from many false negatives – if a file doesn’t have a license referenced in the header file, that license or, just as importantly, lack of license, will not be detected.

#3 Code Scanners

The bulk of commercial open source management tools, including Black Duck Software, Palamida, OpenLogic, and Synopsis, fall into the category of periodical code scanners. These tools scan your entire codebase looking for snippets of open source code and determine what licenses they fall under. Given there are billions of open source components out there, the odds that two unrelated snippets of code may incidentally match are high, causing a large volume of false positives that you will need to sort through when using these types of tools. Another downside is that these code scanners are not agile. You will only know about your open source license vulnerabilities when you perform a scan of your entire codebase. Scans can take a significant amount of time and will need to be repeated as you add more open source code. Even those companies still using waterfall methods can find these scanners causing bottlenecks in their development pipeline.

#4 Continuous Integration Scanners

Continuous integration scanners offer an automated solution to both tracking and managing the open source components in your software. These tools provide accurate and detailed information and remove the need for developers to manually take account of each newly added component. This is the approach provided by Mend.io. Our tool additionally automates tracking and managing security vulnerabilities, software bugs, versions, and more, but for now, let’s stay within the scope of this blog and focus on licenses.

As the name suggests, this type of scanner fits right into your continuous integration or build tools (such as Jenkins, Maven, or Ant) and automatically detects all open source components in your build every time you run them – likely multiple times per day. It works by calculating a unique identifier for each library you use and then cross references with its database to detect the open source libraries. With this approach you get constant feedback about your open source libraries and their licenses, without the false positives, giving you the information you need to react in an immediate and agile way when there is conflict with your open source policy. You can even set an automated policy that will approve, reject, or send a request for approval based on your rules – even breaking the build if a blacklist license is used.

This technology automates the entire process – from automatically enforcing your policy, to managing the approval process, all the way up to automatically creating the attribution document. Once you’ve set up a continuous integration scanner with your policy, much of the rest of your job is done for you, increasing your accuracy and releasing your developers from time consuming bureaucracy.

So which approach is right for you?

Different organizations have different needs and there are tools out there for everyone. To determine what’s right for you, you will need to take a good look at the size of your project, your development methodology, the liabilities for missed compliance, and the cost of swapping out an open source component if its license doesn’t match your open source policy.

For very small projects manual tracking can be sufficient. More complex projects, particularly those built inside of an agile organization and released on a frequent schedule, benefit from continuous detection of open source components.

The growing use of open source code in enterprise software shows that the benefits of using open source code clearly outweighs the cost of compliance. With the continuing development of modern tools for open source license management, it’s easier than ever to integrate smart and streamlined development processes and stay compliant. tools for open source license management, it’s easier than ever to integrate smart and streamlined development processes and stay compliant.

Of course, we know differently. And the same can be said about copying and pasting code. When your developers and programmers are under increasing pressure to deliver and ship products, it might seem like a great idea to copy code directly from open sources and paste it into your projects. After all, it’s quick, easy, and convenient.

But don’t do it!

It won’t leverage the benefits of using open source code. It’s poor practice in the open source community. It could jeopardize the quality and security of your software and apps. And it could put your company and even your job at risk. Let’s find out why.  

Licensing considerations

Never forget that although open source code is freely available, it’s still governed by licensing guidelines that define how you can use it. Some licenses are more permissive than others, so it’s important to know what terms and conditions are attached to the components you use in your software, and ensure you comply with them.

For instance, if you use code or components with copyleft licenses, you have permission to use and modify the open source code, but you must make those modifications freely available. This means that you make your entire code base open source too.

Failure to comply with these conditions is a violation of the license, and breaches of any kind can have serious consequences. They could jeopardize your intellectual property. You could be asked to stop using certain components altogether, which will impact your productivity, and even the appeal and value of your output. In worst-case scenarios, it can mean copyright infringement that could make your company liable for punitive fines.

Is it worth sacrificing your company’s intellectual property, productivity, and reputation for the sake of a programming shortcut? The short answer is “No.”

Neglecting the benefits of the open source community

Developers that use open source components benefit from collaborating with others to create new software and applications and to improve those that are already available. This is because one of the great advantages of open source projects is that more people are using, checking, modifying, and fixing the code than if it were proprietary code. The whole process lends itself to transparency, ongoing development, and incremental enhancement of the code and its capabilities, plus continual scrutiny of its security. Security vulnerabilities tend to be addressed more promptly compared to proprietary software.

However, if you decide to take shortcuts by copy-pasting code instead of properly integrating an open source library, you disconnect your software from the original open source code, and from the link to any future improvements and fixes to that code. So, when the original open source library gets updated, perhaps with new features, security vulnerability patches, or bug resolutions, you’ll be unaware of them, and you won’t know that your copied code requires updating. Eventually, if this isn’t addressed, you’ll inadvertently let your code get out of date and become vulnerable because attackers are always developing ways to compromise existing code if patches and updates aren’t applied. Ultimately you risk degrading your code to the point that it disables the very functionality and utility of the software or application that you used it for. Do you want to be responsible for that? Again, the answer’s “No.”

Risks to security

Copying and pasting code from unknown sources poses substantial security risks. Malicious actors can intentionally embed vulnerabilities or backdoors in code snippets, potentially compromising the entire system. Relying on untrusted code can leave your project susceptible to unauthorized access, data breaches, or other cybersecurity threats.

You can address these threats by prioritizing reputable sources for code snippets, such as official documentation, well-established libraries, or trusted developer communities. Scrutinize the code for any potential security risks and conduct a thorough security assessment. Regularly update and monitor dependencies to ensure you are not exposed to known vulnerabilities.

Compatibility and integration issues

Code snippets found online are typically written in isolation and may not seamlessly integrate with the existing codebase. Copying and pasting snippets without considering their compatibility can result in conflicts, errors, and even system crashes. Ignoring such compatibility issues hampers the stability and functionality of your project, leading to time-consuming debugging sessions.

When integrating external code, thoroughly review its dependencies and ensure they are compatible with your existing setup. Modifying the code to suit your project’s requirements and conducting thorough testing can minimize potential compatibility issues. Prioritize code that aligns with your project’s programming language, frameworks, and libraries.

Quality and maintainability considerations

Blindly incorporating code snippets from online sources may introduce low-quality, poorly optimized, or outdated code into your project. This can adversely impact performance, increase technical debt, and impede the code’s maintainability. Furthermore, code that lacks proper documentation and follows inconsistent coding practices can create confusion and hinder future development.

So, be cautious when selecting code snippets from external sources. Prioritize well-documented, well-tested, and actively maintained code repositories. Review the code for best practices, readability, and modularity. Whenever possible, contribute back to the open-source community by reporting issues or submitting improvements to enhance the code’s quality.

Respecting the rules of the open source community

It’s axiomatic that the collaborative nature of the open source community thrives on cooperation, transparency, and respect. And one of the crucial ways to promote this environment is to honor regulations that the community has in place.

Copying and pasting code directly contradicts the principles at the core of the open source community and marks you out as an untrustworthy partner. That’s not a reputation you want to have. Instead, do the right thing. Stay informed about updates regarding bug fixes and security vulnerabilities and comply with all licensing requirements.

So, when it comes to copy-pasting code, just don’t do it!

While copy-pasting code may offer temporary convenience, it’s a risky practice. However, if you’re conscientious about incorporating external code, and you take care to comply with license terms, then you can harness the benefits of open source while safeguarding the integrity, stability, and security of their projects. And you can confidently build robust and maintainable codebases.

1. What is the Apache License and what are its terms and conditions?

The Apache License is a permissive open source software license. This type of license gives you a broad range of permissions to use, modify, distribute, and sublicense the software, with minimal restrictions. You can integrate the source code into proprietary software and distribute it under a different license with your own specific terms and conditions that govern how others use, reproduce, or distribute their modified code. And you can use software with an Apache license for any purpose: personal, internal or external, and commercial. This flexibility makes it popular among developers.

The rights it gives you can be applied to both copyrights and patents, unlike other permissive licenses applicable only to copyrights. These rights are perpetual, worldwide, irrevocable, but also non-exclusive. That means anyone else can freely use the licensed work.

When you redistribute software with Apache-licensed components, you must include a copy of the license, provide a clear license attribution, and add modification notices to all the files that you modify. Nevertheless, you can release modified or derived products under different licenses if you choose. Any unmodified parts of the software must retain the Apache License.

You can choose to add a copyright statement about your modifications to any Apache-licensed software. It isn’t mandatory, but it’s considered good practice. What is required is the original copyright notice provided with the Apache-licensed software.

2. What are the differences between the versions of the Apache license?

The first version of the Apache license was released in 1995, but it’s rarely used now. Version 1.1 was released in 2000. It introduced some improvements and clarifications, including patent and trademark grants. 

Version 2.0 was released in 2004. It includes patent grants that allow you to use the software without patent infringement concerns. Also, you can modify, copy or update the source code of existing software and distribute any such changes, in source or binary form, providing they retain the copyright notice and disclaimers. You must include a copy of your Apache 2.0 license, a clear attribution, and a notice stating that changes have been made to the software.

3. Is the Apache license copyleft?

No. The Apache 2.0 License is permissive. It allows you to use, modify, and distribute the licensed software, including creating derivative works, without requiring those derivative works to be licensed under the same terms. You can release the modified parts of the code under any license you prefer.

There are some obligations. You must release all the unmodified parts of the software under the same license (the Apache License), and you must include copyright and attribution notices, disclaiming warranties, and provide a copy of the license with any distribution of the software.

4. What is the difference between the Apache License 2.0 and the GNU GPL?

The GNU GPL is a copyleft license. Software that uses any GPL-licensed component must release its full source code and all rights to modify and distribute the entire code. The Apache License 2.0 doesn’t impose any such terms. You’re not forced to release your modified version. And unlike the GNU GPL, you can also choose to release your modified or derivative version under a different license, although you’re required to retain the Apache License for the unmodified parts of the code.

5. Is the Apache License compatible with the GNU GPL?

Apache License 2.0 is compatible with GPLv3, so you can freely mix the code that’s released under these two licenses. Nevertheless, the resulting software must be released under GPLv3. It is incompatible with GPLv2. 

6. What is the difference between Apache License 2.0 and MIT?

MIT is a more permissive license than Apache 2.0. Basically, you can do whatever you want with MIT-licensed software, provided you add a copy of the original MIT license and copyright notice to it.

Apache is stricter because it requires you to list all the modifications you make to the original software. A copy of the license, with copyright and attribution notices, must be included in the source code and any modifications. A specific section on contributions outlines the conditions for accepting external contributions to the project. The MIT license requires a copyright notice, but it does not have explicit requirements for the license or attribution notices.

Apache covers patent rights. It requires contributors to grant a license to any patents they hold that are relevant to the software. The MIT license does not. Apache allows users to sublicense the software under the same license terms. The MIT license does not address sub-licensing.

Apache includes provisions related to trademarks, requiring explicit permission from the license holder to use any trademark associated with the software. The MIT license does not. Also, you can’t name your product in any way that hints at the product being endorsed by Apache. 

While both licenses allow software to be combined with projects under different licenses, Apache has more restrictions in terms of license compatibility compared to the MIT license.

The MIT license is gaining popularity with developers due to its short and clear license agreement that makes it simple and flexible to use. The Apache license agreement provides more protection for patents, contributions, and trademarks, but is far longer. 

7. What is the difference between Apache License 2.0 and BSD?

The BSD (Berkeley Software Distribution) license has minimal restrictions regarding the modification and distribution of software.  Apache has more stipulations regarding these considerations, patent grants, and software sublicensing. Apache explicitly defines all the terms and concepts that it uses, leaving little scope for ambiguity.

Apache includes a clause that provides users with a patent license from the contributors of the software. This grant is perpetual, meaning it continues even after the license termination. BSD does not include a specific patent grant clause, which means it does not provide explicit protection against potential patent claims.

Apache includes an explicit indemnification clause, which offers some protection to contributors and users against legal claims related to patent infringement or other issues. BSD does not typically have such a clause, so it does not provide the same level of legal protection.

The BSD license is compatible with other open-source licenses, but some copyleft licenses, such as the GPL, may impose additional restrictions when combined with BSD-licensed code. The Apache license is generally considered more compatible with other open-source licenses, even copyleft licenses, as long as the license requirements of both licenses are met.

Finally, Apache can be easily used by other projects without any rewording of the license.

8. How can you use Apache License 2.0 in commercial products?

When using Apache-licensed software in your commercial product, you must follow the terms and conditions of the Apache license, such as:

• You must not name your product in a way that looks like an endorsement from Apache. You must also not use any of the Apache marks (like the multi-colored feather) anywhere in your product or its documentation.
• You must retain the copyright notice and license information within the licensed software, and the in your product’s documentation, source code files, and any other relevant materials.
• When you distribute your commercial product, you should provide a notice with appropriate attribution to the original Apache-licensed software and a link to the original license.
• If you modify the Apache-licensed software, you must clearly indicate the changes made, include appropriate notices in your modified files, and make the changes available under the Apache 2.0 license. Also, you must explicitly state any patent claims related to the software.

9. Can you license your own software under the Apache license and can you sell Apache open source software/code?

Yes. You can release your own software under the Apache license, as long as you comply with the license’s terms and conditions. And you can sell any Apache-licensed software/code but you must comply with the terms of the Apache 2.0 license. This includes providing attribution and making the source code available to users, among other obligations outlined in the license. Additionally, any modifications you make to the open-source software must be released under the same Apache 2.0 license. Always review the terms and conditions of the license to ensure compliance with them. Take legal advice when licensing and selling open-source software.

10. What happens if I violate the Apache License?

You may face legal consequences from the Apache Software Foundation (ASF), which oversees the license, or the copyright holder. The specific action taken can vary depending on the circumstances and the severity of the violation. Some possible actions are as follows:

• Cease and desist: You may receive a cease and desist letter, demanding that you stop using or distributing the software in violation of the license.
• Injunction: If the violation is significant, an injunction will prohibit you from continuing the infringing activities.
• Damages: You may be liable to pay damages for any harm caused by the violation. This may include any profits gained from the unauthorized use of the software.
• License termination:  Your rights to use, modify, or distribute the Apache-licensed software may be terminated, and you would need to remove it from any systems where it is in use.

Ensure license compliance

The Apache license is popular because it is permissive. Nevertheless, you must ensure compliance with and proper use of Apache-licensed software. The best way to do this is to deploy a compliance tool, consult the full text of the license, and seek legal advice.  After all, better safe than sorry.

The GPL emphasizes the principles of software freedom and promotes the sharing of knowledge and collaboration. It is a copyleft license that requires any modified versions or derivative works to be licensed under the GPL.

Understanding the GPL is important to ensure that you’re using software in compliance with its license. To help you, here are some answers to the top 10 frequently asked questions about the GPL license.

1. What’s a copyleft license?

Copyleft is a type of open-source software license that allows users to freely use, modify, and distribute software. The main purpose of a copyleft license is to ensure that the software remains free and open for subsequent users. Copyleft licenses typically require the source code to be made available to others, allowing them to modify and distribute it further, as long as any modifications or derivative works are also licensed under the same terms, thereby preventing the addition of further restrictions.

These licenses provide a legal framework that encourages developers to share their modifications, ensuring that the software remains accessible and modifiable by others.

2. What are the terms and conditions of GPL licenses?

• Free distribution. The GPL grants the freedom to distribute copies of the software to others without any restrictions. This includes both commercial and non-commercial distribution.
• Source code availability. The source code of the software must be made available to anyone who receives a copy.
• Modifications and derivative works. Users can modify the software and create derivative works based on it, but these modifications must also be distributed.
• Copyleft provision. The freedoms granted by the license are preserved in all subsequent versions or distributions of the software. So, if you distribute a modified or derivative version of GPL-licensed software, you must also release it under the GPL.
• No discrimination. Any additional restrictions on the software’s recipients are prohibited.  The license cannot restrict use by specific fields of endeavor or groups or types of users.
• Compatibility. The GPL is compatible with other free software licenses, such as the GNU Lesser General Public License (LGPL). This allows developers to combine GPL-licensed code with code under other compatible licenses.
• Warranty and liability. The GPL is a copyright license and does not provide any warranty or liability protection. Users of GPL-licensed software assume all risks associated with it.

Importantly, if you use a GPL component in your software, then your entire software is considered a ‘work based on a GPL’ and you must ensure that its use and distribution comply with the above conditions. Of course, this is a simple summary of the GPL terms and conditions. So, if you plan to use or distribute software under the GPL, you should consult the full legal text of the license to ensure compliance.

3. Is GPL enforceable?

Yes. If someone violates the terms of the GPL by distributing software covered by the license without complying with its requirements, the copyright holder of the software can take legal action to enforce the license. This typically involves sending a cease and desist letter, requesting compliance with the terms, or seeking legal remedies through the court system.

Enforcement of the GPL has been successful, and violations have resulted in settlements, injunctions, and the like. Organizations such as the Free Software Foundation (FSF) defend the GPL and have taken legal action to protect software covered by the license.

The enforcement of the GPL may vary in different jurisdictions when copyright law differs. However, the GPL has been upheld in various legal systems around the world.

4. Can I sell GPL-licensed software?

Yes. However, the GPL requires that the source code be made available to anyone who receives a copy of the software. Customers who purchase GPL-licensed software have the right to access and modify the underlying source code.

When you sell GPL-licensed software, you are essentially selling a copy of the software along with the rights and freedoms granted by the GPL. The GPL allows you to charge a fee for distributing the software, but you must also provide the recipients with the corresponding source code and grant them the same rights and freedoms that you received under the GPL.

Remember that the GPL is a copyleft license, which means that any modifications or derivative works based on the GPL-licensed software must also be distributed under the GPL.

5. Is the GPL a secure license?

The GPL is generally considered a strong copyleft license that’s safe to use. If you plan to combine GPL-licensed software with proprietary code, be aware that the entire project might need to be released under the GPL, which may not align with your business objectives. Always seek legal advice to ensure compliance with the license requirements.

6. What is the difference between GPLv2 and GPLv3?

There are currently two versions of the GPL license in operation: GPLv2 and GPLv3. The main differences between them are:

• Scope. GPLv2 focuses primarily on software licensing and distribution, whereas GPLv3 includes provisions for digital rights management (DRM) and hardware restrictions.
• Compatibility. The FSF tried to increase the compatibility of the GPLv3 with other licenses. To combine two codes into a larger work, both programs must permit it. If such rights are granted by both the programs’ licenses, they are compatible. By making the GPLv3 more compatible, the FSF expanded development options.
• Patent provisions. GPLv3 includes explicit patent provisions to address patent-related issues. It requires any distributor of GPLv3-licensed software to license their patents that are essential to the software under terms that allow everyone to use the software freely. This provision aims to prevent patent holders from imposing restrictions on users of GPLv3-licensed software.
• Additional permissions. GPLv3 allows copyright holders to include additional permissions in the form of extra terms or conditions. These permissions can grant users additional freedoms beyond what the GPL itself provides.
• Internationalization. GPLv3 was written in an attempt to increase usage worldwide. GPLv3 includes improved internationalization and localization, making it easier to translate the license into different languages and ensuring that international laws will interpret it as the FSF intended, unlike the language used in GPLv2, which is considered very US-centric. GPLv3 also allows developers to add local disclaimers, which also helps increase its usage outside the U.S.

Importantly, although GPLv2 and GPLv3 differ in certain ways, they both share the core principles of free software and the four essential freedoms: the freedom to use, study, modify, and distribute software. So, the choice between GPLv2 and GPLv3 typically depends on the specific requirements and preferences of the project and its contributors.

7. Do I have to release my source code if I use a GPL library in my project?

Yes. If you use a GPL library in a project that’s released, the GPL requires that you release the source code of your entire project. This is because the GPL considers the combination of the library and your code as a derived work, subject to the copyleft requirements of the license. If you’ve modified a program’s source code for personal or internal use, there’s no need to release its source code. However, if you make the modified program available to the public, you must also make the code public.

8. Can you mix the GPL license with other licenses, or modify and distribute GPL-licensed software under a different license?

It’s possible to do this with GPLv2 and GPLv3, although there are some restrictions. Nevertheless, the FSF has stated explicitly that GPLv3 is compatible with the Apache 2.0 license. However, there’s an issue with the original BSD license as it imposes a specific requirement that is not in the GPL (the requirement on advertisements of the program).

The GPL license states that any modifications or derivative works must be licensed. So, if you modify GPL-licensed software, you must distribute your modifications under the GPL as well.

9. Can I use GPL-licensed software in a commercial product and a web application and can I link my proprietary software with a GPL library?

Yes, if you make the source code of the GPL-licensed software available to your customers and you don’t restrict the distribution or modification rights of the GPL-licensed components. And you can link your proprietary software with a GPL library.

Remember that if you modify the GPL-licensed software or combine it with your code in a web application, you must also make the modified source code available to users of your web application upon request.

Make sure you either include a copy of the GPL license with any software you develop and distribute or make it available by providing instructions on how to obtain it. If you link your proprietary software with a GPL library and then distribute it, it’s vital that the entire application is licensed under the GPL, and you must provide the corresponding source code.

10. What are LGPL and AGPL and how are they different?

LGPL stands for the Lesser General Public License, and it’s more permissive than standard GPL. AGPL stands for the Affero General Public License, a variation of the GPL that caters to programs that run on a server. Their main differences lie in their scope and requirements. 

• Scope: LGPL is primarily designed for software libraries. It is used to license free software so that developers can use it in both open source and proprietary applications. You are only obliged to subject modifications to the original free library to the LGPL. You must also permit or prevent reverse engineering of the work that uses the library to enable debugging when the LGPL library is modified or replaced with later versions. 

The LGPL is compatible with the GPL. You can decide to “upgrade” to GPL and incorporate it in a wholly GPL-licensed project if you wish, but you can’t go the other way and re-license GPL-licensed code as LGPL.

AGPL extends the provisions of the GPL to cover software used over a network and programs running on a server. Under the AGPL, if a developer modifies a program, they must release the modified version of the program to everyone who uses the service.

• Requirements. LGPL has weaker copyleft requirements compared to GPL or AGPL. If you modify an LGPL-licensed library, you must make the modified source code available but the application using the library can be distributed under different terms.

AGPL has stronger copyleft requirements compared to LGPL. If you modify AGPL-licensed software, you must make the modified source code available to all users interacting with the software over a network, regardless of whether it is distributed or not.

• Distribution. When you use an LGPL-licensed library in your application, you can dynamically link to it, allowing your application to be distributed under different terms. You do not have to share the source code of your application unless you modify the library itself.

If you use AGPL-licensed software over a network, even if you modify it, you must make the modified source code available to the users who interact with it, including the ability to download the source code from the networked application.

In summary, the LGPL is primarily used for software libraries and allows greater flexibility in combining the library with proprietary applications. The AGPL focuses on networked software and ensures that modifications made to the software are shared with users who interact with it over a network.

Licensing is critical

Understanding GPL licenses is crucial for developers and businesses working with open-source software. Nevertheless, always remember to consult legal professionals or experts for specific advice related to your situation.

It’s not just about security; it’s about survival.

In this article, you will learn how to navigate the complex world of open source licenses, understanding their implications for software development, especially during mergers and acquisitions, to protect your business from legal and security risks.

This article is part of a series of articles about Open Source License Compliance

Types of open source licenses

Given the nature of open source, it’s unsurprising that licensing rules are also open. Anyone can create an open source license that suits them — that’s why there are so many out there. In general, however, open source licenses can be divided into two main categories: copyleft and permissive. Permissive licenses, like Apache 2.0, are typically referred to as “anything goes” because they place minimal to no restrictions on how others can use these components. Given the lack of restrictions, there is relatively little compliance risk with this category.

Copyleft licenses, such as the GNU General Public License (GPL) family of licenses, are a different story. This category of licenses gives other people the right to use, modify, and share the work, as long as the reciprocity of the obligation is maintained. In layman’s terms, if you’re using a component with this kind of license, you have to make your source code available for use by others.

Risk of copyleft licenses

We’ll use GPL as our example, but these same principles apply to other copyleft licenses.

GPL requires the release of components’ full source code along with the broad rights to modify and distribute that source code. When you build software using GPL license components, you have to release your work under a GPL-compatible license regardless of the percentage of GPL license code being used.

Nobody wants to do that, because anyone, including competitors, can learn how your software is structured and designed. Then they can modify your program, perhaps building out new high-demand functionality that supersedes your product. That’s a big risk.

How do we reduce this risk?

The GPL requirement to share source code applies to all derivative work. However, it doesn’t extend to programs that are separate and independent from the GPL license work. Unfortunately, there’s no clear legal definition of when proprietary software is separate and independent. Nevertheless, you can reduce your exposure by: 

• Using a dynamic rather than a static link between the GPL module and the custom software.
• Using separate names for the GPL and proprietary modules.
• Including separate copyright notices for GPL and proprietary modules.
• If it’s practical, price the software with and without the GPL module.
• Provide the GPL and proprietary modules to be downloaded separately.
• Provide them as separate executables and have separate documentation.

Creating a company policy for the use of components

Every company needs a clear policy regarding how or if certain open source license components can be used. Using GPL as our example, at a minimum, a policy should cover the following: 

• Will you permit any GPL components in products that get distributed?
• Can they only be used in the backend tools and not part of the distributed product?
• If these components are allowed in deliverables, which GPL versions will you prohibit? 

Licensing should be treated just like security where you manage by exception because it’s easier to have “block” lists instead of “allow” lists. Imagine trying to approve hundreds of thousands of components with over 200 different license types instead of just blocking a few unacceptable license types.

How to ensure license compliance with GPL components

Achieving license compliance with GPL components is essential to avoid legal pitfalls. Two primary steps are crucial:creating a compliant notice file and making all source code accessible. A notice file, often referred to as a header file, must be updated with each new release to accurately reflect the open source license terms. This typically includes a copyright notice, disclaimers, and the specific license text. By diligently following these steps, developers can maintain GPL compliance and protect their software projects.

Technical due diligence: Top tips

Due diligence is crucial for accurately valuing a company and determining potential risks. It’s often conducted during major corporate events like M&A, and IPOs.

It involves assessing a company’s technology-related aspects like its products, software, systems, and practices. Our focus here is on third-party software use. You need to keep a record of any third-party and open-source components that you use. Here’s how to prepare and avoid any unpleasant surprises:

• Prohibit people from downloading any software, without first reviewing its licenses.
• Know the intended use of the software.
• Categorize software by its license type, along with its permitted and prohibited uses.
• Document which version you’re using, including a link to the license text.
• Be aware of any license restrictions.
• Document if you have access to the proprietary program.
• Ensure the source code version is available for download for any GPL components..

Be prepared. Use an SBOM

The main lesson is to get your open source license policies and controls ready if you think M&A activity is imminent. Start by inventorying what components you’re using and their associated licenses and risks. Use tools like a software bill of materials (SBOM) to achieve this. It’s something that numerous governments are mandating. 

Learn More: Best Practices for Open Source Governance

Streamlining the process with SCA

This is overwhelming to do manually, but there’s an easier way, using software composition analysis (SCA).

During the due diligence process, you should produce a list of all your third-party software dependencies and relevant metadata. This should include the package names, authors, supplier inversions, declared hidden licenses, dependency paths, and whether the packages have been statically or dynamically linked to the product.  With the right SCA tool, you can do all this automatically in real time when a developer pushes code.

You could commission an external audit on your code base, but typically firms that do this use an SCA tool anyway. If you choose an external audit, ensure it flags any known open source vulnerabilities with contextual data like the CVE score. Ensure it identifies any copyleft license components and includes a license compatibility report.

Finally, a good audit should include an attribution report, containing all the licenses, the license text, the copyrights, and the notice files required for each open source component.

Developers are tasked with creating engaging and reliable applications faster than ever. To achieve this, they rely heavily on open source code to quickly add functionality to their proprietary software. With open source code making up an estimated 60-80% of proprietary applications’ code bases, managing it has become critical to reducing an organization’s security risk. 

Software Composition Analysis tools help manage open source use.

What is software composition analysis?

Software Composition Analysis (SCA) is a segment of the application security testing (AST) tool market that deals with managing open source component use. SCA tools perform automated scans of an application’s code base, including related artifacts such as containers and registries, to identify all open source components, their license compliance data, and any security vulnerabilities. In addition to providing visibility into open source use, some SCA tools also help fix open source vulnerabilities through prioritization and automated remediation.

Inventory

Software Composition Analysis tools typically start with a scan to generate an inventory report of all the open source components, (dependencies) in your products, including all direct and transitive dependencies. Having a detailed inventory of all your open source components is the foundation of managing your open source use. After all, you cannot secure or ensure compliance of a component you don’t know you’re using.

License compliance

Once all open source components have been identified, SCA tools provide information on each component. This includes details about a component’s open source license, attribution requirements, and whether that license is compatible with your organization’s policies.

Security vulnerabilities

One of the main functions of Software Composition Analysis tools is to identify open source components with known vulnerabilities. Good software composition analysis solutions will not only tell you what open source libraries have known vulnerabilities, but they will also tell you whether your code calls the affected library and suggest a fix when applicable. The solution should also identify open source libraries in your code base that need to be updated or patched.

Types of vulnerabilities that can be found using SCA

Open source vulnerabilities typically occur when there are flaws or weaknesses in the code. These may be unplanned coding errors or inconsistencies that have been deliberately inserted into the code. Attackers can then exploit them to gain unauthorized access to systems, steal data, or cause damage to the software or system. Vulnerabilities can also result from old software or versions of current software that hasn’t been updated. These can cause security vulnerabilities that attackers can use to infiltrate your code and exfiltrate sensitive and valuable data, which can be disabled and ransomed, for example.

SCA can also help identify licensing risks to ensure license compliance with any third-party code being used.

Advanced software composition analysis (SCA) features

Advanced SCA solutions also include automatic policy enforcement, which cross-references every open source component found in your code with organizational policies and triggers different responses, such as initiating an automated approval workflow or failing the build.

Advanced SCA solutions automate the entire process of open source selection, approval, and tracking. Some are even able to alert developers about vulnerabilities in a component before a pull request is made and the component enters the system. This saves developers precious time and increases their accuracy.

Limitations of software composition analysis (SCA)

SCA focuses on identifying and remediating risks in open source components and third-party dependencies. It is not designed to find vulnerabilities in custom (original) code. For example, the SolarWinds supply chain breach wasn’t something that could have been alleviated by SCA, because SolarWinds’s source code is proprietary. To scan and remediate proprietary code, use SAST (static application security testing). SCA also doesn’t detect insecure network configurations.

Older SCA solutions weren’t designed to scan development and deployment environments, so they cannot secure the later parts of your software development lifecycle (SDLC). And some older SCA tools don’t provide the context needed to accurately assess the risk impact of any issues. Without this context, these tools can generate too many false positives, which consumes limited resources as security teams end up making unnecessary fixes. Note: Newer, more modern SCA solutions have addressed this challenge with prioritization capabilities, so make sure to choose a solution that can do this (see “Prioritization and remediation,” below).

The evolution of software composition analysis

The first open source manual scanner was released around 2002. Despite greater visibility into organizations’ code bases, this early technology resulted in a high rate of false positives, which required manual intervention and did not meet the needs of agile development environments.

By 2011, the technology had improved was capable of automatically detecting vulnerabilities and licensing issues in real time. This enabled software and security teams to deploy open source management earlier in the development cycle. At the same time, SCA solutions were also being integrated with software development tools like repositories, build tools, package managers, and CI servers, which put the power of open source management and security in developers’ hands. Despite these advancements, SCA still heavily focused on detection.

The impact of emerging technologies on SCA

More and more source code, components, and dependencies are being used to create new software and applications. It is widely estimated that as much as 90 percent of some organizations’ source code is now open source, which means that the potential attack surface has expanded considerably and continues to do so.  This increases the risk of open source vulnerabilities and the threat of malicious packages infiltrating and attacking software and applications.  So, the need for SCA increases in importance.

The future of SCA in software development

Developers, DevOps, and DevSecOps teams are now being tasked with scanning, identifying, and remediating vulnerabilities in open source far earlier in the SDLC. They are shifting security left to address and fix issues sooner rather than waiting until the software is ready for production or shipping. There is an even newer trend in the development process, known as “shifting smart”, which encourages teams to adopt nimble scanning and remediation processes that quickly and easily fix code wherever it is in the SDLC, and do so within existing developer workflows. Modern SCA solutions can do this, as well as prioritize vulnerabilities and identify those that can be safely ignored. This puts modern SCA at the heart of any robust application security strategy.

Detection is not enough

As open source use continues to proliferate, the number of known open source vulnerabilities has also increased. When you take into account the volume of alerts developers and security professionals deal with daily, it all starts to become noise.

Focusing solely on detection is only the first step. It does not help organizations reduce their risk. Detection without remedy is an incomplete application security model.

So how do you forge ahead? To address today’s threat landscape, you don’t need to strive for perfection, but you do need to keep moving forward. To do so, organizations must adopt a mature SCA security model that includes prioritization and remediation on top of detection so developers and security professionals can focus on what really matters.

Prioritization and remediation

Modern SCA solutions now bridge the gap between detection and remediation.

Prioritization. A mature software composition analysis tool should include technologies that prioritize open source vulnerabilities. By automatically identifying the security vulnerabilities that present the biggest risk, organizations can address these priorities first. Developers and security professionals don’t waste their time and resources sifting through pages of alerts trying to determine what vulnerabilities are the most important, possibly leaving highly exploitable vulnerabilities running in a production system.

Remediation. After prioritization comes remediation. Remediating vulnerabilities automatically goes beyond just showing developers where the vulnerability is located to suggesting a fix and providing data on how likely the fix will impact a build. Automated remediation workflows can be initiated based on security vulnerability policies triggered by vulnerability detection, vulnerability severity, CVSS score, or when an updated version is released. One of the most reliable risk mitigation strategies is to keep your open source components continuously patched to avoid being exposed to known vulnerabilities. A good SCA solution helps you achieve this.

Advanced SCA tools – including repo, browser, and IDE integrations – seamlessly integrate into the software development life cycle (SDLC) to resolve vulnerabilities early when they are easier and cheaper to fix.

Software composition analysis requirements

Comprehensive database

The database is the heart of any SCA solution. The more comprehensive the database, aggregating data from multiple sources, the better it is at identifying open source components and security vulnerabilities. Without a comprehensive, continuously updated database, you would be unable to detect the right versions of open source components to update licenses, remediate security vulnerabilities, and apply updates and patches. The open source community is highly decentralized. Because there is no one centralized source of information on updates or patches, you rely on the database for everything.

Broad language support

An SCA solution should support not only the languages you are currently using but any language you might be considering using within the next year or two. You wouldn’t want to implement an SCA solution only to find it doesn’t support the language of your newest project a year from now. Plan ahead and choose a solution with broad language support.

Extensive reporting

From inventory, licensing, attribution, and due diligence reports to vulnerabilities and high-severity bug reports, you need a solution that offers a wide range of reporting tools tailored to every use case, including management, legal, security, DevOps and DevSecOps.

Robust policies

Choose a solution with automated policies that are robust yet highly flexible and customizable so you can define your organization’s own unique needs. Policies that automate the process of open source selection, approval, tracking, and remediation save developers time and greatly increase their accuracy. 

Vulnerability prioritization and remediation

As discussed earlier, you need a solution that prioritizes security vulnerabilities and offers remediation advice. The more you automate, the easier it will be to resolve the most critical issues first without slowing down development. 

Dual governance and developer focus

SCA solutions fall into two broad categories.

Governance solutions, used by management, security, DevOps, and legal teams, provide full visibility and control across an organization’s software portfolio. 

Developer tools help developers avoid vulnerable open source components before a pull is made and fix any vulnerabilities detected in their code via tools integrated with native development environments.

The best SCA solutions offer both governance and developer tools. This guarantees that everyone gets the tools they need, when and where they need them.

Integration with DevOps pipeline

Choose an SCA solution that integrates seamlessly with a wide range of developer environments at every stage of the SDLC – repositories, build tools, package managers, and CI servers – so developers can decide whether they can or should use an open source component before a pull request is made.

Containers/Kubernetes

Container and Kubernetes use is widespread, yet security remains a challenge. Select an SCA solution that scans open source components from inside your containerized environments, identifying vulnerabilities or compliance issues and automatically enforcing policies. Also, make sure the solution has native support for your specific container registry.

Why SCA should be part of your application security portfolio

Open source components have become the main building block in software applications across all verticals. Yet despite the heavy reliance on open source, too many organizations are lax about ensuring that their open source components meet basic security standards and are compliant with licensing requirements.

Securing your application in today’s complex digital world is a challenge. With the right Software Composition Analysis solution, you are one step closer to mitigating your open source risk.

Overview of regulatory compliance requirements

Regulatory compliance is growing in importance as organizations working on M&A activity or with government bodies are frequently required to demonstrate that their software is secure and legally compliant with license conditions.

Governments are now taking a more active role in this arena by introducing new cybersecurity strategies that companies must follow.

Having issued an Executive Order on improving the nation’s cybersecurity, and having passed the Strengthening American Cybersecurity Act, the U.S. Government announced the release of its national cybersecurity strategy in 2023. Similarly, the European Union announced its Digital Operational Resilience Act (DORA) and its Cyber Resilience Act (CRA) to enforce software security and secure delivery of services.

The Australian government has stated its aim to make Australia the most cyber-secure nation in the world by 2030. And in concert with these developments, agencies from Australia, Canada, Germany, The Netherlands, New Zealand, the United Kingdom, and the United States have together created a guide for software development organizations to ensure their products are both secure by design and by default.

These recommendations and strategies require more accountability from vendors, increased visibility into their code bases, software, application components, and dependencies, and tougher regulatory compliance. 

How SCA can help with compliance

SCA is focused on scanning, detecting, and remediating vulnerabilities in open source, which can include identifying and fixing components and dependencies that do not meet license requirements. By finding such issues and versions that comply with license conditions, SCA can help ensure that your code base is up-to-date and fully compliant.

Case studies of SCA in compliance

Educational technology company Learning Pool sought a further round of VC investment and its preferred investor was particularly concerned about the company’s use of open source software. They wanted assurances that Learning Pool had policies written and a process in place to safeguard its codebase from legal challenges. Learning Pool uses Mend SCA to scan code and identify if any components aren’t compliant. Compliant code is automatically built and deployed. Mend SCA alerts Learning Pool to non-compliant code and blocks it. Everything is done speedily and automatically.

Workvision uses open source software to improve quality and speed in development and to reduce costs. It needs to ensure that this software is used in compliance with the relevant licenses. Before using Mend SCA, the company found it difficult to carry out regular audits of its open source use and often completed these audits in the final stages of development, which led to delay development. Mend SCA has accelerated the process of identifying and fixing any compliance issues, Prior to using Mend SCA, completing an open source audit took about a week to complete. Now it can take as little as 15 minutes.

The Fintech Open Source Foundation (FINOS) accelerates collaboration and innovation in financial services through the adoption of open source software, standards, and best practices. FINOS invested heavily in building its Open Developer Platform (ODP), but FINOS’s members needed to be confident their open source components had no known vulnerabilities and were compliant with license policies. Mend SCA manages the open source licenses and security vulnerabilities in FINOS’s open source projects. With Mend SCA, FINOS can create policies around license compliance, security vulnerabilities, and quality issues that are automatically enforced. This ensures that all committed code meets FINOS’s high standards of code quality, without impeding the speed of the development process.

These are just three of many examples of how SCA can improve and accelerate license compliance.

Benefits of software composition analysis

• Improved security. SCA’s specific purpose is to scan your open source software, components, and dependencies, identify vulnerabilities, and with a modern SCA tool, automatically remediate these vulnerabilities. When using these capabilities to their fullest, SCA will certainly improve your application security.

• Cost savings. Identifying and remediating open source vulnerabilities requires considerable resources when done manually, and missing vulnerabilities can adversely affect the speed of development and innovation. This is costly. SCA accelerates and automates the process, lightening the load for developers and DevOps teams and making security cheaper to implement and more thorough.

• Enhanced efficiency. Modern SCA tools are specifically built to accelerate and automate the detection and remediation process. So, they make the process easier and faster. Plus, their ability to prioritize vulnerabilities to be addressed means that false positive results are significantly reduced, and teams spend far less time fixing issues that aren’t relevant.

• Improved developer productivity. Speed, efficiency, and automation liberate developers from the time-consuming task of scanning and securing open source. They can now do it more efficiently than ever, and the process is seamless when it is done within their development workflow, thereby minimizing any interruption to their innovation pipeline. With SCA, developers can be sure that the security of their code base is robust while enabling them to maintain and increase their productivity.

FAQs