Consider dropping legal requirements

[funnelfiasco]

Most, perhaps all, of the legal requirements are not meaningfully attached to security threats. While they're all good things for projects to do, they seem out of scope for a security baseline and thus violate the "meaningful" part of the "FRAM" guidance.

[david-a-wheeler]

Disagree. The legal mechanisms are foundational mechanisms and assumptions that make it possible to meet the security requirements, and justify why these are enough. These are focused, realistic, actionable, and meaningful, so they are FRAM.

[david-a-wheeler]

Without proper licensing you cannot review code, cannot fix code, or cannot use code.

[david-a-wheeler]

Here's a specific example: There are a number of faux-OSS projects that have no license statement anywhere. In many cases these cannot be legally used, and yet their maintainers think they're part of the OSS community. These are security nightmares, and they're easily fixed by ensuring that they have licenses.

[puerco]

I agree with David. Right now, baseline is a mix of security + oss sustainability + legal risk. It's a more holistic approach to security and risk.

That said, instead of dropping them, I would rather have us split the requirements into profiles that projects could track and maybe even comply with individually. If levels go in one direction, these would cut across. We sort of discussed this when trying to define project types (source/libraries/released artifacts).

A split like this would let each track or profile flourish better. For example, we can do better on the supply chain security side, but I feel so far we've been a little coy not to overload baseline. Having those profiles would let experts in each area focus better.

(cross-cultural note: hopefully I'm using coy as I understand it :) )

[hyandell]

From the bleachers, I do like having the licensing items in the baseline.

[trumant]

I'm highly supportive of @puerco's perspective. Risk is broad and IP/legal risk could stay in if we think about differing groups of controls in combination for different purposes.

[funnelfiasco]

My objection to the risk-foucsed arguments, and specifically is that this is the Open Source Project Security Baseline, not the Open Source Project Risk Baseline. Not everything that projects really, really ought to do is suitable for inclusion. For example, I think a code of conduct is an absolute must for any project in 2025, and one can argue that a code of conduct helps projects be more sustainable (because it helps prevent jerks from driving everyone else away), which then guards against certain risks and could even have a security impact. But if someone suggested we add "have a code of conduct" to OSPS Baseline, I would close my laptop and go for a long walk in the woods.