Running safety prints a scary warning

[mattip]

In #455 we added linting, among the tools is safety. I have remarked elsewhere that the licensing of that database is unclear. And in the CI run I see

You are using Safety's free vulnerability database. This data is
outdated, limited, and 
  licensed for non-commercial use only.
  All commercial projects must sign up and get an API key at
https://pyup.io/

I think we should remove it.

xref @cclauss as the one who added it in #455

[cclauss]

Please let me know if multibuild is (or aspires to be) a commercial product and I can create a pull request to disable Safety. I know @Jwomers who is the CEO of PyUp.

[mattip]

I think we should disable safety not because this is a commercial project, but because the company is using an outdated version of the database in an open source offering and very clearly promoting their non-free offering. If you know the CEO, please ask them to address pypa/pipenv#5453 to clarify the license and the intent of using this product for open source.

As I commented in PR #498, the linting workflow has not proven very valuable, the only thing so far it has found is a vulnerability in the workflow's dependencies. If it continues to give false alarms I think we should disable it.

[Jwomers]

@mattip we just updated Safety's notice about using the free database. It now reads:

Safety is using PyUp's free open-source vulnerability database. This data is delayed by up to 30 days and is limited. For real-time enhanced vulnerability data, fix recommendations, severity reporting, cybersecurity support, team and project policy management and more; get an API key at https://pyup.io

While we haven't published a blog post about this database, I had hoped that my previous responses on your thread made it clear that the data is licensed under CC-BY-4.0 by pyup.io, as stated in the metadata of the data file itself. Our intent is to distribute our security research findings and comprehensive vulnerability database (beyond just CVEs) to the community for free in this open-source database, which is the default database for safety.

Regarding the workflow linting; I can't comment on the specifics here, we publish both the safety scanner and the open-source database to help protect and secure the Python ecosystem. If you are not finding it valuable we'd love to hear how we could improve this? I am also curious about a vulnerability in the workflow's dependencies, while not the same as a vulnerability in the core project, I would still consider that a valid vulnerability worth knowing about and resolving.

I have no horse in this race as to whether this project should use safety or not, but I hope this information helps!

cc @cclauss

[matthew-brett]

@mattip - sorry - I am not keeping up - but could you say more about your worry here? Are you saying that you think we should not be using a project that is using the open-source version for advertising a commercial product?

Could you say more about what you mean by:

clarify the license and the intent of using this product for open source.

It looks from the other thread, and @Jwomers comment above, that the company has released the free, out-of-date database as CC-BY - but is that not what you meant?

[mattip]

I found the message at the top of the issue scary. I am happy to hear the messaging has changed, thanks @Jwomers for the update. I hope the promised blog post clarifying the licensing will appear soon, since that will provide a single point of truth that can be reference in future updates to the message.

[matthew-brett]

@mattip - I'd be happy for us to pull safety until the blog post comes out. What do you think?

[mattip]

As I commented on #499, I would prefer to leave it in for now, but pull it out next time it causes problems.