Update vcr? - Githubissues

The gem "vcr" used to be open source software (OSS), but the latest version is not. We've been using the old OSS version, but that is starting to lead to problems.

The latest version instead uses the Hippocratic License Version Number: 2.1.

I've asked for a legal review to determine if it's safe/legal to use this non-OSS library given this license. I can't share the legal discussion, but I can include the link to show I have asked for such as review: https://legaljira.linuxfoundation.org/servicedesk/customer/portal/1/LR-1472

If they say it's okay, I'll then ask the broader community its thoughts. There's no point in wasting the community's time if it's too dangerous to consider.

The vcr gem is not something that we create or modify, and it is only used during testing - it's never included in released software nor is it included in the production site. Still, it is something we use during testing. This would be an exception to our usual OSS-only policy for anything we depend on during build, test, or deployment.

I've asked legal for review.

In the meantime, what are the alternatives? There are many other gems that do semi-related things, but have other problems. The closest I've found are:

webmock https://github.com/bblimke/webmock - lots of capabilities, but focused on calling functions to return the results, not on storing initial results & then retrieving them later if the stored version exists. I think we could write a little code to shim it, using "Dynamically evaluated raw responses recorded with curl -is" as a starting point.
web_fixtures https://github.com/trydionel/web_fixtures. Limited functionality, no changes since 2010 (presumed unmaintained)
netrecorder https://github.com/chrisyoung/netrecorder - again, no modifications since 2010, probably unmaintained.
puffing billy https://github.com/oesmith/puffing-billy - creates a separate server, which is completely overkill and runs the risk of causing race conditions when running multiple tests (or you have to run a separate server for each test, which is hideous for performance).
ephemeral_response https://github.com/sandro/ephemeral_response - looks great function-wise, but it was archived in 2012 and is unmaintained.
Net::HTTP Spy https://github.com/martinbtt/net-http-spy - shows traces (instead of replaying), early functionality. Not what we want.
REST-assured https://github.com/artemave/REST-assured - fires off a whole new webserver, not what we want (too much overhead)
stale_fish https://github.com/jsmestad/stale_fish - works at a global level, instead of a per-test level. Builds on fakeweb. Sort of, but we need per-test scope not global scope. "Fixtures are updated based on a per-fixture update interval" - maybe we could set the update interval to "never"?
fakeweb https://github.com/chrisk/fakeweb - intercepts calls. It would take extra code to reroute to specific files, I think.

Thoughts?

@david-a-wheeler regarding the list above, webmock we already use and it is integrated with vcr. Fakeweb is an alternative to webmock. I have used puffing_billy and it can do some vcr-like functionality but it's slightly different, I've used it for stubbing/proxying requests in feature tests and the like. The rest I think are generally not maintained well. So I think better than any of all that would be forking the libre version of vcr

@david-a-wheeler to elaborate on this, webmock and vcr work together, they aren't alternatives to each other. Webmock is used to solve the problem of stubbing requests. VCR hooks into webmock to replay the cassettes. Puffing billy has a caching functionality and also supports proxying, which can help when you have requests being made to another backend from the client side. But I think minimally while puffing billy supports caching, it doesn't have the vcr cassette ymls. Stale fish looks more like a replacement for vcr but I think not as well-maintained - pragmatically, if the deprecation warnings from faraday are the only reason, I wouldn't switch on that basis.

Okay. We now need to update our own vcr to something. The easy path is update to current vcr. We need to notify the OpenSSF Best Practices WG & the best practices project via their mailing lists, to see if there are strong objects. Here's a draft message, comments welcome.

All:

The best practices badge project is considering updating the "vcr" library (gem) used by its application code https://github.com/vcr/vcr. This is an external library that is only used during testing; it is never used in production. However, there's a licensing issue with newer versions of vcr. I want to get a sense of how acceptable (or unacceptable) this licensing issue would be to others.

