Open-source licence policy as code

What the SDK does

• Validates SPDX licence expressions against the SPDX Specification 3.0.1 Annex B grammar, including AND, OR, WITH, the + operator and parentheses.
• Normalizes valid expressions to a canonical form: canonical SPDX identifier case, canonical operand ordering for the commutative AND and OR operators, and canonically re-emitted parentheses.
• Resolves identifiers and exception identifiers against a pinned SPDX License List 3.28.0 baseline and flags deprecated identifiers with a deterministic diagnostic instead of substituting a successor.
• Supports LicenseRef- custom licence identities and AdditionRef- custom additions as opaque customer-defined references, with no legal meaning assigned.
• Validates the customer-authored policy document under a strict schema, rejects unknown fields, and reports a stable policy hash.
• Evaluates the policy over each component record and derives an aggregate outcome from the policy's own configured thresholds.
• Fails closed on malformed input, unknown identifiers and schema violations unless the policy explicitly tolerates that diagnostic code.
• Prints the pinned SPDX reference metadata and the local entitlement state as machine-readable JSON.

Structured output

• Per-component category: policy-allowed, policy-denied, review-required or invalid-unsupported.
• Normalized SPDX expression and expression shape for each component record.
• Coded diagnostics with stable machine-readable codes, for example EXPR_UNKNOWN_ID and EXPR_DEPRECATED_ID.
• Aggregate outcome plus an explicit CI-blocking flag, mirrored by the CLI exit code.
• Provenance block: product version, SPDX License List version, reference snapshot version and policy hash.

How production activation works

• Production use is authorized by a signed, time-bounded local entitlement, paired with a signed and versioned production pack.
• Verification happens locally in your process. The evaluator itself makes no network call.
• Each signed production authorization lasts at most 72 hours from issue (earlier if the paid period or a scheduled cancellation ends sooner); there is no additional grace period after the signed deadline.
• Refresh is automatic and activity-driven: createManagedProductionEvaluator().evaluate() refreshes the signed authorization on Production activity once 24 hours have passed since it was issued. No routine daily manual refresh is required.
• There is no timer, daemon or background keepalive: a dormant process makes no requests, and a dormant installation revalidates automatically on its next managed Production use (fail-closed until that revalidation succeeds).
• The CLI refresh command is an explicit recovery and diagnostic action, not a routine requirement.
• Cancellation and expiry are non-destructive: nothing installed is remotely deleted or disabled, and evaluation use continues. Production use stops when the signed authorization expires, not instantly on cancellation.

Activation is explicit and out of band through the CLI wardenkit-licence-policy; the managed Production evaluator and that CLI are the only writers of the local artefact cache in ~/.wardenkit/open-source-licence-policy/.

npx wardenkit-licence-policy status --json
npx wardenkit-licence-policy activate  # asks for the Activation Code; nothing secret goes on the command line
npx wardenkit-licence-policy refresh --json  # recovery/diagnostic; the managed evaluator refreshes on activity, authorization lasts at most 72 hours

Availability. Production activation runs against the WardenKit Live activation service. An activation credential is issued only after Paddle's verified webhook confirms the subscription; the credential is shown once and never stored by this site. Evaluation, policy validation, the SPDX reference command and status run locally and need no service.

Source-available, production-entitled

WardenKit source-available commercial licence, distributed as LICENSE.md inside the package.

• Source-available: the published package contents may be read, audited and inspected.
• Evaluation and integration use is permitted at no cost; production use requires a paid entitlement.
• Not an OSI-approved open source licence and not an SPDX-listed identifier.
• The licence covers the WardenKit product only. Your policies, component records and results remain yours.

What subscribers keep receiving

• The maintained signed WardenKit Licence Reference Pack binds a published SPDX License List release, with WardenKit normalization and deprecation-diagnostics metadata, pack version, provenance and signature envelope.
• New published SPDX License List releases are tracked, and a new maintained pack is produced when a release is adopted.
• Node.js support windows and the package's minimal dependency set are monitored for compatibility and security releases.
• Paid tiers receive maintained Reference Pack refreshes, compatibility releases and security releases while the subscription is current.
• Cancellation keeps paid access through the end of the paid period with no automatic prorated refund; an approved refund of the current paid period, a confirmed chargeback or terminal cancellation stops further issuance and refresh immediately, while a refund that is only requested or pending does not. Installed files and cached evidence are never remotely deleted or disabled, and evaluation-rights use may continue.
• Each signed production authorization lasts at most 72 hours. The managed Production evaluator refreshes it on evaluate activity once 24 hours have passed (no daemon, no background timer, no traffic while dormant), and the CLI refresh command is a recovery and diagnostic action; every refresh re-verifies the subscription with the payment provider and there is no extra grace. Transient service failures follow a bounded retry ladder; an authorization that expires while the service is unreachable reports REVALIDATION_REQUIRED after two bounded recovery attempts (a technical state, not a revocation; the next evaluate on the same evaluator begins a fresh bounded recovery, so no routine daily manual refresh is required), and a subscription in provider-confirmed payment recovery (past due) keeps refreshing under PAYMENT_RECOVERY until the provider reports a rights-changing event.
• A 30-calendar-day initial-purchase refund guarantee applies once, from an organization's first paid transaction for this product; renewals outside that window are handled under the payment provider's refund policy and statutory rights. See the Refund Policy.