Software Integrity Blog


5 software licenses you need to understand

There are different types of software licenses, with some requiring you to make your source code public.

Do you know what’s in your software? If you wrote the software yourself, the answer would be yes. But if you’re like most people, you probably only wrote a portion of it. Industry practices vary but studies do show that up to 90% of the source code may be third-party code.

So do you know what’s in the part you didn’t write?

Here the answer becomes murky.

What if you didn’t purchase the code library and simply downloaded it from an open source repository? While it is free, it may not be without legal peril. There are some forms of free open source software (FOSS) that allow you to use, modify, and distribute the code within your work without direct attribute That’s perhaps what you thought when you were downloading it.

Unfortunately, there are other licenses that do not give you that freedom. And in some cases, these more restrictive licenses might oblige you to make your proprietary project public and subject to the same licensing terms of the original FOSS.

Why use open source?

Let’s say you are starting a company and the business model requires you to develop an app. Rather than reinvent the wheel by writing your own SSL, you might consider using OpenSSL. The current licensing on OpenSSL is “Apache Style.” That means it is a permissive free software license. However, OpenSSL is also dual licensed, so read the download library files carefully.

It is OK to use open source code, but you need to analyze it. In addition to understanding the software license, you should also check to see whether the library files are current and whether there are any outstanding CVEs for the latest version. A good software composition analysis tool is necessary.

What are the different types of software licenses?

While there are many different licenses, here are five common software licenses models you should know about.

Public domain. This is the most permissive model. It means that anyone can modify and use the software without any restrictions. Again, just because it is free and with any legal strings attached, you should always check to make sure it is secure before adding it to your own codebase.

Permissive. A permissive software license contains minimal requirements about how the software can be modified or redistributed. Also known as “Apache style” or “BSD style,” this license is perhaps the most comment and popular with free open source software. Aside from Apache and BSD another common variant is the MIT license.

LGPL. The GNU Lesser General Public License (LGPL is published by the Free Software Foundation (FSF) and allows developers and companies to use and integrate free open source software into their own proprietary software. The catch here is that any end user of your software also has the right to modify the code. Therefore you must make your own source code available. Exposing your source code may not be in your best interests.

Copyleft. The use of copyleft allows the end user to freely modify and distribute new works based on your work with the requirement that any new works or adaptations of the original are bound by the same licensing agreement. For example, you might say the work is free to use and distribute for personal use only. Any derivative would also be limited to personal use only.

Proprietary. Of all the software license, this is the most restrictive model. The idea behind it is that all rights are reserved and is generally used for proprietary software where the work may not be modified or re-distributed.

What’s in your software?

Black Duck Binary Analysis from Synopsys uses a Global Intellectual Property Signatures (GIPS) database containing a billion files from hundreds of thousands of open source and public domain projects. This Synopsys-managed catalog is a reference for detecting open source software (source code or binary) and producing an accurate bill of materials for any software portfolio. Also supported is the latest generation of the Software Package Data Exchange (SPDX) standard.


More by this author