Governance

The TOSSI Foundation - the Telecom Open Source System Integrator - is a neutral, vendor-independent home for the work of integrating the open telecom stack into a coherent, validated, production-grade whole. This page is the charter overview: who we are, what we govern, how we make decisions, and how intellectual property flows through the foundation.

We model our governance on the proven open-source playbook for neutral, community-run projects: transparent decision-making in the open, a Technical Steering Committee that owns the technical direction, a clear project lifecycle, and an explicit, permissive IP policy. We did not invent this model - we adopted the practices that have repeatedly proven to work in large, neutral communities.

Status: forming

TOSSI is a newly establishing foundation. The documents in this section are the initial governance proposal. They become binding once ratified by the founding Technical Steering Committee. Names, seat counts, cadences, and committee membership are placeholders until that ratification. We publish them now, in draft, because governance should be legible from day one - not retrofitted after the fact.

Mission

TOSSI exists to make the open telecom stack deployable as a whole. Excellent open-source projects already exist for every layer - 5G Core, RAN, RIC, SMO, applications, security, cloud-native infrastructure. What is missing is the neutral connective tissue: the conformance harnesses, integration blueprints, interoperability test suites, and reference deployments that let components from different projects and vendors work together in production.

Our mission: to integrate, validate, and steward the open telecom stack - from 5G Core and O-RAN through RIC, SMO, applications, post-quantum security, and the cloud-native substrate - as a coherent, tested, production-grade system, under neutral and transparent governance.

We are a system integrator, not an implementer. We rarely ship a new core, RAN, or controller of our own. Our deliverables are the glue, the tests, and the trust.

Scope

TOSSI’s technical scope spans the full open telecom stack. We organize it as a set of pillars, each governed as one or more projects under the TSC.

5G Core Cloud-native, service-based 5G core integration - open 5G core implementations deployed as CNFs on Kubernetes.

RAN & O-RAN Integration Open gNB and O-CU / O-DU / O-RU stacks, brokering Open Fronthaul 7.2x and F1/E1/NG interoperability across vendors.

RIC Near-RT and Non-RT RAN Intelligent Controllers, aligning E2/A1 across the disaggregated RAN.

SMO Service Management & Orchestration - the management plane terminating O1, O2, and A1.

xApps & rApps The RAN-control application ecosystem, xApp/rApp frameworks and SDKs, descriptors, and the integrator's onboarding pipeline.

Post-Quantum Security Migrating telecom cryptography to NIST-standardized quantum-resistant algorithms with crypto-agility.

Cloud-Native & Operators The Kubernetes substrate, GitOps controllers, operator frameworks, and chart- or OCI-based packaging beneath every pillar.

eBPF & Dataplane XDP/eBPF-accelerated packet processing for the high-throughput user plane.

Out of scope

To stay neutral and focused, TOSSI deliberately does not:

• Compete with upstream projects. We do not fork the projects we integrate; we contribute upstream and carry only the integration layer. See our upstream-first principle.
• Set spec or standards policy. Standards belong to 3GPP, the O-RAN ALLIANCE, the IETF, and ETSI. TOSSI tracks and validates against those standards; it does not author them.
• Endorse commercial products. TOSSI does not certify, rank, or recommend specific vendors. Conformance results are published as facts, not endorsements.

Neutrality

Neutrality is the product. A system integrator is only trustworthy if no single vendor can capture it. TOSSI enforces neutrality structurally, not just rhetorically.

No single-company control

No single employer may hold a majority on the Technical Steering Committee. Maintainer and TSC seats are earned by individuals through contribution and merit, not granted to companies.

Open by default

Decisions, meetings, agendas, and minutes happen in public. Mailing lists, issue trackers, and meeting recordings are open to all. “If it isn’t written down in the open, it didn’t happen.”

Vendor-agnostic validation

Conformance suites test against published standards, never against a preferred implementation. Any compliant component must be able to pass.

Permissive IP

Apache-2.0 code and CC-BY-4.0 docs mean no one - including a future TOSSI - can lock the community out of its own work.

Organizational structure

TOSSI follows the two-track structure common to mature, neutral open-source foundations: a business/stewardship track (the Governing Board) and a technical track (the Technical Steering Committee), kept deliberately separate so that funding never buys technical control.

Governing Board

