While UUID4 can be good for UserID. Sometimes, to avoid having a second index in the DB, ULID is another good option; As not only it supports some of the features of UUID4 of uniqueness, it is also sortable.
Also curious because I don't actually know: If a format spec is GPL, does that encumber implementations of said spec?
Most ULID implementations are still actively maintained and people are still using it in production. Most implementations also have liberal license like MIT so no, you should not worry about the GPL spec (unless you plan to distribute the spec with your app).
I'm using ULIDs for the cases when the entity is publicly orderd by time: any timestamped event, e.g. a chat message, a log entry, or a sensor measurement/metric.
But need to be careful that the timestamp resolution is detailed enough.
Also, while ULID might be good for optimizing RDBMS indexes, it might create hotspots in NoSQL K/V stores (i.e. all entities will be created on the same node in the cluster).
How often is this really a bad thing? Are you worried about someone enumerating the entire space of possible ULIDs for every millisecond without ever rate-limiting them? Not many people are building anonymous, privacy-first websites and there's plenty of other ways to determine when a user first started using the site regardless.
It's not about guessing user IDs, but about deducting some useful information about them.
For example if an attacker may deduct wether an employee in a company a senior or a new one, and will know when exactly they joined the company.
I'd probably start with LinkedIn first :)