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.

Get started →Packages
← OSS

Plain Q&A

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

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 conduct@kyeprotocol.com.

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

  1. Fork the relevant repo under KYE-Protocol.
  2. Create a branch: git checkout -b feat/your-change
  3. Run the test suite locally: npm test (or pytest for Python).
  4. Add a CHANGELOG entry under Unreleased.
  5. Open a PR with a clear description. Link to any Discussion that justified the change.
  6. Sign the DCO with git commit -s. CLAs are not required.

Security disclosures

Do not file security bugs as public issues. Email security@kyeprotocol.com 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/shadow-mode-sdk@0.1.0.

Canonical KYE™ surfaces referenced on this page: KYE™ Conformance Pack™.