Wiki

Edit this Page View Revision History

Legal Policy

Introduction

  • What is FOSS / OSS?
    • FOSS stands for Free or Open Source Software. “Free Software” and “Open Source Software” though are the same, and so most commonly, people merely use the acronym OSS to refer to Free or Open Source Software. Thus, we will be using OSS or Open Source Software to refer to Free or Open Source Software throughout. OSS, basically speaking, allows developers, under a royalty-free license, to develop, extend or customize the software[1].
  • Global interest in using OSS in government
    • If peer adoption is a factor within your organization influencing whether or not to procure or develop open source, then the use of OSS in government globally will be of great interest. Europe, Canada
  • Software Procurement Generally - Or, what this guide does not cover
    • Legal issues of procurement have been traditionally studied with regards to buying “things” like computers, or materials.
      • Legal issues regarding the procuring of open source software development or contributing open source software back to a commons are newer, and thus there has been less research done on these topics.
  • Overall - it’s a different business model - but this business model has been successfully used in many government organizations to save money, leverage internal and local community skills and expertise, and offer high quality solutions for government IT needs.
    • Some legal issues of procurement in a traditional “things” sense overlap with procurement of open source software, but that is not the focus of this guide. Thus, issues not covered in this guide include:
    • contract drafting generally
    • identifying and allocating risks generally
    • advising on important clauses
    • Total cost of ownership (TCO) calculations (note, there are some differences in this calculation for FOSS vs. proprietary, as described Simon Phipps in his article entitled “Open source procurement: Subscriptions” (accessible at http://opensource.com/life/11/3/open-source-procurement-subscriptions), but this topic is not part of the guide scope.
    • Biased or loopholed procurement systems
    • Incumbent Bias - “Incumbent vendors usually have learned about the specific needs of the agency, its peculiar requirements, and how to service idiosyncratic problems quickly. Thus, a vendor bias is often perceived to be an incumbent bias” [2]. This incumbent bias, when used in an exploitative way in the government information technology (IT) world, has been characterized as the “IT Cartel.”[3]
  • Basic problems in procurement often occur with open source procurement as well such as:
    • Integration of OSS into a procurement system that presumes software to have a cost or other “cost” presumptions that don’t directly apply to OSS. For example, the U.S. board of Elections has faced this problem. [4]
    • Communication between procurement staff and management, service departments, and vendors. For example, it has been discussed that effective listening skills and attention to detail are important.[5] Further, the White House has a guide, suggested as reading by the Civic Commons community, on the typical communication issues with vendors.[6]
      • Life Cycle Pricing - How to identify all costs and when they can occur for OSS. [7]
      • Training of city staff: if city staff are not trained in OSS technologies, and if the city does a lot of their own enterprise support in-house, training of the staff is necessary before a new technology can be brought in. However, a city may try to train staff on different technologies, one such technology being an OSS database program, for ex. since it was a dependency of a 311 application the city wants to use.
      • Government tends to follow a solution used in the past, when in doubt. Therefore, without having adequate communication between government and OSS vendors, its likely that a response to a Request for Proposal (RFP) that includes an OSS solution could get thrown out. While not in the scope of the present guide, Civic Commons is interested in building out its Wiki to include a section providing templates or standardized language for OSS vendors, which would allow them to respond to RFP’s, in such a way that would prevent them from getting thrown out.
  • Sources of research & information for this guide:

Chapter 1 - Legal Issues and Best Practices With Procuring or Deploying FOSS In Your Organization

Chapter 2 - Legal Issues and Best Practices With Converting/Contributing In-House Developed Code  into a Reusable FOSS Project

Licensing

Most often, the biggest barrier to releasing government code as open source is in choosing an open source license. The Software Freedom Law Center (SFLC) has written a Primer on legal issues around releasing open source generally (whether or not a government organization), with a focus on IP issues.[8]

Further, the Civic Commons Wiki has a checklist written by open source community expert Karl Fogel, on important tasks to complete before open sourcing code.[9] Some of the key items to cover from his article include:

As discussed in the SFLC guide referenced above, copyleft OSS licenes generally have more legal requirements to satisfy than permissive licenses. Some of the issues encountered with copyleft OSS licenses have been documented by expert David McGowan.[10] Some of the complications presented by copyleft licenses include:

  • Requirements to make publicly available any changes to the code.
  • License interoperability issues as it pertains to development issues (combination of multiple OSS components into one). The OSOR has provided guidance on FOSS license interoperability[11]
**Freedom of Information Act (FOIA)** FOIA requests have caused some issues with the Federal government since the Federal government is, by law, unable to hold copyright on any works created by Federal employees during the course of their employment. Thus, when a FOIA request is made, and no license is attached to the code being released under FOIA, the actual legal status of the code is uncertain. However, whether software is even releasable under FOIA is determined agency by agency, and is not a settled area of law. "The question of whether computer software is included within the definition has been decided according to the particular nature and functionality of the software at issue. [63]" Footnote 63 identifies three court cases:[12] - Gilmore v. DOE: "software .. was not a record under FOIA because ... it does not illuminate anything about [agency's] structure or decisionmaking process" - Cleary, Gottlieb, Steen & Hamilton v HHS: "software program was a record because it was 'uniquely suited to its underlying database'" - Cf. Essential Info, Inc. v. USIA: suggesting internet addresses are not records but means to access records Experts theorize that according to the above, whether software can be FOIA'd depends what the software does. If the software does not influence decisions or indicate organizational structure, a FOIA request may be denied. [13] Further guidance on the FOIA issue has been covered in the CENDI Frequently Asked Questions about Copyright and Computer Software, Question 6.7, which advises on software FOIA requests[14][15] CENDI is an interagency cooperative organization composed of the scientific and technical information (STI) managers from the Departments of Agriculture, Commerce, Energy, Education, Defense, the Environmental Protection Agency, Health and Human Services, Interior, the National Aeronautics and Space Administration, the Government Printing Office, the National Archives and Records Administration, the National Science Foundation, and the Library of Congress. The has been reported to have been influenced by several references to include in the 1996 FOIA amendments to cover electronic data:[16][17][18] Because the issue of whether software can be released under a FOIA request is unsettled, at least the Air Force, Army and Navy have attempted to settle the issue through their own policies: - Air Force: DoD Regulation 5400.7/Air Force Supplement, DoD Freedom of Information Act Program (24June2002)[19] See p.131: "NOTE: Some electronic data requests may include a request for software. You may have to release government-developed software that is not otherwise exempt, if requested under the FOIA. Exemptions 1 - classified software, 2 -testing, evaluation, or similar software, 3 - exempt by statue, 5 -deliverative process/priviliged software, and 7 - law enforcement operations software may apply, based on the nature of the requested software." - Army: Army Regulation 25-55, The Department of the Army Freedom of Information Act Program (1November1997) [20] See p.9: 1-402. Agency Record: "2.b: The following are not included within the definition of the word 'record:' ... Normally, computer software, including source code, object code, and listings of source and object codes, regardless of medium, are not agency records. ... Exceptions to this position ... are in 2.c: In some instances, computer software may have to be treated as an agency record and processed under the FOIA. These situations are rare, and shall be treated on a case-by-case basis. Examples ...." - Navy: SECNAV Instruction 5720.42F, Department of the Navy Freedom of Information Act Program (2January1999)[21] See p.79: FOIA exemption for "(c) computer software, the release of which would allow circumvention of a status or DON rules, regulations, orders, manuals, directives, or instructions. In this situation, the use of the software must be closely examined to ensure a circumvention possibility exists." Summary of the above three policies by an expert [22]: The Air Force seems to state that software is a record, the Army states that software is "usually not" a record, and Navy does not state much except the standard exemption clauses that all three mention. In all, many of the copyright legal issues faced in procuring open source involve adherence to provisions set forth in copyleft licenses such as the GPL, and potential complications arising from public records and FOIA requests. **Public Records Laws** While FOIA requests apply to certain Federal agencies[23], Public Records laws apply to state[24] and municipal governments. Some municipal governments, such as Orange County, California, have made exceptions to their public records law to exclude computer software. The definition of what is considered as "software" may be unclear, and is at issue at least in a lawsuit between the Sierra Club and Orange County, which was accepted to be heard before the Supreme Court of California on September 14, 2011.[25]
Trademark issues: ----------------- In the course of researching IP issues for this guide, no significant trademark policies were discovered in the context of trademark infringement with OSS development. However, there is case law regarding trademark infringement in software. In Board of Regents of the University of Wisconsin System v. Phoenix International Software, Inc., Appeal No. 07-C-665 (7th Cir. December 28, 2010), the University of Wisconsin was sued by Phoenix for use of the mark CONDOR in for a software product.[26] CONDOR was a mark registered to Phoenix. In the end, the University of Wisconsin prevailed under a defense of sovereign immunity. However, when discussing the topic with a county administrator in the course of researching for this guide, it was mentioned that trademarks that may co-exist within different jurisdictional boundaries (for instance, a logo used for a county, and a confusingly similar logo used for the same service, but at the state level) is an example of a trademark issue. In this particular instance, the county administrator capitulated to the requests of the state and altered the county logo accordingly so it would no longer be confused with the state logo. It is worthwhile noting that trademark protections involve both words (like the meaning behind an abbreviated service code such as 311), as well as logos. The Apache Foundation, which is an open source community with a strong brand value, has drafted policy around use of their logo.[27] This policy could work as a template for government organizations seeking guidance on trademark protections for their own logos and words used as a trade or service mark.
Trade Secrets ------------- Trade secrets are not typically thought of as being in practice within government organizations, and thus, often are not considered in any risk analysis of OSS. However, Author David Levine has written a law review article featured in the Michigan Telecommunications and Technology Law Review about trade secrets in government. [28] Although software, especially open source software, in government is not likely to meet trade secret protections, it is worth noting that in theory, trade secret protections could apply to government owned software. For instance, The Restatement (Third) of Unfair Competition includes governments in a list of non-business organizations that can hold trade secrets. Further, it is interesting to note that the Freedom of Information Act (FOIA) does not cover trade secrets - See 5 U.S.C. § 552(b)(4). Scholar Daniel Goldman, in the Seventh Circuit Review journal has written an article on FOIA requests on trade secret protected information, and some of the legal issues that have followed therefrom.[29] To date, the types of trade secrets for which government has sought protection include: - County's modification of voting machines - Public school systems' examinations - Minutes of public corporation board meetings - "But ultimately, the trend towards increased governmental commercial activity, like servicing student loans and selling databases,20 combined with increasing budgetary pressure on state and local governments to provide services at as low a cost as possible,21 means that one can expect that governments will increasingly utilize commercial law concepts like trade secrecy in their operations." In all, while trade secrets do not present a real hurdle to contributing government code to an OSS community, it should be noted that while the Federal government may not be able to hold copyright, it may decide to hold a trade secret on a particular piece of software. Therefore, it is important to at least be aware of the fact that government software could be protected under trade secrets.

Chapter 3 - Legal Issues and Best Practices With Starting a New OSS Development Project In-House ————————————————————————————————

“At each step in a project, programmers face a choice: to do that step in a manner compatible with the future open-sourcing, or do it in a manner not compatible with the future open-sourcing. And every time they choose the latter, the project gets just a little bit harder to open source.” - Open source expert, Karl Fogel [30]

When most government organizations think of in-house development, they worry foremost about time management of the available development staff, and their level of training. However, before any in-house project begins, the project manager should outline a development strategy to keep development open from day one. This not only reduces the amount of work required later to release and reuse the code, but it also establishes a workflow from the beginning which leverages proven and reliable open source development tools to ensure a high level of quality and accountability in the software developed.

**Guidelines for Open Source Development Infrastructure** Open source expert Karl Fogel has drafted a basic guideline for governments to follow to ensure that their projects effectively make use of the "open from day one" methodology.[31] Further, for detailed advice on OSS development in government, the Department of Defense has crafted a comprehensive guide to Managing an Open Source Software Development project.[32]

Project Management ——————

Perhaps the most difficult hurdle to overcome in starting an “open from day one” in-house development project within government is the public hosting and contribution towards such a project. Open source development is collaborative by definition, and so it requires use of a version control system, that is, a system which keeps track of changes made by each developer, and facilitates the reconciliation of any conflicting or competing code edits. Further, in conjunction with the version control systems, the code “repository” or the body of code in its entirety, is stored on a publicly accessible code hosting site.

**Community Contributions to Code** While the public availability alone may not be an issue as long as a license is determined for the code and applied to the code as it is being developed, one of the bigger issues may be public contribution to the code. To overcome such an issue, lawyers at NASA drafted an open development waiver for its Nebula project. [33] Generally, under the open source model, contributor agreements are used to ensure that code being contributed from the public, is free of any legal claims against it. The OSOR has provided some guidance on this topic. [34]

Community sourcing model While the benefits of open source have been widely recognized by some government organizations, concerns over having greater control over public contributions to code have led to the community sourcing model. Some examples of successful community sourcing projects include Kuali[35] and Sakai [36]. The cost savings of open source can often be realized with community sourcing, while still ensuring control over developments and contributions to the code. However, community sourcing requires additional resources to manage the community, and the membership model. One of the experts that was interviewed for this guide, who had experience with the community sourcing model, noted that community sourcing is a good option for those types of software that may not have an immediate appeal for developers to work on voluntarily. That is, the software that is developed and sustainable via open source without community sourcing is typically only for solutions addressing problems which the developers themselves face, such as developer tool software. The kind of software that developers typically don’t enjoy coding as a hobby is better suited for a community development model.

Keeping in line with being “open from day one,” development teams may want to consider ahead of time, using the number of open standards available for various solutions. The Civic Commons Wiki has a section dedicated to the use of open standards, and is a great reference for guidance on this topic.[37]

Data Use/Data Standards Legal Issues ------------------------------------ Included in the Department of Defense guide on in-house government open source development are best practices around data standards,[38] In section A-1 of the DoD guide, the authors warn that a data standard could be encumbered by intellectual property protections, and so, the authors state that it is important to evaluate standards to ensure that any licensing requirements are met. Aside from the data standards themselves, many cities have anticipated issues around government data use in conjunction with applications, and some cities have guidelines or policies on open data use. The Civic Commons Wiki also has a dedicated page on open data policy, and known policies from various government organizations.[39] In the United Kingdom (UK), databases are more easily copyrightable, and open data requires additional legal consideration. To this end, the UK has created their own Open Government License which was designed to be interoperable with any Creative Commons Attribution license and Open Data Commons Attribution License, which covers database rights and applicable copyrights.[40]
Tort ---- Although issues in tort are not as commonplace in government in-house development, this may be due to the fact that many open source solutions have yet to be applied to government services where personal injury could potentially result. However, as open source is increasingly adopted and leveraged within government, these issues could become more important. **Personal Injury** The potential for personal injury has already been studied in the commercial sector, and in particular, in the use of medical devices, as detailed in the article "Killed by Code: Software Transparency in Implantable Medical Devices," written by Attorneys at the Software Freedom Law Center.[41]
**Content Legal Issues** The most prominent issues of tort in open source software and open data presently are in the area of social media, which involves freedom of speech and privacy concerns. To this end, the International Municipal Lawyers Association has developed a guide to provide advice to municipal attorneys in developing a coherent, legal and useful social media policy for local governments.[42] The categories of social media lawsuits outlined in the guide include: - Privacy - Intellectual Property - Defamation - Self-Incrimination

Chapter 4 - Legal Issues Not Well Known, and Possible Solutions —————————————————————

While open source has been in use in government for decades, and many of the legal hurdles and procurement issues have by now been addressed or solved, there exists some issues around which, no general consensus has been made. Some solutions attempted by government, such as drafting custom OSS licenses to suit their individual organization, have not been as successful as hoped, and developers instead return to using the more popular and proven OSS licenses. Further, as government applications generally expand in scope to address issues of greater citizen participation and transparency, the public has greater exposure to the technologies in use in government.

How high liability coverage should be

In terms of dealing with unknown or unforeseen risk, most governments ensure that the extent of the liability coverage on their contracts with vendors is reasonably high. How high this liability coverage should be is not well known, and governments would greatly benefit from further studies on this topic.

**Adherence to GPL License requirements** Some of the requirements of stricter copyleft licenses, like the GPL, can cause problems within government due to the GPL's inflexibility. Some of the known issues which are still being addressed with regards to the GPL include: - Reliance upon assignment and non-revocation of license in GPL.[43] - What constitutes a derivative work under the GPL
**Status of code released under a FOIA request** Other licensing complications include the status of code when it is released under a FOIA request. Without any licensing being applied beforehand which would disclaim warranty and risk, it is uncertain what warranties or risks the government assumes from an unlicensed FOIA release. Typically, copyrightable material that is made publicly available is not by default "public domain." Rather, copyright automatically attaches as long as the release is fixed in a "tangible medium" such as a printed document or computer file.[44] An author must explicitly declare a work as public domain for it to be as such. As long as a FOIA release is issued without an explicit intent to release the material into public domain then, the code in theory at least has a default copyright. However, this could be complicated by the fact that code created by Federal employees as part of their job cannot be copyrighted. In this case, FOIA released code would not have a copyright, but absent the public domain declaration, would not be public domain either. Regardless of whether Federal FOIA released code would be copyrighted, if code is released under FOIA without a license or disclaimer, it is unknown whether a government entity would be liable for harm incurred by use of code released under a FOIA request.
**Sovereign Immunity** In the end, it is possible that government is actually not at much risk for civil causes of action arising from open source development or procurement activities, because another unsettled question is whether sovereign immunity protections are valid, and would not be waived via the Federal Tort Claims act. As set forth by insurance service provider RCM&D[45],"sovereign immunity usually only applies to property damage or bodily injury and has no application to financial damages or lost opportunity." The RCM&D sets forth the following criteria to consider regarding risk in view of the potential for sovereign immunity: - Statutes vary by state, as well as agency. - Application of the statute can vary from contract to contract. - When in force, they usually do not protect a contractor entirely, but instead establish a cap of damages: - The caps may apply only to the government, not the contractor. - The caps may not apply to actions brought by government employees or third parties. - Caps that benefit the general contractor may not pass through to the subcontractor. - Do caps apply to all allegations such as intentional acts and gross negligence? - Do the caps apply to defense costs? However, the Supreme Court has held that intellectual property (such as Patents and Copyrights) are property for Sovereign Immunity purposes.[46] Further, courts have held that the "taking" of intellectual property is authorized under eminent domain power so long as just compensation is paid.[47] In the article cited here, Volokh discusses that the immunities entitled to the Federal government may differ from those entitled to state governments. While sovereign immunity typically does not apply to county or municipal governments, a similar type of immunity from intellectual property liabilities may apply under the doctrine of governmental immunity.[48]

Wish List:

Regardless of whether civil liabilities exist for government development or procurement of OSS, government attorneys and IT staff desire more efficiency around the procurement process. To this end, several of the government staff we interviewed expressed a desire for more standardization around contract language, and overall risk analysis of popular open source licenses.

Unknown Issues in Tort

Lawyers with the International Municipal Lawyers Association have considered that software could pose tortious injury - with just incorrect content. For example, in a guide on Social Media, the authors offer up the question “Does providing directions that are not complete or up to date resulting in injury a basis for a lawsuit?”[49]

Summary / Conclusion

Open source software has a place in government, and as many cities, states and Federal agencies have proven, the legal and procurement hurdles can be overcome to realize billions in dollars of costs savings. To the extent that its procurement and development confuse and disrupt the usual procurement processes, it should be noted that at least the Federal government has resolved this problem by mandating that OSS is classified as Commercial Off The Shelf (COTS) software for procurement purposes.[50]

As discussed earlier in this guide regarding procurement contracts for open source, there has been some research done to collect standardized language for contracts, but to realize this wish list of community reviewed risk analysis and suggested contract language, governments will have to be more open as to their current practices. It can start with warming relations and improving communication between government IT staff and their legal counsel. Policy decision makers and those staff assigned to mitigate risk would benefit greatly from learning more about technology use in government in general, so that other risks, such as the risks of large development projects failing or going over budget, would be better understood as well.[51]

Appendix / References to Existing Legal Resource Wikis/Tools/printed knowledge bases

References

Category:Policy

[1] For a formal definition of OSS, see Open Source Initiatives definition of open source http://www.opensource.org/docs/osd

[2] 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. http://jleo.oxfordjournals.org/content/9/1/159.extract

[3] Statement by Whitehouse CIO, Vivek Kundra regarding “IT Cartel” (incumbent bias). http://www.computerworld.com/s/article/9218466/Outgoing_federal_CIO_warns_of_an_IT_cartel_

[4] Election Boards Voting System Procurement. http://wiki.trustthevote.org/index.php/Business_Models_for_Election_Boards%27_Adoption_of_Open_Source_Election_Technology

[5] Effective Listening Skills and Attention to detail. http://www.training-management.info/Procurement/Marketing.htm#X4

[6] Suggested paper on communication issues with vendors. http://www.whitehouse.gov/sites/default/files/omb/procurement/memo/Myth-Busting.pdf

[7] PHS Management Training - Procurement Training. http://www.training-management.info/Procurement/Cost-Price.htm#X2

[8] Software Freedom Law Center Primer on Legal Issues for Open Source Software Projects

[9] Checklist for Releasing Open Source

[10] Analysis of Issues caused by Gnu General Public License (GPL)

[11]

[12] Department of Justice Guide to the Freedom of Information Act (see page 33 for relevant portion)

[13] Google Group Post by Christopher Sean Morrison https://groups.google.com/group/mil-oss/browse_thread/thread/b69c0384180a95af?pli=1

[14]

[15] Google Group Post by David Wheeler https://groups.google.com/group/mil-oss/browse_thread/thread/b69c0384180a95af?pli=1

[16] Google Group Post by Christopher Sean Morrison https://groups.google.com/group/mil-oss/browse_thread/thread/b69c0384180a95af?pli=1

[17] http://www.justice.gov/oip/foia_updates/Vol_XV_4/foiaelectronic.htm

[18] http://www.justice.gov/oip/foia_updates/Vol_XV_4/foia4.htm

[19]

[20]

[21]

[22] Google Group Post by Christopher Sean Morrison https://groups.google.com/group/mil-oss/browse_thread/thread/b69c0384180a95af?pli=1

[23] FOIA Basics

[24] List of Public Records laws by State

[25] Direction Magazine’s Dec. 14, 2011 article on the Sierra Club vs. Orange County suit

[26] Board of Regents of the University of Wisconsin System v. Phoenix International Software, Inc., Appeal No. 07-C-665 (7th Cir. December 28, 2010)

[27] Apache Logo Use Policy

[28] Levine, David S., The People’s Trade Secrets? (February 18, 2011). Michigan Telecommunications and Technology Law Review, Forthcoming . Available at SSRN: http://ssrn.com/abstract=1571436

[29] Daniel B. Goldman, (Trade) Secrets, Secrets Are No Fun—Especially When Disclosed Through FOIA Requests to Everyone, 3 SEVENTH CIRCUIT REV. 690 (2008), at http://www.kentlaw.edu/7cr/v3-2/goldman.pdf

[30] Be open from day one “Be Open from Day One, not Day N.” by Karl Fogel, January 27, 2011

[31] Civic Commons Wiki on Open Development Guidelines

[32] Managing an Open Source Software Development project (Department of Defense Guide)

[33]

[34] OSOR guidance on contributor agreements

[35] Kuali

[36] 1

[37] Use of Open Standards and Open Standards Policy

[38] Managing an Open Source Software Development project (Department of Defense Guide)

[39] Data Catalog / App Catalog Developer Contract Provisions

[40] UK Open Source & Open Data Licensing

[41] SFLC Publication: Killed by Code: Software Transparency in Implantable Medical Devices

[42] Social Media Defamation Issues

[43] http://mitpress.mit.edu/books/chapters/0262062461chap19.pdf

[44] Wikipedia entry on public domain software

[45] [http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&sqi=2&ved=0CB0QFjAA&url=http%3A%2F%2Fwww.rcmd.com%2Fgalleries%2Fwhite_papers%2Ffederal_government_contractors.pdf&ei=Gcm9TvmtHKLniAK7lNS5Aw&usg=AFQjCNHRHJ0pc2l58PYk3XGXizajnXLI2A RCM&D’s Brochure on Government Technologists’ need for insurance]

[46] Volokh, Eugene, “Sovereign Immunity and Intellectual Property”, 73 Southern California Law Review 1161 (2000)

[47] Volokh, Eugene, Sovereign Immunity and Intellectual Property, 73 Southern California Law Review 1161 (2000)

[48] Kitchen, Chuck, “Sovereign versus Governmental Immunity”, North Carolina Bar Association Newsletter, May 2010

[49] Social Media Defamation Issues

[50] http://www.dwheeler.com/essays/oss-government-acquisitions.html

[51] http://www.nytimes.com/2011/07/13/nyregion/citys-timekeeping-software-can-be-sold-elsewhere.html?_r=1

[52] Board of Regents of the University of Wisconsin System v. Phoenix International Software, Inc., Appeal No. 07-C-665 (7th Cir. December 28, 2010)