“A resource with economic value that an individual, corporation or country owns or controls with the expectation that it will provide future benefit”
The way organisations adopt new software applications has changed significantly in the past 5 years. Previously organisations would licence commercial software products from mainstream vendors and use the applications as building blocks to create the required solution. Quite often this would mean licensing expensive applications but only using a small percentage of the functionality. An added complication was the need to track and manage licence compliance for all the vendors and applications.
This need to manage licence compliance spawned an industry for Software Asset Management which includes standards for Software Asset Management the first being published in 2006 ISO/IEC 19770-1 Standard for Software Asset Management.
With the introduction of new mobile platforms such as Android, organisations are now building their own applications or commissioning bespoke solutions from third party independent software vendors. These applications are built by piecing together proprietary, third-party, Open Source Software , and contractor 3rd party components of code. The wide availability of Open Source Software (OSS) frees developers from having to reinvent the wheel, while accelerating development and reducing costs. For organisations this presents a far more efficient model for delivering solutions where you code what you need and re-use what you have coded. As opposed to the old model of licensing software where much of the functionality is not required and therefore unused.
Open Source Software has become ubiquitous in all major technology solution verticals for example
Mobile – Android
Cloud – Openstack, Cloudstack, Cloudera…
Big Data – Hadoop, MySQL, PostgreSQL…
Social – Cassandra, Drupal…..
Gartner predict “By 2016, Open Source Software will be included in mission-critical applications within 99% of Global 2000 enterprises.”
Outside of development departments there is little awareness of the obligations and risks of using Open Source Software components to build applications. These components can come from various places: Supply chain code, internally developed code, reused code, third party code, legacy code, proprietary code. Each component having its own attributes and obligations.
Similar to any third-party commercial software, organisations need to respect the licensing and copyright terms that govern how the OSS code can be used, address the security vulnerabilities that may be associated with the software, and abide by export control regulations if the used software contains implementations of encryption algorithms.
These obligations are commercial business issues and is why all software whether proprietary or open source needs to be treated as a business asset.
It is essential that every organisation create a clearly defined and well communicated Open Source Software Policy . This policy should be a framework and guideline for both internal and external software development teams to work within. Developers should be focussed on creating great software and not having to have the overhead of self governance. Eventually the policy should become part of the culture and avoid where possible risk being engineered into an application which may need to be expensively remediated in the future.
Once a policy is in place an organisation can then implement tools to discover and maintain what third party Open Source Software components and libraries have been used in the software development process and whether or not they comply with the companies Open Source Softwre Policy. There are free tools that can be used for this such as FOSSology or commercial offerings such as Black Duck Hub, Flexera Flexnet Code Insight and TripleCheck.