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 Agreement templates.

Next steps

• Agreement templates
• How CLA checks work
• Install GitHub Apps