Why open source:

“With the current economic downturn placing public finances under significant pressure, local authorities need to prepare for a more challenging future. In a climate of increasing budget constraints, councils are now facing inescapable demands to develop new and innovative ways to transform services, generate cashable efficiencies and deliver more for less.”

Public Sector Forum’s Survey of Open Source Software in Local Government[1]

Common Concerns:

The typical business models around Open Source Software (OSS) generate many procurement challenges when compared to the business model of proprietary software. Both can be useful types of software, depending on the context, but OSS typically lacks a sales team working overtime to understand, master, and win government procurement processes. Some of the most common concerns specific to OSS business models are detailed below.

We’re Not Sure What’s Out There:

For many government staff, the biggest concern is a lack of awareness of the OSS solutions that are available for their organization. Although a Request for Information (RFI) may be standard practice to discover better what solutions are available, sometimes the RFI process does not reveal an existing OSS solution.

A member of a large city IT team interviewed for this guide had related the following scenario. In this city, typically an RFI was issued, which would describe the software problem the city had, and for which a solution was needed. Vendors would then respond to the RFI and make suggestions for a solution, although these were typically solutions of software which the vendor themselves licensed. The responses could be skewed to what the vendors were capable of offering. Responses would rarely suggest an OSS solution because there is still a lack of awareness of OSS solutions by vendors.

Further, even if an OSS solution was known, there would frequently be mistrust that the OSS solution would not have all the features necessary to suit the need. However, staff in this city had adopted the following best practice to overcome this obstacle.

Because OSS is free to download and implement, given available staff resources, a suggested best practice is to implement an OSS solution as a test case first, then decide later whether or not to go with another product after all. The Civic Commons marketplace is a great first destination to discover what OSS solutions are available. Also, the Civic Commons Wiki has a list of OSS solutions as well as a list of other app catalogs on the web.

As an example of how to “test” OSS first, in the city of the staff member we interviewed, OSS solutions (such as Sugar CRM) would be deployed in a testing environment, and used for developing processes, workflows, and other content for customization to be entered into the CRM. Once this data had been developed in the cost-free OSS environment, the data was then exported and moved to another, proprietary platform. Thus, business/end users could have time to acclimate to using an online/web platform and stabilize their work process before having to contract to a vendor for support of the CRM platform. In one case, the business user became comfortable enough with the OSS CRM that a decision was made not to migrate to the proprietary product after all, and rather to continue using the OSS CRM.

Free Riders:

While not usually a deal-breaker on whether to proceed with an OSS development project, some of the overall value proposition of OSS was related to us by our interviewees as being lost by the perception that there is an unfair “free-rider” situation, where one government organization would be making contributions/changes to an OSS project that other governments would free ride on. However, this in itself would not prevent a government organization from pursuing an open source development option if the government organization feels it is the best solution available.

While the costs themselves don’t weigh against selecting an OSS solution, there is a lack of clarity about the value of what intellectual property (IP) is “being given back to the public,” and whether this IP could be more lucratively leveraged to offset costs or otherwise net income for the agency. To this end, the Civic Commons Wiki has a list of case studies about successful OSS deployments and their value to government.

Long Term Viability:

As related by one of our interviewees, the long term viability and prospects for further development affects IT staffs’ decision as to whether or not to procure OSS. It may come down to how much do you trust the people that are delivering the solution - the OSS community or the vendor that is developing the software.

There is a hesitation to implement OSS enterprise solutions out of fear that there might not be support in the event there are issues. Governments want to have a definite entity they can hold liable for remedies for failure or performance bonds.

To overcome these hesitations, it may be worthwhile to inform decision-makers that long term guarantees are not essential with OSS because, once the OSS application has been completed, tested and accepted, the OSS can be maintained in house or by any qualified consultant since the code is freely available. In contrast, with proprietary products, government must plan up-front and negotiate for the long-term to cover the expected use of the application over many years, and then be sure to have provisions in the contract with the licensor that provides long-term warranties, to protect the agency against such licensor actions as arbitrary price increases for maintenance and discontinuance of maintenance for the product with or without a replacement product. While proprietary software vendors are frequently willing to negotiate these issues, such willingness and the outcome varies by vendor, and the negotiations can be time consuming and require a knowledgeable and experienced negotiating team.

