3 ms·

Also an achievable goal is reimplementing the new feature without relying on code which HashiCorp only released under the BUSL. It’s a shame they didn’t do that

Also an achievable goal is reimplementing the new feature without relying on code which HashiCorp only released under the BUSL. It’s a shame they didn’t do that in this case.

tsimionescu 3y ago
It's not at all clear that they didn't. This article seems biased and misleading.
- jkaplowitz 3y ago
  The article shows a HashiCorp copyright notice coupled with an MPL license header for a file that was never released by HashiCorp under the MPL. How is that biased and misleading?
  - tsimionescu 3y ago
    If you look at the commit history, the reviewers actually asked why the files have the HashiCorp copyright, and it seems that the developers were not sure what is the final copyright notice for new code. The one they settled on recognizes copyright both from HashiCorp and the OpenTofu foundation, as even the new files are probably deemed to be derived works of HashiCorp. Here is the comment I'm mentioning: https://github.com/opentofu/opentofu/pull/1158/commits/35d1ae31b46a63f14ab0b967c14d236f690185d9#r1465188714 https://github.com/opentofu/opentofu/pull/1158/commits/35d1a...
    - jkaplowitz 3y ago
      Thanks for that additional context. Still, there are enough other parallels with BUSL-only Hashicorp code, including several identical new filenames, that the questions raised by the article seem fair as questions to me. I don’t think the article claims to answer them more definitively than initial speculation. (That is, the article is noting a bunch of observations and saying what it looks like to the author, explicitly without firmly asserting any underlying truth.) At the very least, a court would probably send an infringement lawsuit on this basis to trial, surviving an initial motion to dismiss, regardless of what the eventual verdict might be after full fact-finding.

3 ms·

Also an achievable goal is reimplementing the new feature without relying on code which HashiCorp only released under the BUSL. It’s a shame they didn’t do that

by jkaplowitz 3y ago

Also an achievable goal is reimplementing the new feature without relying on code which HashiCorp only released under the BUSL. It’s a shame they didn’t do that in this case.

tsimionescu 3y ago
It's not at all clear that they didn't. This article seems biased and misleading.
- jkaplowitz 3y ago
  The article shows a HashiCorp copyright notice coupled with an MPL license header for a file that was never released by HashiCorp under the MPL. How is that biased and misleading?
  - tsimionescu 3y ago
    If you look at the commit history, the reviewers actually asked why the files have the HashiCorp copyright, and it seems that the developers were not sure what is the final copyright notice for new code. The one they settled on recognizes copyright both from HashiCorp and the OpenTofu foundation, as even the new files are probably deemed to be derived works of HashiCorp. Here is the comment I'm mentioning: https://github.com/opentofu/opentofu/pull/1158/commits/35d1ae31b46a63f14ab0b967c14d236f690185d9#r1465188714 https://github.com/opentofu/opentofu/pull/1158/commits/35d1a...
    - jkaplowitz 3y ago
      Thanks for that additional context. Still, there are enough other parallels with BUSL-only Hashicorp code, including several identical new filenames, that the questions raised by the article seem fair as questions to me. I don’t think the article claims to answer them more definitively than initial speculation. (That is, the article is noting a bunch of observations and saying what it looks like to the author, explicitly without firmly asserting any underlying truth.) At the very least, a court would probably send an infringement lawsuit on this basis to trial, surviving an initial motion to dismiss, regardless of what the eventual verdict might be after full fact-finding.