go-openapi

Common documentation for go-openapi projects

This site hosts the shared documentation that applies to all repositories in the go-openapi organization.

Rather than duplicating contributing guidelines, coding style, security policies and licensing across dozens of repositories, we maintain them here as a single source of truth.

What you’ll find here

For individual project documentation

Each go-openapi project has its own README and may publish additional project-specific documentation. The guidelines on this site apply uniformly unless a project’s own documentation states otherwise.

ProjectDescriptionGo docs
go-openapi/analysisSpec analyzer, flattener, mixer & differpkg.go.dev
go-openapi/codescanSpec generation from sourcepkg.go.dev
go-openapi/errorsCommon error typespkg.go.dev
go-openapi/inflectEnglish words pluralization (unused now)pkg.go.dev
go-openapi/jsonpointerjsonpointer that supports structspkg.go.dev
go-openapi/jsonreferencejson reference for gopkg.go.dev
go-openapi/loadsSpec loadingpkg.go.dev
go-openapi/runtimeRuntime middlewarepkg.go.dev
go-openapi/specOpenAPI 2.0 (Swagger) spec modelpkg.go.dev
go-openapi/strfmtString format validationspkg.go.dev
go-openapi/swagMisc. common utilitiespkg.go.dev
go-openapi/testifyTesting toolkit (testify/v2 fork)pkg.go.dev
go-openapi/validateOpenAPI spec & JSONSchema draft 4 validationpkg.go.dev
go-swagger/examplesExamples & tutorial using go-swagger
go-swagger/go-swaggerSwagger 2.0 implementation

Community

Discord Server

Join us on Discord for questions, discussions, and announcements.

Last edited by: fredbi Mar 20, 2026
Copyright 2015-2026 go-openapi maintainers. This documentation is under an Apache 2.0 license.

Subsections of go-openapi

Contributing to go-openapi

Guidelines for contributing to any go-openapi project.

There are many ways to help this project.

Contributing code is only one of those…

Last edited by: fredbi Mar 20, 2026
Copyright 2015-2026 go-openapi maintainers. This documentation is under an Apache 2.0 license.

Subsections of Contributing to go-openapi

Contributing Guidelines

You’ll find here general guidelines to contribute to go-openapi projects. They mostly correspond to standard practices for open source repositories.

We have tried to keep things as simple as possible.

TL;DR

If you’re an experienced go developer on github, then you should just feel at home with us and you may well skip the rest of this document.

You’ll essentially apply the usual guidelines for a go library project on github.

These guidelines are common to all libraries published on github by the go-openapi organization, so you’ll feel at home with any of our projects.

How can I contribute?

There are many ways in which you can contribute, not just code. Here are a few ideas:

  • Reporting issues or bugs
  • Suggesting improvements
  • Documentation
  • Art work that makes the project look great
  • Code
    • proposing bug fixes and new features that are within the main project scope
    • improving test coverage
    • addressing code quality issues

Questions & issues

Asking a question

You may inquire anything about this library by reporting a “Question” issue on github.

You may also join our discord server where you may discuss issues or requests.

Discord Server

Reporting issues

Reporting a problem with our libraries is a valuable contribution. You can do this on the github issues page of the relevant repository.

Please be as specific as possible when describing your issue.

Whenever relevant, please provide information about your environment (go version, OS).

Adding a code snippet to reproduce the issue is great, and a big time saver for maintainers.

Triaging issues

You can help triage issues which may include:

  • reproducing bug reports
  • asking for important information, such as version numbers or reproduction instructions
  • answering questions and sharing your insight in issue comments

Code contributions

Pull requests are always welcome

We are always thrilled to receive pull requests, and we do our best to process them as fast as possible.

Not sure if that typo is worth a pull request? Do it! We will appreciate it.

If your pull request is not accepted on the first try, don’t be discouraged! If there’s a problem with the implementation, hopefully you’ve received feedback on what to improve.

If you have a lot of ideas or a lot of issues to solve, try to refrain a bit and post focused pull requests. Think that they must be reviewed by a maintainer and it is easy to lose track of things on big PRs.

We’re trying very hard to keep the go-openapi packages lean and focused.

