Need to iron out a model ToS for APIs

[gbinal]

I've been meaning to work with folks on ironing out a model terms of service for agencies that feel a need for one for their developer hub. Now is the time.

• Here are existing developer ToS that agencies are using.
• Here is a vanilla copy of the common ToS in use.
• Pull requests and proposed language can go here.

@konklone @kinlane @gui

[gbinal]

From @kinlane - note http://www.apilicens.se/en/

[gbinal]

Note some unique elements in http://sftool.gov/developers/TermsOfUse, http://search.digitalgov.gov/tos.html, http://www.regulations.gov/#!developers;page=termsOfService, and https://my.usa.gov/terms-of-service.

[afeijoo]

The DigitalGov Search ToS is based on the ToS from FCC, CFPB, and Data.gov with several edits (such as the removal of the indemnification section and addition of the logos for attribution).

[sbma44]

Attribution requirements should be dropped.

In some cases attribution requirements can be difficult to comply with. What if I'm building a Twitter bot? IFTTT recipe? Command-line tool? IVR-configured alert service? Ambient sonification of the data? Some of these are silly ideas, but the underlying point is that it's difficult to anticipate all uses, and that attribution requirements raise the cost of using the data by reducing authors' flexibility. That means there'll be less use. This becomes doubly true when one understands that the data can undergo multiple additional transformations before reaching an end user. If each step adds a viral attribution requirement, untangling the end result is a mess.

There's no compelling need to make users affirmatively provide attribution and disclaim government endorsement. I see two rationales for such requirements: limiting liability and claiming credit. There will doubtless be plenty of limitations on liability elsewhere in the ToS; doing it here is redundant. Claiming credit for use of government services is an understandable motivation, particularly for forward-looking efforts like the API strategy, which could easily be asked to muster support for their continuation. But it's not a sufficient rationale, IMO. It's also out of line with most of our norms surrounding use of government services (imagine requiring a healthcare.gov URL on your cast after getting a broken arm set).

Prohibiting the implication of endorsement seems fine and probably even wise. Asking politely but not requiring attribution seems fine (we do this at Sunlight). Even specifying the form of attribution when one is optionally provided is okay. Attribution requirements are a bad idea.

[konklone]

@sbma44's comment is right on.

I'd go much further, though. I don't see any reason to have nearly any of these clauses. Public government information is copyright-free, and a public commons. An API, by virtue of it being a "service", isn't an opportunity to start asserting downstream control over how data is used, or to start limiting liability just because, or to say it can withdraw that information from you for any reason at its sole discretion.

---

Before getting into more holistic feedback, I'll cover the clauses in the current, widely deployed ToS that I find the most problematic:

Use

You may use any {{ agency }} API to develop a service or service to search, display, analyze, retrieve, view and otherwise 'get' information from {{ agency }} data.

Even though this is defined in an open way, and as written seems to just mean "this is read-only", there's no basis for a Use section at all for government information. Users can use the documented endpoints for whatever they wish. If the API describes a bunch of read-only endpoints, then the only thing they can do is 'get' information.

So as written, this section is unneeded and implies rights that a government information service does not and should not have.

Attribution

All services which utilize or access the API should display the following notice prominently within the application: "This product uses the {{ agency }} Data API but is not endorsed or certified by the {{ agency }}". You may use the {{ agency }} name or logos in order to identify the source of API content subject to these rules. You may not use the {{ agency }} name, logo, or the like to imply endorsement of any product, service, or entity, not-for-profit, commercial or otherwise.

@sbma44 covered this well in his feedback. Attribution requirements don't have a place in the US model of information publication -- this is one of the reasons why it's so important that from a copyright perspective, government data should be license-free. A service layer doesn't change this.

I'd add, though, that {{ agency }}'s objections about implying endorsement, well founded or not, have no place in an API ToS. If there are practical or legal problems with that, mechanisms to address them exist already, and don't need a ToS to define them. Having a "no endorsement" clause here serves only to chill downstream use.

In both cases - attribution, and endorsement - these are misusable levers, by which agencies can seek to control the reuse of information for reasons other than user abuse degrading the service.

Modification or False Representation of Content

You may not modify or falsely represent content accessed through the API and still claim the source is {{ agency }}.

This has the same problem as the clause above - if there's a problem with how someone is using your data like this, API terms are not the place to deal with it.

