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. 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


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


DevOps MeetUp in Mannheim

Yesterday was the very first DevOps MeetUp in Mannheim. VersionEye was sponsoring the event with Location, Pizza & Beer. Beside that I did an intro talk to Docker. I showed the basics and also demonstrated how VersionEye is using Docker for infrastructure deployment. Here are my slides.

The 2nd talk was from Michael Bahr about Ansible. He did a great intro and showed how you can use Ansbile to orchestrate Docker containers. His slides are here on SlideShare.

The event was a great success. More people showed up then expected. The room was full packed with people.


And even more people joint during the Docker talk. The left upper corner was completely full with people by end of the talk.

The event started at 7 PM. After the 2 talks most of the people stayed for Beer & Pizza and the networking part went until midnight.

Screen Shot 2015-09-24 at 12.54.08

It was a great kick off for DevOps Mannheim. Looking forward to the next event :-)

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 if you are interested.

Composer Stability Flags

Composer has a cool feature, called stability flags. That allows you to specify the stability of a dependency.


Assume there is no stable version of silex/silex. Then this entry

    "require": {
        "silex/silex": "1.0.*@dev"

would install 1.0.x-dev, the dev version of the 1.0 branch.

I always interpreted “@dev” as “take the newest, even if it is unstable”. But currently I had this dependency in a composer.json:

"doctrine/migrations": "1.0.*@dev"

And Composer resolved that to “1.0.0-alpha3”. I do not really understand why. There is a stable version 1.0.0 and if “@dev” means “take the newest unstable version” then that would be 1.0.0-rc1.

If somebody can explain why “@dev” resolves to “1.0.0-alpha3” in this case please leave a comment here.

Security Vulnerabilities and Licenses via the VersionEye API

VersionEye can monitor your software dependencies and notify you about out-dated versions. But that’s not all. VersionEye can help you with licenses and security vulnerabilities as well. You can setup a license whitelist for your projects and VersionEye will notify you as soon some of your dependencies are violating your license whitelist. For PHP projects you can even receive notifications about known security vulnerabilities.

Screen Shot 2015-09-20 at 15.16.34

Now the license and security vulnerabilities are available via the API as well. With this Endpoint it’s possible to fetch information about an existing project.

Screen Shot 2015-09-20 at 15.20.14

The response is a JSON object with an Array of dependencies. Now each element in the dependencies Array has a new variable called “licenses”.


If it is empty that means that VersionEye has no license information about this dependency. Otherwise it contains a list of licenses like this.


“on_whitelist” shows if the license is on the license whitelist or not. If the value is “null”, that means that there is no license whitelist assigned to the project. “on_cwl” stands for on component whitelist. The values are equivalent to the “on_whitelist” field.

Beside that each element in the “dependencies” Array contains a new field “security_vulnerabilities”. That is an Array of known security vulnerabilities to the dependency.


The versioneye-php package is a wrapper around the VersionEye API and it implemented this new features already in the newest version.

Now the VersionEye API is even more powerful. Take advantage of it ;-)

Support for composer-asset-plugin

Composer is the dependency manager for PHP. Dependencies are defined in a composer.json file, very similar to the package.json file from NPM. Composer is awesome because it’s solving the problem of installing 3rd party libraries.


But it is only handling PHP packages from Specially in a web environment many times you need some CSS and JavaScript packages as well. For that use case there is the composer-asset-plugin now. With that plugin you can reference NPM packages and bower packages in your composer.json. That way you have ALL your dependencies in 1 single file. If installed correctly you can reference an NPM packages just like this:

    "require": {
        "npm-asset/bootstrap": "dev-master"

And a bower package like this:

    "require": {
        "bower-asset/bootstrap": "dev-master"

Up to now this dependencies have been marked as UNKNOWN from VersionEye, because VersionEye was looking for a PHP package with the name “bower-asset/bootstrap”. But now the composer-asset-plugin is supported and these dependencies are handled correctly.

Please try it out your self and give feedback.

New Pricing

Now there is a new pricing for VersionEye. The new pricing is more consistent and easier to understand. Please check out the new pricing page.

Screen Shot 2015-09-18 at 10.45.18

You can still sign up for free and monitor unlimited open source projects at GitHub/Bitbucket for free. The paid plans are required for private and closed source projects and for additional features like PDF/CSV export. Now the PDF and CSV export for the Bill of Materials in the license tab are only available in the higher paid plans.

The old plans are going to be continued. You don’t have to switch to a new plan if you don’t want. The old plans are available for booking until end of this month. You find the old plans in the settings area under “plans“.

Screen Shot 2015-09-18 at 10.24.42

The old plans can be booked until 1st of October. After that the old plans are closed for booking and only the new plans are available.