Switch to Community Specification license
As discussed during the 2021-12-01 meeting, we should consider switching to the Community Specification license. (more info)
We also may want to remove or replace the existing DCO "Signed-off-by" check. During the call, it was thought that Signed-off-by is redundant, while the Community Specification best practices suggests a CLA bot.
Are we ready to move forward with this switch?
No objections from me.
It appears that the example implementation given uses a dedicated community repo to serve as the source-of-truth and record of updates to the community spec. Should a https://github.com/slsa-framework/community repo be made? Otherwise, I'm happy to create a PR forking the spec into this repo to get the ball rolling
Hi all, I've recently been helping the LF with a writeup on implementing the Community Spec documents (https://github.com/CommunitySpecification/1.0/pull/12), based on some lessons learned from implementing this for SPDX.
I'm starting to put together a draft repo to implement this for SLSA at https://github.com/swinslow/slsa-governance, which could then be moved into the SLSA org as a governance repo. I'll circle back here with some questions for the community to consider. Thanks!
Following from my earlier comment -- please take a look at the updated documents at https://github.com/swinslow/slsa-governance. I've prepared and customized these for SLSA, with the intention that these would eventually move over to the slsa-framework org with governance as the repo name.
There are a handful of items in particular that the community will want to take a close look at. I've created separate issues for each of these at https://github.com/swinslow/slsa-governance/issues, so that folks can take a look and comment on those particular issues.
Feel free to ask questions, submit issues / PRs, etc. Thanks!
Given that the OpenSSF Charter requires Governing Board approval to use a different license for specifications we might consider this a bug, indicating that this is simply a case of implementing the change rather than deciding whether to change.
That would simplify the situation for me, as I am not sure I can fully comprehend the significance of the change.
The one thing we need to do before switching to this license is align the current SLSA governance with the new proposal. SLSA is a project under a WG with its own steering committee. We can sort this out on #https://github.com/swinslow/slsa-governance/issues/4
This is now complete as of #484.