[IND-4226] [COMPLIANCE] Update Copyright Headers

[oss-core-libraries-dashboard]

Hi there 👋

This PR was auto-generated as part of an internal review of repositories that are not in compliance with IBM's licensing standards.

Repository Information

• Repository: terraform
• Repository Type: product
• First commit year: 2014
• Latest commit year: 2025
• JIRA Ticket: IND-4226

Frequently Asked Questions

Why am I getting this PR?

This pull request was created because one or more source code files were found incorrect copyright and/or license headers.

More info is available in these documents - MEMO.

Old Hashicorp Copyright details can be viewed here - RFC.

How do you determine which files should get copyright headers?

Attempts are made to skip scanning autogenerated files (e.g., `go.mod`) and prose. If you find file types you feel should be excluded from future scans, please reach out to:

#proj-software-copyright

I have a file or folder which should be exempted, how do I do that?

You may exempt certain files or folders from being scanned by adding a `.copywrite.hcl` config in the root of your repo. You can use the [`copywrite init`](https://go.hashi.co/copywrite) command to interactively create a config for this project.

An example schema can be found below. Add a doublestar**-capable pattern to the header_ignore list to skip it in future scans.

# (OPTIONAL) Overrides the copywrite config schema version
# Default: 1
schema_version = 1

project {
  # (OPTIONAL) SPDX-compatible license identifier
  # Leave blank if you don't wish to license the project
  # Default: "MPL-2.0"
  # license = ""

  # (OPTIONAL) Represents the year that the project initially began
  # Default: <the year the repo was first created>
  # copyright_year = 0

  # (OPTIONAL) A list of globs that should not have copyright or license headers .
  # Supports doublestar glob patterns for more flexibility in defining which
  # files or folders should be ignored
  # Default: []
  header_ignore = [
    # "vendor/**",
    # "**autogen**",
  ]
}

More information about configuration options is available in [the documentation](https://github.com/hashicorp/copywrite#config-structure).

Additional FAQs are available at https://go.hashi.co/header-faq

Please approve and merge this PR in a timely manner to keep this source code compliant with our OSS license agreement. If you have any questions or feedback, reach out to #proj-software-copyright.

Thank you!

---

Powered by copywrite, made with ❤️ by @hashicorp

[github-actions]

Changelog Warning

Currently this PR would target a v1.15 release. Please add a changelog entry for in the .changes/v1.15 folder, or discuss which release you'd like to target with your reviewer. If you believe this change does not need a changelog entry, please add the 'no-changelog-needed' label.

[SarahFrench]

I've scrolled through the diffs and there aren't any files where the diff extends beyond the copyright header for that file (e.g. if a file is used to generate files and contains the header in a string lower down, this PR hasn't impacted it).

I think this PR is ok to merge but I also think the team needs to briefly discuss how we handle copyright headers in automation:

• This PR's tool replaces the use of https://github.com/hashicorp/copywrite.
• We currently use that tool in automation that asserts any new files added by a PR should include a header.
• The new tool isn't accessible for use in public repos, so we cannot amend our automation to use the new tool.
• The currently provided method for teams to interact with the new tool are either to download it and manually prepare a PR like this one, or to manually trigger a GitHub actions workflow in the tool's repo to prepare a PR like this one.

I think we could keep the old copyright tool in our GHA workflows as that'll flag when a new file doesn't have a header, but then we need to copy the new header from another file instead of using the header suggested from the old tool. Maybe in future we could explore use of git hooks (as we can access the new tool locally) but ideally there would be an org-wide ability to use the new tool in automation.

EDIT: It looks like our current automation will need some changes to suppress diffs:

[SarahFrench]

Removing my acceptance while we have discussions about the above.