Regulations:

While there are several concerns over the business model of OSS which can be challenges to procurement, by and large, many of the challenges occur in the legal review of OSS procurement. In this way, typically, the first concern is ensuring proper adherence to procurement regulations.

What is the Policy or Regulation?

The amount of procurement policies in place within any one particular government organization can widely vary. From interviewing government staff both at the Federal level, and at the State and local level, it would seem that the Federal level has the highest number of procurement policies that must be adhered to. In contrast, cities usually have the fewest policies to follow, although for example, in the state of Massachusetts, procurement policies are in place which also must be adhered to, for certain circumstances for all cities within the state.[4] On the other hand, in some cities, new policies are difficult to put in place, and there are many oversight requirements to be met to create new policies. Therefore, some cities usually wait until a policy is ripe for development before creating a new policy.

The Civic Commons Wiki keeps track of policies and regulations as we learn of them. Be sure to check out our Wiki page on policies and regulations here for a full list.

Considering OSS in Procurement

Because procurement requirements for software are not triggered for cities where the expenditure comes under a certain amount, there is a perception that OSS that comes under a certain price point is “easier” to acquire.

However, sometimes OSS must be further developed to suit a government’s specific need, and services procurement can sometimes require a showing that services had to be purchased from outside labor.

One city staff member we interviewed related how a scope of services with a vendor that the city was drafting for customization to a CRM had to go before a city designated review group, which would question the purchase of services for its need to use outside labor vs. labor from the IT department. The underlying spirit of this policy was to protect city employees jobs. It would then be the task of the review group to identify IT staff capable of doing the proposed work, and the task of the city personnel seeking the vendor contract to argue that the identified IT staff would not be capable of completing the work to be vended. While typically the IT staff said to be capable of doing the work to be vended were in actuality not available to work on the project, convincing the review group of this fact was not easily accomplished. Thus, sometimes the mere requirement of an OSS product requiring additional service can present a hurdle to government.

Language for RFI - Request for Information, RFP - Request for Proposal or RFQ - Request for Quote

When the procurement cycle is active, even in an early stage, during the RFI, RFP or RFQ, the barriers to procuring OSS can be present. Here, the biggest problem is that language within the RFI or RFP can be unintentionally biased to solicit proprietary solutions only.

To this end, it is worthwhile noting that many Federal procurement regulation and policy statements, including the Federal Funding and Accountability and Transparency Act of 2006[6], the Strengthening Transparency and Accountability in Federal Spending Act of 2008 (not enacted)[7], the Federal Acquisition Regulations (FAR)[8], and the NASA Far Supplement[9], all require that OSS solutions are evaluated on equal footing with proprietary solutions in the procurement process.

There is legal recourse for violation of these regulations, at least within the Federal executive branch. Here, the adjudication of procurement regulations falls under the jurisdiction of the Civilian Board of Contract Appeals.[10]

Some states have their own procurement acts which also determine the authority or scope of local government procurement allowances. For example, the State of Massachusetts has a Uniform Procurement Act.[11]

While some procurement policies seek to ensure equal footing early on between OSS and proprietary solutions[12], other policies, enacted by states and local government can have different aims.

The Civic Commons Wiki has a list of various government organizations and their respective open source policies.[13] These policies have ranged in nature. Some policies go beyond requiring a fair comparison, to requiring that if OSS is not used, that an explanation be given why an OSS solution was not adequate, such as is in place with the Department of Defense.[14]

Many procurement regulations and policies require that OSS solutions are considered alongside proprietary solutions. But, given the differences in the business model between open source solutions and proprietary solutions, it can be unclear how to adequately evaluate an OSS solution.

To this end, scholar Dr. David Wheeler has drafted a guide on how best to evaluate open source software while still adhering to procurement regulations.[15] During the course of our interviews with government staff, we learned that the Wheeler guide has become the suggested guideline for at least one regional transit agency in the U.S.

