Background

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.

 

Challenges

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.