On April 3rd, we received a Cease and Desist letter from HashiCorp regarding our implementation of the "removed" block in OpenTofu, claiming copyright infringement on the part of one of our core developers. We were also made aware of an article posted that same day with the same accusations. We have investigated these claims and are publishing the C&D letter, our response and the source code origin document resulting from our investigation.

On April 3rd, we received a Cease and Desist letter from HashiCorp regarding our implementation of the “removed” block in OpenTofu, claiming copyright infringement on the part of one of our core developers. We were also made aware of an article posted that same day with the same accusations. We have investigated these claims and are publishing the C&D letter, our response and the source code origin document resulting from our investigation.

The OpenTofu team vehemently disagrees with any suggestion that it misappropriated, mis-sourced, or otherwise misused HashiCorp’s BSL code. All such statements have zero basis in facts.

HashiCorp has made claims of copyright infringement in a cease & desist letter. These claims are completely unsubstantiated.

The code in question can be clearly shown to have been copied from older code under the MPL-2.0 license. HashiCorp seems to have copied the same code itself when they implemented their version of this feature. All of this is easily visible in our detailed SCO analysis, as well as their own comments which indicate this.

Documents

To prevent further harassment of individual people, we have redacted any personal information from these documents.

Conclusion

Despite these events, we have managed to carry out significant development on OpenTofu 1.7, including state encryption, “for_each” implementation for “import” blocks, as well as the all-new provider-defined functions supported by the recently released provider plugin protocol.

On that note, we will be releasing a new pre-release version next week, and we are eager to gather feedback from the community.

— The OpenTofu Team

The image in this blog post contains code licensed under the BUSL-1.1 by HashiCorp. However, for the purposes of this post we are making non-commercial, transformative fair use under 17 U.S. Code § 107. You can read more about fair use on the website of the US Copyright Office.

  • Deebster
    0•7 months ago

    I’m not saying OpenTofu is doing any accusing, but I am. I was thinking an original author had the sole right to relicense code but I guess they found some legally plausible way to get it done. I wonder if the author was an OpenTofu employee.

    • @[email protected]
      0•7 months ago

      See https://en.wikipedia.org/wiki/Contributor_License_Agreement#Relicensing_controversy for a basic overview.

      Lots of projects will have a CLA that basically says “You assign copyright of your work to us” or some sort of unlimited rights grant to the project. So depending on the exact CLA the author may completely transfer ownership of the patch to the project, maintain ownership but grant the project a licence to do basically anything with it (including re-licencing) or for less strong CLAs just confirm that you license the code under the project license.

      • Deebster
        0•7 months ago

        Thanks for the link, I forgot about CLAs. Interesting - this kind of thing seems to be controversial but common.

        • @[email protected]
          0•7 months ago

          They are a powerful tool. They are controversial because they can be used for good and evil. For example even some FSF projects require copyright requirement: https://www.gnu.org/licenses/why-assign.en.html. (It used to be all projects, but many have them have switched to DCO, example glibc)

          But of course it also means that an organization can take code in a GPL project and start disturbing closed-source versions.