Dr. Wheeler sets forth in his guide a set of criteria that any OSS solution should be evaluated by in order to reduce risk in the use and support of the software, and to minimize the expense of any services that may need to be procured for support of the software. His set of criteria include:

• market share
• support options
• maintenance/longevity
• reliability
• performance
• scaleability
• useability
• security
• flexibility/ customizability
• inter-operability
• legal/license issues
• other issues

Public Records Laws

Finally, while not being procurement regulations, public record laws can have a significant effect on procurement of OSS.

For instance, some states have a public records law which requires that all public records are archived so that they may be served when someone makes a public records request. This law does not apply to student data or health data. Because this law must be met, at least one of the city staffers we interviewed related that due to the public records law, the city views some cloud services, such as Google docs, where the city does not have control of the data to be archived, as a potential legal liability. However, use of these tools is not prohibited, and the city tries to maintain flexibility of these tools while still adhering to the law. One of the strategies for legal compliance is to keep local copies of Google docs.

In the Federal sphere, the Freedom of Information Act (FOIA) can present interesting challenges when FOIA requests are made for federal software. This issue is discussed further below in the context of disclaimer of liability in software licenses during a code release.

Request for Information / Request for Quote Issues as they impact the Contract:

Misunderstanding of the Contract based on poorly written RFP

Procurement scholars have suggested that a well written specification in the RFP can lead to a better, more successful contract.[17] Thus, a first starting point for greater success in procuring open source can begin with the RFP drafting.

Vendors who respond to spirit of RFP and respond “honestly” may bid at a higher price, so there is a perverse incentive to narrowly interpret an RFP and bid lower.[18]

Best Practices:

In a standard RFP or contract, a government can state that they will have final say for acceptance of a developed piece of software. Thus, if the city is not pleased with the result then they can refuse to pay. This helps to overcome any discrepancies between what a government wants in their software, and what actually results as a finished product.

One of the city staff we interviewed for this guide related how sometimes the RFPs generated by their city contained ownership language, but most of the time, the city did not focus on ownership of code. Rather, the city was more focused on price. This city staffer related how their city was unlikely to fight a vendor if the vendor wants to keep ownership of the code.

Another city staffer we interviewed noted though that if a city were to push back and request ownership of the code, most of the time the vendor would not fight back, and would agree to the city ownership of the code. According to this interviewee, most vendors just want your business above all else, and are willing to negotiate. It should be noted however that the time to negotiate is when verbal discussions with a vendor are being reduced to writing. It was related to us by one of our interviewees that the government organizations have the most bargaining power before the contract is signed.

Although RFPs can be better drafted to preemptively address legal hurdles in procuring OSS, because the contract is the binding document between a government and vendor services, the process of drafting and executing a contract for OSS support or development services is usually where most of the legal hurdles are presented.

Contract Issues:

From the OSS Business Model Flows Contract Requirements

OSS itself does not cost money to download, deploy, or extend development on. However, if there are no in-house support staff capable of deploying or developing an open source application, then government can turn to a supporting vendor for these services. It is typically at this point in the open source procurement timeline that contract issues are introduced.

Where there is an OSS project that doesn’t have a commercial support offering either in deployment, configuration or development, a government organization is not likely to choose that solution. Cities need the assurance that there is someone they can call if something breaks with their software solution.

Sometimes, the problem lies with the operations group within a government organization, because they may refuse apps developed in house for various departments on the basis of not wanting to assume administrative responsibilities. Most of the administration may be merely configuration changes. Therefore, because of an inability to scale operations staff, at least a support contract would need to be made for any OSS deployments.

Assuming though, that some outside services will be needed for acquiring and deploying an OSS solution, what services will be needed, and the potential risks associated with these services may be the first step to consider regarding drafting a contract.

Risks to Consider When Drafting OSS Contracts

An expert interviewed for this guide had the following insights regarding the risks associated with various OSS support vendors:

