docs: publish the Contributor License Agreement CONTRIBUTING has promised

[abrichr]

Read this first: a lawyer has to sign off before anyone relies on it

Neither the author of this PR nor its reviewer is a lawyer. CLA.md and
CCLA.md are adapted from a standard template, not written from scratch, but
adapting a template is still a legal act. Please route both files to counsel
before the CLA check is turned on anywhere. Three specific questions for them
are listed at the bottom.

What was wrong

openadapt-web/CONTRIBUTING.md and openadapt-ops/CONTRIBUTING.md have said
this since 2026-07-20:

Contributor License Agreement (CLA). By opening a pull request you agree
to the OpenAdapt Contributor License Agreement. The canonical CLA text lives
at openadapt-flow/CLA.md.

There is no CLA.md in this repository. There never has been. Contributors were
told they had agreed to a document that didn't exist, and this repository
documented neither a CLA nor a DCO sign-off of its own.

openadapt-web already knew. scripts/check_github_link_anchors.mjs carries the
dead link in a hard-coded exceptions list, with the note that publishing a CLA or
dropping the claim "is a licensing decision".

Who was affected: nobody, as it happens

Checked before writing anything:

repo	external human contributors since the claim appeared (2026-07-20)
openadapt-web	none. The last one merged 2024-06-17, over two years earlier
openadapt-ops	none, ever
openadapt-flow	none, ever. Every merged PR is abrichr or dependabot
OpenAdapt	none. That repo said the CLA "has not been adopted", which was true

No external pull request is open in any of the four right now. So the false claim
bound zero people, and there's no one to go back to. See the recommendation
below.

What this PR adds

• CLA.md — Individual CLA, adapted from the Apache Software Foundation
  Individual Contributor License Agreement V2.0
  (https://www.apache.org/licenses/icla.pdf).
• CCLA.md — Corporate CLA, adapted from the Apache Corporate CLA V2.0
  (https://www.apache.org/licenses/cla-corporate.txt), with Schedule A for
  designated employees.
• CONTRIBUTING.md — a licensing section this repo didn't have: DCO sign-off
  required now, CLA published, and a plain statement of how assent works.

Grant clauses 2 through 8 are the Apache text with "the Foundation" replaced by
"the Company". Four deliberate changes, each flagged in a note at the top of
each file:

1. The Apache promise not to use contributions "contrary to the public benefit
   or inconsistent with its nonprofit status" is gone. MLDSAI Inc. isn't a
   nonprofit. In its place is a sentence saying the Company ships both open
   source and proprietary software, may use a Contribution in either, and may
   relicense the Work on terms of its choosing. That's the honest version, and
   it's the clause counsel should read hardest.
2. "Work" is defined as every repository in the OpenAdaptAI GitHub org, so one
   signature covers the whole org rather than one repo.
3. Section 9 sets an effective date. The agreement binds a Contributor from the
   moment they sign. Once they sign, it reaches their earlier contributions too,
   which is what the Apache "present and future Contributions" wording does.
4. Section 10 sets Ontario law, matching the governing-law clause already on
   openadapt.ai/terms-of-service.

Why a CLA and not just the DCO

The DCO is the lighter instrument and it's already in place in three of the four
repos. It should stay. But it certifies provenance; it doesn't grant anything.

MIT inbound already lets the company use contributions in proprietary products,
so the open-core model on its own does not require a CLA. The CLA earns its
friction on two other things:

• A patent grant. MIT has none. Apache-style section 3 gives an express
  patent license with defensive termination. For a company selling automation
  into regulated buyers who run IP diligence, that's worth having.
• Clean relicensing. Under MIT inbound, a contributor's MIT grant to the
  world persists and its notice requirements travel with the code. A direct
  broad license to the company is what makes a later relicense of the combined
  work clean. SOURCE_AVAILABILITY_BOUNDARY.md section 6 already names this as
  the reason a CLA is preferred, while explicitly not taking the BSL decision
  now.

The friction cost is real and it's usually the argument against. Here it's close
to zero: external contribution flow is currently nil across all four repos.

How assent is actually captured

Not by opening a pull request. That claim is removed everywhere in the companion
PRs, and both agreements say signature is never implied.

Assent is by signature, in one of two ways: the automated CLA check once it's
enabled, or an email to hello@openadapt.ai. Until the check is enabled, the DCO
and the MIT License are what govern a contribution, and CONTRIBUTING.md now
says exactly that in each repo. Enabling the CLA Assistant GitHub App remains a
founder action per SOURCE_AVAILABILITY_BOUNDARY.md section 8.

Recommendation on the past

Leave past contributions where they are, under the MIT License they were
submitted under and the DCO. Don't chase anyone. The evidence above is that the
phantom claim covered no external contributor in the two repos that made it, and
the repo with real external history never made the claim. Section 9 is written
so nobody can read the new document as retroactive.

Companion PRs

Three repos carry a CLA claim that has to change with this one:

• docs: stop claiming a pull request signs the CLA openadapt-web#409 — removes the implied-assent sentence, adds the
  CCLA link, and updates the two known-dead-link entries in
  check_github_link_anchors.mjs
• docs: stop claiming a pull request signs the CLA openadapt-ops#170 — same edit to CONTRIBUTING.md
• docs: record that the CLA is published, not under consideration OpenAdapt#1125 — replaces "under consideration but has not been
  adopted" with the published-but-not-enforced state

Merge this one first. The other three link to
openadapt-flow/blob/main/CLA.md, and the web link checker fails on a 404 once
its exception entries come out. Deleting those two entries is the one follow-up
after this merges.

Three questions for counsel

1. Section 2 of the Apache ICLA grants the license to "the Foundation and to
   recipients of software distributed by the Foundation". Kept verbatim with
   "the Company" substituted. Is the recipients half right for a for-profit that
   also ships proprietary builds, or should the grant run to the Company alone?
2. Is the replacement second paragraph (proprietary use, relicensing on terms of
   the Company's choosing) sufficient disclosure, or does a Canadian for-profit
   want that as a numbered clause with its own consent step?
3. Is signature by email to a shared alias adequate record-keeping, or should
   every signature go through a signature service from the start? A dedicated
   legal@openadapt.ai alias doesn't exist yet; hello@ is what the documents
   point at today.

🤖 Generated with Claude Code