Open source policy

Introduction

Recently I was asked to weigh in about setting policy as it is related to the procurement and usage of Open Source based software. Specifically I was asked to research the issues, concerns and best practices surrounding the use of Open Source Software by State of Ohio agencies. Open Source Software represents a diverse offering of software in regard to functionality, quality, innovation, support and licensing. This diversity brings with it several issues which may be addressed through policy guidelines to mitigate some of the inherent risk.

Background

Open Source Software (OSS) is generally considered software which the source code is made publicly available through licensing vehicles that follow the Open Source Initiative (OSI) definition of Open Source[1]. Licensing generally allows for free redistribution, inclusion of source code, derivative works, non discrimination (human, endeavor, or technology) and expects continuation of equivalent licensing. According to Gartner, Inc. 80% of commercial software packages will include some element of OSS technology by 2012[2]. Currently the State has addressed some aspects of licensing of OSS for use by the State under ITP-A.26 which should be considered for inclusion or modification when moving forward with a standalone OSS Policy. ITP-A.26 section 9.7 deals specifically with acknowledgement of the unique licensing under OSS.

Currently very few states and only a few federal departments have attempted to enact policy and legislation directly related to the procurement, development and usage of OSS. Oregon and Massachusetts appear to be the most active in pursuing prominent OSS IT platforms. Self reporting shows that only 6% of US government agencies are using OSS across the enterprise while 39% report pilot and evaluation projects[3]. The largest endeavor so far appears to be the cross state agreement between the KS, MA, MO, PA, RI, UT, VA and WV who have stated, “The Government Open Code Collaborative is a voluntary collaboration between public sector entities and non-profit academic institutions created for the purpose of encouraging the sharing, at no cost, of computer code developed for and by government entities where the redistribution of this code is allowed.”[4]

Policy Considerations

  • Lower burden on procurement process. Low or No Cost license agreements create a situation where OSS components and systems could be brought in under minimum procurement guidelines. This lower burden on the procurement process would also remove an opportunity for enterprise level review of agency or department IT initiatives. Procurement of OSS should be considered within the more defined components of procurement governance to reduce the risk of unsupervised implementation.

 

  • Reduced Total Cost of Ownership (TCO). Low or No Cost license agreements along with some level of community development (could include internal agency interactivity or external state consortiums) and support greatly reduces the TCO. However mission-critical systems may still rely on strong vendor relationships which could negate some of the advantage to TCO. Data supports that TCO is between 15-35% less for OSS over closed source software.

 

  • Increased competition. While OSS does not provide true vendor independence it does provide for greater competition between software products. Software development can have a very high cost of startup in both capital and intellectual resources making the use of open source development much less burdensome. Consideration should still be given to vendor supported OSS however. Mission-critical enterprise quality software means that the vendor relationship may need to be maintained to mitigate risk because reliance on community support may not be reliable enough to complete vendor independence.

 

  • Development and training. Internal and combination internal/external development around open source standards creates questions about worker skill sets as well as administration and user understanding. By maintaining a policy of using open source standards the interoperability of systems and the repurposing of developers across the enterprise should be possible. According to the International Open Source Network (United Nations Development Program) there are currently training standards in place for the most widely used OSS and this should be a consideration during development and implementation of OSS systems5.

 

  • Maintenance, support, security and liability. Use of OSS can potentially increase the State’s liability risk as it pertains to maintenance, support and security. With no vendor under direct responsibility for these components the State’s liability rises. OSS development may include multiple flavors of a very similar base system. Version controls from original procurement through the lifecycle should be in place. As a component of reducing liability, documents tracking all changes made by the State or other related entities should become a permanent component of the software package throughout its lifecycle. Ohio IT Policy ITP-B.1 “Information Security Framework” should be considered in the development of OSS Policy; particularly section 5.1 which details Risk Management.

 

  • Licensing and Legal review. As an extension of the Risk Management component OSS usage may include multiple licensing requirements through the community nature of development which would include intellectual property (IP) and other rights that may have no sunset. Legal review should occur for all licenses attached to the OSS being introduced. States generally have greater protection over IP lawsuits than private individuals and organizations due to supreme court case 527 U.S. 666 (1999) aka Florida Prepaid. A document tracking the license requirements must become a permanent component to the software package throughout its lifecycle to protect against any possible infringement.

 

  • Shared resources. Use of OSS and related standards allows for ease of collaboration between independent organizations or even private individuals. Consideration should be made in respect to how government systems built under OSS licensing might be utilized by other entities and the associated risks that may bring to both the new user and the security of the developer.

 

  • Mandating, preferring or normalizing OSS. In an effort to provide greater government transparency, TCO savings and vendor diversity some states and national government bodies are mandating OSS standards or showing preference for OSS. The least controversial path is providing very limited policy to normalize the use of OSS instead of outright preferring closed source software and standards.

References

1. Coar, Ken 2006 “The Open Source Definition” The Open Source Initiative http://www.opensource.org/docs/osd (accessed 12.02.2008)

2. Driver, Mark 2008 “Key Issues for Open-Source Software, 2008” Gartner, Inc. http://www.gartner.com ID Number: G00155800 (accessed 12.02.2008)

3. Di Maio, Andrea 2008 “Government Survey Dispels Five Myths About Open-Source Software” Gartner, Inc. http://www.gartner.comID Number: G00154776 (accessed 12.02.2008)

4. Lewis, James A. 2007 “Government Open Source Policies” Center for Strategic and International Studies [CSIS] http://www.csis.org/component/option,com_csis_pubs/task,view/id,4663/ (accessed 12.02.2008)

5. Wong, Kenneth 2004 “Free/Open Source Software: Government Policy” International Open Source Network (United Nations Development Program) http://www.iosn.net/government/foss-government-primer/foss-govt-policy.pdf(accessed 12.02.2008)