• What part the OSS license itself has in protecting against risks from support vendors:

An (approved) open-source license guarantees legal use in perpetuity of the software being licensed; however, it does not guarantee that a licensee can achieve or sustain effective use. The owner of the intellectual property has the right to change the terms of the licensing going forward, and even to sell the intellectual property involved. Under an approved open source license, any new restrictions by an owner cannot be made retroactive, so the participant cannot be denied access to the code delivered prior to the change; however, it can be comparatively easy for an owner to make subsequent changes to the evolving code-base that will render the earlier code obsolete or effectively unusable. Coordinated community action (e.g., continuing to develop the “original” code-base independently) may prevent this strategy from succeeding, but coordinated community action is not always a feasible response.

• Suggested best practice: inspect vendor ownership terms of software

For governments considering open-source software, the expert we interviewed suggests to inspect carefully the ownership terms of the software, and assess the risks that the ownership model creates. In the experts opinion, from the perspective of risk-mitigation, projects owned by viable nonprofit organizations created specifically to own and govern the intellectual property (e.g., the Mozilla Foundation, the Eclipse Foundation, the Kuali Foundation) present the lowest risks of loss-of-access. OSS projects which are owned by a single individual or for-profit firm present the highest risks. (This risk should not be confused with the risk of failure of the project, which is another, separate matter.) Size of the owning organization may or may not matter: acquisition of a (small) firm usually implies transfer of ownership (except in cases where antitrust is an issue), but large firms can sell intellectual property, too. Nonprofits having the mission to govern and protect a corpus of intellectual property are far less likely to sell that corpus than is any for-profit firm—but nonprofits whose mission has nothing to do with conserving a particular piece of software are inherently neither more nor less likely to sell than any other type of organization.

It should be noted that actual cases of bad outcomes from the sale of open source intellectual property are difficult to find and document, especially in high-visibility open source projects. However, while the probability of harm may be low, the magnitude of harm is potentially large. The highest-risk project types—single-owner, single-vendor, commercial OSS projects—are seldom highly visible or widely successful (a lack of success which may, in turn, reflect awareness of the risks among prospective users). This makes them less-attractive targets for purchase, but does not reduce the size or scope of potential damage to their users if a purchase does take place.

Perhaps the most widely discussed, concrete example of this problem is counter-factual: it concerns the open-source software Zimbra, a competitor to Microsoft Exchange Server that was developed by a commercial OSS firm and later sold to Yahoo!. During the period when Microsoft was attempting to acquire Yahoo!, industry sources speculated that Microsoft would “kill” Zimbra upon obtaining ownership of its intellectual property, using positive and/or negative incentives to force Zimbra users out of the software and (presumably) into Microsoft’s proprietary product. For many users, this would have been an expensive, organizationally wrenching transformation. Because the Yahoo!-Microsoft merger never took place, the discussion remains speculative, but it suggests the potential seriousness of the problem.

Therefore, before beginning to draft a contract for vendor services with an OSS solution, it is important to consider what kind of vendor or organization you will be contracting with, and whether their organization model is adequate or sufficient for the anticipated viability need for the OSS solution.

One way to ease the contracting process overall is for government staff to build a relationship with the reviewing attorneys which is consistent and nurtured. This methodology has worked at least in one major city interviewed for this guide. In the city we interviewed, the IT department has its own group of lawyers that work with that department only. In this way, the IT staff always works with the same lawyers and an efficient and trusted relationship evolves. Further, the set group of lawyers come to understand the relevant contracting points for the technologies that the IT department outinely procures. Any lack of understanding about the technical requirements could often be left unaddressed, as the attorneys would develop a trust for the personnel they were working with.

Choice of law/venue issues

One of the government attorneys interviewed for this guide, related that government organizations typically want venue for litigation purposes and applicable law to be the state where the organization is located. Most shrink-wrap proprietary licenses have venue and applicable law provisions in a different jurisdiction. While shrink wrap agreements are usually perceived as not-negotiable, licensors will sometimes negotiate the venue and applicable law provisions. Typically, for negotiating shrink wrap, the attorney advises the procurement staff on what needs to be changed, and then the procurement person calls the licensor and negotiates with the licensor to change the license. These negotiations are with the licensor, even if the purchase is being made from a reseller.

