License – Open Source License Compliance & Security

Component Whitelist

At VersionEye you can setup a license whitelist and assign it to your projects. Simply put open source licenses on the license whitelist you want to allow in your projects/company. VersionEye will check all your dependencies against the license whitelist and notify you if there is a license violation. This feature is used frequently at VersionEye.

Today I want to introduce the component whitelist. It is an extension to the license whitelist. Software packages who are on the component whitelist are marked “green” in the license tab, even if they violate the license whitelist. There are a couple of use cases for the component whitelist.

Assume you are using an open source package which is licensed under the MIT license. With the next release the maintainer is changing the license from MIT to GPL-3.0. That means the newest version of the software library would probably violate your license whitelist. But maybe you buy a commercial license for the library, so that you are allowed to use it in closed source software. In that case you could set that artefact on the component whitelist.

Here is an example. Assume you have a project with some dependencies which violate your license whitelist. Just like here:

Now we will turn the 2 red dependencies green by putting them on a component whitelist. Simply click on the button “Manage Component Whitelists”. You will be redirected to this view.

The component whitelist works similar to the license whitelist. You can have as many component whitelists as you want. Create a new component whitelist by typing in a name and clicking on the button “Create New Whitelist”.

By clicking on the name of the component whitelist you come to a view where you can edit the elements on the list.

An element on the component whitelist has in general this structure:

GROUP_ID : ARTIFACT_ID : VERSION

For example:

org.apache.httpcomponents:httpmime:4.5

The expression above would whitelist version 4.5 of httpmime. And it would whitelist only version 4.5. Version 4.4 or 4.6 are not whitelisted!

Now let’s say we want to whitelist all version of junit. That would look like this:

junit:junit

Or whitelist everything in the group “org.apache”.

org.apache

And don’t forget to whitelist mail.

javax.mail:

All right. Now go back to the project and select the new component whitelist and click the save button. Now we will get this view:

Now everything is green. There are 2 dependencies which violate the license whitelist, but because they are on the component whitelist they are marked green anyway.

This feature is very new. Please test it with caution and give feedback. Either here in the comments or on Twitter.

Introducing pessimistic mode for license whitelist

With VersionEye you can setup very easily a license whitelist. Simply put software licenses on the license whitelist you want/allowed to use in your software project. In the edit mask you get even suggestions via autocomplete. The suggestion are from the SPDX license list.

The coole thing here is that VersionEye is doing the normalisation for the licenses. Even if there is no exact match VersionEye will recognise the licenses in your project and will be able to assign the rules.

Some software libraries have more than 1 license. Some have a dual license and some software libraries offer even 3 licenses. Assume you are using a software library which has 2 licenses. A GPL-2.0 license and a Ruby license. The Ruby license is on your license whitelist, but the GPL-2.0 not. Does this software library violate your license whitelist? Should this dependency counted as violation or not? It depends. By default VersionEye is optimistic and as long the dependency has at least 1 license which is on the license whitelist the dependency doesn’t count as violation.

Here in this example we can see that several rows are marked red. But in the project head we can see that there are only 2 license violations. The libraries kgio and raindrops have both just 1 single license (LGPL-2.1+) and it is not on the license whitelist. This 2 dependencies are violations of the license whitelist. The other dependencies have at least 1 license which is on the license whitelist.

Now you can configure this behaviour. Now in the detail view of the license whitelist there is a checkbox for “pessimistic mode”.

If the pessimistic mode is turned on VersionEye will count every dependency which has at least 1 license not on the license whitelist, as a violation of the license whitelist. With pessimistic mode turned on the same project looks like that.

Instead of 2 violations of the license whitelist we have 4 now. Because 4 unique dependencies have at least 1 license which is not on the license whitelist.

This is a very new feature, please try it out and give feedback. If you are not sure how to use it you should talk to your compliance department.

VersionEye Maven Plugin 3.4.0

Just released version 3.4.0 of the VersionEye Maven Plugin. It brings 2 new features and 1 enhancement.

Plugins

The biggest change is that by default it tracks plugins now. All plugins who are explicitly defined in a pom.xml file are now treated a regular dependencies of the project. They get submitted to the VersionEye API with the “plugin” scope. In the Web Interface the plugins show up in the dependency table.

If you don’t want to track your plugins with the VersionEye Maven Plugin you can disable this feature. Simply add this line to your plugin configuration:

<trackPlugins>false</trackPlugins>

dependencyManagement:dependencies

Up to now the plugin only tracked dependencies under the “dependencies” node. Now dependencies under the “dependencyManagement” node are tracked as well!

licenseCheckBreakByUnknown

If a project has a license whitelist assigned to it the goal

mvn versioneye:licenseCheck

will check if there is a violation. If so it will break the build. That is still the default behaviour. But now there is a new configuration option to break the build for dependencies without any license information.

<licenseCheckBreakByUnknown>true</licenseCheckBreakByUnknown>

By default this value is “false”. If it is set to “true” the goal

mvn versioneye:licenseCheck

will break the build if there is a license violation OR if there is a dependency without any license information.

PDF Export & Charts for Licenses

For companies our license whitelist feature is very important. That’s why we put a lot of work into it, to make it even more awesome!

PDF-Export

If you assigned a license whitelist to your project a “PDF-Export” link will appear below the dependency table.

Now the dependencies & licenses are downloadable as PDF! The exported PDF file contains a complete list of the dependencies and licenses. It shows which of the dependencies are whitelisted and which are not!

Beside the list of dependencies it contains a complete list of all licenses which have been on the license whitelist at the time of the PDF export! That way it is reproducible why certain dependencies are marked as whitelisted and others not!

Charts

Now there are 2 charts in the license tab which visualise the license information better! The first chart shows the ratio between whitelisted, violated and unknown licenses!

That way it is very easy to see how many percentage of the project dependencies violate the license whitelist and how many of them don’t have any license information available!

The 2nd chart shows the distribution of the licenses itself.

The chart above shows that 80% of all project dependencies use the MIT license. 7% of the dependencies have no license information. And the other dependencies are using the Ruby & LGPL-3.0 license at the same ratio.

We hope you like the new features at VersionEye 🙂

Dependency & License Management

Last week I did a talk about Dependency & License Management at the Eurostaff Connect(s) – Berlin Developer Group. I was not able to do the trip to Berlin, that’s why we did the talk remote via Skype screen sharing.

I recorded everything with ScreenFlow, but unfortunately the recording was without sound. That’s why I did the presentation again and recorded it this time with sound 🙂 Here is the presentation on YouTube:

And here are the slides on SlideShare:

Feel free to ask questions here in the comments.

Audit Logs for License Whitelists

On VersionEye you can define a License Whitelist to enforce a license policy in your projects. Software developers are pulling in open source libraries every day, without carrying about licenses. They care about features. VersionEye can double check all open source dependencies against a license whitelist and send out notification emails if an open source dependency violates the license whitelist.

This feature is very popular at VersionEye. One of the most asked feature requests to the license whitelist is an audit log. And here it is!

Every time somebody adds or removes a license from a license whitelist it will be logged into the database. The audit log is directly at the footer of each license whitelist and it shows who removed/added which license at which time. The list is sorted descending by “created_at” date. In that way everything is reproducible.

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.