ossf
Consider dropping legal requirements
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.
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.
Without proper licensing you cannot review code, cannot fix code, or cannot use code.
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.
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 :) )
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.
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.
Without proper licensing you cannot review code, cannot fix code, or cannot use code.
This is true, but OSPS Baseline is for project maintainers. Consumers can decide whether or not a project is fit for their purpose, and the project license should be one of those considerations. And depending on who the consumer is, non-OSD-compliant licenses might be sufficient. The Floodgap Free Software License does not permit sale of the covered work or derivatives, but for many use cases, that's not a problem. It would not prevent reviewing, fixing, or using (in many cases) code. Alternatively, having a copyleft license might mean some consumers cannot use the code. We wouldn't argue that Baseline should exclude copyleft licenses on that basis.
We discussed this in today's meeting and reached no firm decision. There's agreement that requiring a license expression in some form is probably worth retaining. We agreed that the next step is to collect the set of threats we want to protect projects against and then we can evaluate our existing and proposed legal requirements against that set.
this is the Open Source Project Security Baseline, not the Open Source Project Risk Baseline.
Yes, so not being OSS is disqualifying. Since it's disqualifying, we need to ensure that we at least check the license as one of the criteria.
OSPS Baseline is for project maintainers. Consumers can decide whether or not a project is fit for their purpose, and the project license should be one of those considerations. And depending on who the consumer is, non-OSD-compliant licenses might be sufficient.
The issue isn't consumers, it's the impact on the project. If it's not OSS, the reason many would review the software has disappeared. So you lose the opportunity for mass peer review, which can really help the security of such software. In addition, the ability or incentive for others to improve the software has generally disappeared. Perhaps worst of all, there's generally no ability to fork the project if things have gone wrong, so many problems are completely unfixable. Baseline was designed to help OSS projects increase the likelihood of developing secure software, building on capabilities and freedoms specific to OSS. Baseline's approach seems inadequate to me for directing a software project to be secure if the software isn't OSS. What's more, that's okay. Few things can do everything. It's better to make something's scope crystal clear.
"Being OSS" though is a distraction. CC-BY isn't OSS, Public Domain isn't OSS, but I doubt anyone would fault them for using Baseline. Absolutely focus Baseline on open source project needs, even state that in the scope, but baking in a rule that makes Baseline fail if something doesn't match a list of licenses is an unnecessary distraction imo. Is explaining why something like SQLite can't meet Baseline Level 1 worth it?
The requirements that I see in https://baseline.openssf.org/versions/2025-02-25 are:
OSPS-LE-02.01: While active, the license for the source code MUST meet the OSI Open Source Definition or the FSF Free Software Definition. OSPS-LE-02.02: While active, the license for the released software assets MUST meet the OSI Open Source Definition or the FSF Free Software Definition.
Public domain (copyright not export control definition) meets the FSF Free Software Definition. It also meets the OSD, though OSI doesn't consider it "OSS" because of the technicality that there isn't a project-specific license text (the license text is given by law, not by a specific project permission). I don't know that I've ever seen software under CC-BY, since Creative Commons specifically asks people to not release software that way. If it happened, I believe it would meet the FSF Free Software Definition anyway (and probably the OSD too), though I don't know that anyone's done the walkthrough. So yes, SQLite (public domain) easily meets the license requirement.
If software isn't OSS, then that should be disqualifying. These criteria were designed presuming that the software is OSS. It's possible to create closed source software that is secure, but at that point mass peer review isn't a practical option, so you need to take different steps.
Fair point on FSF SD including public domain.
On CC-BY (and the rest of the CC family), I've definitely seen software under CC licensing, always a questionable decision. I guess LE.201 et al refer specifically to 'software' and projects that uses CC-BY is more likely to be non-software (or non-typical at least) such as data, fonts, images. Is there an implicit "Baseline is only for software"? Or is it intended that a proprietary specification could show that their project meets baseline while one with software in couldn't?
When I read 'a set of security criteria that projects' I've been reading it as "you have a repository on GitHub/GitLab etc".
If software isn't OSS, then that should be disqualifying. These criteria were designed presuming that the software is OSS.
If the presumption is that the software is OSS, why does the checklist need an item for it? The answer must be yes by the presumption.
While I can somewhat understand the sentiment that projects should make sure they're properly licensed, this checklist just doesn't seem like the right place to do that to me. As a maintainer, I come across this and my motivation for filling it out it is one of the following
- I want to make my project more secure
- I want to be able to show to my consumers that I'm secure
In neither case am I interested in the license I'm currently using.
Admittedly, the website says it's a checklist for maturity, not security[^1], but based on the name of the checklist I'm expecting to fill out a security questionnaire, not a maturity one.
For context, I, as an outsider, tried to fill this out for one of my projects and it took me 45min(!) to do a full pass (and I still have open questions, which I will raise separately). Any and all questions that can be removed to reduce that time are critical if you want maintainers who are not predisposed to security (like me) to take an interest in this project.
[^1]: The word "security" is nowhere to be found in "The Open Source Project Security Baseline (OSPS Baseline) is designed to act as a minimum definition of requirements for a project relative to its maturity level. It is maintained by the OpenSSF Security Baseline SIG according to the project governance documentation."
If the presumption is that the software is OSS, why does the checklist need an item for it? The answer must be yes by the presumption.
It's a requirement, not a presumption, so it makes sense to state it as a requirement. A checklist for closed source software would require many more items, because it would make no sense to encourage or enable public peer review in such cases.
In neither case am I interested in the license I'm currently using.
You may not be interested, but potential contributors and reviewers and users are. A common reason programs don't get security reviews, etc., is because they aren't open source software or free software. There are still people who confuse "posted on the Internet" with "open source software". Having this item forces people to confront the need to make a decision.
For context, I, as an outsider, tried to fill this out for one of my projects and it took me 45min(!) to do a full pass (and I still have open questions, which I will raise separately).
That is a problem. However, I think the solution is automation. The Best Practices Badge site automatically detects licenses and fills in its equivalent question, along with the justification. It turns out to be easy to automate for nearly all cases. Do this for baseline, and then that (legitimate!) problem disappears. I'm actually starting down that road now.