If you search the Internet for "open source geospatial," you will find a wealth of information about free and open source software (FOSS) for geospatial applications. This mirrors a clear trend in the broader IT industry, which points to an explosive growth in the use of open source software. According to a recent survey by Gartner, the amount of open source software in the portfolios of responding organizations is increasing, from less than 10 percent five years ago to an expected more than 30 percent by 2012 (EE Times article: “Open-source software increasingly part of IT strategy to gain competitive advantage”). The abundance of open source software for geospatial applications presents significant opportunities for organizations to reduce costs and gain competitive advantage. However, as I pointed out in part one of this series, the nature of open source software introduces intellectual property risks that need to be properly managed. Management of such risks is not a very complex matter and it should not deter organizations from adopting FOSS.
Risk protection can be implemented through a well-structured open source governance program. Such a program establishes the policies and procedures that govern the acquisition, usage and distribution of open source products and components. A preliminary step to creating a governance program is to articulate a company open source strategy. The strategy defines the overall scope, goals and objectives for a company to adopt, to contribute to or to create open source software. As an example, some companies may use open source simply to reduce development costs while maintaining a low profile; others may embrace open source as an integral part of their business and marketing strategy. Esri, ERDAS and 1Spatial fall into the former category and Refractions Research, OpenGeo and LISAsoft are representatives of the latter.
Before I describe the elements of an open source governance process, let me point out that the intention of such a program is not to introduce a burdensome bureaucracy and restrict creativity. As with most policies, the implementation needs to be adequately adapted to the size, maturity, culture and strategy of the organization. A typical approach to open source governance involves the following: (1) creating an inventory of open source software already in use in the organization, compliance review of each item and remediation - if necessary; (2) establishing an acquisition and distribution process; (3) establishing guidance for community participation; (4) implementing a process for internal audits.
The first element or discovery phase can be very simple for small organizations which make limited usage of FOSS, however, it may become quite complex for large organizations where usage of FOSS is pervasive. In the latter case, an automated open source scanning tool or a service may be used. These are offered by a number of companies (both proprietary and open source). As an example we can mention Black Duck Software, OpenLogic and Fossology. Some scanning tools search for FOSS installed in a machine at a binary level while others do pattern matching at the source code level. Depending on their level of sophistication, source code scanning tools can discover license text or even find code fragments that have been copied from open source files. Once the FOSS usage has been established, a license review needs to be conducted to assure that license obligations are met. If violations are found, it will be necessary to create a remediation plan. In many cases, remediation can be straightforward. For example, in the case of a software vendor, failure to provide appropriate copyright and disclaimer of warranty notices, as required by some FOSS licenses, can be easily resolved. In other cases it may a bit more involved. For example, a component library may need to be replaced with a similar library in order to resolve issues associated with license obligations (again, we refer to part one of this series).
At the heart of a sound open source governance policy is the acquisition and distribution process. This involves software selection (see my article titled “Selecting Open Source: a Practical View”), validation and approval. Validation consists of reviewing and understanding the software license terms and obligations and determining that they are consistent with the intended usage. There are many different ways to implement the validation process. An implementation often recommended is to establish a review board with formal policies and procedures. The review board is the authority that approves usage of FOSS products within the organization. In many organizations this process can be streamlined, but it is important to involve at least a review by an individual knowledgeable of FOSS licenses and supported by legal counsel if necessary. Once software has been approved it can be entered into a repository of approved software for subsequent usage and distribution within the organization. This process is not unlike the management and internal distribution of proprietary software. In the case of software development organizations, this repository can also serve the purpose of FOSS configuration management of the organization’s standard FOSS stack.
Community participation is a key component of the open source model. As organizations adopt FOSS it is important that they articulate guidelines for employee engagement with the community. These guidelines will depend on the overall corporate strategy for FOSS adoption. Many companies will find beneficial the active participation of their employees in open source projects as developers, testers or actively providing end-user feedback. Other organizations may be reluctant to do so for a variety of reasons. Regardless, it is important for employees to understand the company policies in this regard.
Like most processes, once the open source governance program is in place, it requires periodic review and continuous improvement. Periodic audits and compliance review are necessary; otherwise the process sustainability is placed at risk. For organizations that distribute software (ISVs), an open source compliance validation step should be an integral part of the development process (in the test and quality control phase, for example). This will assure that the software meets the appropriate license obligations.
In summary, the risks involved in FOSS adoption can be mitigated through a well-formulated and properly implemented policy. Such a policy will involve various aspects related to the acquisition, usage and distribution of FOSS components. These should be consistent with the overall corporate FOSS strategy. It is fair to say that the burden of such a process is light compared with the benefits of FOSS adoption. For further information on open source governance, I recommend FOSS Governance Fundamentals by Hewlett-Packard and Nine Ways to Protect Your State from the Legal Risks Posed by the Use of Open Source Software by Linda M. Hamel, Commonwealth of Massachusetts. The latter reference focuses on the government perspective, however it is also a very informative source in general. Open source governance, consultation, tools and guidance can be obtained from the vendors mentioned earlier and others (Protecode or Palamida, for example).