Data license?

[pombredanne]

I was wondering what is the license of the data you provide?
I could not find something explicit.
This is to possibly import these in nexB/vulnerablecode#341 as we were alredy planning to import oss-fuzz data otherwise.
Thanks

[oliverchang]

As part of #44 the source of truth for our data will live in various repos.

If that repo happens to be part of OSV / OSS-Fuzz / Something else controlled by us, it'll be whatever license that repo is licensed under, which is most likely Apache 2.0.

Would that work for you?

[pombredanne]

As part of #44 the source of truth for our data will live in various repos.

If that repo happens to be part of OSV / OSS-Fuzz / Something else controlled by us, it'll be whatever license that repo is licensed under, which is most likely Apache 2.0.

Would that work for you?

Thanks. Any license is better than no license, Apache is fine, although not a license designed for data and therefore likely not the best pick. As for the API-accessible data today, what would the license be?

BTW, your API requires an API key but your web site does not. So why an extra layer of auth? Implicitly you are encouraging users (me) to build a web scraper rather than to use your API to avoid the hassle of API key management.

[oliverchang]

Thanks. Any license is better than no license, Apache is fine, although not a license designed for data and therefore likely not the best pick. As for the API-accessible data today, what would the license be?

I don't know the answer for the API-accessible data. I can find out and get back to you. I don't expect this to be an issue.

BTW, your API requires an API key but your web site does not. So why an extra layer of auth? Implicitly you are encouraging users (me) to build a web scraper rather than to use your API to avoid the hassle of API key management.

Thanks for the feedback.

The API key requirement is an unfortunate requirement but it's necessary for the higher QPS allowed by the API and to prevent abuse. The web UI has a lower QPS and serves a different purpose. The web UI primary serves the pagination/search and viewing individual Vulnerability data by a human while the API is mostly for querying by commit or version for automation.

[oliverchang]

Thanks. Any license is better than no license, Apache is fine, although not a license designed for data and therefore likely not the best pick. As for the API-accessible data today, what would the license be?

I don't know the answer for the API-accessible data. I can find out and get back to you. I don't expect this to be an issue.

Following up on this, may I recommend just waiting for our officially supported data dump (#44) to starting dumping OSS-Fuzz vulnerabilities? The license will also likely be something that's friendly for datasets. This will be available very soon.

[pombredanne]

Following up on this, may I recommend just waiting for our officially supported data dump (#44) to starting dumping OSS-Fuzz vulnerabilities? The license will also likely be something that's friendly for datasets. This will be available very soon.

@oliverchang sure thing and thank you for the reply. We have had a pending ticket to include and scrape OSS-Fuzz data for about 1.5 years at nexB/vulnerablecode#117 so we can wait alright and there is no rush!
We will not write a scraper for now.

[oliverchang]

Hi @pombredanne , just following up on this issue.

Our data is now available at https://github.com/google/oss-fuzz-vulns under the CC-BY-4.0 License.

Users can also submit changes to these files and have them reflect in OSV (i.e. they are the source of truth).

[pombredanne]

@oliverchang Thank you ++ for following through! I am closing this then. We will report any issues we face and find.