According to this comment: https://github.com/opentofu/opentofu/issues/1469#issuecomment-2040274218
The code has been done in the open by borrowing code from other parts of existing Terraform code, thus explaining the similarities and the license attribution to HashiCorp but under the old one.
For one, it’s Go. A language designed to discourage any creativity in how the code is written.
Secondly, the “style” for writing statements, configs, etc. would have been established before the license change. If you open the containing folders of the suspect files there are clearly established patterns for each construct.
Within the files there are enough differences that given the above, I don’t think this claim has any merit.
It indeed sounds quite a bit like the SCO vs IBM lawsuit and arguing over suspicious similarities of header files and implementations of /bin/true all over again.
For those of us working with automated generation/optimization of programs, the word “creativity” is not about human chauvinism, but about copyrightability. In Google v. Oracle, one of the main insights is that API signatures might not be original or creative enough to qualify for copyright protection, and this should extend from APIs to specifications. For example, it’s probably not the case that a specification of a list-sorting algorithm could ever be copyrighted; there’s not enough creative input in such an endeavor because the output is so highly constrained.
Maybe it matters that they seem to have changed a line here or there.
I have over 15 years of programming experience and a quick skim of the first two code samples tells me that this article is basically fluff. Those code samples are tangibly different to each other in a meaningful way, as much as is humanly possible given that both systems share the same base layer of code, and that humans put in the same context to solve the same problem will often come up with similar looking solutions. The naming of variables (the style of which precedes HashiCorp’s license change, mind you) really does not matter here when both the structure and methodology of the code is clearly different. In addition, it is easy to step through the PR log and view older versions of the originating code, and see that they had a few weeks if not more of discussion over the code that was written, clearly from scratch.
Really all this does is convince me that copyright in relation to software code is a fool’s endeavour, as are software patents, that the industry settling on good code practices has made this orders of magnitudes worse in terms of legal proof (People will tend to pick “the right way to do things” which increases the chances that any two code samples to solve the same problem will look the same, especially in Go which was designed for that property of regular-ness), and that anyone perpetuating such nonsense really cannot be taken as a serious person in any degree.
OpenTofu recognizes that it’s using HashiCorp’s code but pretends the code in question was licensed under the MPL
The format of the licensing in a comment at the top is hardly the smoking gun you think it is. Sure, you can prove it to laymen in a court of law, but any programmer called as an expert witness is going to throw this accusation out with prejudice.
I really can’t see many similarities beyond them being in the same language, and for the same DSL.
I would presume the hashicorp license header at the top is a mistake, intended for the files in the rest of the project which might have remnants of Hashicorp’s MPL code.
This article reads like it’s trying very hard to portray the maintainers as ‘in over their heads’, particularly with the last sentence:
There’s no way that Cloudflare, Oracle, and other responsible companies signed up for that kind of community, but that seems to be what they’re getting.
I really can’t see many similarities beyond them being in the same language, and for the same DSL. I would presume the hashicorp license header at the top is a mistake, intended for the files in the rest of the project which might have remnants of Hashicorp’s MPL code.
The reasoning here is that when you move code around, the file may start carrying the copyright of Hashicorp (the moved portions).
According to this comment: https://github.com/opentofu/opentofu/issues/1469#issuecomment-2040274218 The code has been done in the open by borrowing code from other parts of existing Terraform code, thus explaining the similarities and the license attribution to HashiCorp but under the old one.
Also it should be noted that Matt Asay (the article author) runs developer relations at MongoDB so that he may be a bit biased about proprietary license changes…
[Comment removed by author]
[Comment removed by author]
These claims seem dubious.
For one, it’s Go. A language designed to discourage any creativity in how the code is written.
Secondly, the “style” for writing statements, configs, etc. would have been established before the license change. If you open the containing folders of the suspect files there are clearly established patterns for each construct.
Within the files there are enough differences that given the above, I don’t think this claim has any merit.
It indeed sounds quite a bit like the SCO vs IBM lawsuit and arguing over suspicious similarities of header files and implementations of
/bin/trueall over again.One obvious way to write trivial code is a more positive way to put it. One of my favorite features of Go.
For those of us working with automated generation/optimization of programs, the word “creativity” is not about human chauvinism, but about copyrightability. In Google v. Oracle, one of the main insights is that API signatures might not be original or creative enough to qualify for copyright protection, and this should extend from APIs to specifications. For example, it’s probably not the case that a specification of a list-sorting algorithm could ever be copyrighted; there’s not enough creative input in such an endeavor because the output is so highly constrained.
I have over 15 years of programming experience and a quick skim of the first two code samples tells me that this article is basically fluff. Those code samples are tangibly different to each other in a meaningful way, as much as is humanly possible given that both systems share the same base layer of code, and that humans put in the same context to solve the same problem will often come up with similar looking solutions. The naming of variables (the style of which precedes HashiCorp’s license change, mind you) really does not matter here when both the structure and methodology of the code is clearly different. In addition, it is easy to step through the PR log and view older versions of the originating code, and see that they had a few weeks if not more of discussion over the code that was written, clearly from scratch.
Really all this does is convince me that copyright in relation to software code is a fool’s endeavour, as are software patents, that the industry settling on good code practices has made this orders of magnitudes worse in terms of legal proof (People will tend to pick “the right way to do things” which increases the chances that any two code samples to solve the same problem will look the same, especially in Go which was designed for that property of regular-ness), and that anyone perpetuating such nonsense really cannot be taken as a serious person in any degree.
The format of the licensing in a comment at the top is hardly the smoking gun you think it is. Sure, you can prove it to laymen in a court of law, but any programmer called as an expert witness is going to throw this accusation out with prejudice.
There’s a comment left on the PR that introduced the feature to opentofu:
https://github.com/opentofu/opentofu/pull/1158#issuecomment-2039310652
I really can’t see many similarities beyond them being in the same language, and for the same DSL. I would presume the hashicorp license header at the top is a mistake, intended for the files in the rest of the project which might have remnants of Hashicorp’s MPL code.
This article reads like it’s trying very hard to portray the maintainers as ‘in over their heads’, particularly with the last sentence:
The reasoning here is that when you move code around, the file may start carrying the copyright of Hashicorp (the moved portions).
So it’s better to keep the header consistent.