Request for contributions

Standard for Public Code

hands shaking

Draft
Version 0.8.0

Licensed CC0 Digital Public Goods approval badge

github.com/standard-for-public-code/standard-for-public-code

Authors

Table of Contents

  1. Authors
  2. Readers guide
  3. Glossary
  4. Criteria
    1. Code in the open
    2. Bundle policy and source code
    3. Make the codebase reusable and portable
    4. Welcome contributors
    5. Make contributing easy
    6. Maintain version control
    7. Require review of contributions
    8. Document codebase objectives
    9. Document the code
    10. Use plain English
    11. Use open standards
    12. Use continuous integration
    13. Publish with an open license
    14. Make the codebase findable
    15. Use a coherent style
    16. Document codebase maturity
  5. Contributing guide
  6. Code of conduct
  7. Governance
  8. Version history
  9. License
codebase

Readers guide

The Standard describes a number of criteria. All criteria have consistent sections that make it clear how to create great public code.

References to “policy makers”, “managers”, and “developers and designers” apply to anyone performing duties associated with these roles, regardless of their job title. It is common for individuals to have duties which span multiple roles.

Below is a brief explanation of each of these sections and how they are used within the criteria of the Standard.

Introduction

This section explains what the criterion aims to achieve and why it is important for a codebase’s users and contributors.

Requirements

This section lists what needs to be done in order to comply with the standard.

The following keywords in this document are to be interpreted as described in IETF RFC 2119:

How to test

This section offers actions you can take to see if a contribution is compliant with the Standard. This is key if you want to operationalize the Standard.

We’ve tried to word it so that someone who is not intimately acquainted with the subject matter can still do a basic check for compliance.

Public policy makers: what you need to do

This section tries to specifically speak to policy makers by offering them concrete actions they can perform in their role.

Public policy makers set the priorities and goals of projects and may be less technologically experienced.

Managers: what you need to do

This section tries to specifically speak to managers by offering concrete actions they can perform in their role.

Managers are responsible for on-time project delivery, stakeholder management and continued delivery of the service. For this they are wholly reliant on both policy makers as well as developers and designers. They need to create the right culture, line up the right resources and provide the right structures to deliver great services.

Developers and designers: what you need to do

This section tries to specifically speak to developers and designers by offering them concrete actions they can perform in their role.

Developers are usually more technically aligned and have more impact on the delivery of services than the previous groups.

Limitation of scope

The Standard for Public Code is not meant to cover individual implementations of a codebase. This means the standard does not tell implementers how to comply with their organization’s local technical infrastructure or legal framework.

Also, while the Standard for Public Code refers to several standards and has considerable overlap with others, its purpose is to enable collaboration. Therefore, it does not aim to replace quality standards, like the ISO 25000 series, or those focusing on security, like the OpenSSF Best Practices Badge, but to synergize well with them.

And while the purpose includes enabling collaboration, it will not guarantee that a community will spring into existence. That still requires proactiveness and ambition beyond making the codebase collaboration ready.

Glossary

Code

Any explicitly described system of rules. This includes laws, policy and ordinances, as well as source code that is used to build software. Both of these are rules, some executed by humans and others by machines.

Codebase

Any discrete package of code (both source and policy), the tests and the documentation required to implement a piece of policy or software.

This can be, for example, a document or a version-control repository.

Continuous integration

In software engineering, continuous integration (CI) is the practice of merging all developers’ working copies to a development branch of a codebase as frequently as reasonable.

Different contexts

Two contexts are different if they are different public organizations or different departments for which there is not one decision maker that could make collaboration happen naturally.

General public

The public at large: end users of the code and the services based upon it.

For example, a city’s residents are considered end users of a city’s services and of all code that powers these services.

Open source

Open source is defined by the Open Source Initiative in their Open Source Definition.

Open standard

An open standard is any standard that meets the Open Source Initiative’s Open Standard Requirements.

Policy

A policy is a deliberate system of principles to guide decisions and achieve rational outcomes. A policy is a statement of intent, and is implemented as a procedure or protocol. Policies are generally adopted by a governance body within an organization. Policies can assist in both subjective and objective decision making.

Public policy is the process by which governments translate their political vision into programs and actions to deliver outcomes.

At the national level, policy and legislation (the law) are usually separate. The distinction is often more blurred in local government.

In the Standard the word ‘policy’ refers to policy created and adopted by public organizations such as governments and municipalities.