If someone made a FOIA request, got documents released to them by the agency, but modified them before publication, and falsely represented what the agency had released: what could that agency do? Lots of things: publicly challenging the citizen, releasing the original documents publicly, and otherwise revealing the republisher of that information as dishonest.

None of them require anyone to sign a contract in advance, and no contract is required here.

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 the {{ agency }}. If the {{ agency }} reasonably believes that you have attempted to exceed or circumvent these limits, your ability to use the API may be permanently or temporarily blocked. The {{ agency }} may monitor your use of the API to improve the service or to insure compliance with this Agreement.

This is the closest thing there is to an acceptable clause, in that it appears to be attempting to manage abuse.

However, even here, the clause is much too broad. It never uses the word "abuse", or says why such limits would be in place. Any limits the API imposes on users should be narrowly defined, with a clear intent of why the limits are in place.

Finally, you don't need anyone to contractually agree to be limited. If the reasons you might limit someone are clear and well-intentioned, then a declaration that this is what you're doing, whether or not Terms have been Agreed to, should easily withstand public scrutiny.

Service Termination

If you wish to terminate this Agreement, you may do so by refraining from further use of the API. The {{ agency }} reserves the right (though not the obligation) to (1) refuse to provide the API to you, if it is the {{ 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, indemnity, and limitations of liability.

The {{ agency }} reserves the right to terminate someone public access to public information, for any reason, in its sole discretion? This is hostile language, and would never fly when publishing government information in any other form. There's no reason to include language like this simply because the delivery mechanism is an API.

Changes

The {{ agency }} reserves the right, at its sole discretion, to modify or replace this Agreement, in whole or in part. Your continued use of or access to the API following posting of any changes to this Agreement constitutes acceptance of those modified terms. The {{ agency }} may, in the future, offer new services and/or features through the API. Such new features and/or services shall be subject to the terms and conditions of this Agreement.

@sbma44 opened #3 to discuss this issue, and I agree entirely with his statement that this clause is "at best unkind and at worst unenforceable." My cronjob is not signing contracts on my behalf every time it makes a request to an agency's API.

Including an RSS feed of ToS changes is a great idea, as is emailing users. But there's an easier way (not mutually exclusive with those) to handle this problem: don't make the ToS a contract at all. More on this below.

General Representations

You hereby warrant that (1) your use of the API will be in strict accordance with the {{ agency }} privacy policy, this Agreement, and all applicable laws and regulations, and (2) your use of the API will not infringe or misappropriate the intellectual property rights of any third party.

If there are intellectual property concerns between a downstream user of an agency's API and some third party, that can be handled between them, outside of the Terms of Service. There's no reason the agency need be involved.

As written, an agency could cite this section in yanking access to someone who used the API to make a mashup that they believed to be in good faith and legal, but which a copyright owner raised a complaint about. Giving the agency a stake and lever in downstream use of the data is a bad idea.

Disclaimer of Warranties Limitations on Liability Indemnification

Regarding the clauses identified by the above 3 headers -

For APIs that distribute information to the public, there is absolutely no reason the government need limit their liability. The government doesn't get limited liability when satisfying a FOIA request, or publishing to the Federal Register, or managing a DMV.

Miscellaneous Disputes No Waiver of rights

These 3 clauses are just defensive legal boilerplate. They serve only to protect an agency from the public, when no such protection is required or deserved. These clauses are never at play in non-digital government services - they have no business here.

---

Overall, this commonly used ToS is maximalist and defensive. It's missing an opportunity to inspire and encourage people to make the most of their public infrastructure.

A ToS for an API like this should only contain language that's specifically and technically necessary to manage an API. And for the government, the burden of what's necessary is much higher than the private sector. All you need to do is describe how you're going to keep your API up and running and serving the public's needs. No contract is needed for that: just publication of your management practices.

So, I've submitted a pull request here, at #4, with a proposed, rewritten Terms of Service. In fact, it's no longer titled "Terms of Service".

Rather than being a contract that affects what the user can do, this document is a description of what the agency will do.

It also goes out of its way to state that use of the API is unlimited and unrestricted.

This positively changes the relationship between citizens and their government to an open and respectful one. Additionally, by changing the document from a contract to a description also seriously lessens the pressure on the language to be precise, defensive, and militarized.

Even with that lessened pressure, I'm sure the language needs further work. But we should be able to do better than requiring a Serious Contract for citizens to make use of public government information.

When it comes to the US government, API terms of service should never be used to control citizen use, and API keys should never serve as a lever for anything but analytics collection, and abuse enforcement.

[sbma44]

strong +1 to what @konklone said about the Use section.

I would personally take a softer line on the contractiness question but I don't want to get in his way :-)

[dsmorgan77]

@konklone i respectfully disagree with your point about the Service Termination clause. Reference OMB Memorandum M-05-04, attachment, item 2(b)

Agencies must reasonably assure suitable information and service quality, consistent with the level of importance of the information. Reasonable steps include: 1) clearly identifying the limitations inherent in the information dissemination product (e.g., possibility of errors, degree of reliability, and validity) so users are fully aware of the quality and integrity of the information or service, 2) taking reasonable steps to remove the limitations inherent in the information, and 3) reconsidering delivery of the information or services.

