Laravel Terms Laravel Package

Product Decisions This Supports

• Consent & terms-acceptance mechanics: this package (as its name implies, and scoped to the typical pattern for Laravel terms packages) covers publishing versioned terms/privacy documents and recording which user accepted which version and when. That underpins decisions like "do we force re-acceptance when the ToS materially changes, or notify-only?" and "what evidence can we produce in a dispute or audit?"
• Compliance-driven roadmap items: GDPR/UK-GDPR consent records, consumer-contract disclosure rules, and app-store policy requirements all need a durable acceptance audit trail. Deciding whether that's a product surface (blocking modal, re-consent gate) or a back-office report is a PM call this package informs.
• Build vs buy: an acceptance table plus a pivot is a day of engineering. The real question is whether this package already handles versioning, effective dates, re-acceptance prompts, and exportability. If it does, buying (free) beats building; if it's a thin model wrapper, building is cheaper than the dependency risk.
• Laravel upgrade planning: v2.6.0 adds Laravel 12 to the support matrix. That removes this package as a blocker on the framework upgrade path — a scheduling input, not a feature input.
• Concrete use cases to evaluate against: signup ToS checkbox with version capture, forced re-acceptance on policy change, per-user acceptance history for DSAR/audit requests, and admin-side publishing of new document versions.

When to Consider This Package

Consider it when:

• You need a standard Laravel-native way to version terms documents and persist per-user acceptance with timestamps.
• You're on Laravel 11 or 12 and want a small, single-purpose dependency rather than a platform.
• Your terms are global or few-in-number — a simple versioned-document model is sufficient.
• You want something lighter than a dedicated consent-management platform (CMP) or contract lifecycle management (CLM) tool.

Look elsewhere when:

• You need fine-grained cookie/tag consent and script gating — that's a CMP's job, not this.
• You need e-signature, jurisdictional variants, localized terms per market, or per-tenant custom terms in a multi-tenant product.
• You already have an identity, billing, or compliance vendor that owns consent records — duplicating that source of truth is worse than any convenience gain here.
• Your legal team requires a vendor with an SLA, security review, or contractual support. This is a community package.

Release-specific read (v2.6.0): additive only — Laravel 12 support, one new contributor, no breaking changes, no new features, no deprecations. That's a maintenance-health signal, not a capability signal. The open question remains unevaluated: adoption, issue responsiveness, test coverage, and whether the package actually models re-acceptance flows versus just storing acceptances. Pull download stats, open-issue count, and commit cadence, and read the source before committing — if it's a few hundred lines, vendoring a fork is a credible hedge against the single-maintainer risk.

How to Pitch It (Stakeholders)

To executives: A small, free, open-source dependency that formalizes how we record customer acceptance of our terms and privacy policy. It reduces legal exposure around policy changes and removes manual spreadsheet-style tracking. No license cost, no vendor lock-in, and nothing to migrate — the latest release simply keeps us compatible with Laravel 12 so it won't hold up our framework upgrade. Recommend a short technical evaluation before adoption; the main caveat is that it's a single-maintainer project, so we'd pin the version and keep a fork option open.

To engineering: Drop-in Laravel package for versioned terms and per-user acceptance records. v2.6.0 is compatibility-only: adds Laravel 12 support, no breaking changes, no migrations beyond the package's own, no deprecations. Ask: review the source size and test suite, confirm it handles re-acceptance and versioning rather than just a boolean accepted_terms flag, pin the version in composer.json, and note the bus factor — one primary maintainer plus a first-time contributor on this release. If it stalls, the fallback is a two-table build we can own outright.