The ugly side of open source

on Apr 2, 14 • by admin • with No Comments

There is a wide array of issues from legal to security to code quality. Let's dive into some of the issues that surround the open source community...

Home » Open Source » The ugly side of open source

My previous posts have usually viewed open source in a positive light, but there is a lot that is wrong in the open source community. There is a wide array of issues from legal to security to code quality. This article will dive into some of the issues that surround the open source community.


I could write an entire article on the issues around open source licensing. Today, let’s touch on a few of these issues.

Conflicting information

Countless times I have seen examples of a developer stating in the Readme file that a project is under one license, yet the developer’s website has a different license listed. The most common example of this is when a developer claims they use the MIT and actually distribute the BSD license or the Apache 1.1 license.

Nested licenses

A common issue that I have discussed before is the issue of nested licenses. Often times a person will believe they download one open source project under one open source license, but in reality there are probably multiple open source projects and licenses nested in the source code they downloaded. This can become an issue when you are trying to avoid certain licenses and those licenses are nested in the project with little to no reference to them.

I have also seen examples where a project has a folder for contributed code and developers are allowed to pick the license they want to use for the files they contribute. This type of practice can quickly make a mess of the project’s licensing, and even change the base license to the project. For example, the base license of the project might be MIT, and then a developer wants his contributed code under the GPL. (Is the whole project under GPL now?)

There is another way multiple licenses can be attributed to one project. In some cases a project will have a base license tied to it but have option parts that can be used under another license.

For example, let’s look at an open source project called FFmpeg. “FFmpeg is licensed under the GNU Lesser General Public License (LGPL) version 2.1 or later. However, FFmpeg incorporates several optional parts and optimizations that are covered by the GNU General Public License (GPL) version 2 or later. If those parts get used the GPL applies to all of FFmpeg . . . Note that FFmpeg is not available under any other licensing terms, especially not proprietary/commercial ones, not even in exchange for payment.” Stipulations such as these can really create license confusion and compliance failure, especially if somebody downloads this project from another origin that isn’t the project website. Difficult licensing terms such as these can cause fewer developers to use the product and hurt the project in the long run. In the case of FFmpeg, a developer might be more inclined to use Bink and not mess with the licensing issues.


There are two camps when it comes to open source security. One camp believes that because source code is readily available it is less secure. These people think hackers can look for weak points in the code to exploit. The other camp believes that because source code is readily available it is more secure. This camp thinks there are more eyes to look at the code in order to identify weak points and write patches and fixes. I tend to agree with the latter for the most part, but there are a few exceptions.

Use of old open source

As with proprietary code, open source code can be written with security issues, and this makes keeping your open source up-to-date crucial. The larger communities are pretty good about identifying security risks and writing patches for them; however, if you download something and never go back to update it then you might have security risks in your code that makes you vulnerable. Cisco recently released information on its blog that backs this exact point up: “TRAC has recently observed a large malicious web redirect campaign affecting hundreds of websites. Attackers compromised legitimate websites, inserting JavaScript that redirects visitors to other compromised websites.”


There are a large number of open source projects that are of a high-quality, but when you look at the full spectrum of open source projects – in the millions – there are an even larger number of lower-quality open source projects. Enterprises typically try to use open source from established communities, but it is still important to watch for low-quality projects. Often, smaller open source projects do not have the resources to vet the code and allow for a quality code review. These small projects often take code contributions from unknown developers with unknown skill levels and do not know where the developers got the code or if they even wrote it themselves. (Did they take it from another open source project or even a commercial project?) It is fair to assume a lot of these smaller projects are not doing their due diligence, and given that the typical open source license comes with no warranty the responsibility is on the organization using the code.

All in all there are an overwhelming number of positives with using open source, but it does come with its drawbacks. The use of open source will allow you to save money and speed up development, but there are costs associated with using it. Do your due diligence on your open source.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top