Licensing Laravel Package

Product Decisions This Supports

Roadmap: monetizing digital goods. This package underpins a specific, well-scoped roadmap item — "sell digital products that need an entitlement" (license keys for software, add-ons, plugins, downloads, course/seat access). If that item is on the roadmap, this package defines the cheapest possible first version of it; if it is not, the package has no product rationale. That is the binary to settle first.

Build vs. buy, scoped correctly. Licensing looks like two functions (issue a key, check a key) but the product surface is larger: activation limits, seat counts, revocation, refund/clawback on order reversal, renewal and expiry, audit trail, and customer self-service. Frame the decision as "buy the hard 20%" and note that this package only claims the easy 80% — it is a foundation, not a finished capability. Any build estimate must include the revocation/refund path, because that is where support tickets live.

Platform commitment, not a component purchase. This is a subtree split of Lunar, a Laravel e-commerce framework, and its principal benefit is "seamless integration with Lunar's ordering system." That benefit only exists if we are on Lunar. For a Lunar-based storefront this is close to a free capability; for any other stack, the headline integration is worthless and we would be adopting a data model plus a dependency for nothing. Treat this as a Lunar platform decision with a licensing sub-item, not a standalone package review.

Packaging and pricing experiments. The activation model (licenses + activations as first-class entities) is what lets product/pricing test seat-based tiers, activation caps, and trial-to-paid conversion without schema work. That is a real product lever and worth naming when scoping the epic.

Explicit non-scope (set expectations early). No billing, invoicing, tax, dunning, self-service portal, or cryptographic/offline activation is evidenced. Those are separate line items in the same epic and must appear in the estimate, or the roadmap will quietly under-deliver.

Signals to log in the decision record. Low visibility (2 stars, effectively unknown standalone usage) and a 2023 split date are not proof of abandonment — issues and PRs are routed to the parent lunarphp/lunar repo, so this repo's metrics are structurally suppressed. The correct check is parent-repo health and whether licensing has since moved in-core. Record the finding either way; a platform decision made on split-repo vanity metrics is a decision made on the wrong data.

When to Consider This Package

Consider it when all of these hold:

• We are already committed to Lunar (or are actively choosing it for reasons beyond licensing) and want an entitlement model that ties to orders and customers without custom schema.
• The requirement is foundational: issue keys, validate them, track activations. We do not yet need provisioning, offline/air-gapped activation, hardware fingerprinting, or a customer-facing license portal.
• We have an engineering owner who can read and patch the source, and we have priced the fork-and-maintain cost rather than assuming upstream support.
• The capability is genuinely new — nothing in our stack already issues entitlements. Duplicating an incumbent is the most common way a package like this gets adopted and then removed.
• We will run it behind a config flag in one non-critical service with a defined rollback before it touches revenue.

Look elsewhere when:

• We are not on Lunar. The integration story is the entire value proposition; without it we are adopting a 0.1 dependency for CRUD we could own in a sprint.
• We need commercial licensing guarantees — SLAs, a support window, security response. Move to a vendor: Keygen, Cryptlex, or a subscription-billing platform with entitlement management; commercial terms are the product here, not the code.
• We need offline or cryptographically signed license validation, floating licenses, or dongle-style enforcement. Those are specialist problems this package does not claim to solve.
• The requirement is really feature-gating and entitlements at runtime (plans, flags, usage metering) rather than per-purchase keys — a different product with a different vendor set.
• We want a maintained dependency with a documented change process. A 0.1 released with empty notes in January 2023, with no stated support window, does not meet that bar today. Use it as a reference implementation to inform our own design, not as a dependency.

The default position: timeboxed discovery (roughly half a day of intake plus a one-day spike), not adoption. Intake is cheap and is where this decision actually gets made. Confirm parent-repo health, current version matrix, and whether licensing now ships in-core; if those come back clean, promote to a single-service pilot. If they do not, the discovery output is still valuable — a documented build estimate.

How to Pitch It (Stakeholders)

To executives — one paragraph. We are evaluating the licensing module of Lunar, the Laravel commerce framework, as the cheapest path to selling digital products that need license keys — software, add-ons, downloads, seat-based access. It is a foundation, not a finished feature: it gives us key issuance, validation, and activation tracking tied to orders and customers, and leaves billing, self-service, and revocation policy to us. The upside is speed and native fit if we are on Lunar; the downside is that it is an early-stage (0.1) component of a single-maintainer ecosystem, with no stated support window, which means we would be buying maintenance risk as well as code. Recommendation: a timeboxed discovery, not an adoption. Estimated cost to find out is one to two engineer-days and no roadmap delay; the cost of getting it wrong in production — an emergency in-house fork during a framework upgrade — is measured in weeks and is invisible at sign-off.

To engineering — the ask. We need a decision on capability scope before architecture: are we building entitlement issuance, or are we only consuming keys issued by a third party? If the former, give us a one-day spike on a clean app at our target Laravel version — install, publish, exercise the documented surface — and a written estimate of what it would take to own this code, including the revocation and refund paths. Name an owner, pin the version exactly if we proceed, and record the review date. Do not let dependency automation bump a pre-1.0 package; every bump is a manual read until it reaches 1.0 or demonstrates changelog discipline.

The framing that keeps this honest. Two questions decide it: Are we on Lunar? and Do we need more than a key and an activation count? If both answers are yes, this is a cheap win worth a pilot. If either is no, we should be evaluating a licensing vendor or a small in-house service — and we should stop describing this as "adopting a package," because the actual commitment is to someone else's roadmap.