Reconsidering the delivery of information or services includes anything up to and include termination of the service, should an agency determine that the service is no longer suitable or of quality.

This brings me to my larger point - why not simply state that all the provisions of the agency's Web policy are incorporated by reference and only focus on terms that are specific to services (such as APIs) for this exercise?

With respect to attribution, I agree that, in general, attribution requirements are not to be placed on government information. Again, however, I reiterate that there is conflicting guidance from the Administration on this point, and we're having this debate on project open data. I reiterate that there are instances where an attribution requirement is warranted, as outlined by the OSTP memorandum on increasing access to federally-funded research results (http://www.whitehouse.gov/sites/default/files/microsites/ostp/ostp_public_access_memo_2013.pdf). Page 5, item (h) clearly directs agencies to:

Develop approaches for identifying and providing appropriate attribution to scientific data sets that are made available under the plan

I agree that this is an edge case in the current environment, but it's policy and we have to acknowledge the reality of it.

[knowtheory]

Just to reinforce the point:

Does the GSA have a ToS on it's website? (if it does, i can't find it) If you're dealing with a read-only API, then from a technical perspective, you aren't doing anything different than just running a plain old government website. The only difference is that instead of serving HTML, you serve JSON or XML or whatnot.

If i'm scraping or crawling the GSA site (or another gov site), what guidelines am I currently constrained by (in the opinion of the GSA)? How/why should that differ from when i access an API?

[JoshData]

No surprise, I echo @sbma44 and @konklone's concerns.

Let's look at this through the lens of M-13-13. And let's make it easy and just consider data produced by a contractor (so copyrighted). And let's use the "Open Definition" to understand what M-13-13 meant by open licensing of copyrighted data. Things that violate open: requiring the user to say " 'but is not endorsed or certified by the {{ agency }}' ", the Modification or False Representation of Content terms, termination at sole discretion (violates non-discrimination), continued use of the API constituting acceptance of an agreement that the party has obviously not read, all of General Representations, and possibly the indemnification and dispute resolution terms (though on these last two I am less sure).

If we're talking about a read-only open data API, then API guidelines should cover what happens from the time the user opens the TCP connection to the server to the time that connection is closed. What the user does after in his or her life after the API call finishes should be treated the same way other open data is treated.

[sbma44]

@dsmorgan77 if only OMB memos were actually obeyed with such regularity!

But seriously, the document you link to concerns one particular class of data, and it only instructs agencies to develop a plan for identifying and attributing the data. That's pretty weak, and could plausibly be interpreted in ways that don't touch the data release itself one bit. Perhaps more to the point, the political dynamics surrounding open access scientific publishing are quite different from the ones that prospective API maintainers face.

This example speaks to the breadth of your knowledge on this topic, but I think it's a peripheral case that will do more to confuse than illuminate this debate.

[dsmorgan77]

@sbma44 that's fair, but i don't want the debate to conclude that government data can never require attribution - and if you want a real-life example, check out http://wdc.cuahsi.org/index.html and the data use and publication terms here (http://cuahsihis.blogspot.com/p/data-use-and-publication-agreement.html). it's government-funded science, there are web services, it's copyrighted, it disclaims NSF endorsement, and it requires attribution. and under the holdren memo (AND M-13-13), it'll have to be inventoried.