Who Owns the Content

Without explicit provisions in a development contract, there can be uncertainty by a support vendor as to whether content of an OSS content management system will be open sourced. While there might be an understanding that the code will be kept freely available, the contract is silent regarding explicitly what parts of the code will remain or be open source, and rather might state only that the city agency retains ownership of any developed code.

Indemnity clauses

Generally, cities use a broad indemnity clause which intends to cover IP indemnities also.

When there is a software developer, the government requires, and the developer usually provides broad intellectual property warranties and indemnification for intellectual property infringement claims. The warranties include warranties that the developer has the right to do what it is doing and the agency has the right to use the application for its intended purpose. On rare occasions the developer may indicate unwillingness to give full indemnification (for example, if there is a known Patent Non-Practicing Entity (NPE or “troll”) in the field) - and the negotiations have to deal with that problem in the context of how the agency views the risks involved and how it wishes to deal with them.

However, sometimes cities have a certain required amount of indemnity specified in their boilerplate contract, which may be significantly higher than what a small, OSS support vendor is able to negotiate. A request from a city for the vendor to increase their liability insurance may incur long delays since it may actually require the vendor to switch insurance providers. Therefore, cities may consider changing the required indemnity necessary, or otherwise tailoring the language in the indemnity clause such that a high amount is not necessary.

One of the government attorneys interviewed for this guide related that an indemnity cap is typically a negotiated multiple of the fee paid to the developer for its services. Exclusions from the cap can be negotiated for such matters as third-party tort and infringement claims and indemnification.

Regarding whether an indemnification clause would cover violations to a Gnu General Public License (GPL), an attorney that we interviewed, experienced in open source issues related that indemnification clauses are often broad and could cover open source license violations but are a last resort remedy, especially given that enforcing an indemnity agreement is expensive. One such instance where the indemnification clause may not help a GPL violation is where the GPL would be asserted by the copyright holders to stop the distribution of the binary (compiled) software, when source code is not also being distributed. In this situation, the government would have to sue the vendor for damages and in addition, would not be able to distribute the software (client software). For web interfacing software, under the GPL, no distribution of source code is necessary.

For infringement of Intellectual Property (IP)

Issues of GPL compliance lie in the fact that the GPL (and all copyleft OSS licenses) are empowered by copyright, wherein copyrights are granted subject to certain conditions. Indemnity clauses in government contracts, while traditionally applicable towards personal injury or tort, are now increasingly being scrutinized for their protection of IP infringement. Author Simon Phipps has written an article regarding IP indemnity in open source contracting.[21]

Some small vendors cannot indemnify for patent infringement, and a government organization may want to consider the risk of being sued accordingly before requiring such indemnifications. That is, they may want to consider if there is an active “Non-Practicing Entity” active in the subject matter of the OSS to be procured/developed.

One of our government IT staff interviewees related that many cities do not require “mutual indemnity” and will accept “hold harmless” indemnity language.

Issues with Contracting in App Contests:

Sometimes contracting concerns regarding open source occur in contexts where the government is not even procuring software, but is a host for say, an application contest. As an example, with one city we interviewed, regarding an app contest to be hosted by the city, the city lawyers had the following concerns over publicly developed apps being built on top of a city provided API:

• What were other cities (or what had other big cities in the past) used in terms of verbiage, contractual language for similar kinds of API based app contests? (Terms of Use). The attorney was interested in the terms of use used previously in app contests hosted by other large cities. The city IT staff person would identify samples from other cities, and map back the understood goals of the present API app contest (as described by city staff) and try to construct a custom terms of use for the city.
• Trademark issue: the city attorney provided language in the terms of use that required developers to disclose in the apps they built that their app was not sourced from the government, but was a product of the vendor/developer. Therefore, the citizen using the app would understand that by using the app they were engaging with a private vendor application, and not engaging with the city.
• Restriction on Distribution of Data: The terms of use prohibited information gathered in the application from being sold for commercial use or spam.
• Offer and Acceptance Best Practice: Developers would commit themselves to the terms of use by clicking “I agree” in order to receive an API key.