Public code

Public code is open source software developed by public organizations, together with the policy and guidance needed for collaboration and reuse.

Public code is both computer source code (such as software and algorithms) and public policy executed in a public context, by humans or machines.

Public code serves the public interest, is open, legible, accountable, accessible and sustainable.

By developing public code independently from but still implementable in the local context for which it was developed, as well as documenting the development process openly, public code can provide a building block for others to:

To facilitate reuse, public code is either released into the public domain or licensed with an open license that permits others to view and reuse the work freely and to produce derivative works.

Repository

A repository is a storage location used by version control tools for files and metadata of a codebase. Repositories allow multiple contributors to work on the same set of files. Repositories are able to store multiple versions of sets of files.

Source Code

Human readable text of a computer program which can be translated into machine instructions.

Version control

Version control is the management of changes to source code and the files associated with it. Changes are usually identified by a code, termed the revision number (or similar). Each revision is associated with the time it was made and the person making the change, thus making it easier to retrace the evolution of the code. Revision control systems can be used to compare different versions with each other and to see how content has changed over time.

Criteria

  1. Code in the open
  2. Bundle policy and source code
  3. Make the codebase reusable and portable
  4. Welcome contributors
  5. Make contributing easy
  6. Maintain version control
  7. Require review of contributions
  8. Document codebase objectives
  9. Document the code
  10. Use plain English
  11. Use open standards
  12. Use continuous integration
  13. Publish with an open license
  14. Make the codebase findable
  15. Use a coherent style
  16. Document codebase maturity
unlock

Code in the open

Coding in the open improves transparency, increases source code quality, makes the source code easier to audit, and enables collaboration.

Together, this creates more opportunities for citizens to understand how software and policy impact their interactions with a public organization.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Bundle policy and source code

Access to both source code and policy documentation provides building blocks for anyone to implement the codebase in their local context or contribute to the further development of the codebase.

Understanding the domain and policies within that domain is fundamental to understanding what problems a codebase is trying to solve and how it sets out to solve them.

To be able to evaluate whether to implement a codebase in a new context, an organization needs to understand what process changes it must choose to make or how to contribute additional configurability to the existing solution in order to adapt it to the new context.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Make the codebase reusable and portable

Creating reusable and portable code enables policy makers, developers and designers to reuse what has been developed, test it, improve it and contribute those improvements back, leading to better quality, cheaper maintenance and higher reliability.

Thoughtfully and purposefully designing a codebase for reusability allows for the mission, vision and scope of the codebase to be shared by multiple parties. Codebases developed and used by multiple parties are more likely to benefit from a self-sustaining community.

Organizing a codebase such that it is composed of well documented modules improves reusability and maintainability. A module is easier to reuse in another context if its purpose is clearly documented.

Source code which does not rely on the situation-specific infrastructure of any contributor, vendor or deployment can be tested by any other contributor.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Source should be designed:

Make sure that the codebase documentation describes the build-time and runtime dependencies. If your context requires deploying to proprietary platforms or using proprietary components, make sure that collaborators can develop, use, test, and deploy without them.

For each commit, reviewers verify that content does not include situation-specific data such as hostnames, personal and organizational data, or tokens and passwords.

Further reading

Welcome contributors

The atmosphere in a codebase community helps users decide to use one codebase over another. Welcoming anyone as a contributor enables the community to grow and sustain itself over time. A community where contributors have clear ways to influence codebase and community goals and progress is less likely to split and end up in diverging communities. Newcomers need to understand and trust the codebase community’s governance.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Make contributing easy

To develop better, more reliable and feature rich software, users need to be able to fix problems, add features, and address security issues of the shared codebase.

A shared digital infrastructure makes it easier to make collaborative contributions. The less effort it takes to make contributions that are accepted by the codebase, the more likely users are to become contributors.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Maintain version control

Version control means keeping track of changes to the source code and other files of the codebase over time. This allows you to maintain structured documentation of the history of the codebase. This is essential for collaboration at scale, as it enables developers to work on changes in parallel and helps future developers to understand the reasons for changes.

Requirements

How to test

Public policy makers: what you need to do

For example, adding a new category of applicant to a codebase that manages granting permits would be considered a policy change.

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Require review of contributions

Peer-review of contributions is essential for source code quality, reducing security risks and operational risks.

