As literally everyone has figured out, the licenses section needs a lot of improvements. It hasn't had a structural revisit since the early days of v1, and the way companies use licenses has changed over the years.

We have at least three different scenarios:

Scenario 1 -Licenses with a single product key, expiration, etc where all of the seats share the same key, etc.

This is the way the licenses currently work, and it's a bit limiting. Folks have come up with clever workarounds, like using the license seat ID as a map back to the multiple product keys they've entered into the single product key box. That works pretty well for a small number of licenses, but it's not really tenable for licenses with 100 or more seats.

Scenario 2 -Licenses with different keys, expirations, prices, etc per seat

This is a pretty common scenario as well, and one we don't currently handle particularly well but we could. The seats already exist in the database, we'd just need to add a few additional pivot fields to store those individual attributes per seat. This really makes Licenses behave a bit more like Asset Models, with seats behaving more similarly to Assets. The problem there becomes UX. It could easily become horrible and unwieldy to have to enter product keys, etc for thousands of license seats, and we're discussing internally how to make that not suck as much as it seems like it would.

We've discussed using a larger text field with each product key separated by a new line, but that doesn't account for the registered user/email, and it doesn't handle the case where an actual .lic or .xml file is the actual key and would need to be uploaded per seat.

Prices can also fluctuate over time per seat, since some folks might be using older licenses that had a lifetime purchase option but newer versions of the same license don't have that.

This is by far the hardest UX challenge of all of these scenarios.

Scenario 3 - Cloud licenses

Stuff like MS Office, where you have a pool of seats that you can add and remove, but the expiration date is the same. I think most folks just use the way it currently works and they add/remove seats as needed, but there's likely some other scenario I'm not thinking about at the moment.

Right now, perhaps stupidly, we create a record in the license_seats table for each license seat, even if it has never been checked out. This is dumb for the way it currently works, but is more conducive to handle Scenario 2, since those individual associated seats could be made to be precious. Right now, they're not.

We've been talking about this internally for quite some time and really need to get this sorted. I'm open to hearing additional scenarios that aren't covered by the ones I posted above as we work through the license rework.