wg-best-practices-os-developers
wg-best-practices-os-developers copied to clipboard
ossf
Contribution proposal: Scorecard Monitor and Scorecard API Visualizer
As suggested in the [updated] process for project donation, interested parties should submit a request to the relevant WG for consideration.
We've been having discussions with the maintainers of Scorecard Monitor and openssf-scorecard-api-visualizer and they are interested in donating these projects to OpenSSF as part of the Scorecard ecosystem.
Our ecosystem today:
- https://github.com/ossf/scorecard
- https://github.com/ossf/scorecard-webapp
- https://github.com/ossf/scorecard-action
- https://github.com/ossf/scorecard-dependencyanalysis
Given Scorecard is already an OpenSSF project and its maintainers are interested in absorbing these new projects, what is the best way to move forward?
WG maintainers: @SecurityCRob @david-a-wheeler @drusso-rh Scorecard maintainers: @ossf/scorecard-maintainers xref: https://github.com/ossf/scorecard/issues/3204, https://lists.openssf.org/g/openssf-tac/message/686
Hi, I'm a bit surprised by the use of the term "donate" here. We typically don't received donations. We receive contributions. The difference is important in that a donation doesn't imply any further involvement while a contribution does. For that matter the page you linked from "project donation" in your description does not use that term. If the maintainers aren't planning on staying involved, are the Scorecard maintainers ready to take over? Please clarify. Thanks.
If the maintainers aren't planning on staying involved, are the Scorecard maintainers ready to take over?
The maintainers (@kooltheba and myself) plan to continue maintaining the project and further involvement after the contribution/donation 👍
Hi Stephen - Thanks for flagging this for me. We'll want to follow the process documented in the TAC github for sandbox entry: Sandbox Entry Requirements and Considerations
1.) Projects must have a minimum of two maintainers with different organization affiliations. 2.) Projects must be aligned with the OpenSSF mission and either be a novel approach for existing areas or address an unfulfilled need. It is expected that the initial code needed for an OpenSSF WG to work be kept within their repository and will not function as a project in its own right. Should initial WG code grow and mature that it warrants its own Project status, then it is subject to Sandbox entry requirements. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project. 3.) If contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF).
Monitor For 1.) I see two contributors from separate orgs For 2.) I personally feel this is aligned with our mission and is something novel 3.) This would be our next step
Visualizer
- same, I see two maintainers from separate orgs
- same, interesting idea
- same next step
Have you talked about these two projects with the Scorecard team and they were cool with the idea? CC'ing @laurentsimon (my point of contact for the Scorecard project to the BEST WG).
On the whole, I am very positive about this and once I hear back from the project team, we can create the PR start the IP review stage in the TAC repo. Cool ideas, nice extensions of the existing Scorecard work!
First of all, welcome! We're always glad to see people trying to improve security!
To me, these look like new projects being proposed by @UlisesGascon and @KoolTheba - which is awesome!
We'll need to do a quick legal review. I think these projects are all code projects, yes? All use Apache-2.0 or MIT licenses, correct? Those two are always fine for code (per OpenSSF charter). Please email me at dwheeler @ linuxfoundation.org, I'll forward you on to others for legal review. I don't expect any problems, but we always have to do a basic legal review.
Thanks for flagging this @david-a-wheeler operations had missed this as we have only expected this IP Policy and License Review to come through TAC issued. We have moved this through the system, and legal will get back to us on the timeline for when they can finish the request. @justaugustus you should know to always ping [email protected] by now! :) We apologies for the delay.
@hythloda - as always, thank you!!
If it's just Apache-2.0 and MIT licenses there's usually no issues. Please let us know if you have trademarks, domain names, patents, etc. As I mentioned earlier, I expect no issues.
@hythloda - nothing to apologize for. I figured we could get the legal review started sooner, so we can complete it sooner.
I took the liberty to change the title because the original one really conveyed the wrong idea.
How did the legal review go? Are we good to merge and adopt some new friends?
How did the legal review go? Are we good to merge and adopt some new friends?
Still waiting on legal, they normally do Friday updates but haven't heard back yet :(
Just to provide an update... IP Policy and License Review is still pending.
Legal (and LF staff in general) were busy with LF Member Summit this week.
Hoping for an update next week!
`###
LICENSE INTAKE SCAN & ANALYSIS: OpenSSF: openssf-scorecard-monitor
- This intake scan is a static analysis of the source code in your repository. A dependency scan was not performed. Once a project is added to LFX [https://security.lfx.linuxfoundation.org], you can use SNYK to view a dependency scan for both licenses and vulnerabilities.
CODE SCANNED: [pulled 01–Dec-2023]
- https://github.com/UlisesGascon/openssf-scorecard-monitor
PROJECT LICENSE: MIT
- Top level project license file found.
SPDX LICENSE IDENTIFIERS: SPDX license identifiers were not found in any source file headers.
- I recommend that SPDX license identifiers be added to ALL source file headers. [see https://spdx.dev/learn/handling-license-info for examples]
PERMISSIVE LICENSES: MIT, Apache-2.0, BSD-3-Clause
COPYLEFT LICENSES: None found
PROPRIETARY LICENSES: None found
LICENSE CONFLICTS: None found
BINARY / PACKAGE FILES: None found
THIRD PARTY CODE / DEPENDENCIES: Dependecies were found in package.json files. These dependencies were not scanned, and any potential license conflicts from them are not identified here.
- https://github.com/UlisesGascon/openssf-scorecard-monitor/blob/main/package.json
- https://github.com/UlisesGascon/openssf-scorecard-monitor/blob/main/package-lock.json
THIRD PARTY NOTICE FILE: None found
SUMMARY FINDINGS: The code is licensed under the MIT license, which is the project license. SPDX license identifiers were not found and should be added to all source file headers. No license conflicts found.
LICENSE INTAKE SCAN & ANALYSIS: OpenSSF: openssf-scorecard-api-visualizer
- This intake scan is a static analysis of the source code in your repository. A dependency scan was not performed. Once a project is added to LFX [https://security.lfx.linuxfoundation.org], you can use SNYK to view a dependency scan for both licenses and vulnerabilities.
CODE SCANNED: [pulled 01–Dec-2023]
- https://github.com/KoolTheba/openssf-scorecard-api-visualizer
PROJECT LICENSE: Apache-2.0
- Top level project license file found.
SPDX LICENSE IDENTIFIERS: SPDX license identifiers were not found in any source file headers.
- I recommend that SPDX license identifiers be added to ALL source file headers. [see https://spdx.dev/learn/handling-license-info for examples]
PERMISSIVE LICENSES: Apache-2.0
COPYLEFT LICENSES: None found
PROPRIETARY LICENSES: None found
LICENSE CONFLICTS: None found
BINARY / PACKAGE FILES: None found
THIRD PARTY CODE / DEPENDENCIES: Dependecies were found in package.json files. These dependencies were not scanned, and any potential license conflicts from them are not identified here.
- https://github.com/KoolTheba/openssf-scorecard-api-visualizer/blob/main/package.json
- https://github.com/KoolTheba/openssf-scorecard-api-visualizer/blob/main/package-lock.json
THIRD PARTY NOTICE FILE: None found
SUMMARY FINDINGS: The code is licensed under the Apache-2.0 license, which is the project license. SPDX license identifiers were not found and should be added to all source file headers. No license conflicts found.
`
@jeffcshapiro - thanks for the scan! Adding license info to each source file is a good practice, but that won't prevent initial acceptance. License of the main code looks fine to me (let me know if I missed something).
I presume there aren't other legal "IP" things to deal with beyond copyright, correct? I'm thinking trademarks, trade secrets, patents, domain name registrations, or government seals. I doubt any of that's an issue, but if it is please let us know.
The goal is to make sure there are no legal "gotchas".
@david-a-wheeler
Adding license info to each source file is a good practice, but that won't prevent initial acceptance.
Agreed - a good idea but no reason to cause any delay.
License of the main code looks fine to me (let me know if I missed something).
The project under MIT (which is a fine license) you may want to re-license under Apache-2.0 as I think that is what your charter specifies, or your board can approve a simple exception if needed.
I presume there aren't other legal "IP" things to deal with beyond copyright, correct? I'm thinking trademarks, trade secrets, patents, domain name registrations, or government seals. I doubt any of that's an issue, but if it is please let us know.
I don't think there is anything else, but I will double-check with @mkdolan
The project under MIT (which is a fine license) you may want to re-license under Apache-2.0 as I think that is what your charter specifies, or your board can approve a simple exception if needed.
Actually the OpenSSF charter provides for code to be licensed under either the Apache 2.0 license or the MIT license so the code can stay with the MIT license.
@lehors is correct, the charter specifically states that MIT or Apache-2.0 is fine. Other licenses are possible but require governing board approval. So the code can stay with the MIT license, there's no problem.
@justaugustus : Are there any other legal "IP" things to deal with beyond copyright? E.g., trademarks, trade secrets, patents, domain name registrations, or government seals? I doubt any of that's an issue, but if there is something please let us know. The reviews above don't show any copyright-related issues. Really, this looks like all is smooth sailing, but we just need to confirm that there aren't any other potential issues (if there are issues, we want to quickly get them resolved).
As far I know there are no other "IP" thing in any of the projects ( trademarks, trade secrets, patents, domain name registrations, or government seals). 👍
@david-a-wheeler - since you were helping on the staff-side, could you check and see what we need to do to close this out? It looks like things are good, but just want official LF-word so we can let these folks keep rolling.
@hythloda - as noted above, no legal issues have been identified. MIT license is fine, license scan saw no issues, no other legal issues have been identified (patent, trademark, domain name, etc.). I presume this is fine by today's end unless I hear otherwise...!
My understanding is we are waiting on the Scorecard charter to be approved @justaugustus might know more.
Do we know if the Scorecard charter was approved? (cc: @justaugustus )
We've just completed review of the Scorecard project charter with LF Legal and it's over to them to establish the project officially. Once that is done, we'll be able to accept the project donation request.
@afmarcum or I will provide an update on this issue weekly!