Together, these packages constitute a toolkit for go developers: it won’t do everything for everybody out of the box, but everybody can use it to do just about everything related to OpenAPI.

This means that we might decide against incorporating a new feature.

However, there might be a way to implement that feature on top of our libraries.

Environment

You just need a go compiler to be installed. No special tools are needed to work with our libraries.

The minimal go compiler version required is always the old stable (latest minor go version - 1).

Our libraries are designed and tested to work on Linux, MacOS and Windows.

If you’re used to work with go you should already have everything in place.

Although not required, you’ll be certainly more productive with a local installation of golangci-lint, the meta-linter our CI uses.

If you don’t have it, you may install it like so:

go install github.com/golangci/golangci-lint/v2/cmd/golangci-lint@latest

Conventions

Git flow

Fork the repo and make changes to your fork in a feature branch.

To submit a pull request, push your branch to your fork (e.g. upstream remote): github will propose to open a pull request on the original repository.

Typically you’d follow some common naming conventions:

  • if it’s a bug fixing branch, name it fix/XXX-something where XXX is the number of the issue on github
  • if it’s a feature branch, create an enhancement issue to announce your intentions, and name it feature/XXX-something where XXX is the number of the issue.

NOTE: we don’t enforce naming conventions on branches: it’s your fork after all.

Tests

Submit unit tests for your changes.

Go has a great built-in test framework ; use it!

Take a look at existing tests for inspiration, and run the full test suite on your branch before submitting a pull request.

Our CI measures test coverage and the test coverage of every patch.

Although not a blocking step - because there are so many special cases - this is an indicator that maintainers consider when approving a PR. Please try your best to cover at least 80% of your patch.

Code style

You may read our stance on code style there.

Documentation

Don’t forget to update the documentation when creating or modifying a feature.

Most documentation for our libraries is directly found in code as comments for godoc.


Check your documentation changes for clarity, concision, and correctness.

If you want to assess the rendering of your changes when published to pkg.go.dev, you may want to install the pkgsite tool proposed by golang.org.

go install golang.org/x/pkgsite/cmd/pkgsite@latest

Then run on the repository folder:

pkgsite .

This will run a godoc server locally where you may see the documentation generated from your local repository.

Commit messages

Pull requests descriptions should be as clear as possible and include a reference to all the issues that they address.

Pull requests must not contain commits from other users or branches.

Commit messages are not required to follow the “conventional commit” rule, but it’s certainly a good thing to follow that convention (e.g. “fix: fixed panic in XYZ”, “ci: did this”, “feat: did that” …).

The title in your commit message is used directly to produce our release notes: try to keep them neat.

The commit message body should detail your changes.

If an issue should be closed by a commit, please add this reference in the commit body:

* fixes #{issue number}

Code review

Code review comments may be added to your pull request.

Discuss, then make the suggested modifications and push additional commits to your feature branch.

Be sure to post a comment after pushing. The new commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment.

Before the pull request is merged, make sure that you’ve squashed your commits into logical units of work using git rebase -i and git push -f.

After every commit the test suite should be passing.

Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.

Sign your work

Software is developed by real people.

The sign-off is a simple line at the end of your commit message, which certifies that you wrote it or otherwise have the right to pass it on as an open-source patch.

We require the simple DCO below with an email signing your commit. PGP-signed commit are greatly appreciated but not required.

The rules are pretty simple:

using your real name (sorry, no pseudonyms or anonymous contributions.)

You can add the sign-off when creating the git commit via git commit -s.

Code contributions by AI agents

Our agentic friends are welcome to contribute!

We only have a few demands to keep-up with human maintainers.

  1. Issues and PRs written or posted by agents should always mention the original (human) poster for reference
  2. We don’t accept PRs attributed to agents. We don’t want commits signed like “author: @claude.code”. Agents or bots may coauthor commits, though.
  3. Security vulnerability reports by agents should always be reported privately and mention the original (human) poster (see also Security Policy).
Last edited by: fredbi Mar 20, 2026
Copyright 2015-2026 go-openapi maintainers. This documentation is under an Apache 2.0 license.

Developer's Certificate of Origin

TL;DR

We welcome this (simple email signature):

