Open Source vs. Proprietary Software in the Supply Chain


Open Source Software Proprietary Software have very different supply chain mechanics. Programmers, Architects, and Systems Administrators need to understand the long term impact of leveraging Open Source software versus Proprietary Software.

For as long as I have been programming, it has been common for programmers to leverage libraries of code. Historically, these libraries were always written by me or someone that I was working with on a project, these would typically be considered Proprietary Software, owned by the company that I worked for. However, over the last 10 years, it has become common place to leverage open source libraries, projects, and entire distributions of software. The Comprehensive Perl Archive Network was conceived in 1993, and released online in 1997, but now it is common for almost every language to have an online content management system for code modules.

When a programmer sits down to start building a new project, use ranges from simple libraries, like a driver to syslog, to a full blown module, such as the Natural Language Toolkit. When an architect plans out a new tiered application, it it’s common to leverage projects such as long lived daemons, like Drools rules engine, to a full blown Linux distribution as the foundation.

This is an old article from Groklaw but it provides an excellent analogy for how we leverage Open Source software supply chain.

If you are going to build a bridge, you don’t usually start by opening an Iron Mine. You don’t usually start by manufacturing girders and rivet’s either

Just like leveraging proprietary software, there are impacts to leveraging open source software. Each of the major Licenses, GPL, Apache, BSD, etc, have different rules guiding what can and can’t be done with the code. Each project has a different level of community health and participation, look at the Heart Bleed bug. Different projects have different levels of support. Finally, different projects are in wildly different phases of the lifecycle. This can have huge impacts on your application or system.



The article from Groklaw also highlights challenges in the supply chain. Each company has different opinions on what open source means. Google relied on architecture and formats used in Java to implement the Dalvik virtual machine as a foundational technology for the Android Operating System. This used caused Oracle to sue Google for infringement of patents.


Call to Action

There are technical, legal, and business consequences in the use of the software supply chain. Next time you deliver a project think of the software you rely on as a supply chain which can affect what you want to do with this new code.

In 2008, HP released a tool called FOSSology, which appears to still have a healthy community. The goal do the project is to help track the use of open source software and the impact of their corresponding licenses. The goal is to help individuals and companies can better understand and safely comply with the legal impacts of leveraging the Open Source supply chain.

Let’s all keep using Open Source software, as I believe the benefits are great, but let’s do it professionally and responsibly.



  1. Deep Dive: Rebasing vs. Backporting | Crunch Tools - May 19, 2014

    […] released. In this article I want to clarify how Red Hat and others leverage and contribute to the Open Source Software Supply Chain. My intent is to clarify why the operating system matters and explain what the version number of […]

  2. Reasons for adapting Open Source Technology in Web development - Israel Foreign Affairs - May 22, 2014

    […] While making use of proprietary software the users are in the control of the vendor wherein case of open source software there is absolutely […]

  3. Core Builds in the Age of Service | Crunch Tools - December 3, 2014

    […] In this article, I will treat any baseline operating system as a core build. There are two core mechanisms for providing a baseline operating system; image and blueprint. Provisioning from an image has the advantage of being able to include large amounts of software, while a blueprint has the advantage of being easily understood, reproduce-able and automated. These mechanisms are not mutually exclusive. For example, Docker and Project Atomic are providing more granularity to the software supply chain. […]

  4. Securing Docker Containers with sVirt and Trusted Sources | Crunch Tools - May 21, 2015

    […] are a couple of key points in the circle of trust, or software supply chain. First, I went and downloaded the binary from Red Hat’s site. Notice the SHA-256 keys. This […]

Leave a Reply