Permissions by OA.Works


To learn more about Permissions jump to:

What is permissions checking? Why does it matter?

It’s understanding which version of your work you can deposit, where, how, and when. Depending on when you published, with which publisher, in which journal, and at which institution in which country, the answer can be quite different. Figuring this out is known as permissions checking, and it’s one of the biggest hurdles when self-archiving.

While we don’t talk about it much as a community, getting it right and making it easy stands between us and a transformation in how self-archiving is done. For authors and librarians alike, permissions checking is a complex and slow task, and there aren’t enough useful tools to help digest the myriad policies in order to obtain clear answers.

How it works

Information on how it works can be found on the homepage, and more specifics, including the schema can be found on this page. If you’d like to know more, send us a message and we’ll happily get back to you asap.


There are two major ways we need the community to help, but before you do please let us know who you are. You can:

  • Contribute individual policies—if you find that we don’t have a policy you are aware of, you can contribute it here.
  • Contribute in bulk—If you have a list of relevant policies you think we could use, we’d love to work with you to include them. Get in touch.

We’ll accept contributions from anyone; however, we ask that you identify who you are and that you source your information. We recommend contributing only if you are intimately familiar with what you’re contributing, e.g., you’re a trained scholarly communications practitioner or a journal editor / publisher.


  • Kenny Whitebloom and Sarah Wipperman at the University of Pennsylvania Libraries, whose work on the University of Pennsylvania’s Publisher Policy Database and structured permissions workflow provided essential sources and templates for this work. Their ongoing review and consultation were also crucial.
  • Peter Suber, who provided substantial review of this work and generously offered his time to talk us through properly using university policies. His careful documentation of these policies allowed their inclusion.
  • Leila Sterman, for her partnership on generally, and seemingly endless capacity for guidance and leadership.
  • Matt Ruen, Alicia Huber, Devin Soper, Ryan Otto, Kathryn Pope, Sherry Lake, Rachel Smart, and Antonin Delpeuch, who also conducted a substantial review and offered their ideas at an early stage of this work.
  • Ian Harmon, April Gilbert, and Katherine Howard, who reviewed the project at an early stage.
  • Natalia Norori, who manages the Open Access Button Request System. We'd also like to thank the alumni of the team, notably Chealsye Bowley and Sarah Melton, who taught us how to perform the process of permissions checking.
  • The work of SHERPA/RoMEO, who continue to contribute immensely to this area.

API Docs

Our free REST JSON API provides programmatic access to Permissions.

The API provides responses as shown in the schema, but it should be easy to understand most fields without it.

You don’t need to authenticate in order to use the API, but if you’re going to rely on it we recommend joining the mailing list for updates.

Support available from [email protected].

Base URL, nothing interesting here


Returns permissions information specific to a particular paper, together with relevant policies so that you can arrive at your own answers.

/:doi?affiliation=:ROR ID

Returns permissions information as above, together with the institutional policy in effect. Affiliations are specified as ROR IDs.


Returns all journal policies available in our database.


Returns a particular journal policy in our database that you need.


Returns all publisher policies available in our database


Returns a particular publisher policy in our database that you need


Returns all affiliations in our database that have self-archiving permissions attached.


Returns policies in our database associated with the affiliation you need.



Our schema and database do not directly track policies. We track permissions. Said another way, one line in our database doesn’t equate to a policy. One line is one permission. For us, a ‘permission’ is one way that self-archiving has been permitted by an institution. A policy may contain many permissions, and our database aims to capture them in a machine usable format. For example, a policy may give permission to self archiving a postprint in an institutional repository after 12 months with a certain statement and license. This is one permission. The same policy may also say you can self-archive on your personal website, immediately, without a statement or license. To describe the whole policy in a machine readable format is difficult. To describe the individual permissions in a machine readable format, and surface the appropriate permission at the appropriate time is easier. Currently, we focus on permissions to self-archive a postprint in an institutional repository.

We have a shared data schema across our database and APIs, although some elements are only present in one part or the other. The schema is subject to change, both as we change it, and at short notice when publishers change their policy. In either case, efforts will be made to avoid breaking changes.

The API responses, and data within it, come in a few major sections. First, at the highest level, are permissions, as discussed above. The API details an ‘authoritative_permission’, which is our best attempt at identifying an accurate and advantageous permission. We generate a response that is specific to the DOI in question in these cases. We also provide ‘all_permissions’ which details all the available permissions in their raw form. Each permission has a schema as detailed below.


View the Schema here

Data Download

View Data Download Data

Occasionally, we upload a copy to Zenodo to ensure the dataset is archived and citable, you can find those here.


The back-end code driving the APIs can be found on Github, here. It will soon be moved and joined with other code.

The database is managed in a Google Sheet; it does not contain any interesting code, only raw data that can be downloaded. You’re welcome to use the Google Sheet code and formulas currently used for the bulk checker.


We have lots of plans. Some of the highlights include:

  • Refine API response
  • Including copyright ownership and deeper licensing information
  • Getting to 100 percent coverage of publisher policies for journal articles. We’re working down the list of publishers while exploring a data-driven approach to this task.
  • Interfaces allowing authors and libraries to obtain more information on a one-by-one basis in
  • Improving data coverage for conference proceedings and preprints.
  • Considering expanding the data schema where you can post, and providing terms for depositing in subject repositories and on author websites.
  • Streamlining querying even in the absence of a DOI, or with a Datacite DOI.

At any point, you can see what we’re up to using our Github issues.

If you have any requests, please let us know.


All data and information provided on this site is for informational purposes only. While New Venture Fund and its Scholarly Publishing and Academic Research Coalition ("SPARC") project have used their best efforts to ensure that the information provided on this site is accurate and complete, they make no legal representations as to the accuracy, completeness, suitability or validity of any data or information on this site and will not be liable for any errors or omissions in this data and information or for any losses, injuries or damages arising from its display or use. All information is provided on an as-is basis. The Open Access Button is an initiative of the Scholarly Publishing and Academic Research Coalition ("SPARC"), a project of the New Venture Fund.


We never thought we’d say this, but we love talking about permissions checking! If you’d like to chat, reach out.