https://github.com/18F/technology-budgeting/blob/master/handbook.md#share-your-software

"Additionally, in many states software created as a work of government is inherently in the public domain, which means an open-records request is all that’s necessary for software to become public." I believe this is a overstatement. At the very least the citation to Harvard's project does not support the assertion.

For example California is listed as being green on that map indicating "documents" are "presumptively public domain." the problem is that the researchers were looking at documents not software. So even in California which is one of the few states listed as green, Software is specifically by California statute not in the public domain and subject to Copyright. Cal. Gov't Code § 6254.9. [1] If you go to the California page on the site, the statute is specifically cited. [2]

Further, states, often have a very complex policies on copyrighted works. For instance state universities often have very different policies governing who owns the IP created by its employees then employees of other state agencies.

[1] http://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?sectionNum=6254.9.&lawCode=GOV
[2] http://copyright.lib.harvard.edu/states/california/

While I would love if this was true. And there have been attempts to free software, I believe this is paragraph is an overstatement. Even just looking at the map you are referencing without digging into how it applies to software, Only two states are "green" and two states are "light green". One of those green states specifically excludes software from this openness, so it is green despite software not being open. Florida the other green state also retains IP rights for IP created by several state agencies including "data processing software created by a state agency." And if you look at one of the light green ones, Massachusetts, the citation makes clear the light green status is based on a court case discussing "records."

I would suggest removing this paragraph. Your recommendations for including requirements about sharing in the RFP are good, but the reason to do them is if you don't it is very hard to get the software to be publically available.

The security section currently reads:

Clean tests from a static testing SaaS (such as npm audit) and from OWASP ZAP, along with documentation explaining any false positives

The npm audit tool is a very necessary security check and it does kind of seem like static testing. However npm audit does not seem like a sufficient tool static testing tool. Similarly, ZAP is great but I believe it requires a skilled individual using it to be effective. I think there are maybe 3 levels of tools to consider:

1. Basic dependency checker (e.g. npm audit, roave/security-advisories, snyk)
2. SAST e.g. the tools on OWASP page Tools
3. DAST e.g. OWASP Page list

I'd be happy to try to put together a PR if you agree.

Reading through the handbook, it struck me that very little of it was actually specific to states. Seems that it could be made applicable to federal government as well (at least), mostly with find-and-replace:

• Governor -> Executive
• Legislature -> Lawmakers
• Etc.

Thoughts?

• In Building with Loosely-Coupled Parts, the words "magic bullet" bring to mind an image of a blender. Consider "silver bullet" or "magic button".
• In the Fund Systems, Not Monoliths checklist, the phrase "they're not for e.g. setting up a database or maintaining servers" read awkwardly ("for, for example"). Consider revising, or eliminating the "for" (the next clause in the sentence appears to take this form).

Happy to PR if this looks ok.

This document is excellent, thank you for writing it. 🇺🇸