Create guide to a COMPLIANCE file

[david-a-wheeler]

In the 2025-07-21 working group meeting it was posited that it'd be useful to have a "COMPLIANCE.md" file. Many of the people tasked to get compliance-related information won't know how to handle a SECURITY-INSIGHTS.md file.

@david-a-wheeler has drafted Guide to creating a COMPLIANCE file as a Google document to see if this can go anywhere. Suggestions welcome.

[rozhukov]

Not objecting creating such a file in principle, but strongly objecting the naming "COMPLIANCE".

I'm a huge supporter of the CRA is a good thing and super interested to cook it right for the projects. I'd encourage us to continue brainstorming if it could be as light as recommendation to add compliance expression directly to readme.md or security.md. Alternatively, we can consider steward.md, cra.md and even defer/channel this idea into security-insights.yaml or collaborate with OWASP sustainability.yaml effort.

Here are reasons why:

• compliance.md naming as could potentially have the opposite effect for maintainers, raising resistance instead of encouraging for security practices. I've already experience a few pushbacks from open-source projects out in the wild. Chances to promote CRA in the right way are lower here.
• compliance.md brings unnecessary complexity
• compliance.md gives the wrong signal to open source project consumers (aka users, manufacturers, etc.) that they can expect (even demand) compliance
• compliance.md doesn't (at the moment) support automation/machine-readable notation

Idea is good. The wording COMPLIANCE is just not the right term in the open-source vocabulary, in my opinion.

Thanks folks.

[sjn]

I think a COMPLIANCE.md file can be made useful, assuming we're crystal clear about a couple of things.

1. Complete clarity on who is the intended audience of the message in this file.
2. Complete clarity on who is the author if this message.
3. What the intention and scope of this file is.

As with any well-made message, the author has to tailor it to the intended audience. If the audience are compliance officers, software procurement staff, auditors or market authorities, then "COMPLIANCE" is a keyword they know very well, and will be looking for.

As for the message itself, it should contain only the author's view on each of the compliance-relevant questions addressed in the file. If the author says "You are on your own", then the document should contain exactly those words.

As for the intention and scope, let's keep in mind that there are already a LOT of files one can add to any given project. If one more is going to be added, it needs to have a clear and unambiguous purpose, with a minimal "conceptual overlap" with other files. If the audience can look for a singe file containing their relevant information and nothing else ("just the bare facts, m'am!"), then this file has the perfect scope.

"All-in-one" files create different headaches, but can be made useful by making them machine-readable and let relevant tooling select and present only the relevant bits.

Human-readable files, on the other hand, are consumed using human attention without a filtering/curation step, and should therefore be created with respect for the (human) reader's time and attention.

Happy to accept that COMPLIANCE.md isn't the best name for catching the attention of the intended audience. If that's the case, then what would be a better name?

(On a side note, the OWASP project you mentioned has recently been promoted to ECMA-TC54 TG4: CONTRIBUTING.yaml)