fix(instrumentation): remove dependency on the shimmer module

[cjihrig]

Which problem is this PR solving?

This PR vendors the shimmer dependency into the project since the shimmer API is currently part of this project's exposed API.

Fixes #4837

Short description of the changes

This commit removes the dependency on shimmer and @types/shimmer.
Instead, the shimmer code is vendored into the instrumentation
module.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

• Ran the existing test suite.
• Ported tests from dynatrace-oss-contrib@24a951d

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added

[pichlermarc]

@cjihrig thanks for working on this 🙌

Could you rebase the PR? It looks like the PR check updates got lost somewhere on GitHub's infra on the first run, and I can't re run it myself as there's no build linked.

[cjihrig]

It looks like the PR check updates got lost somewhere on GitHub's infra on the first run, and I can't re run it myself as there's no build linked.

I think there were already conflicts as soon as I opened the PR, so the CI probably never ran. Those changelog conflicts come at you quickly 😄

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.03%. Comparing base (4919fd1) to head (9e868d7).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5652   +/-   ##
=======================================
  Coverage   95.03%   95.03%           
=======================================
  Files         310      310           
  Lines        7998     7998           
  Branches     1615     1615           
=======================================
  Hits         7601     7601           
  Misses        397      397           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[legendecas]

this needs a rebase

[cjihrig]

Rebased. PTAL.

[pichlermarc]

Marking as requested for changes to block this PR from getting merged until I've figured out the licensing story.

(there are no actual changes I'm requesting for now - there's just no other way to block PRs on github until some question is resolved. I just need to find out if we might be getting our end-users into legal trouble 😬)

I'm pretty sure we're fulfilling the first clause of BSD-2 clause (the second one one too since we're not redistributing in binary form) so we're in the clear, but it may be difficult to our end-users to follow that license since our package is licensed under Apache 2.0 and they might not be aware of the BSD-2 clause component. 🤔

I'll report back once I know more. I had assumed that this was compatible before, but it seems like the package we already did this with in the past (semver), was using ISC instead of BSD-2 clause which has different requirements. 😕

[trentm]

I believe the PR satisfies https://github.com/open-telemetry/community/blob/main/guides/contributor/processes.md#code-attribution-and-licensing

[pichlermarc]

I believe the PR satisfies https://github.com/open-telemetry/community/blob/main/guides/contributor/processes.md#code-attribution-and-licensing

Hmm, I looked into these guidelines and they unfortunately only allow us to copy unmodified code. 😞
I reached out to our GC liason and opened open-telemetry/community#2774 to seek clarification on this question.

I had previously assumed that BSD-2-clause is compatible and should not cause any more friction than integrating Apache-2.0 code does, but I'd just like to double check this first - sorry for the wait.

[pichlermarc]

Alright, sorry for the delay, everyone.

I just came back from open-telemetry/community#2774 and it looks like since I am not a lawyer I was just confused about some wording. It seems like we're good with the license headers in the file, but according to the guidelines we should also add the original license to a LICENSES/ directory in the package for good measure.

So the way I understand it, we should:

• copy this file to experimental/packages/LICENSES/shimmer/LICENSE
• include the LICENSES directory in the files field of the @opentelemetry/instrumentation package
• in README.md under License we explicitly state where to find the thrid-party licenses
  • Third-party licenses and copyright notices can be found in the [LICENSES directory](./LICENSES).

And then we should be good. 🙂

[cjihrig]

@pichlermarc a couple of questions:

include the LICENSES directory in the files field of the @opentelemetry/instrumentation package

Will that work properly on publish? The LICENSES directory you're proposing will be above the opentelemetry-instrumentation root directory.

in README.md under License we explicitly state where to find the thrid-party licenses

Do you mean the top level README or the one for @opentelemetry/instrumentation? Using ./LICENSES as the link target will not be correct for either one of those.

[pichlermarc]

@pichlermarc a couple of questions:

include the LICENSES directory in the files field of the @opentelemetry/instrumentation package

Will that work properly on publish? The LICENSES directory you're proposing will be above the opentelemetry-instrumentation root directory.

in README.md under License we explicitly state where to find the thrid-party licenses

Do you mean the top level README or the one for @opentelemetry/instrumentation? Using ./LICENSES as the link target will not be correct for either one of those.

Ah, sorry - yes you're right that won't work. I meant to say that we put the LICENSES directory into experimental/packages/opentelemetry-instrumentation/

So the shimmer license text would go into experimental/packages/opentelemetry-instrumentation/LICENSES/shimmer/LICENSE.

And then package's README.md is modified, not the top-level one.

[cjihrig]

That makes more sense, thanks. I've pushed the requested changes.

[pichlermarc]

Looks good, thanks for your patience. :)

[opentelemetrybot]

Thank you for your contribution @cjihrig! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey.