Make a licensing note somewhere about pipenv check

[ncoghlan]

While writing pyupio/safety-db#2261, I realised that commercial redistributors of pipenv should take close note of the fact that pipenv check relies on a CC-BY-NC-SA CVE database maintained by pyup.io: https://github.com/pyupio/safety-db

This means that commercial redistributors of pipenv need to choose between:

• disabling pipenv check;
• patching pipenv to use a different vulnerability database (e.g. one they maintain themselves); or
• paying pyup.io for a commercial usage license

[kennethreitz]

We actually embed a commercial license within the project, to ensure users get up-to-date security notifications.

Likely against TOS, but I’m one to ask forgiveness before permission. I know they’re Pipenv fans, so I’m sure they wouldn’t mind.

[kennethreitz]

Er, not a license, an API key.

[kennethreitz]

@pyupio any concern here? Happy to make immediate changes if so. :)

[ncoghlan]

#1652 added a Sphinx note to https://pipenv.readthedocs.io/en/latest/advanced/#detection-of-security-vulnerabilities pointing out that while we're confident the "I'm a non-commercial user" case and the "We have our own pyup.io license" case are both fine, there are otherwise quite a few legal grey areas here, so commercial redistributors and end users will need to make their own assessment of the legal risks.

[kennethreitz]

👍

[jayfk]

@pyupio any concern here? Happy to make immediate changes if so. :)

No, the use case perfectly fine! The reason the database is CC-BY-NC-SA is to get funding off of corporations who want to include it in their (closed) security products.

Having a little info text when running pipenv check should also wipe out all concerns about attribution. Something like using Safety DB from YY-MM-DD should work. This is, however, not a requirement.

If a licensing expert thinks that both licenses are incompatible, I'd be happy to relicense it for pipenv or work on another solution.

[ncoghlan]

@jayfk Thanks for the clarification!

The murkiness I was worried about was that while pipenv itself is non-commercial, it definitely has commercial users, and potentially commercial redistributors as well (although I'm not personally aware of any of the latter yet - I just expect it may happen at some point in the future).

I think between your comment above, and the note in the docs pointing out that commercial users and redistributors may want to follow up with pyup.io themselves, it's all good for now :)

[jayfk]

Yes, indeed.

Just to make it perfectly clear if someone stumbles upon this issue: Commercial pipenv users should be perfectly fine.

If someone wants to package and redistribute pipenv (with Safety DB) for commercial purposes, we might need to talk about that.

[tristanz]

Is there a simple way to prevent SafetyDB from being installed? We (Cloudera) ship a Docker container for our data science product that has Python and pip installed. We'd like to include pipenv inside a Docker container and recommend it as the preferred Python packaging tool, but this license will cause legal review problems.

I think the three acceptable options are:

1. Make it an optional dependency
2. Remove it
3. Relicense it

[kennethreitz]

It's part of Pipenv.

Your best option is to rm -fr it (safety.zip).

[kennethreitz]

You'll have to patch check to be compatible with that removal of course.

[tristanz]

Thanks. Any chance @jayfk is willing to relicense?

I completely understand motivation to encourage contributions, but I don't think the "officially recommended" python packaging tool should be incompatible with commercial distros like RHEL shipping it. CC-NC is explicitly banned by legal in most corporations, so it's a heavy lift. Patching is an option, but that doesn't feel like the right solution here.

[jayfk]

I completely understand motivation to encourage contributions

The problem is you can‘t keep a project like that alive with contributions alone. They won‘t pay the bills for the people reviewing changelogs and thus keeping the DB up-to-date.

Relicensing the project is a risky gamble in so far as it directly impacts funding available for it. An MIT licensed database won‘t help if it is no longer updated because the people working on it had to move on.

In an ideal world, corporations that directly benefit from efforts like this would pay regardless of the licensing situation. But time and time again, we‘ve seen that this isnt the case.

[jayfk]

From my POV, the only tricky part here is the one about redistribution. Instead of bundling the zip, pipenv check could simply call https://raw.githubusercontent.com/pyupio/safety-db/master/data/insecure.json and use the data from there.

That wouldn't require the DB to be re-licensed and wouldn't impact the redistribution in any way.

[kennethreitz]

We're not even using the database, we're hitting the API.

We can remove the database.

[jayfk]

We can remove the database.

If that's the case, simply remove it and everything is fine :)

[kennethreitz]

I'll work on it. Unless you want to do it :)

[kennethreitz]

:rimshot:

[jayfk]

Getting late here, I'll check it out tomorrow! :D

[kennethreitz]

Removed.

[ncoghlan]

@jayfk Given that the copy of the DB is gone and pipenv check is only hitting the API now, perhaps we should remove the legal caveat again?

If the traffic starts getting to be too much on the pyup.io side, you should be able to throttle the default embedded key, and we can look at offering a way for folks to provide their own checking key on the pipenv side

[jayfk]

Yep! For the time being, It's fine. Once it gets too much, I'm optimistic that we'll be able to figure something out :)

Instead of removing it completely, rewording is maybe the better option. The DB itself is still under a different license than pipenv itself. As we already figured out, that's perfectly fine for pipenvs usecase. If someone copies the API key from pipenv's code on the other hand and starts hitting the API, that's a different kind of thing.

[kennethreitz]

We can obfuscate it, if needed.

We've found that literally almost no one "looks at the code" though, so I don't think someone will do that, especially to save $15.

[kennethreitz]

We could add a special license to the API key included, actually.

[kennethreitz]

"this string is CC-NC-AR" :P

[jayfk]

Lets focus on that once there are any problems :D. We're good!

[kennethreitz]

i agree — doing that would do nothing but highlight its presence.

[kennethreitz]

Thanks for the openness @jayfk!

[jayfk]

Well, thanks for pipenv @kennethreitz!

[ncoghlan]

https://github.com/pypa/pipenv/pull/1749/files rewords the note in the docs, but I don't really see a way to word it usefully that doesn't also draw attention to the presence of the API key :)

[uranusjr]

Is this issue still relevant after #1749 is merged? Reading the above it seems that decision was to not do too much until something goes wrong.

[ncoghlan]

Belatedly closing this as resolved :)