# Contributing without signing the CLA

> Track B-8 from `docs/handovers/session-2026-05-09-license-infrastructure.md`
>
> If you've landed here from a "CLA required" check failure, the bot is
> doing what it's designed to do — every merged contribution to PROJECT
> JAMES requires a signed [Individual CLA](CLA.md). We can't merge work
> without one. **But we still want your input**, and there are several
> equally useful paths that don't require signing.

## Why the CLA exists

The CLA isn't a copyright transfer — you keep ownership of your code.
What it grants is (i) a perpetual license for Hashevolution and downstream
users to use your contribution, (ii) a patent peace clause, and
(iii) **§4-bis Relicensing Grant** — the clause that lets the project
evolve its license model in future without renegotiating with every past
contributor. That last one is the decisive piece. Without it, a project
of any longevity becomes legally frozen.

If those terms aren't acceptable to you or your employer, these paths
remain fully open.

## Paths that do not require a signed CLA

### 1. Bug reports

Open an issue in
[GitHub Issues](https://github.com/Hashevolution/James-RAG-Evol/issues)
with reproduction steps, environment info, and the unexpected behavior.
A high-quality bug report is often more valuable than a code patch —
it lets the maintainer (or a CLA-signed contributor) fix the root cause
correctly.

### 2. Design discussion

Open a thread in
[GitHub Discussions](https://github.com/Hashevolution/James-RAG-Evol/discussions).
Architectural ideas, alternative implementations, ecosystem comparisons,
performance observations — all welcome, no CLA needed.

### 3. Documentation suggestions in issue form

Spotted a typo, an outdated example, or a missing explanation? Open an
issue with the exact location and the suggested correction. A maintainer
will apply it on your behalf. Doc patches in PR form still need a CLA
because the docs are part of the licensed work.

### 4. Reviewing pull requests

Comment on any open PR. Constructive code review, security observations,
or pointing out edge cases doesn't require a CLA — only your own code
contributions do.

### 5. Forks and derivative work

Fork the repo and publish your own modified version under MIT — that's
explicitly what MIT permits. You stay in control of your fork; nothing
about your fork is required to come back here. If your fork later grows
into something this project should learn from, you can either (a)
contact the maintainer to propose a merge (you'd sign the CLA at that
point) or (b) keep maintaining your fork independently.

### 6. Sharing a patchset off-tree

If your employer's IP policy lets you publish patches but not sign third-
party CLAs, you can publish your patches as a gist, a separate repo, or
an attached file to an issue. A CLA-signed contributor may then apply
the patch upstream with attribution.

### 7. Sponsorship / financial contribution

If you'd like to support the project without contributing code, the
maintainer profile lists sponsorship channels.

## What we cannot do

We cannot merge a pull request that contains code (or docs, or
configuration) without a signed CLA. The CLA Assistant bot enforces
this automatically — it isn't a judgment about the contribution's
quality.

We also can't accept partial CLAs (e.g., signing §1-3 but striking
§4-bis). The Relicensing Grant is structurally non-negotiable; without
it the project's license cannot legally evolve and the entire CLA loses
its forward-looking purpose. If §4-bis is the blocker, paths 1–6 above
are the right alternatives.

## Re-evaluating later

The CLA decision isn't permanent. If your circumstances change (different
employer, different project, different role), the same single-click
signing flow remains available. One signature, all future contributions
covered.

## Questions

Ask in
[GitHub Discussions](https://github.com/Hashevolution/James-RAG-Evol/discussions)
or open an issue. There's no penalty for asking before signing.
