superagent_

// security workers

Contributor Agreements

[ view markdown ]

Create, version, assign, and enforce contributor agreements on pull requests.

If your project accepts outside contributions, someone has to make sure every contributor has signed the CLA before their code merges. Agreements handles that: you maintain CLA templates and versions in Superagent, and the Open CLA GitHub App enforces coverage as a check on every pull request.

How the pieces fit together

Piece Where Role
Templates Agreements CLA legal text and immutable version history
Repository assignment Repository detail Which template version applies to each repo
Contributors Contributors Who has signed and who is covered by a corporate agreement
Checks GitHub pull requests The Contributor License Agreement check passing or failing

Signing

Contributors sign from the pull request when the check fails:

  • In-app Markdown: the default hosted signing flow after GitHub authentication
  • Dropbox Sign: hosted e-signature, when connected on Integrations

With Dropbox Sign, Superagent emails signature links to contributors or organization signers, records completion through the Dropbox Sign callback, and can import Dropbox Sign templates as CLA template versions. Organization owners connect a Dropbox Sign API key from the Integrations page, and individual repositories can then use Dropbox Sign as their signing mode.

Versioning and audit

Every template version has a content hash, and signatures bind to that hash. Update terms without losing track of who signed what: historical signatures stay tied to their versions, and every signature is timestamped for your compliance records. Activating a new version on a repository starts a re-sign cycle for its contributors. See Templates and versions.

Templates and versions

Templates on the Agreements page (/app/agreements) store the CLA legal text your organization enforces. Each saved version is immutable for audit purposes; edits create new versions instead of overwriting history.

What you can do

  • List organization-wide CLA templates
  • Create a template with Markdown body content
  • Import Dropbox Sign templates for e-signature-based signing
  • Open /app/agreements/[templateId] to edit and review versions

Versioning

Every template version has a content hash. Signatures and corporate agreements bind to that hash:

  • Contributors must sign again when you activate a new version on a repository
  • Historical signatures remain tied to older hashes for compliance records

Communicate version bumps to contributors before switching the active version on busy repositories.

Assigning templates to repositories

Templates do not enforce anything by themselves. You assign a template version on each repository detail page where Open CLA is installed.

Before activating a CLA version

  • Use clear template titles (for example, "Standard CLA v2")
  • Review language with counsel before production use
  • Use Dropbox Sign when you need a hosted e-signature audit trail
  • Keep one active version per repo unless you intentionally run parallel policies

How CLA checks work

When someone opens or updates a pull request on a repository with CLA enabled, the Open CLA GitHub App runs a Contributor License Agreement check on GitHub.

Evaluation steps

  1. Resolve the active CLA document and version hash for the repository (from repository settings).
  2. List all contributors on the pull request.
  3. For each contributor, check personal signatures and eligible corporate agreements for that CLA version.
  4. Publish check success when every contributor is covered; otherwise fail with guidance to sign.

What contributors see

On failure, the check comment links to the signing flow:

  • In-app signing: a GitHub-authenticated Markdown agreement
  • Dropbox Sign: an email link to complete the hosted signature

After signing, contributors should push a new commit or re-run checks so GitHub refreshes status.

Corporate coverage

If the contributor commits through a GitHub organization with an active corporate agreement, Open CLA may pass the check without a personal signature. This requires organization membership read permission on the GitHub App install.

Repository not configured

If the repository has no template assigned, or Open CLA is not installed, checks may not run or may report configuration errors. Assign a template on the repository detail page and confirm the app is installed on that repo.

Monitoring coverage

Use Contributors for org-wide signature status and the repository's pull request checks for per-PR CLA state alongside security scans.

Next steps