> I don't know exactly what you're asking of me.
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?
Okay, I understand the analogy. You imagine a world where there would be a "standard contract" that could be referenced by its name, just like the MIT license can be referenced by its name without having to read it every time. Would that be nice? Sure. But we didn't create anything like that. Our contract-generator can output many different kinds of contracts depending on the inputs. This was a design choice that we made early on: we wanted to support many different kinds of needs, as opposed to just creating a singular one-size-fits-all contract template. The whole point of having a web generator for the contract is that it gives you easy access to tweak all the different clauses. If it was just a one-size-fits-all contract template, why would there be any "generator" in the first place? So... I'm back wondering what it is you're asking me to do exactly.
This:
> 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.
So, suppose you have 2 different contracts. One is extremely favorable to the freelancer, whereas the other one is extremely favorable to the client. And they both have the same git commit id. What does the git commit id help in this situation? What would somebody gain from seeing it?
Gpl and mit licenses dont have multiple parameters