Alternatively, one can step through the web UI flow to see what all the options are without the legalese.
You'll "get it" once you start bringing in open-source libraries in a project where the lawyers need to screen them.
Often, the lawyers will says, "these licenses are good, these are bad." Then you pretty much know what you can grab because most projects just pick from a set of well-known open-source liscenses.
What makes it complicated is if you try to grab an open-source project that writes its own license (or otherwise uses one that isn't well known.) Then the lawyers need to read the whole thing.
---
So, assuming your contract becomes common, people will say things like, "We're working with the 2025 ohjelmistofriikit.fi at XX an hour, open commitment, ....", and not have to read the actual contract, because it's so common that everyone already knows what it means.
(Kinda like releasing open-source software and saying, "I'm using MIT" or "I'm using GPL" and everyone knows what you're talking about.)
Make sense?
> Consider having some kind of version information, such as a date (more human readable) git commit id (unambiguous), or just 1.0.0.
Remember, the point is to make it easy for people who are familiar with the generator.
Kind of like the six different variants of Creative Commons licenses: CC-BY, CC-BY-SA, CC-BY-NC, CC-BY-NC-SA, CC BY-ND, CC BY-NC-ND.