This page brings together notes about potential areas for improvement of agency terms of service. Please add suggestions below.
The notes here are all drafts and currently works in progress. To see the author of any given piece of text in this document, use GitHub’s “blame” tool.
NIDA content can be presented anywhere on your Web site.
This is not a requirement even though it is under a heading called “Usage Requirements”. It can be safely removed.
Do not manipulate or alter the calculation of the screening tool results.
If the screening tool is embedded alongside other content, please ensure that the content provides related value, is consistent with the NIDA content, and does not harm the integrity of the NIDA content.
The ToS is probably not a good place to regulate downstream use of open information. Furthermore, “manipulate,” “alter,” “related value,” and “integrity” are very subjective terms in the API context, and thus lead to uncertainty from a developer’s perspective.
Generally speaking, downstream controls prohibiting things like “manipulation” of information go against norms in other areas of government publishing. For example, when a Supreme Court opinion is released, there is no ToS, and no requirement that users not modify, prohibit, or misrepresent the information.
Your application may only send a maximum of 10 requests per second unless you have received prior authorization from NIDA’s web team.
This is good. Though it’s always ideal to not have rate limits this low, if rate limits are going to exist, it’s always excellent to transparent in what the limits are. It would be nice for a sentence or two that clarifies how the limit is enforced, as well as any tips and tricks that will make it easy for the user to respect the limit.
- requires developers include this in their html:
- “The APIs should be used on demand, rather than be queried and pulled into a separate database.” vs. in the Usage Requirements “Use best practices to determine when to use the healthfinder.gov API in real-time versus when to use the API to gather the healthfinder.gov content and store it in a local database.”
Data accessed through USA.gov do not, and should not, include controls over its end use.
This is a good principle. It really should apply by default to all agency APIs, and need not be stated in the ToS.
TO THE EXTENT PERMITTED BY APPLICABLE LAW, YOU AGREE TO INDEMNIFY GSA, AND ITS AFFILIATES, OFFICERS, AGENTS, AND EMPLOYEES AGAINST ANY ACTUAL CLAIM OR DEMAND (BUT EXCLUDING CLAIMS RELATING TO OWNERSHIP OR RIGHTS ASSOCIATED WITH THE DATA), INCLUDING REASONABLE ATTORNEYS’ FEES, TO THE EXTENT SUCH CLAIM OR DEMAND RELATES TO THE USE AND DISTRIBUTION OF THE DATA BY YOU. THE DATA ARE PROVIDED BY GSA “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. IN NO EVENT SHALL GSA BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER, INCLUDING BUT NOT LIMITED TO CLAIMS ASSOCIATED WITH THE LOSS OF DATA OR PROFITS, WHICH MAY RESULT FROM ANY ACTION IN CONTRACT, NEGLIGENCE OR OTHER TORTIOUS CLAIM THAT ARISES OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE DATA.
In-Progress Personal Notes on ToS from Alan deLevie
White House - We The People Write API
The WTP API does not appear to have a ToS. There is a Terms of Participation that applies generally to the WTP program.
USDA - Agricultural Marketing Service
The Farmers Market Directory API has its own ToS.
But, as the data owners and/or authoritative source, AMS retains all version control.
I am not sure what this means. The context of the paragraph suggests that a third party publisher of the data is responsible for it, and the USDA AMS is not.
The ToS requires API users to disclose:
“This product uses USDA’s National Farmers Market API but is not endorsed or certified by USDA.”
As part of our ongoing efforts under the Transparency and Open Government Initiative, any feedback and input from members of the public will help contribute to the continued improvement and evolution of our APIs and open data sets.
This is not a term of service. It is a great goal, though. Including an email address or link would serve that goal. It also should probably be removed from the ToS and instead be mentioned somewhere else.
Modification or False Representation of Content
Users of AMS data may not modify or falsely represent content accessed through the AMS website and still attribute the source as AMS or USDA.
The use of “modifying” here is overly broad. Many modifications to data still fall under the banner of faithful representation (rounding numbers, for example). This sentence, in its plain meaning, bars users from making any modification ot the data and citing its source. Moreover, as a potential user of this API, I strongly prefer not to limit my ability to correctly cite sources by contract. Any time and effort I put into this API is potentially wasted if USDA or AMS determines (after the fact) that an attribution violates the ToS. This is especially concerning given the earlier section of the ToS that requires attribution.
There are several reasons to remove this clause. First, without any amendment, agreement to these ToS (which is triggered from mere use of the API) possibly constitutes a violation of the Anti-Deficiency Act (according to the Federal Acquisition Regulations and a Department of Justice memorandum). Agreement to this indemnficiation by federal employees who do not have contracting authority, though not a violation of the Anti-Deficiency Act (according to the FAR and DOJ), is unenforceable (according to the FAR and DOJ). At minimum, the ToS needs an amendment excempting federal users. Until then, the indemnificatione clause is moot, at best, and a potential precursor to a violation of the Anti-Deficiency Act at worst.
For non-federal users, this clause still poses uneccesary risk to API users. usda.gov and ams.usda.gov do not have ToS and thus no indemnification clause.
Bureau of Justice Statistics - DOJ
There is no ToS for BJS or its API and data. There is only the DOJ’s main Legal Policies and Disclaimers page.
National Institute on Drug Abuse - NIH
I cannot find their APIs or data.
Healthfinder.gov - HHS
The APIs should be used on demand, rather than be queried and pulled into a separate database.
This is helpful in a guide, but is not a term of use.
The healthfinder.gov logo and URL must be displayed as the content source wherever healthfinder.gov content is used. To properly use the healthfinder.gov API, we ask that the following code is embedded wherever healthfinder.gov content appears on your site.
The logo and URL only need to appear once on a webpage where healthfinder.gov content appears. Please reference healthfinder.gov as the source and provide credit and the link to healthfinder.gov. The URL does not need to be displayed; wrapping the URL around the healthfinder.gov logo is the proper format.
This code is not valid HTML. Thus requiring its use in an HTML page means that developers are required to publish content that breaks the HTML specification.
The analytics collects: the URL where the content is displayed and how many times the content has been loaded.
It appears that the previous code sample is required to make possible these analytics. Nevertheless, this should not be required.
healthfinder.gov content can be presented anywhere on your website.
This clause is unecessary. ToS need not dictate where on a website content may reside.
Do not manipulate or alter the healthfinder.gov content. This is particularly important for the myhealthfinder API, since the myhealthfinder results are evidence-based and require careful maintenance and oversight by the healthfinder.gov team to ensure they are up to date.
While misrepresentation of information, especially health-related, is a serious concern, overly-broad language prohibiting any manipulation or alteration means that developers should not alter or manipulate the data in ways that 1) are not misrepresentations of the data, and 2) could be useful. Rounding numbers, for example, is a modification of data. Is this never acceptable?
If the content is mashed up or presented with other content, please ensure that the content provides related value, is consistent with the healthfinder content, and does not harm the integrity of the healthfinder.gov content.
Providing “value” is highly subjective. This should be recommended (and taught and clarified) in a guide, but should not be a black letter requirement to use the API.
Use best practices to determine when to use the healthfinder.gov API in real-time versus when to use the API to gather the healthfinder.gov content and store it in a local database.
This is redundant at best, and contradictory, at worst, with the earlier clause that requires that the APIs be used on demand.