[codysc]

This makes a lot of sense. Providing some kind of categorized/easily digestible format for the policy to fit into. When I was writing mine I tried to be very clear, but my startup is specifically focused on privacy, so I didn't really have much to disclose.

[smichel17]

The GitHub terms of service[1] have a pretty good format. However, the summaries are often too vague -- they describe the type of content instead of summarizing its contents, so it's still possible to hide unsavory details. For example, section R2, on assignability, is grossly imbalanced.

I co-authored the Snowdrift.coop terms of service[2], which we adapted from GitHub -- we could not afford legal review and figured GitHub has enough lawyers to make sure the CYA language included was thorough enough to cover us pre-launch (we will get legal review before processing payments for outside projects). There was some legalese we'd prefer to remove but didn't feel comfortable without legal counsel, but the summaries are non-binding so we rewrote many of them to be more descriptive. Curious what you think!

On the privacy policy[3] side, we agreed with you -- if our policy was long or complicated enough that a summary was necessary, we were doing something wrong. So we just described all the ways we collect personal data, in "If you X, we will Y" format. For example,

> If you create a Snowdrift.coop account, we store your email address and use cookies to keep you logged in.

I wish more sites had policies like this, so that "long and unreadable policy" would become more of a red flag.

[1]: https://help.github.com/en/github/site-policy/github-terms-o...

[2]: https://snowdrift.coop/terms

[3]: https://snowdrift.coop/privacy

[codysc]

Re: Terms

I read through a good amount and I think they make sense. The short version helps, but that always worries me from a legal standpoint. If we summarize something in a legally ambiguous way have we undermined the original intent?

There are some inconsistencies with how you present the data that I think would help to smooth out. On your summary table. You start with the description being more of a goal for that section, than sporadically start switching to the "short version" of what your terms are.

For me I was hoping that it would be the short-version so I essentially get a comprehensive cliff-notes kind of view.

Also some minor issues with bolding some headers 4. Project Termination 4. Survival

As well as inconsistently formatting the short version. (I prefer the all bold version to help clearly show where the short part ends)

Privacy policies are much easier for me to wrap my head around. What you store, How you store it, and what you do with it.

This clause was a good idea that I will "borrow":

If our corporate structure or status changes (e.g., if we restructure, are acquired, or go bankrupt), we will notify all users so that you may choose to anonymize or delete your private data before we pass on any data to a successor or affiliate.

My version is here https://www.pritact.com/privacy-policy.html which I think follows along a lot with yours in spirit, but just has less ground to cover because of the nature of my platform.

[smichel17]

> If we summarize something in a legally ambiguous way have we undermined the original intent?

I share some of your concern. A written contract (including ToS) is supposed to capture an agreement between two parties, so if they later disagree on what was agreed, there's an unambiguous record. If one party isn't clear on the terms as written (say, because they only read the legally-ambiguous summary), then it's hard to say there was an agreement.

Unfortunately, these goals are often at odds: many websites/services feel the need to include lots of boilerplate to shield themselves from liability, and in the pursuit of precision, legalese is often jargony and inscrutable. In my opinion, we'd be better off if people didn't disclaim so much liability and were willing to take a chance on clearer but less established language. But there are societal reasons for those things that I can't really fix as an individual.

So, ideally, terms should be both legally precise and short/layperson-readable; in practice that's often not possible, which means any readable summary is necessarily ambiguous (otherwise, we'd just replace the terms with it). Given that existing ToS are often not layperson-readable, I think they're already failing to establish agreement, so I think that summaries, while clearly a non-ideal compromise, are a net positive.

> You start with the description being more of a goal for that section, than sporadically start switching to the "short version" of what your terms are.

I agree it could use more consistency and I agree the "shortest version" is better (many "goals for the section" barely have more meaningful words than the section title alone). It is how it is because summarizing is hard and our time is not unlimited. Definitely open to future revision.

For what it's worth, there is a "short version" at the top of each individual section; the table at the top is a further summary (hence "shortest" above). Given more bandwidth, I'd make each of the table sections expandable to show the "short version" as well.

> Also some minor issues with bolding some headers 4. Project Termination 4. Survival

Thanks. I suspect this has to do with the conversion from markdown (as they were written) to hamlet (for display). Opened an issue to track it. https://gitlab.com/snowdrift/snowdrift/-/issues/186

> As well as inconsistently formatting the short version. (I prefer the all bold version to help clearly show where the short part ends)

This was intentional; the bolded summaries are for two sections (warranty and liability) which, IIRC, are legally required to be emphasized. Usually that's done by putting the sections themselves in all caps (ugh), with the side effect of making them unreadable. GitHub's terms, on which ours are based, have a bold "Please read this section carefully; you should understand what to expect." in that section after the summary; we opted to just bold the whole thing. Maybe that's confusing, though, and we should just follow their lead.

> https://www.pritact.com/privacy-policy.html

I agree, it looks nice. :) Especially, I like putting the form of data collected as the first words of each sentence under "what we store". Having our "If you…" part first makes it read better but harder to skim. I'll propose changing that next time we modify the policy.

Aside, I looked at the home page and while I understood what your service does, it wasn't clear to me how it was delivered (app? website? dedicated hardware (joking)?). I don't think I would have figured it out if I hadn't seen a reference to app.pritact.com in the privacy policy.

[emilecantin]

I really like Tarnap's terms: http://www.tarsnap.com/legal.html

Concise, understandable, and explanations for almost all items are available.

[smichel17]

Thank you for the link; I really like the [why?] footnote style. Also, keeping the terms so short mean summaries really aren't needed :)

[asdff]

Credit card companies were forced to do this, and it has improved the industry for consumers having some bullet points of the key facts up front. Industries have to be forced to act on consumers behalves, as they stand to benefit from fleecing them.