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.

**Total Costs & Hidden Costs:** Generally, while open source software is free to download and use, government organizations may have to procure development services to add further desired features to the software. Additionally, if there is not enough in-house staff to support the operation of the open source software, the operation services may have to be procured. At least one of our interviewees related that procurement staff are comfortable with proprietary software licenses that are expensive, but scrutinize development labor costs on an OSS project much more closely. There is a tendency for any labor related expenses to understand better the exact kind of labor that is being done, and the itemization of this labor as it is being charged per hour. Accordingly, one way to overcome this misperception that OSS is somehow less legitimate because its expenses are incurred in labor rather than licensing, is to provide city staff with well researched and written explanations which set forth the full benefits of the OSS business model. In this way, agency lawyers, procurement staff, and management can clearly weigh the benefits of open source development against the labor costs.[2] To assist technology decision-makers in understanding the expenses of OSS as compared to a traditional Commercial Off the Shelf (COTS) product, The MITRE corporation has drafted a Business Case Study of Open Source Software. [3]

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.


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.

**Does Downloading of OSS Trigger Procurement?** While in theory, the downloading and implementation of an OSS solution may be viewed as a circumvention of the traditional procurement process, and the cost benefit reviews that may be performed therein, generally speaking, as related by the U.S. government staff interviewed for this guide, the downloading of OSS does not trigger procurement process requirements. However, there have been concerns over ensuring that proprietary software and open source are considered at the same time while procuring software, and to the extend that open source is preferred because it is free, at least in Europe, procurement requirements may be triggered by merely downloading OSS.[5]

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]

**Best Practices for Complying with Procurement Regulations**

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
In the aforementioned OSOR guide is provided suggested language for governments to put in RFPs in order to receive the most effective government tech responses (be they OSS or otherwise).[16] Some of the key points raised in this guide are: - Procurement should be based on functional requirements not on specific products or vendors. - Do not simply state that software should be Open Source - rather, the properties of open source software should be described and justified. - The ownership of the software should be transferred to the public agency, with no restrictions on what the agency can do with the software. - The software may be used for any purpose as the public agency does not want to be restricted in how it can use (or allow others to use) the software. - The public agency or a third party of its choice may study the source code as the public agency wants to be sure of the functioning of the software; alternatively, the public agency may require that any member of the public can study the source code, in order to promote transparency of government processes, or enable other parties to provide support and training associated with the software. - The public agency or a third party of its choice may modify the software as the public agency does not wish to be dependent on the original vendor for bug-fixes, adaptations and other modifications. - The public agency can distribute the software, with source code and modifications, to anyone of its choice and provide recipients with the same abilities to use, study, modify and redistribute because the public agency needs to ensure that citizens and firms and other agencies that access its services using the software or variants of the software do not need to become customers of the original vendor in order to do so; for example, a national administration may wish to be able to pass on the software, without extra costs, to other administrations at the local, regional, national or European levels.

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.

**The Typical Contracting Context** In most government organizations, the customary contracting context regarding procuring open source is with a software project supported by a third party vendor. Some governments have recognized the potential in reuse of standard terms and conditions, and to that end, have endeavored to develop a standard set that can be shared. South Carolina has been developing a set of terms and conditions that other states could use. Further, the state of Oregon has won an award for terms and conditions that they have developed. The standard Federal template indemnifies government entirely, which absolves at least in theory, the Federal government from any liability. But the award winning Oregon terms and conditions have endeavored to be more risk balanced. The zero risk indemnity provision in the Federal template, has tried to been adopted by State governments with adverse effects. One of the civic entrepreneurs we had interviewed for this guide had related that experienced contractors will choose not to respond to RFPs if they know they will be burdened with the full risk. Therefore, inexperienced vendors willing to take the risk will win the bid, and because of their inexperience, usually do a poor job performing on the contract. Aside from state government organizations such as Oregon, and South Carolina[19], academic organizations have also been working to collect and standardize terms and conditions used in common and customary contracting contexts. In the education space, Contract Commons, a project housed by the New York Law School, has sought to curate standard contract clauses in the procurement of educational software and technology.[20] Although legal issues can arise in any number of circumstances where OSS or open data is in use with a government organization, the focus for the rest of this section will be on issues to consider regarding the terms and conditions of the contracts drafted between government and a support vendor.

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:

Patent Infringement Issues -------------------------- Software patents have always incurred heated debate in the OSS community and within the patent bar. Popular culture has recently taken notice to the dilemma of Non—Practicing Entities with some of the more aggressive suits surfacing as of late.[22] Further, recently passed patent laws offer at least some interesting, albeit industry specific, provisions providing some protections against exploitation by Non-Practicing Entities.[23] However, if faced with a lawsuit from a non-practicing entity, there are some pro-bono legal resources available to consult with. Some of these resources include: - Public Patent Foundation - Local area law school clinics - The Electronic Frontier Foundation (Patent Busting Project) One of the OSS legal experts we interview related that patents are written for lawyers, and generally are not in a language accessible for engineers, and technologists. Any technologist who may be trying to read patents to understand what technology to avoid will have difficulties understanding what exactly the patent is claiming, and further, may be exposing themselves to willful infringement in that if they do wind up infringing on a patent, by having read it, they could be held as being “willfully infringing.” Additionally, there are a lot of meritless patents, and the legal expert we interviewed related how there is no way to know if a patent is valid (and one you should avoid) until its been subject to challenge in the courts. Therefore, it may be that the best course of action regarding potential patent infringement is not to try to read a patent and make a determination on your own. Either seek legal counsel for review of code, or do not attempt to do a patent search at all, given the likelihood that a layperson would misinterpret a patent anyway. It is worthwhile noting that notwithstanding the protections afforded under sovereign immunity, there are other Constitutional arguments that could be set forth to defend a government being pursued by a patent non-practicing entity. Although typically required for tangible inventions, one could argue that infringement damages against an innocent party are forfeited when notice of an existing patent on a particular business method was inadequate.[24] Of course, if a government organization does find itself accused for patent infringement, there exists several legal recourse options including Inter-partes Reexamination[25], and litigation[26]. Additionally, government organizations can take preemptive measures such as requesting a Declaratory judgement[27], or defensive patenting which includes filing a patent on government technology and cross-licensing - DPL (Defensive Patent License)[28]. **New Patent Law in Effect - The Leahy-Smith American Invents Act** New sections 35 U.S.C. 321-329, provide for a new procedure in fighting back against meritless patent infringement accusations. The procedure is called a "Post-Grant Review" and can be filed by a third party (someone other than the U.S.P.T.O. or the inventor/assignee), but must be filed within nine months of patent issuance or reissue issuance.[29] In the open source software space, business method patents pose a threat of infringement. To this end, the new patent law provision, Public Law 112-29 Sec. 18, entitled "Transitional Program for Covered Business Method Patents," starting in September 2012 provides a specific transitional program for entities sued for infringement of business method patents. The new procedures will not be available until September 16, 2012, but they offer an effective way to counter infringement claims. Aside from when the new procedures will be available, there are several other important dates that must be met in order to qualify for the Transitional Program for Business Method Patents.[30] Like any entity operating on a fixed budget, many government attorneys will consider the costs of each strategy when faced with a patent infringement suit. It should be noted that exploitative Non-practicing Entities will typically try to settle with a government organization for less than what the cost of the lawsuit would be, and accordingly the business model of exploitative non-practicing entities is based upon some likelihood that a government organization will choose to pay a license rather than fight a meritless case. For new procedures like the Transitional Program for Covered Business Methods, the cost of implementing one of these procedures can only be predicted. Many practicing attorneys in the intellectual property field will refer to the AIPLA's Economic Survey report to learn what the predicted costs are.[31]

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.


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

[2] See Section 4, “Why Would Governments Use or Create OSS in their Acquisitions?”

[3] 1

[4] State of Massachusetts Uniform Procurement Act (followed by all cities in MA). http://www.malegislature.gov/Laws/GeneralLaws/PartI/TitleIII/Chapter30B

[5] OSOR OSS Procurement Guide - Appendix B.2.1 - Acquiring OSS “Without Tenders.” http://www.osor.eu/studies/OSS-procurement-guideline-public-final-June2010-EUPL-FINAL.pdf/at_download/file

[6] Federal Funding and Accountability and Transparency Act of 2006. http://en.wikipedia.org/wiki/Federal_Funding_Accountability_and_Transparency_Act_of_2006

