5 Tips to Avoid Open Source Licensing Infringement

For developers, incorporating software from open source projects into codebases is a great way to save time and avoid having to reinvent the wheel.

But it also comes with a major challenge: licensing infringement risks. When you reuse open source code, you need to comply with whichever of the numerous open source licenses govern that code. If you don't, you (or the business you work for) risk lawsuits for violating the open source licenses.

And although such lawsuits are relatively uncommon, they do happen — and they may happen more and more often given that many open source projects are now controlled by corporations eager to defend the investment they make in open source communities.

Related:Secure Open Source Software Is Helping Enterprises Find Their Edge

Keep reading for tips on steering clear of these legal issues if you borrow open source code for your projects.

1. Educate Yourself About Open Source Licensing

The single most important step toward avoiding open source licensing infringement issues is understanding open source licenses.

It's easy to assume that all open source licenses have the same requirements, or that they all boil down to requiring that source code remain open. In reality, there are many dozens of open source licenses in existence, and their terms vary widely. It's a big mistake to assume that just because you obtain code from an open source project, you can reuse it in any way you want provided that you keep the source open. You may also need to attribute the original authors, as an example of one common — but easily overlooked — requirement of some open source licenses.

So, before choosing to use open source, learn the basics of open source licensing, and understand the nuances and diversity between them.

2. Document When You Use Open Source

A second best practice for borrowing open source code is to establish a consistent process for documenting when you do so.

It's easy enough to import a module or copy and paste some code from GitHub. But if you don't record where that code came from, or which license governs it, you can easily lose track of where and how you are incorporating open source into your codebase. It also becomes harder to prove that you adhered to the licensing terms that applied at the time you borrowed the code, which could become an issue in the event that the applicable open source license changes.

To avoid this issue, consider including a page in your documentation wiki (if you have one) that records which open source code you borrowed. At a minimum, you should also comment inside your own source code when you introduce open source components or dependencies.

3. Avoid Unlicensed Open Source Components

Sometimes, you may happen upon an obscure GitHub repository or other source code hosting location that contains code you want to borrow but that doesn't specify licensing requirements at all.

You may be tempted to assume that the code's developers intend for it to be open source and that they will allow you to do whatever you want with it. But that's a risky assumption. It's possible that the developers will later impose certain licensing terms over the code and expect you to follow them, leading to licensing infringement allegations down the line. Unless you have a really good reason to use obscure code that comes with no specific licensing terms, stay away from it.

4. Make Your Own Code Open Source

One way to mitigate some open source licensing risks is to make your own codebase entirely open source. This means that you'll comply by default with any open source licensing terms that require derivative source code to be kept open.

Related: Who's Using Open Source Software and Why

Keep in mind, however, that simply open-sourcing your own code doesn't guarantee full licensing compliance. The licenses that apply to the code you borrowed could be different from the open source license you choose, so you'll still need to do some work to ensure that you follow each license's requirements. But at least you won't have to worry about terms related to the sharing of source code.

5. Automatically Identify Open Source Components

While manually tracking where and how you use open source within your codebase is a best practice, you can reduce the risk of oversights by using software that helps you to identify open source components and dependencies automatically.

There are two types of tools to consider here. One is Source Composition Analysis, or SCA, tools, which automatically scan source code and identify components that are borrowed from known third-party sources. The other is software supply chain management tools, which help identify and track (among other items) any open source dependencies within your application stack.

Conclusion

Open source is a great thing, but navigating the complexities of open source licenses can be harder than it looks at first glance. Make sure you have the right tools and processes in place to take advantage of open source responsibly, without running into licensing infringement issues.