Requiring thorough review of contributions encourages a culture of making sure every contribution is of high quality, completeness and value. Source code review increases the chance of discovering and fixing potential bugs or mistakes before they are added to the codebase. Knowing that all source code was reviewed discourages a culture of blaming individuals, and encourages a culture of focusing on solutions.

A policy of prompt reviews assures contributors of a guaranteed time for feedback or collaborative improvement, which increases both rate of delivery and contributor engagement.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Document codebase objectives

Clearly documenting codebase objectives communicates the purpose of the codebase. It helps stakeholders and contributors scope the development of the codebase. The objectives also provide an easy way for people to decide whether this codebase, or one of its modules, is interesting for them now or in the future.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Document the code

Well documented source code helps people to understand what the source code does and how to use it. Documentation is essential for people to start using the codebase. It also makes contributing to the codebase easier.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Use plain English

English is the de facto language of collaboration in software development. However, some contexts require languages other than English. Therefore, a codebase can have a set of authoritative languages, including English.

Public sector information needs to be accessible to all its constituents. Plain and simple language makes the code and what it does easier to understand for a wider variety of people.

Translations further increase the possible reach of a codebase. Language that is easy to understand lowers the cost of creating and maintaining translations.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Use open standards

Open standards guarantee access to the knowledge required to use and contribute to the codebase. They enable interoperability between systems and reduce the risk of vendor lock-in. Open standards which are unambiguous allow for independent development of either side of data exchange.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Use continuous integration

Asynchronous collaboration is enabled by developers merging their work to a shared branch frequently, verified by automated tests. The more frequent the merging and the smaller the contribution, the easier it is to resolve merge conflicts.

Automated testing of all functionality provides confidence that contributions are working as intended and have not introduced errors, and allows reviewers to focus on the structure and approach of the contribution. The more focused the test, the easier it is to clearly identify and understand errors as they arise.

Documenting a codebase’s continuous integration workflow helps contributors understand the expectations of contributions. Continuous integration allows for an easier monitoring of the state of the codebase.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Publish with an open license

An open and well known license makes it possible for anyone to see the source code in order to understand how it works, to use it freely and to contribute to the codebase. This enables a vendor ecosystem to emerge around the codebase.

Clearly indicating the license for each file within a codebase facilitates correct reuse and attribution of parts of a codebase.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Make the codebase findable

The more findable a codebase is, the more potential new collaborators will find it. Just publishing a codebase and hoping it is found does not work, instead proactiveness is needed.

A metadata description file increases discoverability. Well-written metadata containing a unique and persistent identifier, such as a Wikidata item or FSF software directory listing (thus being part of the semantic web), makes the codebase easier for people to refer, cite, disambiguate and discover through third party tools.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Use a coherent style

Following a consistent and coherent style enables contributors in different environments to work together. Unifying vocabularies reduces friction in communication between contributors.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

If the codebase does not already have engineering guidelines or other contributor guidance, start by adding documentation to the repository describing whatever is being done now, for example in the CONTRIBUTING or README. An important purpose of the file is to communicate design preferences, naming conventions, and other aspects machines can’t easily check. Guidance should include what would be expected from source code contributions in order for them to be merged by the maintainers, including source, tests and documentation. Continually improve upon and expand this documentation with the aim of evolving this documentation into engineering guidelines.

Additionally:

Further reading

Document codebase maturity

Clearly signalling a codebase’s maturity helps others decide whether to use and contribute to it. A codebase version’s maturity includes the maturity of its dependencies. Understanding how a codebase has evolved is key to understanding the codebase and how to contribute to it.

Requirements

How to test

Public policy makers: what you need to do

Managers: what you need to do

Developers and designers: what you need to do

Further reading

Contributing to this standard

🙇‍♀️ Thank you for contributing!

We understand that a standard like this can only be set in collaboration with as many public technologists, policy makers and interested folk as possible. Thus we appreciate your input, enjoy feedback and welcome improvements to this project and are very open to collaboration.

We love issues and pull requests from everyone. If you’re not comfortable with GitHub, you can email use your feedback at info@publiccode.net.

Problems, suggestions and questions in issues

A high-level overview of the development that we already have sketched out can be seen in the roadmap. Please help development by reporting problems, suggesting changes and asking questions. To do this, you can create a GitHub issue for this project in the GitHub Issues for the Standard for Public Code.

Or, sign up to the mailing list and send an email to standard@lists.publiccode.net.