Our current policy is that required reused components MUST be open source software (OSS). However, newer versions of vcr are not OSS. They are instead released under the Hippocratic License Version 2.1. https://github.com/vcr/vcr/blob/master/LICENSE. This license is similar to OSS (it's based on the MIT license), but adds a nonstandard usage requirement named "Compliance with Human Rights Principles and Human Rights Laws" along with arbitration, notification, and indemnification requirements. We've been using older versions of vcr, which are OSS, but changes in other components' interfaces are making it untenable to keep using the older versions. The technically easy thing to do is to allow using this license by vcr as an exception to our usual policy. However, that would be an exception to our policies. Below are details. Comments welcome.

=== Details ===

Our current policy per https://github.com/coreinfrastructure/best-practices-badge/blob/main/CONTRIBUTING.md says:

All required reused components MUST be open source software (OSS). It is not acceptable to insert a dependency that requires proprietary software; making it portable so it can use some proprietary software is gratefully welcome. We also have to combine them legally in the way they are used.

Adding a newer version of vcr would an exception of that policy.

We are currently using an older version of vcr, which is OSS. However, other library interfaces have changed, making staying with this older version untenable. The vcr library is a necessary part of our current testing process. Its purpose is to "record your test suite's HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests." A vast number of our tests use vcr.

Our current thinking is that we should make an exception in this case:

We do not plan on modifying the library, but instead plan to use it as-is.
The component is only used in testing, it's never used or deployed in production.
We plan to comply with human rights anyway (as we understand them).
Useful alternatives aren't really available in this ecosystem. We would end up having to rewrite its code (presumably based on an older version of it), that is, maintaining a fork. A discussion of (non) alternatives is listed at https://github.com/coreinfrastructure/best-practices-badge/issues/1947.
It has a notification requirement, but we believe we can meet that requirement.

There are risks that they might believe something we do (now or in the future) violates the requirements. I find the requirements vague (which concerns me), and its arbitration process could become exhausting. But as best I can see, the risks are small. I don't like making this exception, but for a test-only library that uses an OSS-adjacent license, I think we can live with it.

We already use another non-OSS tool (Brakeman) during our CI/CD process. That's different, however. Brakeman is simply an externally-run tool used to analyze our source code. We can test our software without running Brakeman, and thus using Brakeman doesn't conflict with our policy. It's just an extra source of information. In the case of vcr, we load it into the application during testing and testing won't work without it. That's different. This would therefore be an exception to our policy.

If you intend to create an alternative with its interface under an OSS license, & then maintain it, let me know :-).

I've begun the process to have LF legal look at this, but that review won't matter if we won't make this change.

I'd love to have a better solution. Maybe someone sees an alternative I don't. Or maybe this is no big deal at all.

If we don't do this, the best alternatives I see are either (1) never update a number of components, or (2) create and maintain a fork. Neither seem desirable.

Again, comments welcome.

Sounds good to me

On Tue, May 2, 2023, 2:58 PM David A. Wheeler @.***> wrote:

Okay. We now need to update our own vcr to something. The easy path is update to current vcr. We need to notify the OpenSSF Best Practices WG & the best practices project via their mailing lists, to see if there are strong objects. Here's a draft message, comments welcome.

All:

The best practices badge project is considering updating the "vcr" library (gem) https://github.com/vcr/vcr. This is a library only used during testing, not in production. However, there's a licensing issue; I wanted to hear from others if this would be acceptable.

In short, newer versions of vcr are not open source software. They are instead released under the Hippocratic License Version 2.1. https://github.com/vcr/vcr/blob/master/LICENSE. This license is similar to OSS, but also requires "Compliance with Human Rights Principles and Human Rights Laws."

This would be an exception to our current policy per https://github.com/coreinfrastructure/best-practices-badge/blob/main/CONTRIBUTING.md which says:

All required reused components MUST be open source software (OSS). It is not acceptable to insert a dependency that requires proprietary software; making it portable so it can use some proprietary software is gratefully welcome. We also have to combine them legally in the way they are used.

We are currently using an older version of vcr, which is OSS. However, other library interfaces have changed, making staying with this older version untenable. The vcr library is necessary part of our current testing process. Its purpose is to "record your test suite's HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests." A vast number of our tests use vcr.