if we're having this debate about government-owned and government-published information from via .gov Web services, i get the attribution argument - and quite frankly, i agree with it. but let's be crisp about what we're talking about - "government data" is too broad a term and includes the stuff covered by the holdren memo.

[benbalter]

There are two major buckets of users:

1. Civic hackers, who are primarily concerned with data rights, and whom I'd hope, a decade from now would be a minority edge case
2. Small (or large) businesses who depend on the government data for their business model

It sounds like @konklone's primarily optimizing for the former at the expense of the latter. Semantics aside, a document governing the relationship between data producers and data consumers needs to do two things:

1. Let developers know what they can and can't do (manage expectations) — the thing humans read
2. Limit liability — the thing lawyers read

Even though this is defined in an open way, and as written seems to just mean "this is read-only",

For context, the document, as originally written (three years ago) was for a read-only API, and the language reflects that. It should be flexible enough for both.

if there's a problem with how someone is using your data like this, API terms are not the place to deal with it.

See number one above. One motivation is to let developers know what they can and can't expect to do with your data.

None of them require anyone to sign a contract in advance, and no contract is required here... don't make the ToS a contract... Rather than being a contract that affects what the user can do, this document is a description of what the agency will do.

You call call it whatever you want, but legally, it's a contract, specifically a clickwrap agreement. A license is a contract as well. It's a document which describes the legal relationship between parties.

Reserves the right to terminate someone public access to public information, for any reason, in its sole discretion? This is hostile language, and would never fly when publishing government information in any other form... or to say it can withdraw that information from you for any reason at its sole discretion.

The difference between foo.gov going down, and api.foo.gov going down is that if foo.gov goes down, you may not be able to visit the government website. When api.foo.gov goes down, and companies have built business models models on that data, there's a financial impact. Absent a disclaimer to the contrary, the relationship would be subject to implied warranties such as fitness for a particular purpose, and could expose the agency to liability if the API did not last into perpetuity.

Finally, you don't need anyone to contractually agree to be limited. If the reasons you might limit someone are clear and well-intentioned, then a declaration that this is what you're doing, whether or not Terms have been Agreed to, should easily withstand public scrutiny.

Good intentions don't carry weight when another party has relied on your manifest representations to their detriment (or if you implicitly endorse their behavior through knowledge and inaction). I'm a company that has been making 3000 requests an hour for a while. If due to budget constraints, an agency decides form now on to limit requests to 2000 an hour, it doesn't matter how well intentioned the limit is, the agency be subject to liability. "No hard feelings" is not a defence of tort.

It also goes out of its way to state that use of the API is unlimited and unrestricted.

Use is not, and should not be unlimited and unrestrictive. One clear limit is abuse. This isn't an IP restriction, but a restriction none the less. Don't conflict data rights in the output of the API and rights in the API itself.

If there are intellectual property concerns between a downstream user of an agency's API and some third party, that can be handled between them, outside of the Terms of Service.

You're assuming all data published via the API will be government work (which is not, itself public domain). Agency may choose to publish restricted data via the API, and would use this clause to force the down-stream consumer to indemnify the agency against the data provider.

There's no compelling need to make users affirmatively provide attribution and disclaim government endorsement.

Again, part of this is not what's legally required (motivation two), but not requiring a data consumer to have a legal degree to understand what they can and can't do with the data. There are a handful of reasons for making it clear when something is the "official" government version, and when it's a third-party representation of that information. For one, relying on the published statement of a government agency can be a defense in many cases. For another, you don't want someone publishing alternate versions of laws under the guise that their the real deal.

Agree though, that affirmatively disclaiming government endorsement is a bit much (not implying would be better), and attribution doesn't solve for veracity.

[JoshData]

@benbalter wrote: It sounds like @konklone's primarily optimizing for the former at the expense of the latter.

I'd like to see a future in which more civic hackers are running businesses that rely on gov data for their business model. If we optimize for a world in which civic hacking using gov APIs is impossible because we have to waive rights in order to access the data, then civic hacking will become the minority as you predict.

[sbma44]

@benbalter I think I agree on all points until the end, where the attribution argument gets a little muddled. Prohibitions on claims of endorsement/authority seem fine; requiring affirmative statements disclaiming these is an unnecessary imposition (I think you acknowledge this, though?).