You don’t need to change any of our code or documentation to be a contributor!

Documentation and code in pull requests

If you want to add to the documentation or code of one of our projects you should make a pull request.

If you never used GitHub, get up to speed with Understanding the GitHub flow or follow one of the great free interactive courses in GitHub Skills on working with GitHub and working with MarkDown, the syntax this project’s documentation is in.

This project is licensed Creative Commons Zero v1.0 Universal, which essentially means that the project, along with your contributions is in the public domain in whatever jurisdiction possible, and everyone can do whatever they want with it.

1. Make your changes

Contributions should follow the requirements set out in the criteria of the Standard for Public code itself. Reviewers will also be ensuring that contributions are aligned with the values of public code. Furthermore, they will review that the contribution conforms to the standards and remains coherent with the overall work.

This project uses the GitFlow branching model and workflow. When you’ve forked this repository, please make sure to create a feature branch following the GitFlow model.

Add your changes in commits with a message that explains them. If more than one type of change is needed, group logically related changes into separate commits. For example, white-space fixes could be a separate commit from text content changes. When adding new files, select file formats that are easily viewed in a diff, for instance, .svg is preferable to a binary image. Document choices or decisions you make in the commit message, this will enable everyone to be informed of your choices in the future.

If you are adding code, make sure you’ve added and updated the relevant documentation and tests before you submit your pull request. Make sure to write tests that show the behavior of the newly added or changed code.

Applicable policy

Currently, the Standard for Public Code is not implementing any specific public policy.

Style

The Standard for Public Code aims to use plain English and we have chosen American English for spelling. Text content should typically follow one line per sentence, with no line-wrap, in order to make diff output easier to view. However, we want to emphasize that it is more important that you make your contribution than worry about spelling and typography. We will help you get it right in our review process and we also have a separate quality check before making a new release.

Standards to follow

These are the standards that the Standard for Public Code uses. Please make sure that your contributions are aligned with them so that they can be merged more easily.

2. Pull request

When submitting the pull request, please accompany it with a description of the problem you are trying to solve and the issue number that this pull request fixes. It is preferred for each pull request to address a single issue where possible. In some cases a single set of changes may address multiple issues, in which case be sure to list all issue numbers fixed.

3. Improve

All contributions have to be reviewed by someone. The Foundation for Public Code has committed to make sure that maintainers are available to review contributions with an aim to provide feedback within two business days.

It could be that your contribution can be merged immediately by a maintainer. However, usually, a new pull request needs some improvements before it can be merged. Other contributors (or helper robots) might have feedback. If this is the case the reviewing maintainer will help you improve your documentation and code.

If your documentation and code have passed human review, it is merged.

4. Celebrate

Your ideas, documentation and code have become an integral part of this project. You are the open source hero we need!

In fact, feel free to open a pull request to add your name to the AUTHORS file and get eternal attribution.

Languages and translations

The authoritative language of the Standard for Public Code is English.

Versions in other languages are provided by the community as best-effort. These courtesy translations may not be up to date with the English version, as missing translations do not block releases. We invite you to help maintain existing and add new community translations of the Standard.

Releases

We have dedicated documentation for creating new releases and ordering printed standards.

For more information on how to use and contribute to this project, please read the README.

collaborative-development

Code of Conduct

Many community members are from civic or professional environments with behavioral codes yet some individuals are not. This document expresses expectations of all community members and all interactions regardless of communication channel.

Be here to collaborate.

Be considerate, respectful, and patient.

Strive to be as constructive as possible.

To raise a concern, please email directors@publiccode.net.

collaboration

Governance.md

The Standard for Public Code is a community governed project.

Principles

The Standard for Public Code community adheres to the following principles:

Steering team

The community of Standard for Public Code has one steering team.

Composition

Any active contributor in the community can request to become a steering team member by asking the steering team. The steering team will vote on it (see voting below).

The current team members are:

Ideally, no single organization will employ a majority of the steering team.

Responsibilities

The steering team members are active contributors who are on a day-to-day basis responsible for:

Besides the day-to-day activities, the steering team has the joint responsibility to:

Meetings

The steering team meets regularly. Their agenda includes review of the roadmap and issues that are at an impasse. The intention of the agenda is not to review or approve all patches. (Reviewing and approving patches is done through the process described in CONTRIBUTING.md.)

Decision making process