Author: Frederic BIDON <fredbi@yahoo.com>
Date:   Mon Dec 15 11:24:43 2025 +0100

    feat: brainstrom RAG-equipped linter
    
    Signed-off-by: Frederic BIDON <fredbi@yahoo.com>

or this (PGP-signed commit):

gpg: Signature made Tue 30 Dec 2025 09:53:48 PM CET
gpg:                using RSA key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
gpg: Good signature from "Frédéric BIDON <fredbi@yahoo.com>"
Author: Frederic BIDON <fredbi@yahoo.com>
Date:   Tue Dec 30 21:53:48 2025 +0100

    tentative project doc site
    
    Signed-off-by: Frederic BIDON <fredbi@yahoo.com>

From https://developercertificate.org/:

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
660 York Street, Suite 102,
San Francisco, CA 94110 USA

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.
Last edited by: fredbi Mar 20, 2026
Copyright 2015-2026 go-openapi maintainers. This documentation is under an Apache 2.0 license.

Coding Style

Coding style at go-openapi

TL;DR

Let’s be honest: at go-openapi and go-swagger we’ve never been super-strict on code style and linting.

But perhaps now (2025) is the time to adopt a different stance.

Even though our repos have been early adopters of golangci-lint years ago (we used some other metalinter before), our decade-old codebase is only realigned to new rules from time to time.

Now go-openapi and go-swagger together make up a really large codebase, which is taxing to maintain and keep afloat.

Code quality and the harmonization of rules have thus become things that we need now.

Meta-linter

Universally formatted go code promotes ease of writing, reading, and maintenance.

You should run golangci-lint run before committing your changes.

Many editors have plugins that do that automatically.

We use the golangci-lint meta-linter. The configuration lies in .golangci.yml at the root of each repository. You may read the linter’s configuration reference for additional reference.

This configuration is essentially the same across all go-openapi projects.

Some projects may require slightly different settings.

Linting rules posture

Thanks to go’s original design, we developers don’t have to waste much time arguing about code figures of style.

However, the number of available linters has been growing to the point that we need to pick a choice.

Our approach: evaluate, don’t consume blindly

As early adopters of golangci-lint (and its predecessors), we’ve watched linting orthodoxy shift back and forth over the years. Patterns that were idiomatic one year get flagged the next; rules that seemed reasonable in isolation produce noise at scale. Conversations with maintainers of other large Go projects confirmed what our own experience taught us: the default linter set is a starting point, not a prescription.

Our stance is deliberate:

  • Start from default: all, then consciously disable what doesn’t earn its keep. This forces us to evaluate every linter and articulate why we reject it – the disabled list is a design rationale, not technical debt.
  • Tune thresholds rather than disable when a linter’s principle is sound but its defaults are too aggressive for a mature codebase.
  • Require justification for every //nolint directive. Each one must carry an inline comment explaining why it’s there.
  • Prefer disabling a linter over scattering //nolint across the codebase. If a linter produces systematic false positives on patterns we use intentionally, the linter goes – not our code.
  • Keep the configuration consistent across all go-openapi repositories. Per-repo divergence is a maintenance tax we don’t want to pay.

The result is a three-layer defense: the .golangci.yml config as a baseline, //nolint with mandatory justification for the rare exceptions, and an audit trail for documentation. Contributors should read the disabled list as a set of conscious choices, not gaps to fill.

We enable all linters published by golangci-lint by default, then disable a few ones.

Here are the reasons why they are disabled (update: Feb. 2026, golangci-lint v2.8.0).

  disable:
    - depguard              # we don't want to configure rules to constrain imports. That's the reviewer's job
    - exhaustruct           # we don't want to configure regexp's to check type name. That's the reviewer's job
    - funlen                # we accept cognitive complexity as a meaningful metric, but function length is not relevant
    - godox                 # we don't see any value in forbidding TODO's etc in code
    - nlreturn              # we usually apply this "blank line" rule to make code less compact. We just don't want to enforce it
    - nonamedreturns        # we don't see any valid reason why we couldn't use named returns
    - noinlineerr           # there is no value added forbidding inlined err
    - paralleltest          # we like parallel tests. We just don't want them to be enforced everywhere
    - recvcheck             # we like the idea of having pointer and non-pointer receivers
    - testpackage           # we like test packages. We just don't want them to be enforced everywhere
    - thelper               # too many false positives on test case factories returning func(*testing.T). See note below
    - tparallel             # see paralleltest
    - varnamelen            # sometimes, we like short variables. The linter doesn't catch cases when a short name is good
    - whitespace            # no added value
    - wrapcheck             # although there is some sense with this linter's general idea, it produces too much noise
    - wsl                   # no added value. Noise
    - wsl_v5                # no added value. Noise