Stewards the foundation’s resources, budget, marketing, legal, trademark, and membership. It does not make technical decisions. Composed of member representatives plus a non-voting TSC liaison.

Technical Steering Committee (TSC)

Owns all technical direction: project lifecycle, cross-project architecture, conformance policy, and release coordination. Members are elected by and from the active maintainer community. See Technical Steering Committee.

Projects & SIGs

Each pillar maps to one or more projects, run day-to-day by their maintainers, and to Special Interest Groups / working groups open to all contributors. See Community.

Code of Conduct Committee

A small, independent committee that receives and adjudicates conduct reports confidentially. See Code of Conduct.

Separation of powers

Money and merit are kept apart on purpose. The Governing Board controls the budget but cannot direct the architecture; the TSC controls the architecture but cannot allocate the budget. This is the same firewall that mature, neutral open-source foundations use to keep technical decisions honest.

Decision-making

TOSSI decisions are made in the open, and almost always by lazy consensus.

1. Propose in the open. Any contributor may raise a proposal as a GitHub issue, a pull request, or - for cross-project changes - a lightweight TOSSI Enhancement Proposal (TEP).

2. Discuss. The proposal is discussed on the issue/PR and, when relevant, in the appropriate SIG or community call. Minutes are public.

3. Lazy consensus. If no one with standing objects within the review window (typically 3–5 business days for routine changes, longer for architectural ones), the proposal is approved. Silence is assent.

4. Escalate only when needed. If consensus cannot be reached, the question escalates: maintainers resolve project-local disputes; the TSC resolves cross-project disputes.

5. Vote as a last resort. When the TSC must vote, decisions pass by simple majority of voting members, with quorum at two-thirds. Votes and rationale are recorded publicly.

We prefer consensus over voting, the open record over private decisions, and the smallest body that can decide over escalation. Voting is a backstop, not the default.

IP & licensing policy

TOSSI’s IP policy is permissive by design, following a standard inbound-equals-outbound contribution model.

Code - Apache License 2.0

All TOSSI-originated code - integration tooling, conformance harnesses, blueprints, operators, and SDKs - is licensed under Apache-2.0. Apache-2.0 includes an explicit patent grant, which matters in a standards-heavy domain like telecom.

Documentation - CC-BY-4.0

All documentation and written content, including this site, is licensed under Creative Commons Attribution 4.0. You may reuse, adapt, and redistribute it with attribution.

Inbound = outbound, with DCO

• Contributions are licensed under the project license. By contributing, you agree your contribution is provided under Apache-2.0 (code) or CC-BY-4.0 (docs) - the inbound = outbound principle. TOSSI does not require a CLA.
• DCO sign-off is required. Every commit must carry a Developer Certificate of Origin sign-off (git commit -s), certifying you have the right to submit the work. See Contributing.
• Trademarks belong to the foundation and are governed by a separate trademark/usage policy administered by the Governing Board. The TOSSI name and marks may not be used to imply endorsement.
• Third-party components retain their own licenses. TOSSI integrates many upstreams across every pillar - open 5G core implementations, open RAN stacks, RIC platforms, SMO/orchestration projects, eBPF-based CNIs and dataplanes, post-quantum cryptography libraries, and more; we respect and preserve their licensing.

Why Apache-2.0 and not a copyleft license?

Telecom integration sits at the boundary of many ecosystems with differing license preferences. Apache-2.0 maximizes downstream adoption, carries an explicit patent grant suited to a standards-driven field, and is the de-facto choice across the cloud-native ecosystem. Upstream projects we integrate keep their own licenses; TOSSI’s integration layer is Apache-2.0.

Amending this charter

This charter is a living document. Changes follow the same open process as any other decision: proposed in the open, discussed, and ratified by the TSC (with Governing Board concurrence for changes affecting IP, trademark, or membership). The current revision and its history live in the public repository.

Explore governance

Technical Steering Committee TSC composition, responsibilities, the sandbox → incubating → graduated project lifecycle, and how technical decisions are made.

Code of Conduct Our Contributor Covenant–based community standards, scope, enforcement process, and how to report.

Community Get involved - channels, community calls, and the SIGs/working groups mapped to each pillar.

Contributing How to contribute code and docs, DCO sign-off, the PR workflow, and the upstream-first principle.