The decision making process is consent as a default, and voting for certain matters.

For this community, “consent” means that if you think that a decision is uncontroversial you can just go ahead and make that decision. Any decision made this way is considered supported as long as no one objects. Of course, you have to be prepared to roll back your work if someone does object.

If there is uncertainty about a decision, a steering team member can inform the rest of the team that they are about to take a certain decision. If no team member objects within 96 hours, the decision is considered supported. If objections are made, and no solutions can be found through discussion, a team member can call for a majority vote on a decision, see below.

Voting

Every steering team member has 1 vote. All votes are recorded publicly.

Many of the day-to-day project maintenance tasks can be done with the consent decision-making process. But the following items must be called to vote:

By simple majority, we mean that at least half of the steering team members have voted in favor, and super majority two thirds of the steering team members.

Code of Conduct

The Standard for Public Code’s Code of Conduct is explained in CODE_OF_CONDUCT.md.

If the possible violation involves a team member that member will be recused from voting on the issue. Such issues must be escalated to the steering team contact, and the steering team may choose to intervene.

ecosystem

Version history

Version 0.8.0

January 9th 2024: 🌐 The 17th draft distinguishes between authoritative and courtesy translations.

Version 0.7.1

July 31st 2023: 💄 The sixteenth draft change the name of a criterion and clarifies references to code.

Version 0.7.0

May 31st 2023: 📑 the fifteenth draft adds new requirements for documenting review funding and clarifies review process requirement.

Version 0.6.0

April 20th 2023: 🔀 the fourteenth draft adds new requirements for portability and tests and an introduction to each criterion.

Version 0.5.0

January 25th 2023: 🎨 the thirteenth draft focuses on documenting style guidelines.

Version 0.4.1

December 5th 2022: 📝 the twelfth draft clarifies document maturity.

Version 0.4.0

September 7th 2022: 🔭 the eleventh draft adds a new findability criterion.

Version 0.3.0

May 23rd 2022: 🗎 the tenth draft strengthens documentation and localization.

Version 0.2.3

March 15th 2022: 📜 the ninth draft allows English summaries for policy lacking an official translation.

Version 0.2.2

November 29th 2021: 🏛 the eighth draft recognizes that policy which executes as code may not be in English.

Version 0.2.1

March 1st 2021: 🧽 the seventh draft has minor cleaning up after version 0.2.0.

Version 0.2.0

October 26th 2020: 🎊 the sixth draft splits a requirement and adds clarity.

Version 0.1.4

November 27th 2019: 🧹 the fifth draft consists mostly of additional minor fixes.

Version 0.1.3

October 8th 2019: 🍂 the fourth draft only patches and fixes minor things for the autumn cleaning

Version 0.1.2

August 22th 2019: 🌠 the third draft focuses on better text and takes community input

Version 0.1.1

May 9th 2019: 🤔 the second draft fixes a few basic oversights and fixes a lot of typos

Version 0.1.0

April 16th 2019: 🎉 the first draft is ready, it is all brand new and has snazzy new ideas in it

This first version was produced together with the Amsterdam University of Applied Sciences and the City of Amsterdam as a part of the Smart Cities? Public Code! project.

This license is the legal contract that allows anyone to do anything they like with the content in this entire document.

CC0 1.0 Universal

Creative Commons Legal Code

CC0 1.0 Universal

    CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
    LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
    ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
    INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
    REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
    PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
    THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
    HEREUNDER.

Statement of Purpose

The laws of most jurisdictions throughout the world automatically confer
exclusive Copyright and Related Rights (defined below) upon the creator
and subsequent owner(s) (each and all, an "owner") of an original work of
authorship and/or a database (each, a "Work").

Certain owners wish to permanently relinquish those rights to a Work for
the purpose of contributing to a commons of creative, cultural and
scientific works ("Commons") that the public can reliably and without fear
of later claims of infringement build upon, modify, incorporate in other
works, reuse and redistribute as freely as possible in any form whatsoever
and for any purposes, including without limitation commercial purposes.
These owners may contribute to the Commons to promote the ideal of a free
culture and the further production of creative, cultural and scientific
works, or to gain reputation or greater distribution for their Work in
part through the use and efforts of others.