As you may see, we agree with the objective of most linters, at least the principle they are supposed to enforce. But all linters do not support fine-grained tuning to tolerate some cases and not some others.

Note on thelper: the only value we needed from this linter was checking for t.Helper() calls inside genuine test helpers. Unfortunately, it produces persistent false positives on test case factories (functions returning func(*testing.T)), which is a pattern we use extensively. It also enforces naming conventions we don’t subscribe to. The issue has been reported upstream. We prefer disabling it entirely over maintaining //nolint:thelper directives across every test file.

When this is possible, we enable linters with relaxed constraints.

  settings:
    dupl:
      threshold: 200        # in a older code base such as ours, we have to be tolerant with a little redundancy
                            # Hopefully, we'll be able to gradually get rid of those.
    goconst:
      min-len: 2
      min-occurrences: 3
    cyclop:
      max-complexity: 20    # the default is too low for most of our functions. 20 is a nicer trade-off
    gocyclo:
      min-complexity: 20
    exhaustive:             # when using default in switch, this should be good enough
      default-signifies-exhaustive: true
      default-case-required: true
    lll:
      line-length: 180      # we just want to avoid extremely long lines.
                            # It is no big deal if a line or two don't fit on your terminal.
Last edited by: fredbi Mar 20, 2026
Copyright 2015-2026 go-openapi maintainers. This documentation is under an Apache 2.0 license.

Code Of Conduct

Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.

Our Standards

Examples of behavior that contributes to creating a positive environment include:

  • Using welcoming and inclusive language
  • Being respectful of differing viewpoints and experiences
  • Gracefully accepting constructive criticism
  • Focusing on what is best for the community
  • Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

  • The use of sexualized language or imagery and unwelcome sexual attention or advances
  • Trolling, insulting/derogatory comments, and personal or political attacks
  • Public or private harassment
  • Publishing others’ private information, such as a physical or electronic address, without explicit permission
  • Other conduct which could reasonably be considered inappropriate in a professional setting

Our Responsibilities

Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

Scope

This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at ivan+abuse@flanders.co.nz. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.

Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project’s leadership.

Attribution

This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at https://contributor-covenant.org/version/1/4

Last edited by: fredbi Mar 20, 2026
Copyright 2015-2026 go-openapi maintainers. This documentation is under an Apache 2.0 license.

Maintainer's Guide

TL;DR

This guide covers the practices common to all go-openapi repositories: CI/CD workflows, release procedures, dependency management, and tooling.

Individual projects may document their repo structure and project-specific details in their own docs/MAINTAINERS.md.

Repo configuration

All go-openapi repositories follow the same baseline configuration:

  • Default branch: master
  • Protected branches: master
  • Branch protection rules:
    • require pull requests and approval
    • required status checks:
      • DCO (simple email sign-off)
      • Lint
      • All tests completed
  • Auto-merge enabled (used for dependabot updates and other auto-merged PR’s, e.g. contributors update)

Continuous Integration

CI workflows use a shared workflows setup defined in go-openapi/ci-workflows and shared GitHub Actions in go-openapi/gh-actions.

This approach gives us:

  • custom actions for installing vetted versions of tools
  • better control over updates
  • less noisy dependabot updates across the board (a single update per shared workflow instead of one per repository for every single action update)

Code Quality checks

NOTES

codefactor inherits roles from github. There is no need to create a dedicated account.

The codefactor app is installed at the organization level (github.com/go-openapi).

There is no special token to setup in github for CI usage.

Testing

  • Test reports

  • Test coverage reports

  • Fuzz testing

    • Fuzz tests are handled separately by CI and may reuse a cached version of the fuzzing corpus. At this moment, cache may not be shared between feature branches or feature branch and master. The minimized corpus produced on failure is uploaded as an artifact and should be added manually to testdata/fuzz/....

