Adding Revised TOS Draft #11
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,39 @@ | ||
| # API Terms of Service Agreement | ||
|
|
||
| The U.S. AGENCY ("AGENCY”) offers some of its public data in machine-readable format through an API (Application Programming Interface), a service located at https://open.AGENCY.gov. Use of the data made available via the API is generally unrestricted ([see “Data Rights and Usage”](#data-rights-and-usage)). However, the service through which we make that data available is offered subject to your acceptance of the terms and conditions contained herein as well as any relevant sections of the AGENCY Website Policies (http://www.AGENCY.gov/WebsitePolicies/default.htm). | ||
|
|
||
| ## Scope | ||
| The service (“API”) through which you may access AGENCY public data is subject to these terms. Use of the API constitutes acceptance to this Agreement. | ||
|
|
||
| ## Data Rights and Usage | ||
| Unless otherwise noted, the content, data, documentation, code, and related materials associated with the API is public domain and made available with a Creative Commons CC0 1.0 Universal (http://creativecommons.org/publicdomain/zero/1.0/legalcode) dedication. In short, AGENCY waives all rights to the work worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law. You can copy, modify, distribute, and perform the work, even for commercial purposes, all without asking permission. AGENCY makes no warranties about the work, and disclaims liability for all uses of the work, to the fullest extent permitted by applicable law. | ||
|
|
||
| Some data from the API may not be public domain, such as copies of copyrightable works made available to the AGENCY by private entities. AGENCY may make these works available under the fair use provision of the Copyright Act or as a result of regulatory directives. Therefore, your rights to use those works may be similarly limited. Works where CC0 do not apply will be clearly marked by a warning in the relevant documentation (for example: “This data is not in the public domain. Third party copy rights may apply.”). | ||
|
|
||
| ### Attribution | ||
| While not required, when using content, data, documentation, code, and related materials associated with the API in your own work, we ask that proper credit be given. | ||
|
There was a problem hiding this comment. May be worth adding that best practices (and arguably law) dictates you can't imply endorsement or modify and misrepresent the validity of the data. There was a problem hiding this comment. +1 to best practices, perhaps besides attribution. I'd be interested to discuss the potential implications of an agency adding restrictions to use of data that is in the public domain. There was a problem hiding this comment. I'd steer clear of having the ToS point out anything that's not a service-specific restriction. Implying endorsement and misrepresenting the data is bad practice, but those are much more subjective actions than attribution (which is mentioned, appropriately as a request) and hard restrictions (which are inappropriate). By discouraging implied endorsement and misrepresentation without making them restrictions, they're essentially scare language. There was a problem hiding this comment. That goes back to some of this discussion... we have an opportunity here to do more than blindly barf legalease on a piece of paper... we have a chance to rethink the process. What are we solving for?
Rephrasing the first goal a bit, it's that we want to enable developers to do cool stuff with the data, and all that that entails. The end goal is data consumption. So far this document does a great job at number 2, but does little to actually enable successful use beyond covering the agency's liability. There was a problem hiding this comment. You can achieve number 1 (managing user expectations) most simply by just stating any restrictions that exist. You don't need to state "also you can't break these other laws or do other things we may think are naughty" - that's not managing expectations, that's just intimidation. I'd love for the ToS to be an opportunity to break out of the legal-ese and signal to people that a new font of data has been constructed for public use -- that's why I submitted a non-ToS ToS. Maybe if that was the base, and the agency had no legal levers in any way, it'd be easier to have an agency jocularly wag their finger at the user and remind them to be nice. But what we're dealing with here is a contract, and one of the ramifications of forcing citizens to sign one before accessing data is that it makes it dangerous for the agency to also say mushy, abuse-able things like "you shouldn't misrepresent the data or imply we endorse your claims". That's a recipe for cracking down on parody and criticism the agency finds uncomfortable. There was a problem hiding this comment.
Totally agree, strawman aside, if you keep reading, "it's that we want to enable developers to do cool stuff with the data, and all that that entails. The end goal is data consumption." It's not simply a matter of managing expectations. Would changing the title of the document from "terms of service" to "usage guidelines" or "using our API" assuage your concerns? There was a problem hiding this comment. Twitter now calls what was their API ToS the "Developer Rules of the Road" https://dev.twitter.com/terms/api-terms On Fri, Apr 4, 2014 at 9:02 AM, Ben Balter notifications@github.com wrote:
Noah Kunin | @NoahKunin http://twitter.com/noahkunin | There was a problem hiding this comment. Btw, I really love this line in it (emphasis added) Don't do anything prohibited by the Rules and talk to us if you think we We'll never get everything right at first. Or, ever. I could imagine a On Fri, Apr 4, 2014 at 3:13 PM, Noah Kunin - Q0B noah.kunin@gsa.gov wrote:
Noah Kunin | @NoahKunin http://twitter.com/noahkunin | There was a problem hiding this comment. Sure, I love that too; friendlier tone and titles definitely help. My main concerns, that @seanherron is already addressing very well as it's written, are:
This PR doesn't mention anything about endorsement or misrepresentation, so the third one is moot. But if you do include those, then in my mind that third one is hard to satisfy without either having the terms on a separate page, or dedicating design time to UX that clearly separates them. Even labeling best practices about misrepresentation/endorsement as "Rules of the Road" wouldn't be appropriate, because they aren't rules. Twitter does a great job at making their terms friendly, but they don't have the same obligation to put aside potential levers for abuse. When I say abuse, I mean: if someone makes a highly critical I don't mean to make any strawmen, and I could certainly see all kinds of proposals that address this concern. But the easiest way to deal with it is simply not mentioning best practices that are about discouraging subjective uses. That certainly doesn't prevent the page from saying lots of inspiring, positive, encouraging things, linking to examples the agency thinks are great uses, or really anything nice. :) There was a problem hiding this comment. Agencies have existing mechanisms to go after people who are misrepresenting themselves. I want to respect those mechanisms and ensure that they are the process by which such issues are handled. I'm wondering if there is existing precedent of those mechanisms being used to block access to a resource on the internet? |
||
|
|
||
| ## Service Management | ||
|
|
||
| ### Right to Limit | ||
| Your use of the API may be subject to certain limitations on access, calls, or use as set forth within this Agreement or otherwise provided by AGENCY. These limitations are designed to manage load on the system, promote equitable access, and prevent abuse. If AGENCY reasonably believes that you have attempted to exceed or circumvent these limits, your ability to use the API may be temporarily or permanently blocked. AGENCY may monitor your use of the API to improve the service or to ensure compliance with this Agreement. | ||
|
There was a problem hiding this comment. I'd go with "limited" over "blocked". If this were to actually be litigated, a smart lawyer would drive a wedge between rate limiting and banhammering. There was a problem hiding this comment. I disagree. "Temporarily blocked" is equivalent to limiting. If we change "permanently blocked" to "permanently limited" one could argue that, say, denying all requests from an IP that is attempting to gain unauthorized access to the system is now allowed. |
||
|
|
||
| ### Service Termination | ||
| If you wish to terminate this Agreement, you may do so by refraining from further use of the API. AGENCY reserves the right (though not the obligation) to: (1) refuse to provide the API to you, if it is AGENCY’s opinion that use violates any AGENCY policy; or (2) terminate or deny you access to and use of all or part of the API at any time for any other reason in its sole discretion. All provisions of this Agreement, which by their nature should survive termination, shall survive termination including, without limitation, warranty disclaimers, and limitations of liability. | ||
|
There was a problem hiding this comment. Violates agency policy, applicable federal, state, and local laws, or public policy. There was a problem hiding this comment. Why? I'd suggest dropping (2) entirely and leaving (1) as constrained as possible. The agency's opinion that a use violates a law (compare to: a court has ruled that a use violates a law) should not be an acceptable reason to deny access. Whatever policy the agency uses in (1) should be clear and not capricious. There was a problem hiding this comment. The commas in There was a problem hiding this comment. Oh yeah, I missed There was a problem hiding this comment.
There was a problem hiding this comment. There's an important distinction between everyone gets cut off (govt shutdown, out of control circumstances like |
||
|
|
||
| ## Liability | ||
|
|
||
| ### Disclaimer of Warranties | ||
| The API platform is provided "as is" and on an "as-available" basis. While we will do our best to ensure the service is available and functional at all times, AGENCY hereby disclaim all warranties of any kind, express or implied, including without limitation the warranties of merchantability, fitness for a particular purpose, and non-infringement. AGENCY makes no warranty that data will be error free or that access thereto will be continuous or uninterrupted. | ||
|
There was a problem hiding this comment. First half of the sentence doesn't match the second. I'd break up into two paragraphs, one limiting liability for uptime (e.g., no SLA), and another limiting liability for accuracy. That said, not 100% sure the accuracy side it true. It may be true civilly, but reliance on an official statement can be a defense in criminal cases. |
||
|
|
||
| ### Limitations on Liability | ||
| In no event will AGENCY be liable with respect to any subject matter of this Agreement under any contract, negligence, strict liability or other legal or equitable theory for: (1) any special, incidental, or consequential damages; (2) the cost of procurement of substitute products or services; or (3) for interruption of use or loss or corruption of data. | ||
|
|
||
| ## Miscellaneous | ||
| This Agreement constitutes the entire Agreement between AGENCY and you concerning the subject matter hereof, and may only be modified by the posting of a revised version on this page by AGENCY. | ||
|
There was a problem hiding this comment. Giving one party unilateral authority to modify a contract is a bit iffy, especially absent a notification mechanism and means to discontinue use. Merge clause also isn't 100% accurate when you make reference to other documents. There was a problem hiding this comment. The proper way to do this would be to tie the TOS to an API version or to an API key so that you know what's been agreed to at the moment of each call. There was a problem hiding this comment. Listing a timestamp at the top of TOS versions (and showing previous versions) might also be effective enough at determining which TOS was in effect for any given call. You'd have to make the timestamp go down to the second, which is a little weird for a TOS, but hey, this is a contract for real-time APIs, so go for it. @benbalter's point about a notification mechanism is super valid, and a separate issue from @JoshData's. However, since API key registration isn't always required (which is 👍) then even just using an RSS feed (and mentioning this in the TOS as a subscription mechanism for updates) would help a lot to push this clause forward. There was a problem hiding this comment. Things we can't assume the agency will have the ability to do:
There was a problem hiding this comment. You don't need to have version control to put times at the top of the page or to have permalinks for past ToS versions. And sure, RSS and push notifications are technical infrastructure. But if the agency has the ability to deploy an API, they have the ability to deploy an RSS feed. That RSS feed doesn't even have to live on the same domain as the ToS - it could run as a side endpoint in the API app itself. There was a problem hiding this comment. What about an embedded gist? There was a problem hiding this comment. That would have some other nice benefits, like commentability and forking, though I don't know of any subscription or notification mechanisms for gists. There was a problem hiding this comment. Actually... encouraging agencies to link to a repo or pages site and incorporating by reference could solve all three. Simply watch the repository to get updates. |
||
|
|
||
| ## Disputes | ||
| Any disputes arising out of this Agreement and access to or use of the API shall be governed by federal law. | ||
|
|
||
| ## No Waiver Rights | ||
| AGENCY’s failure to exercise or enforce any right or provision of this Agreement shall not constitute waiver of such right or provision. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you run this past IP counsel at all? CC0 makes perfect sense for contractor-created data, but If it's government created data, the government agency can't waive rights it's not legally allowed to have under the definition of copyright.
Edit: Specifically, the edge case is use of US data abroad.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See "to the extent allowed by law"
Within the US, it can't waive rights thus this clause doesn't apply, though there is value in pointing out the data is public domain as I did. Internationally the government does potentially have rights, thus the importance of CC0.