Open source is about something else entirely: Supply chain efficiency. But is it really?
Today I read a number of articles related to Open Source. Some were addressing current trends in Open Source litigation (and this is a complicated and ongoing issue), one got my attention as it tried to address the distinction between Free Software and Open Source software. I thought is was a decent informative article but it got my attention with the statement:
Open source is about something else entirely: Supply chain efficiency
Well I am sorry to say that I couldn't leave that one alone. But before I share my comments, which are an edited version of those I posted to the article, I want to say a couple of other things. First of all, I am not a lawyer so anything I say here should not be considered legal advise, there are lawyers out there to give you that!
Secondly, why was I looking at Open Source litigation in the first place? Well, anecdotally I was at a Trade Show in Lisbon a couple of weeks ago and had a brief chat with Jim Zemlin, Executive Director at the Linux Foundation. One of the things he said to me was that he was seeing an increase in Open Source litigation that concerned him. I took that under advisement to look at later.
Yesterday I attended a meeting here in Nice where a very clued in Innovation Enabler was discussing enabling Start Ups in France. I found the talk fascinating, not least because it really challenged my grasp of business French (which needs more attention!) but because of the discussion I had on Open Source afterwards.
The bottom line I heard was this (and it is a theme I have heard from IT executives before), and I am paraphrasing.
"Start Ups don't worry, and nor should they, about what Open Source they use in their products. The important thing is to get to market, then, if they start to make money or get investment for their products they can address any issues. Up to and including rewriting the software that might be at issue".
Now it is not my intention to be negative towards the person who said this to me. Actually, I would like to grab a beer with him at some stage and discuss this further. But I wanted to get some information together for him that showed some of the possible bad things that happen (usually incurring costly legal fees and worse) when you don't pay attention to what goes into your product at the beginning of its life. So being reminded of Jim's comments I went on my search for recent litigation. A few clicks later and I was at looking at an article addressing Open Source in the Supply Chain. And now I am here.
Open Source Litigation Is Real.
I have attached a couple of reference articles below to support this but this is the tip of the Iceberg. If you happen to be the plaintiff in an Open Source litigation case, and you are not savvy to your Open Source obligations and more importantly, you happen to be part of a larger supply chain then what may appear to be your problem can quickly become your Customers' problem and in turn their customers' problem. Open Source, under some licenses, has a viral effect and there is no Commercial remedy or protection for the most part. (I may get some lawyers commenting on this bold statement).
A quick summary of one of the cases I read today between Versata v. Ameriprise on a blog by Aaron Williamson. Versata sued Ameriprise for license breach which lead, during discovery, to the fact that Versata had used GPL code supplied by a third party XimpleWare. Ameriprise counter sued Versata claiming that because the product used GPL then they had GPL rights to the code and Versata had not met its GPL obligations. Along the way XimpleWare found out about this and ended up counter suing both Versata and Ameriprise for patent infringement (something that using Open Source, especially GPL is supposed to protect). Not only did XimpleWare sue Versata and Ameriprise, but they also went after Versata's other customers including United Healthcare. So almost overnight a seemingly simple lawsuit escalated and the lawyers were all very happy! I believe the suits have been settled and you can go to Aaron's blog if you want to know more.
My point here is that when you don't know what software you are using in your product you create a ticking time bomb that is waiting to go off. It may well go off for the most bizarre and unexpected of reasons but if you don't pay attention it will go off. Most people focus on accounting for Commercial Software because there are dollars and obvious IP issues at stake, but Open Source is often pushed to one side because it is perceived to be free and I can always remove it from my product if it becomes a problem can't I? Cisco Systems and others have learned the hard way that this is a very bad assumption.
Getting Back on Track!
So now where does the Supply Chain fit in here? Well hopefully in the Versata example you will have seen what a Supply Chain looks like for Software. XimpleWare provides software that Versata uses and embellishes somehow and then redistributes it on to Ameriprise and United Healthcare and others. I am sure that if you roll back the covers on Ameriprise's or XimpleWare's software you will find software coming from other sources some Commercial but possibly more Open Source.
The fact is that Software these days is generally a huge assembly of components authored by many folks, for different reasons and often distributed in a different piece of software than you might find it in now. Open Source Software is the epitome of this.
The Supply Chain is vast and often very complicated. Creating a perfect basis for that ticking time bomb I mentioned earlier.
So what is Supply Chain Efficiency?
I think if you talk to many experts in the area of Product Lifecycle Management (PLM) - the current phrase used to encompass Supply Chain practises - the term you will hear is Frictionless.
For a Supply Chain to be efficient it needs to have less friction. That is not be slowed down by anything, infact it needs to be "lean and mean". With optimal delivery, usually just in time, of goods and services to the Customer.
So surely if I have free software then that speeds things up right? No contracts to negotiate, quick access to features I need, hopefully pretested by a wide community. Once that gets to the supply chain who cares right?
Open Source actually creates friction in the Supply Chain if you "do Open Source" properly!
I'll address doing Open Source properly below. Please don't take this as me being a detractor of Open Source. Open Source is a great way to get product to market and do things rapidly BUT there is no Open Source Free Lunch (ask Ameriprise or XimpleWare or Versata).
Let's look at the premise about Open Source being about Supply Chain efficiency. Hopefully you might agree with me using a British phrase here and that is poppycock!Â
How does Open Source add friction to your Supply Chain?
I spent over 10 years working in the Supply Chain function at Cisco Systems and my role was to track and audit ALL software coming into the supply chain from Engineering (Commercial and Open Source) and make sure that the licensing had been followed.
Several issues, that are easily overlooked in the use of Open Source are problematic to large companies, like Cisco, who have invested millions of dollars building a comprehensive compliance process. This process is cross company and includes hundreds of people, developers, business managers, lawyers, supply chain professionals and managers, and more. Why? Well there is a fairly public reason that followed the acquisition of Linksys that I am not going to dwell on here. So what are the issues?
The perception of and confusion caused by the phrase "Free and Open Source Software" (FOSS). Cisco narrowed down the focus to Open Source and trained on the principals that ALL Open Source was owned intellectually by someone else who, via one license vehicle or another, had made their code available for use without an initial cost (money cost).
However there is, in most cases, a cost for using the software. Distribution is normally a significant trigger for certain types of Open Source especially copyleft such as GPL. In addition you also have to be careful (even with BSD and other more permissive licenses) that you follow the obligations in the applicable license which, for non copyleft licenses in general, requires that you publicise attribution to the author somehow. It may be a trivial ask but we should do the right thing here.
Extra Engineering Analysis Effort
If you use GPL you have to provide access, either as part of your distribution or via an offer in some publication that accompanies your work, to the GPL source code AND any AND ALL changes that you made to that code. Moreover, if you were not very smart in how you developed your product and combined your IP with said GPL or copyleft code then, sorry, that needs to be published also. So guess what? Your engineering department now has to incorporate additional steps in their peer review, static analysis or other development processes to check for these things AND certify that they have done so. Most busy engineering departments hate having things in their way to slow them down Cisco engineers are no different!
Complex Conjunctive Licenses
A lot of GPL code and other Open Source is notorious for being mixed licensed (also called conjunctive licenses). This is less of an issue with Commercial Licenses because you can hold the supplier accountable for down stream licensing. With Open Source YOU CAN'T! So this means that a piece of code that is licensed under MIT (for example) may include code from a BSD or Apache style license or a simple request for attribution or a beer in the future. Guess what - you then have an obligation to follow the requirements laid down in each and every license that makes up what is notionally just an MIT license, which in reality is not.
Open Source buried in Commercial Distributions
In many cases commercial suppliers can distribute Open Source into the Supply Chain, Red Hat and Google immediately come to mind, but all commercial suppliers these days use Open Source one way or another. Many folks think that a commercial supplier's license agreement trumps (no pun intended) Open Source use. It DOES NOT :-). If you receive any Open Source code from a supplier and use it you are obligated to follow each and every Open Source license. So you better know what they gave you.
Bait and Switch Licensing
What is "bait and switch" licensing? That is a license that purports to be Open Source but then somehow leads you into some form of commercial relationship. These are real and can be costly. Sometimes a 'so-called' Open Source license, take the famous Community Source license pioneered by Sun Microsystems back in the day, permits free and open use for limited purposes, just like the GPL license, and, unlike the GPL license, includes a distribution clause that requires a commercial license. These, thankfully are getting fewer and fewer but they are out there. The most prevalent are similar to Android where you get some basic Open Source features but to get better performance or higher encryption or some other 'advanced' feature you need a commercial agreement. Google are currently the focus of an Anti-Trust violation investigation by the European Commission for this business practise.
Do you Click to Accept instead of Click, Read then Accept?
Often many of these licenses are placed in the simple click throughs on a web site, that most people don't bother to read, but click on so they can get their software fix!
Maintenance and Security Costs
Lastly (but this is not an exhaustive list) a real cost of using Open Source is the additional maintenance required. With cyber attacks on the rise it is increasingly important that your software is current and all security threats removed very quickly after they are discovered. Some Open Source communities are very effective and efficient with updates, bug fixes and security patches etc. some are not. Some engineering departments are very good at monitoring Open Source community updates and some are not.
When you start using Open Source you had better build a suitable support team in your engineering department and, I would recommend, join the applicable community so you can maximise your chances of keeping the code in a viable and safe state. Your other option is to go to your Finance department and get some money to pay a company like Red Hat to do that for you.
How do you know what you have in your product?
Well lets think about what you get when you buy anything from Ikea. You get a document that does two things.
Identifies everything that you should have received in the box you purchased.
A guide showing you how the pieces come together to build your product.
This in the business is called a Bill of Materials or (BOM). BOMs are the core of Product Lifecycle Management. They connect suppliers to components, components with assemblies and finished good and are versioned and costed so you can address product defects and raw material costs.
I am a big advocate of putting all of your Software, especially all 3rd Party Software, on the product BOM. I pioneered this idea at Cisco and it is becoming a reality. It is a REALLY hard thing to to retrospectively. But, if you treat third party software, commercial or Open Source, like any other product component then you will have the basis for an excellent Software Compliance System and you will create an environment where the Friction that Open Source could contribute in your supply chain is mitigated.
Its not FOSS - its FTUOSS so lets just stick with OSS!
So let me finish this by saying that there is no "Cost Free" Open Source. There is "Freedom To Use" Open Source where you do not seek to gain from its use. As with anything in life, there is no Free Lunch.Â
The moment you decide to share what you have done with Open Source and have someone else make use of your work then you extend the Supply Chain one more link. You now have an obligation to your customer (whether commercial entity or friend) for providing a supported and compliant product and making them aware of what their obligations are. You also have an obligation to your Supply Chain to do this and uphold the terms that you agreed to when adopting and using the code in the first place. Its only right that you do so, after all, what you have used didn't grow on trees.
Be careful out there!