Coverage threshold status is informative and not blocking. This is because the thresholds are difficult to tune and codecov oftentimes reports false negatives or may fail to upload coverage.

Some repositories may have additional integration tests beyond the standard unit test suite (e.g. go-openapi/strfmt, go-openapi/analysis).

All tests across go-openapi use our fork of stretchr/testify: github.com/go-openapi/testify. This allows for minimal test dependencies.

NOTES

codecov inherits roles from github. There is no need to create a dedicated account. However, there is only 1 maintainer allowed to be the admin of the organization on codecov with their free plan.

The codecov app is installed at the organization level (github.com/go-openapi).

There is no special token to setup in github for CI usage. A organization-level token used to upload coverage and test reports is managed at codecov: no setup is required on github.

Automated updates

  • dependabot

    • configuration: .github/dependabot.yaml in each repository

    Principle:

    • dependabot applies updates and security patches to the github-actions and golang ecosystems.
    • all updates from “trusted” dependencies (github actions, golang.org packages, go-openapi packages) are auto-merged if they successfully pass CI.
  • go version updates

    Principle:

    • we support the 2 latest minor versions of the go compiler (stable, oldstable)
    • go.mod should be updated (manually) whenever there is a new go minor release (e.g. every 6 months).

    This means that our projects always have a 6 months lag to enforce new features from the go compiler.

    However, new features of go may be used with a “go:build” tag: this allows users of the newer version to benefit the new feature while users still running with oldstable use another version that still builds.

  • contributors

    • a CONTRIBUTORS.md file is updated weekly, with all-time contributors to the repository
    • the github-actions[bot] posts a pull request to do that automatically
    • at this moment, this pull request is not auto-approved/auto-merged (bot cannot approve its own PRs)

Vulnerability scanners

There are 3 complementary scanners - obviously, there is some overlap, but each has a different focus.

None of these tools require an additional account or token.

Github CodeQL configuration is set to “Advanced”, so we may collect a CI status for this check (e.g. for badges).

Scanners run on every commit to master and at least once a week.

Reports are centralized in github security reports for code scanning tools.

Releases

Single module repos

A bump release workflow can be triggered from the github actions UI to cut a release with a few clicks.

The release process is minimalist:

  • push a semver tag (i.e v{major}.{minor}.{patch}) to the master branch.

  • the CI handles this to generate a github release with release notes

  • release notes generator: git-cliff https://git-cliff.org/docs/

  • configuration: the .cliff.toml is defined as a shared configuration on remote repo ci-workflows/.cliff.toml

Commits from maintainers are preferably PGP-signed.

Tags are preferably PGP-signed.

We want our releases to show as “verified” on github.

The tag message introduces the release notes (e.g. a summary of this release).

The release notes generator does not assume that commits are necessarily “conventional commits”.

Mono-repos with multiple modules

The release process is slightly different because we need to update cross-module dependencies before pushing a tag.

A bump release workflow (mono-repo) can be triggered from the github actions UI to cut a release with a few clicks.

It works with the same input as the one for single module repos, and first creates a PR (auto-merged) that updates the different go.mod files before pushing the desired git tag.

Commits and tags pushed by the workflow bot are PGP-signed (“go-openapi[bot]”).

Standard documentation files

Every go-openapi repository should include:

  • CONTRIBUTING.md guidelines
  • DCO.md terms for first-time contributors to read
  • CODE_OF_CONDUCT.md
  • SECURITY.md policy: how to report vulnerabilities privately
  • LICENSE terms
  • NOTICE on supplementary license terms (when applicable: original authors, copied code etc)
  • MAINTAINERS.md: this document, plus possible repo-specific instructions

Reference documentation (released):

  • pkg.go.dev hosts the Go reference documentation for each package (see the individual package URLs in the project table)

AI coding agent support

Recent improvements across go-openapi repositories add documentation to support AI coding agents and improve their productivity. The goal is to guide agents so that code and contributions stay aligned with our standards.