Terms of Use For Government:

• Example terms of use from a web platform with Government clients: MeasuredVoice.com Terms of Service and Blog Post on the Creation of these terms of Service

Copyright Infringement Issues —————————–

Copyright issues can arise merely from the content that exists on a content management system. A city staff member we interviewed related that they do receive on occasion take down notices under the Digital Millennium Copyright Act (DMCA) for inadvertent posts to city websites of copyrighted material. To this end, Creative Commons has a page on their wiki about use of Creative Commons by government.[32]

Best Practices: Copyright Policies in use by government:

Some government organizations have been proactive in terms of setting forth in advance the licenses that should be used with copyrightable material. For example, the policy of the Commonwealth of Virginia authorizes agencies to use Creative Commons and open source licenses for their work.[33]

However, official policies regarding the licensing of copyrightable material have been more prolific abroad. For example, Australia’s Official Gov2.0 Policy[34], and the New Zealand Government Open Access and Licensing Framework[35] set Creative Commons as the default license for government works.

Further, the UK Open Source & Open Data Licensing[36] - sets the Open Government License as the default license for government created work, but allows government to maintain native open licenses for existing works they contribute to. The OGL is meant to be interoperable with any Creative Commons Attribution License and Open Data Commons Attribution License, which covers database rights and applicable copyrights.

Copyright the OSS license Hurdle

Aside from any copyright liability via the content on a website, copyright liability can also be introduced via an OSS license.

OSS licenses have been perceived by at least one government attorney we interviewed for this guide to be easier to deal with contractually than a proprietary software development project. There is no need to negotiate the software license and most of the significant issues that would be important for a proprietary software license are avoided. Further, chapter 19 of the book Perspectives of Free and Open Source Software[37], entitled “Legal Aspects of Free and Open Source Software,” discusses in great detail the copyright issues with OSS licenses.[38]

What OSS Software licenses mean to government procurement (GPL3, Apache)

OSS software licenses can have several implications for government procurement. OSS licenses operate by assuming copyright ownership by the party granting rights under the license, but the Federal government cannot hold copyright for works created by Federal employees in the course of their employment.

As an example of the problems surrounding the prohibition of the Federal government from holding copyrights, the Veterans Administration’s Vista software - was written by government employees, so the government could not copyright the software, but enhancements to software constituted a derivative work allowing for copyright. There is a loophole in the prohibition against the U.S. government holding copyright, and that is, that the U.S. government can be assigned to an existing copyright.[39] So for example, in the case of the derivative Vista development, the third-party vendor can assign copyright back to the U.S. so that the U.S. can then have copyright over the software.

Further, it is worthwhile noting that while U.S. government cannot hold copyright in the U.S., they can hold copyright outside the U.S.

Non-Negotiability of some Open Source Licenses

When contracting for development work on OSS, it is important for government staff to note that the work for Hire boilerplate conflicts with Open Source derivative work (distribution of “fork” code) requirements.[40]

Some concerns of OSS licenses are with interoperability issues - as it pertains to deployment dependencies.[41] This can include interoperability with hardware as well.[42] However, scholars have dispelled the myth that GPL licensed software cannot, under the terms of the GPL, be interoperable with proprietary software.[43]

While copyleft GPL requires end users and developers to abide by certain requirements, as compared to proprietary licenses, the users still have significantly more freedom of use.[44]

Specifically, the GPL, has requirements for code distributions which can affect procurement. The GPL requires that for any code licensed under GPL, modifications to the code must also be available as a source distribution. Therefore, it is important that the procurement process includes requiring the vendor to identify all of the OSS that they used in making the deliverable, whether and how the GPL code was modified, and have a source package corresponding with the modifications.

