Establish license for code & advisory data

[mbauman]

There are three questions here:

• What is the license of the code: this one is easy IMO: it's MIT. (cc @nHackel, could you please confirm that you can license your contributions in Add purl entry to osv_dict #102 as MIT?)
• What is the license of the advisory data that are first authored and directly contributed here? There seem to be two prevailing good-practice options here: either CC0-1.0 or CC-BY-4.0. See, e.g., OSV's list of databases and their licenses: https://google.github.io/osv.dev/data/#current-data-sources
• What is the license of the advisory data that are derived from other sources? We currently support three four data sources:
  • NVD: Public domain, but I suppose we should add the clause "This product uses data from the NVD API but is not endorsed or certified by the NVD": https://nvd.nist.gov/developers/start-here
  • EUVD: It's a little muddy, but I think it effectively requires attribution, deferring to their upstream source... but they don't really even do this in their own data.
  • GHSA: Actually has two different sources with — I think — different terms.
    • The global advisory DB itself is CC-BY-4.0, with attribution to the database URL itself.
    • Individual repo advisories don't have any specific terms or guidance (AFAICS) and as such I would think they're driven by the terms of their repository unless otherwise specified.

We are capturing source data well with the jlsec_sources field, which is then provided to downstream consumers via the database_specific dict. We could potentially add a license field like rustsec has done.

[nHackel]

@mbauman, yes my contribution can be licensed as MIT

[Octogonapus]

I believe EUVD states in their legal notice that "Reproduction of ENISA material published on this website is authorized, provided the source is acknowledged, unless it is stated otherwise." My understanding is that that covers the EUVD. Therefore, we only need to "acknowledge" the source (whatever that means, perhaps simply stating the source is sufficient). If you have doubts, perhaps you could contact info@enisa.europa.eu.

For GHSA, are you republishing any individual advisories that aren't under https://github.com/advisories? If so, I am not sure of the licensing (maybe an example would help). Otherwise, everything under that URL is licensed under CC BY 4.0.

I agree with your other suggestions.

[mbauman]

Yes, there are no Julia advisories currently under the global https://github.com/advisories. An example is the current DONOTUSEJLSEC-2025-1. That's imported directly from the repository advisory GHSA-4g68-4pxg-mw93. In that case, we requested a CVE from GitHub staff, so they submitted an edited version of the advisory to MITRE under public domain as CVE-2025-52479.

[mbauman]

I'm thinking it makes sense to use CC-BY for contributions here. That's what global GHSAs are, and the NVD and EUVD are both effectively requiring attribution themselves. The only annoying part then are advisories like GHSA-4g68-4pxg-mw93 — is that really MIT licensed? Should we try to get permissions from the advisory authors for CC-BY? What about the advisories on repos with more restrictive licenses?

[mbauman]

Closed by #131