"while active" felt confusing

[hyandell]

Reading the baseline entries, the "while active" items felt somewhat arbitrary (and unclear as to its meaning - EOL? Developers haven't done anything for 2 weeks?).

For example, an inactive project would fail baseline level 1 if it has an 'http:' url, but it is fine if the project's source is no longer available.

Note also that items like 'OSPS-QA-01.02' appear to imply 'while active' as they wouldn't make sense if OSPS-QA-01.01 is passed only because the project isn't active.

[hyandell]

The following are the ones that felt confusing as to why they are 'while active'. I feel all of the below are as true when not active:

• 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.
• OSPS-LE-03.01: While active, the license for the source code MUST be maintained in the corresponding repository's LICENSE file, COPYING file, or LICENSE/ directory.
• OSPS-LE-03.02: While active, the license for the released software assets MUST be included in the released source code, or in a LICENSE file, COPYING file, or LICENSE/ directory alongside the corresponding release assets.
• OSPS-QA-01.01: While active, the project's source code repository MUST be publicly readable at a static URL.
• OSPS-QA-04.01: While active, the project documentation MUST contain a list of any codebases that are considered subprojects.
• OSPS-QA-05.01: While active, the version control system MUST NOT contain generated executable artifacts.
• OSPS-QA-05.02: While active, the version control system MUST NOT contain unreviewable binary artifacts.

That said, I think the better path is to simply say that an inactive project is not within scope for the Security Baseline and instead there is a "End of Lifed Security Baseline" that they must meet. Then "While active" can be removed entirely because the Security Baseline would only focus on projects that aren't EOL.

[funnelfiasco]

For context, I said in the Slack discussion:

we want to make it clear that people don't need to go back and retroactively fix archived projects

The challenge that, IIRC, the "while active" phrasing was intended to address is also a challenge for the next paragraph: most projects don't explicitly go EOL, they just sort of fade away over time. "Active" is a tough to define term, which argues in favor of dropping it. I can definitely see that "while active" causes confusion.

I am on board for an edit to say EOL projects (and releases, which are separate considerations, IMO) are explicitly out of scope. An "EOL Security Baseline" is probably more a "checklist of things to do before you EOL your project", but that's probably not for this group to handle (at least not for a while).

[eddie-knight]

I'm fine with the idea of dropping While active, as it was originally included to enforce style.

A similar conversation was opened last week on the CCC repository recommending simplification of the assessment requirement prose, which follows the same style of When <CONDITION>, <ACTOR> MUST/NOT <ACTION>.

[ericcornelissen]

I found this very confusing as well.

Here's my point of view: If my project is not active I won't be filling out this checklist for it. Hence, "while active" is useless at best and distracting/confusing at worst.