Contribution proposal: Scorecard Monitor and Scorecard API Visualizer

[justaugustus]

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: ossf/scorecard#3204, https://lists.openssf.org/g/openssf-tac/message/686

[lehors]

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.

[UlisesGascon]

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 👍

[justaugustus]

Spoke with @SecurityCRob and he'll take a look at this request soon!

[SecurityCRob]

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

1. same, I see two maintainers from separate orgs
2. same, interesting idea
3. 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!

[david-a-wheeler]

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.

[hythloda]

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 operations@openssf.org by now! :) We apologies for the delay.

[david-a-wheeler]

@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]

Legal says they will get to it next week.

[david-a-wheeler]

@hythloda - nothing to apologize for. I figured we could get the legal review started sooner, so we can complete it sooner.

[lehors]

I took the liberty to change the title because the original one really conveyed the wrong idea.

[SecurityCRob]

How did the legal review go? Are we good to merge and adopt some new friends?

[hythloda]

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 :(

[justaugustus]

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!

[hythloda]

Should get the update tomorrow

[jeffcshapiro]

`###

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.

`

[david-a-wheeler]

@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".

[jeffcshapiro]

@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

[lehors]

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.

[david-a-wheeler]

@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.

[david-a-wheeler]

@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).

[UlisesGascon]

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). 👍

[UlisesGascon]

Is there anything that I can do to help with this? 🙂

[SecurityCRob]

@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.

[david-a-wheeler]

@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...!

[hythloda]

My understanding is we are waiting on the Scorecard charter to be approved @justaugustus might know more.

[UlisesGascon]

Do we know if the Scorecard charter was approved? (cc: @justaugustus )

[UlisesGascon]

any news? Just a friendly ping 😊

[david-a-wheeler]

@hythloda or @justaugustus may know more. Any news?

[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!

[justaugustus]

The Scorecard project charter ([pdf][markdown]) was adopted yesterday, 2024-04-24! 🎉
We're working with LF Legal on a few outstanding questions around the donation requests for Scorecard Monitor and API Visualizer.

[justaugustus]

Closing this, as any remaining items for the project donation are constrained within the scope of the OpenSSF Scorecard, which is now chartered, with donation requirements in draft.
The project-level tracking issue is here: ossf/scorecard#3204

Thanks for the help here everyone!