Mostly my dander's up over the "fake version of laws" argument, I admit. This comes up again and again when talking to people from Congress. As far as I can tell it has never happened -- not once. And if it did, everyone would know where to go for the canonical source. I don't particularly mind telling people they can't do this, I suppose, but it's hard to imagine a scenario under which it would be a real problem that a ToS (as opposed to a fraud prosecution) would be useful for resolving or preventing.

[JoshData]

And to the extent anyone is making up the laws, we're all ON THIS THREAD. :) Between @sbma44, @konklone, and I, we routinely modify the law (generally non-substantively) before displaying it to millions of Americans. To correct Tom, it does happen and that's what the public wants.

[konklone]

It sounds like we can break up the clauses into a few different groups.

Service management: Right to Limit, Service Termination

Limitations on end use: Use, Attribution, Modification or False Representation of Content, and General Representations.

Contract enforcement/meta: Scope, Changes, Miscellaneous, Disputes, and No Waiver of Rights

Limiting agency liability: Disclaimer of Warranties, Limitations on Liability, Indemnification, and Disputes (assuming "federal courts only" is intended to be limiting)

If people agree with my grouping, it's probably worth creating separate tickets to discuss each of them. But here's how I'd argue we should think of them.

Service management: Right to Limit, Service Termination

Service management policies should be clear of intent, reasonable, and non-discriminatory.

Catch-all language, "we can shut down anyone for any reason", is in clear tension with this. Agencies should be able to produce a justification for revoking access to an API user that complies with a stated intent.

Limitations on end use: Use, Attribution, Modification or False Representation of Content, and General Representations.

There should be no limitations on end use of any kind. As @JoshData said: "If we're talking about a read-only open data API, then API guidelines should cover what happens from the time the user opens the TCP connection to the server to the time that connection is closed."

I disagree strongly that prohibitions of claims of endorsement or authority are reasonable. If API users misrepresent the data in inappropriate ways, that should be handled outside of the terms of use of a public data source. Whatever way an agency would handle misrepresentation of FOIA response materials, that's how they'd handle it here. There's nothing different about an API in this regard.

In other words, all of these should be struck.

Contract enforcement/meta: Scope, Changes, Miscellaneous, Disputes, and No Waiver of Rights

I am (quite obviously) not a lawyer, and I'm certainly willing to offer some deference to those with greater understanding of implied contract and tort law.

