Clarify data license

[JamieMagee]

What license is the data¹ licensed under? It would be nice to add Arch Linux vulnerability information to OSV². Current data sources³ are licensed under either CC-BY 4.0 or CC0 1.0

Footnotes

1. https://security.archlinux.org/all.json ↩

2. https://osv.dev/ ↩

3. https://github.com/google/osv#current-data-sources ↩

[Foxboron]

It's unclear to me if we can license anything at all really. We usually re-purpose information from external trackers (Redhat, SUSE, MITRE and so on) and I don't think we do anything on top of that would constitute anything unique enough to be licenseable? It's essentially just a collection of work from several sources.

Inputs @diabonas @SantiagoTorres @anthraxx ?

It's also unclear what would be needed on the tracker side of things to be used in OSV. Is the intention to write a scrapper or have the tracker utilize the Google CVE shema?

[JamieMagee]

Thanks for the explanation. MITRE seems to have a pretty broad license¹ and explicitly allows derivative works and sublicensing:

MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy.

As for the OSV side of things, when I made this post I was under the impression that OSV was an OSSF project. However, it's only OSV schema. And that is apparently up for debate too? I'd like to park that part of my question until it's been cleared up by the vulnerability disclosure WG.

Footnotes

1. https://www.cve.org/Legal/TermsOfUse ↩

[Foxboron]

Thanks for the explanation. MITRE seems to have a pretty broad license1 and explicitly allows derivative works and sublicensing:

Right, but since we reuse a text from other trackers which is (probably?) licensed under something else I'm not sure if the MITRE license works in relation to this.

It also makes me question how we approach reusing text from other CVE tracker on our tracker :/

As for the OSV side of things, when I made this post I was under the impression that OSV was an OSSF project. However, it's only OSV schema. And that is apparently up for debate too? I'd like to park that part of my question until it's been cleared up by the vulnerability disclosure WG.

Yes, I have been rattling about with some opinions in the WG :p
However I don't have anything against the OSV project even if it's a Google project. So it's still a good idea to figure out how this could be done and what value it has.

[SantiagoTorres]

FWIW, I do wonder if we want to specify our data license beyond whatever OSV becomes...

[diabonas]

Thanks for the explanation. MITRE seems to have a pretty broad license1 and explicitly allows derivative works and sublicensing:

Right, but since we reuse a text from other trackers which is (probably?) licensed under something else I'm not sure if the MITRE license works in relation to this.

It also makes me question how we approach reusing text from other CVE tracker on our tracker :/

Even for descriptions taken directly from MITRE, we should probably consider adding their copyright notice in order to comply with the license: "Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy."

FWIW, in my opinion all the information in our tracker is not original enough to be copyrightable at all. Even if it somehow were, reproducing it would probably fall under fair use. Obviously I am very much not a lawyer though.

Therefore I would be perfectly fine to license our original work (the mapping of CVEs to our repository package versions) under something like the CC0 to make reproduction as easy as possible. The CVE descriptions however are usually not written from scratch by us, but adapted from some upstream source, so slapping our own license on them does not really feel appropriate.

[SantiagoTorres]

I think it's a little trickier than that.:

• We do write the impact, and mitigation sections of the ASA.
• The CVE description themselves is often verbatim, but often massaged (either by us or automated scripts).
• However, we generally do not take the description from MITRE (at least in my experience), but rather from descriptions in oss-security and such. These are usually from the vendor/author themselves. Are those licensed by MITRE too?

[diabonas]

• We do write the impact, and mitigation sections of the ASA.

The impact is indeed usually written completely by us. Mitigations are often taken from the upstream advisory and shortened/adapted for our use, similar to CVE descriptions.

• The CVE description themselves is often verbatim, but often massaged (either by us or automated scripts).

Indeed, we mostly do relatively minor changes though, like fixing package names, adding affected version numbers, fixing grammar mistakes, forming complete sentences from information presented in a tabular format etc.

• However, we generally do not take the description from MITRE (at least in my experience), but rather from descriptions in oss-security and such. These are usually from the vendor/author themselves. Are those licensed by MITRE too?

For oss-security, my observation is that the disclosures there are often coordinated with MITRE and the descriptions are either published verbatim by MITRE or at least end up being very similar to the "official" description. The same holds true for a couple of other vendors. The reason for using these sources over MITRE is mostly that publishing the official CVE record often takes a little longer than the vendor advisory.

As a special case, there are some vendors that also function as a CNA, like Red Hat. Their advisories are usually guaranteed to end up verbatim in the CVE database because they are the ones responsible for publishing them in the first place.