100% Open Source [oss-verified] program

Background

Open source software has become foundational infrastructure across modern industry, and the underlying licensing norms have considerable standing in the developer community. As the ecosystem has matured, the spectrum between fully open source and fully closed source has widened; many projects now operate hybrid models that combine open licensing with proprietary components, hosted services, or enterprise tiers. Such arrangements are often appropriate and, in many cases, materially necessary for a project's continued maintenance and stewardship.

Friction arises in the gap between a project's declared posture and its effective posture. A repository may describe itself as open source while material capabilities — security features, configuration management, scaling primitives — are reserved for a hosted or licensed tier. When that distinction is not represented clearly within the repository itself, the cumulative consequence is an erosion of signal quality and an attenuation of what "open source" denotes in practice.

Approach

The oss-verified program combines a fixed set of deterministic licensing checks (SPEC §3) with an LLM-based second-opinion audit (SPEC §4) that cross-references a project's stated open source posture against the contents of its repository. The audit functions as utility, not endorsement. The intended outcome is improved decision quality for downstream consumers and stronger informational integrity across the open source ecosystem.

Criteria

Each badge represents an objective check, not an opinion. A project earns the badge when it passes four deterministic criteria — REUSE-style SPDX-License-Identifier headers on source files, an OSI-approved declared license, a dependency tree whose declared licenses are all OSI-approved, and the absence of unexplained binary blobs — together with an LLM-based second-opinion audit. The LLM can block a badge but cannot, on its own, grant one. The full normative criteria live in spec/SPEC.md.

How to self-attest

If you maintain an open source project and would like to publish a badge yourself, add the oss-verify GitHub Action (or GitLab CI include) from better-internet-org/oss-verify. It runs the criteria in your own CI, signs the result with Sigstore keyless OIDC, and commits the attestation bundle back to your repository. The badge then becomes available at /verify/<forge>/<owner>/<repo> for your project. No account or registration is required on our end — discovery is automatic the first time someone requests your badge.

How to contribute

Anyone can help curate the badge program. To raise a concern about an existing badge — e.g. a licensing change, vendored proprietary code, or a misleading claim — use the POST /challenges/<forge>/<owner>/<repo> endpoint; challenges are public and resolved by reviewers. To suggest a project for our watchlist (so we re-run the criteria against it on a regular cadence), open an issue at better-internet-org/oss-verify; accepted suggestions are added to our watchlist and their results appear in the table below.

How to verify

Every signed attestation is independently reproducible. To verify a badge yourself, use tools/verify-vc.mjs from the oss-verify repository — a small, zero-dependency Node script that validates an OssVerifiedCredential end-to-end (DID resolution, signature verification, JCS canonicalization, Ed25519 check). Or re-run the criteria from source: clone the project at the attested commit and run npx @better-internet/oss-verify --report-json. Predicates are content-addressed by commit SHA, so anyone can reproduce the result.

Tracked projects

Attested projects below carry a Sigstore-signed attestation that we re-verify on every request, plus a W3C Verifiable Credential signed by did:web:oss-verified.better-internet.org. Watchlist projects are projects we have observed externally — we ran the criteria against them ourselves, but their maintainers have not yet published a signed attestation.

14 of 14