As a SAM professional should you worry about Open Source? After all your job is to optimise software spending and avoid the pitfalls and costs of software misuse right? Read on...
I have been thinking about the area of SAM a lot recently.
I track a lot of SAM groups and read many of the posts that drop into my inbox. Sometimes I am inspired to chip in with thoughts and recommendations on license compliance, or process issues, challenges with juggling license models (subscription, term, buyout), optimising costs and how all of these should me managed or blended into some of the standardised IT process models addressed by Prince and ITIL etc.
What I feel is often missing, and not always understood, is how SAM needs to expand to address Open Source.
Why? You might ask.
First some quick background. Since this is a Linked in blog post you will be able to take a look at my profile and experience. I have spent many years working with Software licensing and performed most roles that can be associated with software be it developer, sales/marketing, IT management, procurement or asset management. I may not have formal ITIL, Price2 or other certifications but I do have hands on experience working in a Fortune 500 technology company and managing 100s of software components (and in some cases hardware IP) of all types in many different use cases.
My most interesting and challenging experience was in the realm of the software supply chain. Let's see how this is relevant.
It could be perceived that Software Asset Management is purely an IT function. This function is responsible for:
ensuring that their organisation is tracking commercial assets licensed from third parties (particularly large software publishers like Microsoft, Oracle, SAP, IBM etc.)
that the usage of this software meets the commercial agreements in place with the software publisher
that all license fees are correctly accounted for and kept to a minimum
This perception is far too narrow and overlooks some of the things we see happening in the IT world especially with the advent of "the Cloud" and "the Internet of Things". Our world is trending to one where Apps dominate our lives. Apps are everywhere, on our phones, tablets, laptop and desktop computers and increasingly, cars, in-home systems (electricity meters, alarm systems, lighting and heating systems....), CCTV and the list keeps growing. How is it possible for so much innovation and so many new technologies to be developed and pushed into the market? The answer is a very simple one.
Open Source
One of the most popular platforms in use today that includes a large amount of open source is Android. At its core Android is a Linux based system and available in source code form to anyone that wants to build an Android device. I cannot conceive of any organisation these days that don't have some Android use.
Microsoft is embracing Open Source in leaps and bounds. This can be seen its most recent Windows releases (7 - 10), Visual Studio 2015 Community, in the Visual Studio support environment of developer templates and feature libraries made available and distributed via NUGet and GitHub, and the release of mono in 2004 and more recently .NETCore.
So what's the problem for SAM? Why should SAM practitioners care about Open Source and make sure it factors into portfolio management? Surely the commercial agreements in place with their suppliers covers them for Open Source right?
Wrong!
Free and Open Source Software (FOSS) comprises a set of licenses that are completely independent of Commercial license terms. Open Source licenses, and there are many, have some very simple concepts founded around the idea of communities of interest, sharing software and knowledge, unrestricted distribution without a financial cost. This is what leads to accelerated technology development and the huge growth in Cloud and IoT we are seeing.
There is a problem though. Don't think of Free as being without financial cost, think of Free as in Freedom. Freedom doesn't generally come without a cost. With FOSS this cost is based around the requirement to share and in some cases, give back to the community. The cost comes from the obligations to clearly attribute authors and community projects in your products or (in some cases) your service offering.
Additionally the cost may also come from a misapprehension that a given FOSS license when used avoids the need for a Commercial agreement. Java is a good example here as is MySQL. These are technologies that enable development of and use for internal purposes but as soon as you redistribute (or in some cases use) commercially then a Commercial License requirement is triggered.
If you are a SAM practitioner working with an IT team that is building applications using Open Source that are either redistributed to your customer in the form of an App, or hosted in the Cloud then Caveat Emptor! Start looking at which Open Source components are in use and how they are used. Be particularly careful with anything that has a GPL license or an AFFERO GPL license. These license could force you to disclose or even release your proprietary IP to anyone who asks for it depending upon how you have used the GPL licensed code. At a minimum you MUST be prepared to give a requestor the source code for the applicable GPL licensed technology.
AFFERO GPL is a little more challenging. If you use an AFFERO GPL license in your cloud based offerings then this code can trigger similar obligations even though you haven't technically redistributed the software on your Cloud Servers.
Cloud based systems often deploy one ore more Java Applets to the consuming clients to perform certain services. Make sure that these Applets are completely free of third party code. There are many Open Source Java frameworks that if used in your Apps may trigger unintended consequences.
Bottom line here is this. Most IT teams these days do not license software solely for the use and consumption of an organisations employees. They also license software, sometimes via a simple click through on a third party web site, for use in customer facing SAAS and App offerings.
If you have an Open Source process and policy in place in your SAM program (you should have one for your organisations Engineering teams) then well done!
If you don't then I recommend you get one in place ASAP. Having been on the sharp end of trying to track and manage Commercial and Open Source software in a product company where OEM licensing was the norm I can tell you this is a non trivial problem and will get worse and not better. FOSS transferred in Commercially licensed software cannot be ignored, you cannot push FOSS license obligations onto your supplier, you take on those responsibilities when you use or redistribute such code. So know what is in those components and add compliance checks accordingly.
To wrap up. Open Source provides a fantastic opportunity to accelerate technology development, it also presents a fantastic opportunity to reduce your IT costs if you can find viable alternatives to existing incumbent technologies (e.g. OpenOffice or LibreOffice instead of Microsoft Office). While these might not be what your users want, they do present opportunities and may already be in use in your organisation today :-). Whatever you do don't ignore Open Source in your Sam practise. Manage it in the same way as you do Commercial software and beware that this may well incur some additional costs.
Whatever you do do not fall foul of the Free Software Foundation or any of the other organisations or individuals who are out there forcing companies to account for their Open Source use. if you think a Microsoft or IBM or Oracle audit can be painful I can assure you that an Open Source driven one is much worse!
If you have any questions or suggestions for more information in this area I will be happy to accommodate either.
Cheers
Open Source References