Each repository may include the following instruction files:

  • AGENTS.md – top-level agent instructions (often a symlink to .github/copilot-instructions.md)
  • .github/copilot-instructions.md – instructions for GitHub Copilot
  • .claude/CLAUDE.md – instructions for Claude Code, with detailed rules under .claude/rules/

These files typically cover:

  • Go code conventions and formatting (license headers, supported Go versions, etc.)
  • Linting standards (golangci-lint configuration and //nolint policy)
  • Testing requirements (test framework, coverage targets, fuzz tests)
  • Contribution rules (DCO sign-off, commit hygiene, PR quality expectations)
  • GitHub workflow conventions (YAML style, action pinning, secret handling)

See for example the jsonpointer repository for a reference setup.

Last edited by: fredbi Mar 20, 2026
Copyright 2015-2026 go-openapi maintainers. This documentation is under an Apache 2.0 license.

Security Policy

This policy outlines the commitment and practices of the go-openapi maintainers regarding security.

It applies to all repositories in the go-openapi organization.

Vulnerability checks in place

Our repositories use automated vulnerability scans, at every merged commit and at least once a week.

We use:

Reports are centralized in github security reports and visible only to the maintainers.

Reporting a vulnerability

If you become aware of a security vulnerability that affects any go-openapi repository, please report it privately to the maintainers rather than opening a publicly visible GitHub issue.

Please follow the instructions provided by github to Privately report a security vulnerability.

TL;DR

On Github, navigate to the affected project’s “Security” tab then click on “Report a vulnerability”.

Last edited by: fredbi Mar 20, 2026
Copyright 2015-2026 go-openapi maintainers. This documentation is under an Apache 2.0 license.

LICENSE

                                 Apache License
                           Version 2.0, January 2004
                        http://www.apache.org/licenses/

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

      "License" shall mean the terms and conditions for use, reproduction,
      and distribution as defined by Sections 1 through 9 of this document.

      "Licensor" shall mean the copyright owner or entity authorized by
      the copyright owner that is granting the License.

      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or
      otherwise, or (ii) ownership of fifty percent (50%) or more of the
      outstanding shares, or (iii) beneficial ownership of such entity.

      "You" (or "Your") shall mean an individual or Legal Entity
      exercising permissions granted by this License.

      "Source" form shall mean the preferred form for making modifications,
      including but not limited to software source code, documentation
      source, and configuration files.

      "Object" form shall mean any form resulting from mechanical
      transformation or translation of a Source form, including but
      not limited to compiled object code, generated documentation,
      and conversions to other media types.

      "Work" shall mean the work of authorship, whether in Source or
      Object form, made available under the License, as indicated by a
      copyright notice that is included in or attached to the work
      (an example is provided in the Appendix below).

      "Derivative Works" shall mean any work, whether in Source or Object
      form, that is based on (or derived from) the Work and for which the
      editorial revisions, annotations, elaborations, or other modifications
      represent, as a whole, an original work of authorship. For the purposes
      of this License, Derivative Works shall not include works that remain
      separable from, or merely link (or bind by name) to the interfaces of,
      the Work and Derivative Works thereof.

      "Contribution" shall mean any work of authorship, including
      the original version of the Work and any modifications or additions
      to that Work or Derivative Works thereof, that is intentionally
      submitted to Licensor for inclusion in the Work by the copyright owner
      or by an individual or Legal Entity authorized to submit on behalf of
      the copyright owner. For the purposes of this definition, "submitted"
      means any form of electronic, verbal, or written communication sent
      to the Licensor or its representatives, including but not limited to
      communication on electronic mailing lists, source code control systems,
      and issue tracking systems that are managed by, or on behalf of, the
      Licensor for the purpose of discussing and improving the Work, but
      excluding communication that is conspicuously marked or otherwise
      designated in writing by the copyright owner as "Not a Contribution."

      "Contributor" shall mean Licensor and any individual or Legal Entity
      on behalf of whom a Contribution has been received by Licensor and
      subsequently incorporated within the Work.

   2. Grant of Copyright License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      copyright license to reproduce, prepare Derivative Works of,
      publicly display, publicly perform, sublicense, and distribute the
      Work and such Derivative Works in Source or Object form.

   3. Grant of Patent License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their
      Contribution(s) alone or by combination of their Contribution(s)
      with the Work to which such Contribution(s) was submitted. If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.

   4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:

      (a) You must give any other recipients of the Work or
          Derivative Works a copy of this License; and

      (b) You must cause any modified files to carry prominent notices
          stating that You changed the files; and

      (c) You must retain, in the Source form of any Derivative Works
          that You distribute, all copyright, patent, trademark, and
          attribution notices from the Source form of the Work,
          excluding those notices that do not pertain to any part of
          the Derivative Works; and

      (d) If the Work includes a "NOTICE" text file as part of its
          distribution, then any Derivative Works that You distribute must
          include a readable copy of the attribution notices contained
          within such NOTICE file, excluding those notices that do not
          pertain to any part of the Derivative Works, in at least one
          of the following places: within a NOTICE text file distributed
          as part of the Derivative Works; within the Source form or
          documentation, if provided along with the Derivative Works; or,
          within a display generated by the Derivative Works, if and
          wherever such third-party notices normally appear. The contents
          of the NOTICE file are for informational purposes only and
          do not modify the License. You may add Your own attribution
          notices within Derivative Works that You distribute, alongside
          or as an addendum to the NOTICE text from the Work, provided
          that such additional attribution notices cannot be construed
          as modifying the License.

      You may add Your own copyright statement to Your modifications and
      may provide additional or different license terms and conditions
      for use, reproduction, or distribution of Your modifications, or
      for any such Derivative Works as a whole, provided Your use,
      reproduction, and distribution of the Work otherwise complies with
      the conditions stated in this License.

   5. Submission of Contributions. Unless You explicitly state otherwise,
      any Contribution intentionally submitted for inclusion in the Work
      by You to the Licensor shall be under the terms and conditions of
      this License, without any additional terms or conditions.
      Notwithstanding the above, nothing herein shall supersede or modify
      the terms of any separate license agreement you may have executed
      with Licensor regarding such Contributions.

   6. Trademarks. This License does not grant permission to use the trade
      names, trademarks, service marks, or product names of the Licensor,
      except as required for reasonable and customary use in describing the
      origin of the Work and reproducing the content of the NOTICE file.

   7. Disclaimer of Warranty. Unless required by applicable law or
      agreed to in writing, Licensor provides the Work (and each
      Contributor provides its Contributions) on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
      implied, including, without limitation, any warranties or conditions
      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
      PARTICULAR PURPOSE. You are solely responsible for determining the
      appropriateness of using or redistributing the Work and assume any
      risks associated with Your exercise of permissions under this License.

   8. Limitation of Liability. In no event and under no legal theory,
      whether in tort (including negligence), contract, or otherwise,
      unless required by applicable law (such as deliberate and grossly
      negligent acts) or agreed to in writing, shall any Contributor be
      liable to You for damages, including any direct, indirect, special,
      incidental, or consequential damages of any character arising as a
      result of this License or out of the use or inability to use the
      Work (including but not limited to damages for loss of goodwill,
      work stoppage, computer failure or malfunction, or any and all
      other commercial damages or losses), even if such Contributor
      has been advised of the possibility of such damages.

   9. Accepting Warranty or Additional Liability. While redistributing
      the Work or Derivative Works thereof, You may choose to offer,
      and charge a fee for, acceptance of support, warranty, indemnity,
      or other liability obligations and/or rights consistent with this
      License. However, in accepting such obligations, You may act only
      on Your own behalf and on Your sole responsibility, not on behalf
      of any other Contributor, and only if You agree to indemnify,
      defend, and hold each Contributor harmless for any liability
      incurred by, or claims asserted against, such Contributor by reason
      of your accepting any such warranty or additional liability.

   END OF TERMS AND CONDITIONS

   APPENDIX: How to apply the Apache License to your work.

      To apply the Apache License to your work, attach the following
      boilerplate notice, with the fields enclosed by brackets "[]"
      replaced with your own identifying information. (Don't include
      the brackets!)  The text should be enclosed in the appropriate
      comment syntax for the file format. We also recommend that a
      file or class name and description of purpose be included on the
      same "printed page" as the copyright notice for easier
      identification within third-party archives.

   Copyright [yyyy] [name of copyright owner]

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.