Contributing to KYE OSS
KYE Protocol™ is an open protocol with private operational engines. The OSS surface — SDKs, verifiers, schemas, fixtures — is community-driven under Apache 2.0. Here's how to participate.
Plain Q&A
Short questions. Short answers.
- What is open? Schemas, vocab, SDKs, verifier.
- What is closed? Nothing in the protocol layer.
- Which licence? Apache 2.0 for code. CC-BY-4.0 for vocab.
- Where is the source? On GitHub. KYE-Protocol org.
- Can I fork? Yes.
- Can I contribute? Yes. Open a PR.
- Will you take my fix? Yes if it follows the constitution.
- Is the runtime open? Reference Gateway is. Hardened build is paid.
Plain take
Apache 2.0 SDKs. CC-BY-4.0 vocab. No runtime lock-in.
- Three SDKs. One protocol. Same names.
- Schemas and vocab versioned on GitHub.
- Public JWKS. Open verifier.
- Bring your own runtime.
Code of Conduct
All KYE OSS spaces follow the Contributor Covenant 2.1. Be respectful. Disagree on substance, not identity. Report incidents to [email protected].
Governance
KYE OSS uses a "single steward + community PRs" model. The KYE Protocol team owns the public-key set, the schema registry, and the release cadence. PRs from outside the team are very welcome — they're reviewed within five business days.
- Decisions on protocol direction happen at Discussions.
- Specifications are versioned in the published constitution; substantive changes require a KEP (KYE Enhancement Proposal).
- Releases follow semver. Breaking changes are batched into major versions every 6 months max.
What we accept
Always welcome
- Bug fixes with a regression test
- Documentation improvements
- New SDK language ports (e.g. Go, Rust, Java) — open a Discussion first
- New Stack Bindings that respect the schema contracts
- Performance work backed by benchmarks
- New synthetic fixtures (banking, healthcare, energy, etc.) — must be fully synthetic
Requires discussion first
- Schema changes (touch
schemas/) - New top-level packages (e.g.
@kye/*) - Anything touching the COSE signing flow
- License changes (Apache 2.0 is the floor)
Out of scope
- Authority Gap detection, Guard Recommendation, drift-detector internals — these live in the private engines
- Conformance Pack signing keys — only the KYE Protocol team can sign
- Anything that violates the OSS/IP split in constitution §21.11
Workflow
- Fork the relevant repo under KYE-Protocol.
- Create a branch:
git checkout -b feat/your-change - Run the test suite locally:
npm test(orpytestfor Python). - Add a CHANGELOG entry under
Unreleased. - Open a PR with a clear description. Link to any Discussion that justified the change.
- Sign the DCO with
git commit -s. CLAs are not required.
Security disclosures
Do not file security bugs as public issues. Email [email protected] with a PGP-encrypted report (key in .well-known/security.txt). See SECURITY.md for the disclosure timeline.
Releases & signing
Releases are tagged in git, built reproducibly in CI, and published to npm + PyPI with Sigstore attestations. Every published artefact has a provenance attestation you can verify with npx @kye/conformance-pack-verifier verify-provenance @kye/[email protected].