Increasing the value of open source usage with tools

Many software companies are leveraging open source software as part of their business models and solutions. The reasons for doing so are simple: Open source software usually does not carry license fees, has high quality and can be easily accessed.

So let us talk about how commercial software vendors are using open source components as part of commercial software. Despite the opportunities and advantages open source provides, there are important development operations aspects, like updating open source components, and risks like security vulnerabilities that have to be managed. So let us look a little deeper into each of these aspects.

Development operations issues

On average, software products usually contain between a few and a few hundred open source components (source: hippocmms.com/software). The complexity gets even worse when we consider the fact that open source components themselves often contain numerous other open source components.

While it is easy for a developer to follow the community for one component, it is hard to follow the communities of dozens or hundreds of open source components. Getting notice of updated and improved versions of many open source components is often impossible. So the usage of numerous open source components leads to high effort maintenance work for developers which lowers productivity. Fortunately, tools like VersionEye allows you to manage and update these components continuously and lets you leverage developer capacity for innovation instead of looking for updates of open source components

Risks

One key source of risk of open source besides license compliance are security vulnerabilities, that are not fixed. To determine security vulnerabilities is a high effort activity. Fortunately, many people in the open source community test, collect and fix open source security vulnerabilities. The developer only needs to get notice of these activities.

Nowadays, many updates of open source components are related to fixing security vulnerabilities. Missing a security update is critical. If a developer misses an update, he exposes products and their customers to a hacker attack. Hackers know that a vulnerability exists in an old version of the open source component. Fortunately there are tools like VersionEye that track security vulnerabilities for you and alert you regarding those vulnerabilities and about security related security updates of open source components.

New book on open source best practices

There is a new a book that has all the necessary background information. It provides an overview of business models, processes and tools relevant for commercial software vendors leveraging open source software and open source communities, no matter if the company participates in open source development or not. The one of a kind combination of academic and pragmatic information, from researchers, practitioners and tool vendors like VersionEye make this book a must have for all people in the software industry.

The book is called “Best practices for commercial use of open source software” and it is available in all major online and offline bookstores, in Google Play, iBooks and on Kindle. ISBN 3738619097

Guest Post

This is a guest from Dr. Karl Popp, Senior Director Corporate Development M&A @ SAP.

Dr. Karl Popp is all about corporate development and mergers and acquisitions in the software business, from successful partnerships to successful mergers and acquisitions. He loves to share his wisdom in books and other media like http://www.drkarlpopp.com.

kposiemens_400x400

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.

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.