“Patching”: Best practices in identifying the correct license

Open Source is everywhere. Experienced developers do not write code from scratch, they know where to get code. Improving productivity, shortening time to market, and reducing development costs are all good reasons to use Open Source code. However, by using open source components, organizations ultimately take responsibility for the code they did not write.

One interesting aspect of Software Composition Analysis is how to handle patches. A patch is a set of changes to a computer program or its supporting data designed to update, fix, or improve it. This includes fixing security vulnerabilities and other bugs, with such patches usually being called bugfixes or bug fixes. Patches are often written to improve the functionality, usability, or performance of a program.

Patches often come bundled in one file and apply patches to several other files of an existing software component. Sometimes a patch may contain a license, sometimes not. Sometimes it is clearly applied to one file of a component with a well-defined license. Sometimes a patch file patches files from different components (or files) with different licenses. Sometimes a patch fixes a file with source code, sometimes a patch is applied to config or makefiles.

What does this mean for the license of the patch file itself? We need to differentiate several cases. First of all, in this blog, we consider files that contain source code only. Make and config files may only be applicable if they contain some kind of source code, or if they already have some variant of a license header in it.


If a license is declared within the patch file, the patch typically will be listed under the license mentioned.


If no license is mentioned in the patch file, a patch will typically inherit the license of the file which it is applied to. For an auditor, this implies that he has to read the code and understand which file is patched and to investigate the corresponding license. If you are unable to identify the license in the patched file, the README or COPYING file of the component may name it for you, or you can directly examine the LICENSE file to determine the license. SPDX can help you figure out the exact type of the license.


If no license is mentioned in the patch file, and the patch modifies several other files with different licenses, license analysis gets tricky. We will typically report all licenses for all the patched files being applicable for this patch file.

The latter case gets even more complicated when the licenses identified are incompatible to each other. A clean solution may be to ask the developer to split up the patch file into individual patches for each component with a different license, however, this may not always be possible.

Another use case that should not be overlooked is when patches are binary and hence either modify existing binary files or add new ones. The most risk is such a scenario comes from modified binary files which in the worst-case scenario may get an injection of business restrictive code (such as any Public License) without knowledge from the vendor.

To reduce the legal and security risk associated with patching of OSS libraries and using OSS libraries in general we commend contacting us for consultation.

This is not legal advice. The text is giving best practices based on our experience. If in doubt, consult a lawyer.

Comments are closed.