Our current thinking is that we should make an exception in this case:

The component is only used in testing, it's never used or deployed in production.

We plan to comply with human rights anyway as we understand them.

Useful alternatives aren't really available in this ecosystem. We would end up having to rewrite its code (presumably based on an older version of it).

It has a notification requirement, but we believe we can meet that requirement.

We do not plan on modifying the library, but instead plan to use it as-is.

There are risks that they might believe some we do (now or in the future) violates the requirements; I find the requirements vague (which concerns me), and its arbitration process could become exhausting. But as best I can see, the risks are small. I don't like making this exception, but for a test-only library that uses an OSS-adjacent license, I think we can live with it.

We already use another non-OSS tool (Brakeman) during our CI/CD process. That's different, however. Brakeman is simply an externally-run tool used to analyze our source code. We can certainly test our software without running Brakeman. In the case of vcr, we load it into the application during testing. That's different, and is already allowed by our current policy. This would be an exception to our policy.

If you intend to create this functionality under an OSS license & maintain it, let me know :-).

Comments welcome.

— Reply to this email directly, view it on GitHub https://github.com/coreinfrastructure/best-practices-badge/issues/1947#issuecomment-1531993236, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEKFJG2LM2O2IOOAME4F4LXEFKO5ANCNFSM6AAAAAAW4AD3NM . You are receiving this because you were mentioned.Message ID: @.*** com>

Ugh. I just noticed that this license ALSO has an “indemnify Licensor” clause. It’s not obvious because it’s hiding under the lengthy human rights statements. I don't know if that kills it. Its text says:

Indemnity. Licensee shall hold harmless and indemnify Licensor (and any other contributor) against all losses, damages, liabilities, deficiencies, claims, actions, judgments, settlements, interest, awards, penalties, fines, costs, or expenses of whatever kind, including Licensor’s reasonable attorneys’ fees, arising out of or relating to Licensee’s use of the Software in violation of Human Rights Laws or Human Rights Principles.

I've notified legal. I am not lawyer, I don't even play one on TV. But I know that such clauses can cause trouble, and therefore that you need to ask lawyer when they show up.

I am also not a lawyer, though I have played one, and a judge, in college mock trial. My read is that we hold the licensor harmless against any losses, etc., only due to any use of the Software in violation of Human Rights Laws or Human Rights Principles, which we don't plan to reasonably ever do, so it shouldn't ever apply to us. However, I can see that a legal department might not want the potential exposure of being sued for human rights violations. Still, the chance of that happening seems quite slim. Let's see what they say I guess.

On Tue, May 2, 2023 at 6:20 PM David A. Wheeler @.***> wrote:

Ugh. I just noticed that this license ALSO has an “indemnify Licensor” clause. It’s not obvious because it’s hiding under the lengthy human rights statements. I don't know if that kills it. Its text says:

Indemnity. Licensee shall hold harmless and indemnify Licensor (and any other contributor) against all losses, damages, liabilities, deficiencies, claims, actions, judgments, settlements, interest, awards, penalties, fines, costs, or expenses of whatever kind, including Licensor’s reasonable attorneys’ fees, arising out of or relating to Licensee’s use of the Software in violation of Human Rights Laws or Human Rights Principles.

I've notified legal. I am not lawyer, I don't even play one on TV. But I know that such clauses can cause trouble, and therefore that you need to ask lawyer when they show up.

— Reply to this email directly, view it on GitHub https://github.com/coreinfrastructure/best-practices-badge/issues/1947#issuecomment-1532230046, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEKFJFGPMO6TX6M2VQ37L3XEGCDJANCNFSM6AAAAAAW4AD3NM . You are receiving this because you were mentioned.Message ID: @.*** com>

coreinfrastructure / best-practices-badge

Update vcr? #1947

Okay. We now need to update our own vcr to something. The easy path is update to current vcr. We need to notify the OpenSSF Best Practices WG & the best practices project via their mailing lists, to see if there are strong objects. Here's a draft message, comments welcome.