For these and/or other purposes and motivations, and without any
expectation of additional consideration or compensation, the person
associating CC0 with a Work (the "Affirmer"), to the extent that he or she
is an owner of Copyright and Related Rights in the Work, voluntarily
elects to apply CC0 to the Work and publicly distribute the Work under its
terms, with knowledge of his or her Copyright and Related Rights in the
Work and the meaning and intended legal effect of CC0 on those rights.

1. Copyright and Related Rights. A Work made available under CC0 may be
protected by copyright and related or neighboring rights ("Copyright and
Related Rights"). Copyright and Related Rights include, but are not
limited to, the following:

  i. the right to reproduce, adapt, distribute, perform, display,
     communicate, and translate a Work;
 ii. moral rights retained by the original author(s) and/or performer(s);
iii. publicity and privacy rights pertaining to a person's image or
     likeness depicted in a Work;
 iv. rights protecting against unfair competition in regards to a Work,
     subject to the limitations in paragraph 4(a), below;
  v. rights protecting the extraction, dissemination, use and reuse of data
     in a Work;
 vi. database rights (such as those arising under Directive 96/9/EC of the
     European Parliament and of the Council of 11 March 1996 on the legal
     protection of databases, and under any national implementation
     thereof, including any amended or successor version of such
     directive); and
vii. other similar, equivalent or corresponding rights throughout the
     world based on applicable law or treaty, and any national
     implementations thereof.

2. Waiver. To the greatest extent permitted by, but not in contravention
of, applicable law, Affirmer hereby overtly, fully, permanently,
irrevocably and unconditionally waives, abandons, and surrenders all of
Affirmer's Copyright and Related Rights and associated claims and causes
of action, whether now known or unknown (including existing as well as
future claims and causes of action), in the Work (i) in all territories
worldwide, (ii) for the maximum duration provided by applicable law or
treaty (including future time extensions), (iii) in any current or future
medium and for any number of copies, and (iv) for any purpose whatsoever,
including without limitation commercial, advertising or promotional
purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each
member of the public at large and to the detriment of Affirmer's heirs and
successors, fully intending that such Waiver shall not be subject to
revocation, rescission, cancellation, termination, or any other legal or
equitable action to disrupt the quiet enjoyment of the Work by the public
as contemplated by Affirmer's express Statement of Purpose.

3. Public License Fallback. Should any part of the Waiver for any reason
be judged legally invalid or ineffective under applicable law, then the
Waiver shall be preserved to the maximum extent permitted taking into
account Affirmer's express Statement of Purpose. In addition, to the
extent the Waiver is so judged Affirmer hereby grants to each affected
person a royalty-free, non transferable, non sublicensable, non exclusive,
irrevocable and unconditional license to exercise Affirmer's Copyright and
Related Rights in the Work (i) in all territories worldwide, (ii) for the
maximum duration provided by applicable law or treaty (including future
time extensions), (iii) in any current or future medium and for any number
of copies, and (iv) for any purpose whatsoever, including without
limitation commercial, advertising or promotional purposes (the
"License"). The License shall be deemed effective as of the date CC0 was
applied by Affirmer to the Work. Should any part of the License for any
reason be judged legally invalid or ineffective under applicable law, such
partial invalidity or ineffectiveness shall not invalidate the remainder
of the License, and in such case Affirmer hereby affirms that he or she
will not (i) exercise any of his or her remaining Copyright and Related
Rights in the Work or (ii) assert any associated claims and causes of
action with respect to the Work, in either case contrary to Affirmer's
express Statement of Purpose.

4. Limitations and Disclaimers.

 a. No trademark or patent rights held by Affirmer are waived, abandoned,
    surrendered, licensed or otherwise affected by this document.
 b. Affirmer offers the Work as-is and makes no representations or
    warranties of any kind concerning the Work, express, implied,
    statutory or otherwise, including without limitation warranties of
    title, merchantability, fitness for a particular purpose, non
    infringement, or the absence of latent or other defects, accuracy, or
    the present or absence of errors, whether or not discoverable, all to
    the greatest extent permissible under applicable law.
 c. Affirmer disclaims responsibility for clearing rights of other persons
    that may apply to the Work or any use thereof, including without
    limitation any person's Copyright and Related Rights in the Work.
    Further, Affirmer disclaims responsibility for obtaining any necessary
    consents, permissions or other rights required for any use of the
    Work.
 d. Affirmer understands and acknowledges that Creative Commons is not a
    party to this document and has no duty or obligation with respect to
    this CC0 or use of the Work.