[7] Strengthening Transparency and Accountability in Federal Spending Act of 2008 (not enacted)[http://thomas.loc.gov/cgi-bin/query/z?c110:S.3077.IS: http://thomas.loc.gov/cgi-bin/query/z?c110:S.3077.IS:]

[8] Federal Acquisition Regulations (FAR). https://www.acquisition.gov/far/

[9] NASA Far Supplement (see 1852.227-14 Rights In Data–General). http://www.hq.nasa.gov/office/procurement/regs/5227.htm

[10] Federal Executive Branch contracts via the Civilian Board of Contract Appeals. http://www.cbca.gsa.gov/

[11] State of Massachusetts Uniform Procurement Act (followed by all cities in MA). http://www.malegislature.gov/Laws/GeneralLaws/PartI/TitleIII/Chapter30B

[12] San Francisco City/County Software Evaluation Policy (mandates OSS to be evaluated equally with other software solutions). http://www.sfcoit.org/index.aspx?page=616

[13] Open_Source_Policy http://wiki.civiccommons.org/Open_Source_Usage_Policies

[14] Policy Statements from Department of Defense. http://cio-nii.defense.gov/sites/oss/

[15] Evaluating Open Source Software for Procurement. http://www.dwheeler.com/oss_fs_eval.html

[16] OSOR Guideline on public procurement of Open Source Software http://www.osor.eu/studies/OSS-procurement-guideline-public-final-June2010-EUPL-FINAL.pdf/at_download/file

[17] A specification is art and Science. http://www.training-management.info/Procurement/Getting-the-Deal.htm#X2

[18] Procedural Rules and Procurement Regulations: Complexity Creates Trade-Offs, Shane Greenstein, Journal of Law, Economics, & Organization, Vol. 9, No. 1 (Apr., 1993), pp. 159-180. Abstract available at: http://jleo.oxfordjournals.org/content/9/1/159.extract

[19] The National Association of State Procurement Officials (NASPO) in particular is interested in standardizing procurement terms in state government IT procurement. They released this whitepaper in 2010 on the topic: Comparative Review of State IT Procurement Practices(September 2010), http://www.naspo.org/documents/NASPO_IT_Procurement_Whitepaperfinal2.pdf

[20] Contract Commons. http://dotank.nyls.edu/contract-commons/

[21] Blog post by Simon Phipps. http://opensource.com/law/11/2/open-source-procurement-indemnity

[22] “When Patents Attack” - NPR, This American Life program. http://www.thisamericanlife.org/radio-archives/episode/441/when-patents-attack

[23] http://www.govtrack.us/congress/billtext.xpd?bill=h112-1249

[24] Findlaw article on notice requirement generally. http://library.findlaw.com/2002/Dec/19/132442.html

[25] Gene Quinn on Inter-partes Rexamination - http://ipwatchdog.com/2011/07/06/inter-partes-reexam-under-utilized-patent-litigation-defense/id=17984/

[26] “Slaying the Patent Troll” Jason Rantanen- SANTA CLARA COMPUTER & HIGH TECH. L. J. http://www.chtlj.org/sites/default/files/media/articles/v023/v023.i1.Rantenan.pdf

[27] http://www.patentspostgrant.com/lang/en/2011/08/declaratory-judgement-less-attractive-after-patent-reform

[28] Jason Schultz and Jennifer Urban, “A Defensive Patent License Proposal,” http://www.youtube.com/watch?v=ttB_mjcIKcY

[29] See 35 U.S.C. 321(a)-(c).

[30] For more on the required deadlines and about the transitional program, see the Patents Post-Grant Blog and [www.pbi.org/resources/extras/7089_patent_10_11/18_Prepelka.pdf Presentation on the Transitional Program for Business Method Patents, by Nathan J. Prepelka, Esq.]

[31] AIPLA Economic Survey 2011

[32] Government use of Creative Commons. http://wiki.creativecommons.org/Government_use_of_Creative_Commons

[33] Copyright and Patent Policies of the Commonwealth of Virginia. http://leg1.state.va.us/cgi-bin/legp504.exe?091+ful+CHAP0791

[34] Australia’s Official Gov2.0 Policy. Sets Creative Commons as default license for all public information. http://www.finance.gov.au/publications/govresponse20report/doc/Government-Response-to-Gov-2-0-Report.pdf

[35] New Zealand Government Open Access and Licensing framework. http://www.e.govt.nz/policy/nzgoal

[36] UK Open Source & Open Data Licensing. http://www.nationalarchives.gov.uk/information-management/government-licensing/the-framework.htm

[37] Perspectives on Free and Open Source Software - <Http://mitpress.mit.edu/books/chapters/0262562278.pdf>

[38] Legal issues of OSS licenses. http://mitpress.mit.edu/books/chapters/0262062461chap19.pdf

[39] http://stason.org/TULARC/business/copyright/3-6-Can-the-government-copyright-its-works.html

[40] Blog post by Simon Phipps. http://opensource.com/law/11/2/open-source-procurement-copyrights

[41] OSOR Guidance on FOSS license interoperability. https://www.osor.eu/legal-questions-1/licence-compatibility-and-interoperability

[42] Open Source Digital Voting Foundation Public License (OPL) v 1.0. http://osdv.org/wp-content/uploads/2010/11/opl-rtv-license.pdf

[43] Summary by Sydney Morning Herald. http://www.smh.com.au/articles/2003/04/24/1050777342086.html

[44] The GPL as it compares to Microsoft EULA http://asyd.net/docs/misc/comparing_the_gpl_to_eula.pdf

[45] Open Source Digital Voting Foundation. TrustTheVote - An OSDV Project Blog Post “A License to Adopt”, Gregory Miller, February 28th, 2010. http://www.trustthevote.org/a-license-to-adopt

[46] Security in open vs. closed software. http://mitpress.mit.edu/books/chapters/0262062461chap8.pdf