Default License Whitelist

In VersionEye it’s very easy to setup a license whitelist. A license whitelist describes licenses which are allowed in your organisation. You can even have multiple license whitelists per organisation. That way different projects can have different license whitelists. That makes totally sense because licenses have different obligations. Some licenses can be used in a cloud environment but not for mobile apps.

However, most people don’t know much about software licenses. They simply don’t know what to put on a license whitelist and what not. That’s why VersionEye has a default license whitelist now. It contains a small set of software licenses which can be used in any environment. The default license whitelist currently contains this licenses:

  • Apache-1.0
  • Apache-1.1
  • Apache-2.0
  • BSD
  • BSD-2-Clause
  • BSD-3-Clause
  • BSD-4-Clause
  • BSD-4-Clause-UC
  • CC0
  • CC0-1.0
  • ISC
  • MIT
  • Public Domain
  • WTFPL

This license whitelist has always the name “default_lwl” and for newly created organisations it’s marked as default license whitelist. That means it gets assigned to all new created projects and all the project dependencies are compared against that whitelist.

Screen Shot 2017-06-12 at 19.10.11

Of course you can edit the “default_lwl” any time. You can remove licenses from it and you can add new licenses to it any time. It’s just a suggestion to start with.

Let us know how this works out for you.

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.

Screen Shot 2015-09-17 at 09.49.30

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.

Screen Shot 2015-09-17 at 09.51.05

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.

Screen Shot 2015-09-21 at 11.53.58

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.

How to component whitelist non Java dependencies

Since last week VersionEye supports component whitelists. In the last blog post I described how to whitelist Java/Maven dependencies. The structure for that is like this:

GROUP_ID : ARTIFACT_ID : VERSION

Now the question was coming up how to put non Java/Maven dependencies on the component whitelist?

That is possible as well! For non Java/Maven dependencies simply use this pattern:

LANGUAGE : PROD_KEY : VERSION

For example:

Ruby:rails:4.2.4

to whitelist version 4.2.4 of Ruby on Rails. If you want to whitelist ALL versions of Ruby on Rails use this expression:

Ruby:rails

Let me know if you have more questions. Either here in the comments or on Twitter.

Improved Componente Whitelist

Since last week VersionEye is offering a component whitelist for software dependencies. The component whitelist is an extension for the license whitelist. Dependencies which usually would violate a license whitelist can be whitelisted through a component whitelist.

After using the component whitelist for a couple days the question was coming up wich dependencies are whitelisted through the license whitelist and which through the component whitelist. In the current version the dependencies who are whitelisted through the component whitelist are marked with a thumbs up icon. Like in this example.

component_whitelist

In the screenshot above the 2 dependencies “junit” and “mail” usually would be marked red, because their licences is not on the selected license whitelist. But they are “green” anyway because they are on the component whitelist.

Contact me if you have more suggestions for improvements, either here in the comments or on Twitter.

CSV Export

At VersionEye you can setup a license whitelist to enforce a license policy. For each project there is a PDF Export, which contains the BoM (Bill of Materials). Now the same export is available as CSV as well. The links for the export are in the project detail view in the license tab.

VersionEye-License-Export

The new CSV Export has the same format as the PDF Export. It contains the list of dependencies with the information if they violate the license whitelist or not. Here is a screenshot of an example.

VersionEye-License-CSV-Export

The PDF/CSV Export also contains the current status of the license whitelist and the current status of the assigned component whitelist. That way the exported document is a complete snapshot of the current state of the project, license whitelist and component whitelist. That makes it easy to reproduce why a component is whitelisted or not.

Try out the CSV Export and let me know if you have any questions. Either here in the comments or on Twitter.

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:

component_whitelist_3

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.

component_whitelist_1

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.

component_whitelist_2

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:

component_whitelist_4

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.

03-license-whitelist

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.

Screen Shot 2015-06-22 at 10.55.45

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

Screen Shot 2015-06-22 at 11.37.45

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.

Screen Shot 2015-06-22 at 11.39.08

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.