DSPY GROUP · How it works
You keep what you write until a specific, visible thing happens. This page explains what that thing is, what it deliberately is not, and how to check for yourself which side of the line any piece of your work is on. The last section shows the reasoning behind the rule, including the audit that made us change it — it is here because you should see it argued rather than take it on faith.
01
Almost everything else on this page is a consequence of this sentence.
The rule
Your work becomes DSPY GROUP's when your identified revision is merged into a designated branch and no NOT ACCEPTED notice was posted first. Not before. Not by anything else.
Everything up to that moment leaves you the owner. Everything after it is recorded, timestamped, and checkable by you without our help.
Three things are worth noticing about that sentence. First, it names a single, objective event — something that either happened or didn't, that you can look up. Second, that event is an act of the company, not a conversation: only the company can grant the write access that lets anything land in a designated branch at all, so a merge there happens only because the company permitted it. Third, the merging account is recorded as evidence, but its identity is not a condition; a maintainer who submits and merges the same revision does not leave a title gap.
Which branches are designated is not a matter of interpretation. The default branch of every repository owned by immutable GitHub organization ID 317005020 or Company user ID 317045915 is designated automatically, including future repositories. Personal user ID 107362955 is not a designated owner. .github/DESIGNATIONS.md records only prospective exclusions and additional branches; a later exclusion never unwinds an earlier acceptance.
The reason for this design is unglamorous: ambiguity about who owns what is the thing that kills companies at diligence, and it is much cheaper to be precise on day one than to reconstruct intent from a two-year-old Slack thread.
02
When you open a pull request, the exact commit at its head becomes a Submitted Revision — identified by its Git SHA, which is immutable and unforgeable.
At that moment you grant DSPY exactly one thing: the right to evaluate it. Host it, copy it, run it, test it, security-review it, and keep records of it. That's the whole grant. You still own the copyright. If nothing further happens, it stays yours.
Push a new commit and you have made a new Submitted Revision. Every head SHA is its own thing with its own record. This matters more than it sounds: it means acceptance can never be vague about which version of your work transferred. It is always one specific commit.
Alongside the code you disclose provenance — third-party and open-source dependencies with their licences, which AI tools you used and on what, whether any company-confidential material went into an AI tool, and what you reviewed yourself. This is not bureaucracy for its own sake. Unlabelled third-party code is the single most common thing that blows up an acquisition, and the disclosure is what lets us catch it before it's load-bearing.
Why a SHA and not a PR number. A pull request is a mutable object; its title, description and head commit can all change. A commit SHA is a hash of content and history, so it cannot be edited to mean something else. The record pins the SHA, so "what was accepted" survives any later edit to the PR.
The evaluation licence is non-exclusive. Granting it does not stop you doing anything else with your own work while it is pending.
Blocked licence classes. Reciprocal or network-source (GPL/AGPL-style), non-commercial, royalty-bearing, field-of-use restricted, and custom source-available licences require explicit authorisation before your contribution can be accepted. Not because they're bad, but because they change what the company can do with everything they touch.
03
An Acceptance Event is the only thing that moves ownership. There are exactly three, and in practice you will only ever see the first:
| # | What happens | How often |
|---|---|---|
| a | Your identified revision is merged into a designated branch (normally the repository's default branch), and no NOT ACCEPTED notice was posted on the pull request beforehand | Essentially always |
| b | An authorised company representative creates a company record expressly marked ACCEPTED naming your revision by SHA | Rare — for work that lands outside a normal merge |
| c | An authorised company representative signs a written acceptance naming your revision | Almost never |
The branch and Company permission carry the weight. If you have Company-granted merge permission and merge your own pull request into a Designated Branch, that merge can be an Acceptance Event. The account is still captured in the record as evidence; it simply no longer determines whether title moved.
When an Acceptance Event happens, the assignment is automatic and immediate. There is no second step, no signature to chase, no waiting period. The transfer is effective at the recorded timestamp of the event itself — the assignment time and the acceptance time are the same instant, always, by construction.
It applies only to the exact revision named. Not earlier commits, not later ones, not the branch, not related work.
Sometimes the company wants to land your work without taking ownership of it. There is exactly one way to do that, and it is deliberately awkward: we must post a notice on the pull request, before the merge, naming your revision by SHA and saying it is NOT ACCEPTED and that no assignment will occur.
Post that notice and the merge transfers nothing — you keep the copyright, and the company gets only a licence to run and ship that revision for as long as it keeps it, ending when it takes it out. Post it after the merge and it is worth nothing at all: the assignment already happened, and a later notice cannot unwind it.
The timing is the whole protection. A notice that could be posted afterwards would let the company look at how a change performed and then decide whether it had bought it. Forcing the notice to precede the merge means the choice is made in the open, before anyone knows the outcome, and it is on the pull request where you can see it.
Why this is good for you, not just for us. A bright line cuts both ways. It means nobody at DSPY can later claim your unmerged experiment was "obviously" company property, and it means you never have to wonder whether a conversation created an obligation. If it wasn't merged by someone else into a designated branch, it's yours.
04
This list is the part people find hardest to believe, so it is written into the agreement explicitly. None of the following transfers anything, no matter how many of them accumulate:
Repetition doesn't help. Accumulation doesn't help. Time passing doesn't help. A hundred approvals is worth exactly as much as zero approvals, which is nothing.
The reason is that most of that list is a signal about intent rather than an act with a consequence. Signals are ambiguous, they happen in private channels, and reasonable people remember them differently a year later. A merge into a designated branch is a fact with a timestamp, revision, branch, and merging account, recorded in a system neither side controls unilaterally.
The last entry is there for a different reason: it looks exactly like acceptance and isn't. A merge is an Acceptance Event only if its target was a Designated Branch at that time and no timely NOT ACCEPTED notice blocked it.
05
Take one contribution through its life. Watch the owner label — the point is how little moves it. The two merge buttons are the ones to compare: the same action, aimed at a different branch, has a completely different legal result.
The only two buttons that change ownership state are Open a PR and Merge into default branch. Pushing a commit changes which revision is pending. Everything in between is noise, legally speaking — useful, human, necessary for good software, and completely irrelevant to who owns the copyright.
Merge into feature branch is the one worth comparing. The code can land and run, but ownership does not move because the target is not designated. Who clicked merge is recorded either way and does not change the result.
06
Two records exist per contribution: one when you submit, one when it is merged. Each names the revision by SHA, the governing agreement versions and their fingerprints, and your provenance disclosures. An acceptance record adds the merge commit, the designated branch, the account that merged it, and the exact timestamp the assignment took effect.
A record is written for every merge into a designated branch, including a merge blocked by a prior NOT ACCEPTED notice. If ownership did not move, the record says so and says why. The absence of a transfer is recorded as deliberately as a transfer.
These live in a company-controlled store outside GitHub. Every write is read back and re-hashed before it counts, so a record that appears to exist actually does. GitHub holds a receipt and a hash, nothing authoritative.
You do not have to trust any of that. The underlying fact is on the pull request itself: whether it was merged, into which branch, by whom, when, and the resulting merge commit. That's visible to you on GitHub, permanently, without our cooperation. Our records are evidence of the event, not the event itself — if we lost every record tomorrow, what transferred and when would be unchanged.
Exact-byte discipline. The agreements you accept are hashed as the exact bytes shown to you — UTF-8, no byte-order mark, LF line endings. The SHA-256 of what you signed is stored with your acceptance. Historical signed text is never reconstructed from whatever the website says today.
Fail closed. If the authoritative record can't be written and verified, onboarding fails outright rather than creating a half-finished acceptance. An error in recording never invents an acceptance that didn't happen, and never undoes one that did.
Idempotent retries. Record identifiers are derived from the revision and event, not generated randomly, so a re-run of the automation produces byte-identical output instead of a second record claiming the same transfer.
07
An earlier draft of the agreement said "an authorised maintainer merges," where authority came from a hand-maintained register of named people keyed by GitHub numeric ID. We deleted the register. This section is the argument for that, because a rule you cannot check the reasoning of is a rule you are being asked to trust.
The register was a condition the company imposed on itself. Acceptance required the merging account to appear on a list the company maintained, so the company could only take ownership of your work by having remembered to keep its own paperwork current. That sounds harmless. It is not, and we can prove it.
The audit that settled it. Every merge performed in this repository to date was made by an account that does not appear in the register. The register had exactly one row, and it was not that account. Under the old wording, none of those merges was an Acceptance Event — so nothing transferred, while the code sits in main and ships.
The register was nineteen days old and already wrong in the one way that matters. Nobody did anything careless; the list simply described a state of the world that had moved on, and nothing in the system noticed.
That is the failure mode worth naming precisely: a stale register fails silently, and it fails against the company. There is no error, no alert, no broken build. Work lands, ships, and earns money, and years later the ownership of it turns out never to have moved. You find out at diligence, from someone else's lawyer, about code you can no longer identify the author of.
So we removed the step that can rot. A merge into a designated branch is not a claim anyone has to keep up to date — it is a fact that only the company can permit, because only the company can grant the write access that makes it possible. It is stamped on the pull request with an actor and a timestamp, it is visible to you forever, and it needs nobody to feed it.
The register was the better answer to one specific question.
Acceptance is: the identified revision was merged into a designated branch without a prior NOT ACCEPTED notice.
The tradeoff is real, and we are not pretending otherwise. We chose the mechanism that cannot fail quietly over the one that produces stronger evidence right up until the moment it stops being true. A rule that depends on an administrative habit is only as good as the habit.
The current guardrails avoid both stale rosters and self-merge gaps. Default branches are designated automatically by immutable organization ID, exclusions are prospective only, and merging without accepting requires a notice posted before the merge, so the company cannot look at how a change performed and then decide retroactively whether it bought it.
Timing matters here too: nobody has signed or accepted this generation, so the gap was closed before it could require re-assent. The current rule is in CT-3.5, Section 4.
Unchanged: submission grants evaluation rights only; the negative list in section 04; assignment effective at the recorded acceptance time; per-revision specificity; every provenance obligation. The change is about who can accept, not about what acceptance does.
Changed: the named register remains deleted; every organization default branch is now designated automatically by immutable organization ID; .github/DESIGNATIONS.md holds only prospective exclusions and additional branches; and self-merges are no longer excluded. Merging without accepting still requires a notice on the PR before the merge.
Automation counts, and is recorded. A merge performed by an auto-merge rule or a merge queue the company configured is still the company's act — the company set that automation up. The account that performed the merge is recorded as evidence either way, but it is no longer a condition of the transfer, which is exactly the change that removes the silent-failure mode.
Credentials the company did not authorise. If a designated branch is merged into using stolen access, that is not an Acceptance Event — but the company has to revert it and say so in writing on the pull request within seven days. Miss the window and the acceptance stands. The escape hatch is narrow and it expires.
Two questions worth watching. Whether a merge performed by automation is cleanly attributable to the company, and whether a pre-merge notice prevents an assignment rather than attempting to unwind one. Both are answered the way this page describes, and both are worth revisiting as the rule meets real cases.
08
This page explains the mechanism in plain language. It is not the agreement. Where anything here differs from the Contributor IP and Participation Agreement, that document governs — and it is worth reading, because it is short and it is the thing that actually binds.