Where does the idea of a datasheet for datasets come from?
It comes from a 2018 paper by Timnit Gebru and colleagues, who borrowed the idea from electronics, where every component ships with a datasheet. They proposed "that every dataset be accompanied with a datasheet that documents its motivation, composition, collection process, recommended uses, and so on" (Gebru et al., Datasheets for Datasets, first posted March 2018, published in CACM December 2021). The aim, in the authors' words, is better communication "between dataset creators and dataset consumers".
What goes in a datasheet for SOPs, documents or code?
It describes the data without exposing it. For SOPs and internal documents: what kinds of documents are included, which systems they came from, the years they span, which teams wrote them, the languages, known gaps, and what was excluded or de-identified. For support conversations: products, channels and periods covered. For a codebase: languages, repositories, how much commit and review history is included, and which third-party code sits inside and under what licences. A closing section can state the uses you will allow and the ones you will not.
Why does a datasheet help a company licensing its data?
It answers a buyer's first questions in one document, so less of your actual data needs to change hands while they evaluate it. Writing it also forces the internal checks that matter before a licence, on provenance, personal data and third-party rights, and it gives the scope and terms of the deal a plain description to point to. Your company can be paid more than once, through renewals and repeat licences. A datasheet you keep current makes each renewal easier to describe.