Sometimes we can guess easily enough, and sometimes we don’t much care anyway for the subsequent story is hardly that interesting or original. Sometimes however, the name of the customer is not really relevant because you know there is more than one of them, and the chances are that others are about to fall into the same trap the story illustrates.
This was certainly the case earlier this year when CAST Software held its annual conference in Paris, and CEO/Chairman, Vincent Delaroche first talked about a partnership between CAST and the Software Heritage Archive, which is part of the Institute for Research in Computer Science and Automation, INRIA in France.
CAST is providing Software Heritage Archive with tools that not only examines application code for programming errors and weak logic, but can also identify if a piece of code has been used before. This is of particular importance when it comes to applications using open source components as part of their make-up. For while perceived wisdom suggests that open source code on services such as GitHub are 'free', the impact of the various licensing models that are in regular use means that the exact opposite can be true.
Sting in the tail
Delaroche, using the classic 'I can’t name the company, but…' defence, talked at the time about companies CAST and the Heritage Archive had already done investigative work for. One had developed a new app and then discovered that one sub-routine was open source and the licence gave the holder the right to restrict the way the whole application could be used. So the only alternatives were to re-write the application and remove that sub-routine.
Another user found that the licence used for one open source routine meant that the licence-holder automatically owned the IP of any other application it became a part of. Another of his anecdotes on the subject told of a large application where a small, but commonly-used, open source applet had been incorporated in different parts no less than 28 times. That might not have been an issue, except for the fact that all 28 were different in some way, and several different open source licences were being used.
For the likes of you and me, dabbling with building a little application to achieve a small domestic solution of some sort, such licence issues are neither here nor there. The code is free and, if we feel suitably proud of the result we might even submit it as an applications to one of the open source repositories. For any business, and for major corporations in particular, the implications of this are however somewhat concerning.
An interesting question here might well be: how many CIOs think that open source software is free? How many think the code is out on GitHub or whatever and their development teams can simply download and use it all with impunity? Well, yes they can, up to a point. But that point is that open source software is now opening up a whole new skillset requirement in investigative software licence management.
The needs of such a role will require a pretty good level of legal knowledge, skills and judgement in order to plough through the different types of open source licence and determine what they mean for any application a business is using. And this is likely to include applications that are either purchased for on-premise use or run as SaaS via a Cloud Service Provider, as well as applications developed internally for specific use just by that business.
Indeed, those SaaS applications and services providers will need to be doing the same thing, as will the Service Providers that host such businesses: they all may need to be examining their own positions as well.
Not that long ago, this would not have been an issue for businesses. But the cloud has changed all that. Open source software is now in use everywhere – not so much in obvious ways such as a complete, packaged open source application or service, but as millions of readily available applets and sub-routines that developers can download and incorporate.
This is now a world where the 80:20 rule is endemic. This is where the 20% is that business IP, the algorithms, process steps and optimisation tricks that make the application specific to the needs of that business. The 80% these days is likely to made up of open source components from hither-and-yonder and, potentially, each one coming along with its different licence terms and obligations.
Each licence obligation can become a potential bomb once a business then sells or take subscriptions for that application, and maybe even just uses it internally to cut costs or generate more revenue.
The second problem here is then actually trying to find all the bits and bobs of open source code that get used in a modern application development. This is where the partnership between the Software Heritage Archive and CAST Software is pitching its tents.
There’s billions of ‘em
The Archive is a non-profit initiative which aims to build THE universal archive of software source code. It is currently supported by Microsoft, Intel, Google, GitHub, and a wide range of large corporations and organisations in the public sector. It has gathered up over 5.6 billion source files from some 88 million projects, and it continues to grow. As the Archive’s Head, Roberto di Cosmo, said of the project:
I feel I am building the code equivalent of the Library of Alexandria.
CAST has, since last year, been offering a Software Composition Analysis service, which is primarily intended for developers of business applications. This provides the tools needed to identify areas of poor coding that either impede the smooth operation of an application or cause a security weakness or flaw. It also can identify what software components are in the application and, in the case of open source code, what licence applies and who holds it.
The partnership puts these two - the wealth of data and the analytic tools required to make sense of it, - together for the first time, giving CIOs the first opportunity to really look at the insides of their applications and identify the elements that are going to cause them problems technically, security-wise, and those sneaky legal ones that creep up unexpectedly.
It is also worth keeping one small factor in mind; the service is accessible via a RESTful web API, and it is reasonable to assume that open source coders are going to be exploiting it, if only as an exercise in ego-stroking. So it is, arguably, beholden on CIOs to keep pace.
To me this looks like a sensible answer to a sneaky problem. Open source code is now the de facto backbone of most new applications, and they can be remarkably cost-effective. They can, however, carry a pretty vicious sting in the tail for the unwary. Finding those stings and dealing with them is going to become a major component of the business of managing a modern IT environment.