To the extent that a contract is seen as necessary (and I continue to believe it's incumbent on the government to lead the way on avoiding requiring this), I'd like to see boilerplate clauses justified individually. Just slapping on terms because they show up on other big-name companies' terms just contributes to Terms of Service; Didn't Read culture.

Limiting agency liability: Disclaimer of Warranties, Limitations on Liability, Indemnification, and Disputes (assuming "federal courts only" is intended to be limiting)

@benbalter and others are saying that by simply operating an API and not disclaiming liability, an agency can be successfully sued for simple interruptions. @benbalter and others also know more than me about the law! So I can see why basic disclaimers would be warranted under those assumptions.

But I am honestly confused about where the line gets drawn between "well, we put some XLS files up, and they happen to be at completely predictable URLs" and a formal API that is now treated as Serious Business. I don't understand why the term "API" suddenly triggers a different set of legal responsibilities than other means by which governments serve the public information.

[johnwonderlich]

Page 5, item (h) clearly directs agencies to:

Develop approaches for identifying and providing appropriate attribution to scientific data sets that > are made available under the plan I agree that this is an edge case in the current environment, but it's policy and we have to acknowledge the reality of it.

The disagreement is over whether it's appropriate to require attribution as a condition of access. The policy you cited does not require that.

[konklone]

@johnwonderlich pointed me to this page by the USGS on how to credit them when using their data.

Relevant description, emphasis mine:

Most U.S. Geological Survey (USGS) information resides in the public domain and may be used without restriction. When using information from USGS information products, publications, or Web sites, we ask that proper credit be given. Acknowledging or crediting the USGS as an information source can be provided by including a line of text citation such as those shown below.

USGS says clearly that you can do whatever you want, but it stating their preference. That's fantastic - of course, attribution is polite and helpful in a lot of cases. Binding requirement is a whole different matter.

[gbinal]

This is great collaboration, folks. I've taken much of this and am trying to frame more of it around this readme, but definitely could use folks help in offering up alternates. @dsmorgan77, @JoshData, @sbma44, @benbalter - are you game to create new files in this folder with your suggested variants? @johnwonderlich, @knowtheory - game to give feedback on them via pull requests or offer up competing variants?

[seanherron]

Putting this out there as a draft that I would love to open up to feedback. Not committing this to the repo yet as it's literally hot off the presses, but would love input. Tried to take a lot of the comments from @konklone @gbinal @benbalter. The objective here is to:

1. Clearly define separation between data usage rights (public domain) and the service through which you access that data
2. Limit liability if access goes down for some reason
3. Clearly define the types of limits the agency will place on users

API Terms of Service Agreement

The U.S. AGENCY ("AGENCY”) offers some of its public data in machine-readable format through an API, 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”). 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” , or Application Programming Interface) 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.

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.

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.

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.

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.

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.

[konklone]

I think this is fantastic work. Thank you for being game to share a draft, @seanherron.

Framing usage restrictions as a simple function of underlying license status (rather than any that can be applied above and beyond what copyright allows) is totally the right direction -- and licensing that data under CC0 wherever possible is the perfect complement. Even when an agency is unable or unwilling to dedicate their data to the public domain internationally, drawing that distinction between copyright and service restrictions is incredibly helpful.

The addition of "These limitations are designed to manage load on the system, promote equitable access, and prevent abuse." to the Right to Limit section also makes a huge difference.

Overall, I think this draft much more closely reflects the spirit of open data in the United States. Where agencies feel the need to disclaim liability and have users agree to terms of service, this draft makes an excellent model.

[HobokenMartha]

I think this is great.

As a past legal proofreader and current digital content editor, might I suggest spelling out everything before giving it an acronym? I realize this is boilerplate, but it always helps people to understand what they're reading. So: application programming interface (API).

On Thu, Apr 3, 2014 at 12:35 PM, Eric Mill notifications@github.com wrote:

I think this is fantastic work. Thank you for being game to share a draft, @seanherron https://github.com/seanherron.

Framing usage restrictions as a simple function of underlying license status (rather than any that can be applied above and beyond what copyright allows) is totally the right direction -- and licensing that data under CC0 wherever possible is the perfect complement. Even when an agency is unable or unwilling to dedicate their data to the public domain internationally, drawing that distinction between copyright and service restrictions is incredibly helpful.

The addition of "These limitations are designed to manage load on the system, promote equitable access, and prevent abuse." to the Right to Limit section also makes a huge difference.

Overall, I think this draft much more closely reflects the spirit of open data in the United States. Where agencies feel the need to disclaim liability and have users agree to terms of service, this draft makes an excellent model.

Reply to this email directly or view it on GitHubhttps://github.com/GSA/API-Resources/issues/1#issuecomment-39473844 .

Martha Garvey Writer/Editor/Digital Strategy

---

Web Editorial Director @ Ogilvy Books: My Fat Dog, Hatherleigh Presshttp://www.amazon.com/My-Fat-Dog-Simple-Weight/dp/1578261988/ref=sr_1_1?ie=UTF8&qid=1307200305&sr=8-1 My Fat Cat, Hatherleigh Presshttp://www.amazon.com/My-Fat-Cat-Simple-Weight/dp/157826197X/ref=ntt_at_ep_dpt_1 Yarnbombing Documentary: Looons Create Art or Else http://bit.ly/looons http://www.linkedin.com/in/marthagarvey

[seanherron]

Good point @HobokenMartha. I actually did a find-and-replace to change another term (the name of a service being created) to "API" to make this more generic, but some of the grammar got messed up as a result. Edited my content to reflect your comment.

[benbalter]

Putting this out there as a draft that I would love to open up to feedback. Not committing this to the repo yet

@seanherron maybe it'd be more productive to move the proposed content to a pull request where it can have a dedicated discussion space, line-by-line comments, etc rather than a comment buried half way down an issue?

[seanherron]

Fineeeee @benbalter

[gbinal]

A quick sidenote to add in a post from Kin on this, a while back -

http://apivoice.com/2012/08/30/crowdsourced-api-terms-of-service/

[gbinal]

Thanks, everyone for contributing to this effort. I've updated the readme to reflect all of the work that went into this. I'm closing this issue but feel free to file further issues or offer pull requests.