I looked at the sample:

> This contract was created using ohjelmistofriikit.fi contract template.

Very good. Consider having some kind of version information, such as a date (more human readable) git commit id (unambiguous), or just 1.0.0.

Assuming your contract becomes popular, it's easy to just see that "oh, this is the ohjelmistofriikit contract version 2" instead of reading every word.

▲

baobabKoodaa 3 days ago | parent [-]

Hmmh. We have to also keep in mind that there are various customization options in the form. So even though someone might see "oh, this is ohjelmistofriikit contract", they should read through, because the customization options change the contents of the contract significantly. We can't solve this by adding git commit info or similar versioning.

▲

gwbas1c 3 days ago | parent [-]

Then you can list all the options in a concise manner.

▲

baobabKoodaa 3 days ago | parent [-]

I don't know exactly what you're asking of me. We already released the GoogleDoc that has all the options. It's linked on the landing page. It's the most concise way of expressing all the possible options in the generated contract. We don't want the generated contract to look like that, as that would defeat the whole purpose of the web generator.

Alternatively, one can step through the web UI flow to see what all the options are without the legalese.

▲

gwbas1c 3 days ago | parent [-]

> 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?

▲

baobabKoodaa 3 days ago | parent | next [-]

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.

▲

gwbas1c 3 days ago | parent [-]

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.

	▲	baobabKoodaa 3 days ago \| parent [-]
		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?

▲

gfna 3 days ago | parent | prev [-]

Gpl and mit licenses dont have multiple parameters