Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenTofu may be showing us the wrong way to fork

infoworld.com

Post reply on HN
Print view View original

11–20 of 37 posts

Re: OpenTofu may be showing us the wrong way to fork

#11

Post by cassianoleal »

spooneybarger wrote: post #7

I diffed one of the example files. I don't see clear copying. It looked at a moderate glance to be a different implementation of similar functionality. I didn't spend time looking at the others as I felt the argument as put forth was already weak. I'd suggest comparing yourself and not assuming that the author's points are all valid.

I had a skim as well, and they're substantially different. Sure there will be some similarities since they're trying to achieve the exact same results given equal inputs but I don't know how you could qualify OpenTofu's code as "copy-paste and change the license".

Re: OpenTofu may be showing us the wrong way to fork

#12

Post by mirekrusin »

spooneybarger wrote: post #7

I diffed one of the example files. I don't see clear copying. It looked at a moderate glance to be a different implementation of similar functionality. I didn't spend time looking at the others as I felt the argument as put forth was already weak. I'd suggest comparing yourself and not assuming that the author's points are all valid.

Did the same with the same conclusion.

Re: OpenTofu may be showing us the wrong way to fork

#13

Post by tsimionescu »

dartos wrote: post #5
dlahoda wrote: post #4

no diff referenced, incompetency or pr campaing from hc

There are links to 3 files in both opentofu and hashicorp. You could get the diff yourself from that. The point about the header comments is pretty damming. It’s probably just laziness / not knowing how to make diffs from 2 different repos.

I looked at the pull request that added this new feature and it didn't seem to touch the headers at all. My guess is that the headers are left over from before the fork, and anyway they are true, HashiCorp still holds the copyright to the majority of that code.

Later edit: for new files, it seems that the old copyright notice was kept until a new copyright notice was settled on [0], and anyway even the new copyright notice references HashiCorp as well [1] (I don't know the history, but possibly because they could be considered derived works?).

[0] https://github.com/opentofu/opentofu/pull/1158/commits/35d1a...

[1] https://github.com/opentofu/opentofu/issues/454#issuecomment...

Re: OpenTofu may be showing us the wrong way to fork

#14

Post by tsimionescu »

jkaplowitz wrote: post #10
xbar wrote: post #6

If true, it's impressively foolish. Still, pre-BUSL Terraform is an achievable goal.

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.

It's not at all clear that they didn't. This article seems biased and misleading.

Re: OpenTofu may be showing us the wrong way to fork

#16

Post by jkaplowitz »

tsimionescu wrote: post #14
jkaplowitz wrote: post #10

Earlier quoted context omitted.

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.

It's not at all clear that they didn't. This article seems biased and misleading.

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?

Re: OpenTofu may be showing us the wrong way to fork

#17

Post by mirekrusin »

dartos wrote: post #5
dlahoda wrote: post #4

no diff referenced, incompetency or pr campaing from hc

There are links to 3 files in both opentofu and hashicorp. You could get the diff yourself from that. The point about the header comments is pretty damming. It’s probably just laziness / not knowing how to make diffs from 2 different repos.

He's got a point because if you look at first example (didn't bother to look at others) the diff is substantial and invalidates argument made in the article. Embedding diff in website is super easy novadays and whole article talks about just that.

Re: OpenTofu may be showing us the wrong way to fork

#18

Post by mrd3v0 »

spooneybarger wrote: post #7

I diffed one of the example files. I don't see clear copying. It looked at a moderate glance to be a different implementation of similar functionality. I didn't spend time looking at the others as I felt the argument as put forth was already weak. I'd suggest comparing yourself and not assuming that the author's points are all valid.

The author is paid to make these articles, it is his job to make these points, valid or not. "Infoworld" is putting itself as an outlet for corporate propaganda providing a sneaky disclaimer at the bottom.

Re: OpenTofu may be showing us the wrong way to fork

#19

Post by sethops1 »

spooneybarger wrote: post #7

I diffed one of the example files. I don't see clear copying. It looked at a moderate glance to be a different implementation of similar functionality. I didn't spend time looking at the others as I felt the argument as put forth was already weak. I'd suggest comparing yourself and not assuming that the author's points are all valid.

Take a look at the actual commit history. It's clear copying the BUSL files and then changing things.

https://github.com/opentofu/opentofu/pull/1158/commits

Re: OpenTofu may be showing us the wrong way to fork

#20

Post by apitman »

nullindividual wrote: post #2

Beyond the license issue, the promised features vs. difficulty of implementing them is a knife in the 'if you don't like it, it's open source -- you can do anything you want'. It's a technically correct statement. But that is all it is.

To get the full benefit of OSS, it's not enough to make open source software. You have to make forkable software. Sure, projects such as Chromium and Keycloak are technically OSS, but they're so massive and complicated that very few have the resources to fork them. It's not as bad as proprietary software, but it has some of the same drawbacks.
Post reply on HN