due diligence – Open Source License Compliance & Security

Verdict to GPL violation in Germany

There is a verdict from a German court to the violation of the GPL license!

A university in Germany was using Open Source Software to manage end user devices in their Wireless Network. The OS Software was/is licensed under the GPL license. The university was offering the students a binary download without referencing correctly to the GPL license and without offering the source code of the binary as download as well. The copyright owner of the OS Software sued the university because of violating the copyrights of the used OS Software.

The amount in dispute is 50K EUR.

The GPL 3.0 license text says:

“Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.”

That means you have 30 days to fix the problem if somebody notifies you about a violation. BUT the court decided that violating the copyright laws the very first time is reason enough for a punishment. Giving the university the chance to fix the situation in the first 30 days means they are allowed to use the Software in future, but it doesn’t prevent from punishment in the first place. Otherwise everybody would simply violate copyright laws with knowing they get anyway a 2nd chance for free without getting sued.

Most companies think Open Source Software is always for free. But that’s not true! OS Software comes with a wide range of licenses and companies have to deal with that. There is no modern Software development without Open Source! Software Developers are using Open Source Components every day in their daily business. There is no way around. And the risk of accidentally using a component which is licensed under GPL in a closed source project is not too small. Here are the numbers of Open Source Components which are licensed under GPL, separated by programming languages.

Do you have a license whitelist for your development process? How do you ensure that your developers are not accidentally pulling in a GPL component?

With VersionEye you can setup a license whitelist and VersionEye can check on each build your license whitelist against all your project dependencies. If there is a license violation we can even break the build and prevent you from shipping GPL code to production.

Write an email to support@versioneye.com if you are interested.

License Whitelist

How do you ensure the license policy of your company in your projects? You don’t? VersionEye is here to help you.

We just released a new feature, the “License Whitelists“. The idea behind this feature is that you put Licenses on a Whitelist and VersionEye notifies you as soon there is a software component in your project which violates your Whitelist.

Just navigate to one of your projects on VersionEye, to the License Tab. Above the License table you will notice a new list. Here you can assign a License Whitelist to your project.

By default there is no License Check and if you see this the first time you have anyway no License Whitelist. You can click the “Manage Whitelists” button to create a new License Whitelist for your account.

You can create as many License Whitelists as you want. By clicking on a License Whitelist you can add/remove Licenses to it.

The autocomplete function suggests you Licenses out of the over 300 SPDX Licenses. If you are done with creating your License Whitelist, navigate back to your project, to the License Tab and select the Whitelist which you would like to enforce in your project. After clicking the save button, the page will reload and you will see something like this.

Software components whose Licenses are on the selected License Whitelist are marked green. Components whose Licenses are not on the License Whitelist are marked red.

Now VersionEye sends you email notifications about License Whitelist violations in your project. By default once a week, but you can even change it to once a day.

This is specially useful if you work in a team. Software Developers don’t care so much about Licenses, they care much more about features. They can pull in new software components every day and without a tool you even don’t know if they use a component with a “bad” software license. With VersionEye you get notified about License violations and you can react very quickly. If you choose so, you get email notifications every day. The email would look like this.

If there is no violation of the License Whitelist, you don’t get the email. If you don’t hear anything from VersionEye then everything is good 😉

License Normalization

There are different ways to write a License name. Some developers are writing “Apache 2”, some write “The Apache 2.0” and somebody else might write “The Apache License 2.0”. VersionEye is doing a lot of normalization in the background and recognizes all these different written license names as “Apache License 2.0”. And VersionEye always shows you the normalized name in the Web Interface.

New Software License View

Free and Open Source Software wouldn’t be possible without Free and Open Source Licenses. These licenses give us developers and users permission to do with the software what the license states.
So these are very important because they essentially are a contract between the different parties with access to the software.

Software licenses are one of the most important meta informations we collect at VersionEye and some of our enterprise customers need to know these for due diligence. We already had a license view, but now this view is new and improved. 😉

Yo dawg, I heard you like software dependencies (and licenses)

Let me put it that way: Your project has dependencies. Those dependencies have licenses. Your project’s dependencies have dependencies, and these have licenses too. So instead of just showing the licenses for your dependencies, we actually are able to display all licenses of all transitive dependencies.

(– this is missing a yo dawg meme)

How to see all software licenses of your project for due diligence (DD)

Go into your project’s details view. Next to the Dependencies tab you see the Licenses tab.
This is how it looks like:

Below the table we display the direct dependencies also grouped by licenses. To see the licenses of all transitive dependencies you have to click the button below at the end of the page:

When you click the button, VersionEye will fetch all transitive dependencies and their licenses. This will give you a complete overview about ALL licenses which might effect your project. We know this is a lot of scrolling, but some of our customers might need to print on paper.

At the bottom of the page we display all dependencies with unknown licenses. These are dependencies we can’t provide license info for yet. For due diligence you have to double check the licenses manually.

So we hope this might be useful to you and please let us know what you think about this new feature. 🙂