In addition to the standard OSI approved licenses, some government organizations have undertaken creating their own open source licenses to suit their individual organization’s needs. This practice however, has not always been successful, and generally is advised against. However, some of the specific reasons why organizations were interested in creating their own licenses include:[45]

• The omission of a “law selection” clause in most open source licenses when most government procurement regulations require the application of local state law or federal contracting law to the material terms and conditions of any contract.
• The omission of a “venue selection” clause in most open source licenses when many state and federal procurement regulations require that disputes be resolved in particular venues.
• The lack of a “government rights” provision in open source licenses which clarify that software is “commercial software” and thus not subject to rules of federal procurement that may require an assignment of rights to the software when the government funds development.
• The lack of a waiver of “sovereign immunity” in open source licenses to actually make the licenses meaningfully enforceable.
• The lack of a “march-in rights” provision in open source licenses that may be required by federal procurement regulations for software development.
• The need to be able to edit a license (which is forbidden for certain open source licenses), to include provisions necessary, for example, to include certification assurances necessary for adoption by certain government entities, such as election committees which may require a warranty of certain stability in the code and a rigid version control process.

Tort / Injury Liability Issues:

Finally, as government entities are very risk adverse, there are no areas of law that government attorneys wish to ignore in their comprehensive risk analysis of procuring open source. Thus, typically broad indemnities are desired when contracting.

A government legal staff member interviewed for our guide related how broad indemnity includes personal injury, bodily injury, and tort claims generally. This is usually not a major issue with OSS procurement and is dealt with through indemnification and insurance provisions.

However, it is believed by some OSS legal experts that no bargain is formed typically with a GPL license, therefore, no duty of care if owed – further, the GPL has a disclaimer of warranty for harm caused by the GPL’d code.

Security Concerns

Personal data risk can be overcome with a security audit. Typically, security is fine behind a firewall - whether it is FOSS or proprietary. However, security concerns from security staff in a city IT department can often signal some other concern about the deployment, and not necessarily a security concern.

Many in the OSS community believe that OSS may actually be more secure because with more “eyes on the code” the odds of catching security holes are better. Further, when contractors working with government are altering code, it is better to have the code available for community review since many contractors are not adequately trained, and inadvertently open security holes.

Additionally, OSS experts have opined that OSS is not more secure simply because it is open source. It depends more on the community (both good and bad actors) around the software.[46] Somethings to consider regarding the security vulnerability of OSS due to its exposure are are:

• How likely is someone to be looking at the code?
• How easy is it for people who care to fix existing vulnerabilities?
• How likely is there to be a bad actor who would have an incentive to exploit a security issue? There are situations where clearly “security through obscurity” as employed in proprietary code can be very harmful. One such example is with voting machine software. Because voting is a government function closely tied to citizens’ rights and liberties, security through obscurity through a proprietary vendor is especially harmful.

Best practice for mitigating security risk:

One of the government staffers we interviewed had told us about a tiered approach used in their city to ease security risks and exposure. This methodology consists of:

• Take all of the systems in place, and assign risk levels (privacy risk) by understanding risk level.
• For the least risky systems use OSS or deploy the software in the cloud. Like Wordpress - which is mostly content, and thus, less risky, should be able to be hosted in the cloud. That is, Wordpress is not detrimental to peoples health if it goes down. Thus, low risk apps should be deployed first so you do not have to deal with privacy issues. For riskier applications such as Public Safety apps - wait until safety issues with the lower risk apps are known first, then begin a strategy to deploy higher risk apps like Public safety apps.
• Further, government IT staff can leverage checks already in place to avoid security liabilities
  • While OSS may be free to download, staff at the agency do not have the permission to install software on their desktops. Therefore, IT staff must be consulted at least for security access for installation purposes.
  • The desktop installation access may be locked down to prevent illegal copies or unlicensed copies of proprietary software from being installed on agency computers. In order to allow the installation of the OSS software, the Project Manager can be required to produce the OSS license to the IT staff in order to prove that the software was indeed, a free license.
  • Some downloading of software is blocked by firewalls, but the purpose behind these lockdowns is not related to procurement.

References