hckrnws

It's great to see more companies adopting OpenTofu, and especially larger ones!

As a side note, we've recently released OpenTofu 1.7 with end-to-end state encryption, enhanced provider-defined functions, and a bunch more[0].

If you've been holding out with the migration, now is the perfect moment to take another look, and join the many companies that have already migrated!

[0]: https://github.com/opentofu/opentofu/releases/tag/v1.7.0

Note: Tech Lead of the OpenTofu project, always happy to answer any questions

Are there any plans for a conditional way to enable/disable modules that doesn't use "count"?

For example:

  # current method
  module "foo" {
    count = var.enable_foo ? 1 : 0
  }

  # better?
  module "bar" {
    enabled = var.enable_bar
  }

I'd also really like to be able to say in an output block, "this value doesn't have to exist, only display it if its parent module is enabled", again without the "count" attribute.

The relevant issue[0] is currently the 7th top-voted[1] feature request, so it's definitely high on our radar. Please upvote it as well, if it's important to you!

There's a bunch of nontrivial technical complexity though, because of how OpenTofu currently works.

[0]: https://github.com/opentofu/opentofu/issues/1306

[1]: https://github.com/opentofu/opentofu/issues/1496

Use CDKTF.

All of these "how can I do X in HCL" just go away.

I do agree CDKTF is an improvement over HCL, but aren't you bothered by being blocked by terraform itself? You have to resort to intrinsics [1].

This is why I dropped CDK for TF in favor of Pulumi, although I do feel Terraform has more maturity and polish but not enough to warrant its limitations.

[1]: https://developer.hashicorp.com/terraform/cdktf/concepts/fun...

Once in a while, I forget to use Fn when I should.

But I'll take that annoyance anyday over the absolute pain of HCL.

I haven't tried Pulumi, I will eventually. (Cloud services have TF providers more often than Pulumi ones. But if Pulumi is easy to extend, maybe doesn't matter.)

I suspect Pulumi is easy to extend because most of the API is basically a state-preserving, idempotent wrapper around existing APIs. When I was messing with it on GCP, their API almost always used the exact same objects the GCP API accepted. I could actually use the GCP docs to create the objects (there are big upsides and downsides to this).

Are there any incompatibilities cropping up between terraform and opentofu? I believe we're on terraform 1.7.5, I'm not sold on migrating yet but would like to keep the option open, especially if something like delaying an upgrade would help not have future backwards incompatible things to fix.

I understand why people were upset about licensing changes but I was not one of them who were particularly bothered. Why should I switch?

> Are there any incompatibilities cropping up between terraform and opentofu?

OpenTofu is indeed a hard fork. When doing similar features (like provider-defined functions) we try to stay compatible where it makes sense, but there's often some differences (like our more extended capabilities of provider-defined functions[0]) and also new features in Terraform that we're not introducing - and vice versa.

You can check for known incompatibilities in our migration guides[1], based on your Terraform version. In practice, the longer you wait, the more the projects will diverge, so if you still want to "wait and see" I would suggest settling on your current Terraform version for now - otherwise, the migration will just be more work for you later.

Regarding the reasons for switching, I'd say features and community-first process. We're striving to be very community driven in what work we're prioritizing[2] and have received a lot of positive feedback over that from our users.

Some companies we've spoken to see adopting the open-source community-driven project as a way to reduce risk long-term. It's also a way to keep your options open if you're in the market for commercial Terraform/OpenTofu management systems.

[0]: https://github.com/opentofu/terraform-provider-go

[1]: https://opentofu.org/docs/intro/migration/

[2]: https://github.com/opentofu/opentofu/issues/1496

I'm really excited to see the end-to-end state encryption. I've always thought it was bizarre that Hashicorp didn't prioritize this.

Could it be because it weakens the business case for using their SAAS?

Possibly, but we are paying enterprise customers (but not using HCP) and this still isn't possible. Seems like an obvious thing they could have at least offered to vault enterprise or TF enterprise customers years ago.

My guess is internal politics in the development team(s) rather than commercial reasons.

The trend will continue. A company will be crazy to trust that IBM would give them fair-priced high quality support.

Do you appreciate the irony of that comment on a post about Oracle adopting OpenTofu?

I'm sure Oracle doesn't want to be gouged by their vendors any more than the rest of us do. They probably don't buy Oracle either.

Yep. Funny.

In this case Oracle is the user, not the vendor.

"Oracle’s move seems like a straightforward decision to ensure it is using the most permissive underlying IaC tool without having to worry about downstream license complications, no more and no less."

Hm, with that logic they could dump MySQL in favor of MariaDB as well

Especially ironic, given that Oracle is one of the nastiest and most aggressive companies at enforcing license terms.

Thats the way world works. Here in this forum so many software people asking for best possible salaries and perks, and when it comes paying a bit to good productivity software same developers are always full of excuses like.

1) Oh, I prefer open source alternative for ideological reason.

2) This software is not really worth that much.

3) Hectoring developers every single time in providing why their software should be preferred over unpaid alternatives.

4) Blaming companies that they are bigger users so they should pay not me.

If these entitled developers who deserve all the money but no one deserve their money just shut the fuck up every once in a while it will be a good thing.

It's important to remember that a community is not a single minded entity. It's members can hold many contradicting beliefs, while each individual is ideologically consistent.

This shouldn't be unexpected and it's not an excuse to be dismissive to an imagined hypocrite. Not saying there aren't hypocrites in this world, just that we shouldn't treat members of a community as some kind of superset of everything in that community.

It's the upvote where that opinion falls short. Sure, it may just be one hypocrite, but it sure is funny when a community raises scarcely concealed hypocrisy to the top comments or sub-comments. And then forgets about it 2 weeks later.

Its not unexpected and neither is Oracle's approach unexpected still its worth talking about.

Besides I made observation about people in community and not community itself as I did not say HN thinks software should not be paid for.

> Besides I made observation about people in community[...]

Can you link any specific HN user who holds any 3 of those specific beliefs, or was this hypocritical strawman purpose-built to bolster your argument?

It's important to remember that a company is not a single minded entity. It's members can hold many contradicting beliefs, while each individual is ideologically consistent.

They often do have a hierarchical command structure and that should entail some top down consistency and some accountability rolling upwards but you're not wrong.

Believing every employee at Walmart thinks the same is silly and while someone is to blame for policy its important to not blame retail clerks for store policy, for example.

I mean, sometimes the entitled developers are right and predict that the monetization of a software product will lead to it's inevitable demise. More often than not that's how these sorts of projects end up.

Linux as a whole exists because developers said "fuck AT&T, we're taking this train off the rails" and nobody ever looked back since.

And the majority of code in Linux is created by corporate employees getting paid to make changes. Those companies are merely helping to “commoditize their complements”

That's not really a problem as long as the source license stays the same. If Amazon or Microsoft need a feature in the kernel, nobody tends to care as long as it's GPL.

> Those companies are merely helping to “commoditize their complements”

That's how they justify it internally, yeah. From an administrative standpoint it's pretty obvious that they all choose Linux because it's easier than retrofitting proprietary UNIX for modern software. But indeed, they market it as goodwill and complimentary development.

I think you may have misinterpreted the parent comment. "Complement" as in a complementary good in economics terms. Not "complimentary", as in free. There's a good article on this by Joel Spolsky

https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

In a way they know the worst that can happen :D

Yeah this is absolutely projection on Oracle's part

There is no contradiction here. It's exceedingly simple: companies will take as much as they can and give as little as they can. That's why it's important to raise the bar on what they have to give and reject all permissive (non-copyleft) free software licences.

Copyleft is not required, free software is a gift freely given. Even public domain is ok (weird places like Germany that don’t have public domain notwithstanding).

What must be rejected is nonfree licenses like the BSL.

BSL is preferrable to completely closed because at least researchers can look at it now and it will eventually transition to open source. If Windows XP was BSL licensed then Wine would have a lot less trouble now.

Citation is sorely needed for both "transition" and "BSL XP be good for wine" claims above.

Specifically, supposed inevitability of BSL->OSI transition is dubious. If anything, there are examples of the opposite - terraform itself being prime one.

> Citation is sorely needed for both "transition"

Sure! [1]

> The Business Source License requires the work to be relicensed to a "Change License" at the "Change Date". The "Change License" must be a "license which is compatible with GPL version 2.0 or later". The Change Date must be four years or sooner from the publication date of the work being licensed

So the business source license is less "non-OSI" and more "not currently non-OSI, but eventually and irrevocable at future date".

In the case of Terraform it says [2]:

>Change Date: Four years from the date the Licensed Work is published.

>Change License: MPL 2.0

So is this ideal? No. But it's better than OpenVMS screwing over historians and hobbyists [3] decades after it's relevancy has expired.[6]

It's also better than SSPL [4] which has no such transition and stays permanently non-OSI [5].

> "BSL XP be good for wine" claims above.

Well Wine uses the LGPL, and Windows XP was released in 2001 so even if they set the expiry 20 years after release, it'd be GPL'd by now.

---

[1] https://en.wikipedia.org/wiki/Business_Source_License#Terms

[2] https://github.com/hashicorp/terraform/blob/main/LICENSE

[3] https://www.theregister.com/2024/04/09/vsi_prunes_hobbyist_p...

[4] https://en.wikipedia.org/wiki/Server_Side_Public_License

[5] https://web.archive.org/web/20230411163802/https://lists.ope...

[6] https://www.theregister.com/2013/06/10/openvms_death_notice/

I disagree. I don’t face any copyright issues from writing code that resembles something in Windows. I never had access to its source code, so any similarities have to be purely coincidental.

A BSL project could say, hey, look at this guy stealing our code!, even if I’ve never seen it. I could have, and that opens a plausible risk I wish I didn’t have.

> I don’t face any copyright issues from writing code that resembles something in Windows. I never had access to its source code, so any similarities have to be purely coincidental.

> A BSL project could say, hey, look at this guy stealing our code!, even if I’ve never seen it. I could have, and that opens a plausible risk I wish I didn’t have.

By that argument, you could have looked at Windows code too, since Windows source code has leaked multiple times, and 5 minutes of searching will find it.

> Copyleft is not required

Yes it is. Because companies (like Oracle) will take as much as they can and give as little as they can.

> free software is a gift freely given

It's a gift to the public, not to individuals and companies (like Oracle).

> Even public domain is ok

Even worse because that expressly allows companies (like Oracle) to take everything and give nothing.

All of which is well understood by anyone who release permissively licensed software?

If they didn’t accept that, they could have used a non-commercial license. If they expected contributions they could have sold a paid product.

I’d suggest not using others hard work as the basis for your argument. If it was your work and you regret it, say that. If you don’t like oracle, say that. Otherwise, people who contribute to FOSS software do so knowingly, yet you are trying to inject your own opinions of “public” vs whomever, as though you know better than those contributors own feelings and intentions.

> Because companies (like Oracle) will take as much as they can and give as little as they can.

Which in the case of free software is a completely neutral fact that causes exactly zero negative impact to the project. You're trying to apply principles of scarcity to a product category that has no scarcity—replicating the bits to serve Oracle doesn't cost a maintainer anything at all.

They can prefer not to let Oracle use their otherwise-freely-provided software, but that's not a position that's as easy to get sympathy for as pretending there's harm done.

> Yes it is. Because companies (like Oracle) will take as much as they can and give as little as they can.

Yes, they will. So? Nobody is actually harmed by this. The software is still perfectly available for the public to make use of.

> It's a gift to the public, not to individuals and companies (like Oracle).

The public is not some separate entity from individuals or companies. It's simply the collective of all individuals and companies. So yes, when you gift something to the public it's a gift to Oracle as well. It's not exclusively to them, but they are a part.

[dead]

At oracle-

Hey, what if they do - what we do to other companies ... to us ...

presses a red button

Funny that you mention MariaDB.

Oracle bought MySQL which was forked into MariaDB. MariaDB created the Business Source License (BSL). Hashicorp switches Terraform to BSL which then leads to Terraform being forked into OpenTofu. OpenTofu seems to be getting adopted by Oracle.

Full circle of corporate facepalm

[dead]

Oracle owns the most permissive possible license to MySQL.

Ah, that flexible "COST license" - "contact our sales team" license

Oracle owns MySQL but not Terraform

Ah, so they meant avoiding 'downstream license complications' they don't cause.

I wouldn't expect Oracle to have a license complication with itself...

it's mostly just hypocritical.

If everyone acted like Oracle; there would be no mysql users. Which is the point being made.

I don't understand your comment. Oracle is hypocritical because like every company they take everything they can and give the minimum they have to? which part is hypocritical?

I'm incredulous that you don't understand, but I'll humour you.

Let's see;

If I giving away a product because I think it's for the betterment of mankind, and definitely not an attempt to rug-pull or anything like that: no, just for developer good will.

Then I am offered a free service, and I do not use it for fear that there could potentially be some rugpulling, despite having a reputation for that myself: and the project I'm considering having no reputation for that.

Then the pretense in which I "give away" my software, is morally dubious. I would never permit myself to be in the same situation as I need others to be in order for my product to be successful.

MySQL/Virtualbox/Java etc;

This still doesn't make any sense to me. In order to use free software you need to make all your software free, is it that?

I have no sympathy for oracle or their products but I fail to see the hypocrisy here. I think oracle is pretty consistent in their position over the years.

If I give you software, and tell you to trust me - but I will not use software given because I do not trust: surely I can read something into that.

Clearly Oracle are aware of the danger that they themselves ask people to ignore.

Business is business. I wouldn't call Zuck a hypocrite for not exposing himself on TikTok.

(There may be other reasons to do so but that's not here nor there)

You are also committing the classic mistake of anthropomorphizing Larry Ellison.

What are you talking about? this is a COMPANY NOT A PERSON. Who is "I" in your example? The point of Oracle is to maximize it's profits, it appears to be doing that via whatever means are available. This is not hypocrisy or anything like it

This is a slam dunk for free software. Even Oracle can't deny the benefits.

Slightly off-topic, but one of my greatest pet-peeves of working in devops is every few years a new "killer tech" comes out that some contingent of very-highly-opinionated (though not always very senior) people insists is life-and-death stakes and wants the whole company to move to (e.g. terraform).

Too often it's a failure. Too often it has some upsides, but also is a LOT of work that is discovered over time. Too often it's seen as good BUT now some incompatible new version or alternative requires the whole debacle start again.

I only want to learn technologies that will be relevant until the day I retire, otherwise I'm not advancing, it's all just a treadmill.

If you think devops has it bad, don't ever work in front-end. Or web development in general

Lol @ svelte's reactive statements being lauded then runed.

You have to carve your own path. I've experienced the same revelation and have adopted FreeBSD and Erlang. It's for hobby / home use but if I ever launch it'll be on this stack. It's been a rewarding journey. YMMV, but this is how I dealt with this situation.

Would you classify k8s in this bucket?

I'm still debating that. Certainly on the one hand it seems like there's already dozens of different incompatible variants/tools/setups/workflows to learn [most of which will be zombies in 5 years]. If I had to pick -- my gut instinct is kubernetes will be around for 5 more years but won't be common in 20 years.

What is going to replace it?

Welcome to technology.

Yes, I too wish I could make a living programming in 65C02 assembly on my Apple //e like I did in 1986.

I also don’t see any reason I have to learn about S3 instead of storing all of my files on an on prem CDRW jukebox

No, it's not inevitable. There are many technologies that will outlast my whole career: java, sql, tcp/ip, linux, to name a few.

S3 will also certainly be around in 20 years.

That’s true. But when I was first learning Java, Java beans and Java Server Pages were the hotness. The last time I did production code in Java was writing Android apps that required knowing the Android SDK.

Programming in Java in 2024 is nothing like it was in the 1990s when it was first embedded in Netscape Navigator - yeah I played around with it back then.

When I was first using C and C++, I was writing Windows apps with MFC in 1999. Good luck if that’s all you know in 2024z

I’ve been at this awhile. I started writing C and Fortran apps on DEC Vax and Stratus VOS mainframes in 1996z

My second job was part development and part managing Windows servers on prem running IIS and Classic ASP.

I got my first, only, and hopefully last job at BigTech in the cloud consulting department at 46 (full time role) consulting companies on all of the latest “serverless” goodness.

Either evolve or end up complaining on HN about “ageism”. When I got Amazoned at 49 last year, it took all of three weeks to have multiple offers. I’ll put my buzzword compliance against anyone of any age in my niches.

While “tcp/ip” will be around as will assembly language. I’ve programmed in assembly language on five different architectures either professionally or as hobby. I haven’t touched it since 2008. Jobs are at a higher level of abstraction these days.

100%, technology evolves, sometimes to a dead end but it keeps moving and it's an interesting, frustrating and fun ride.

if moving to terraform fails for your org, you have much deeper issues that likely aren’t related to terraform

I didn't downvote, but I disagree. You put forth the question of when a company might rightly not use terraform and I think I can answer that.

I think of terraform as a form of insurance. It's "Oops manual change" insurance. In the event that somebody breaks something in the console and you need to undo it, it's exponentially faster-easier. However you have to pay premiums to get this insurance as well as a setup cost.

So is the insurance worth it? It depends on the org. But I've seen small places where it's a small team that communicates well and nobody screws around in the console with stuff they don't understand (and if they break it they can own it). So there absolutely are places where the amount of time terraform costs you (in learning, setup, and extra PR time, waiting for atlantis to finish, locks) is higher cost than the time saved when you need.

> if moving to terraform fails for your org, you have much deeper issues that likely aren’t related to terraform

That is nonsense.

You just said, equivalently, "Terraform is all things to all people".

No I didn't. Failing to adopt an IAC approach, which I have seen in my career many times, whether it's terraform or any of the other tools - comes down to organizational issues.

I'll pose a question to your snotty response - What specifically about terraform would lead to it failing to be implemented at a company? The answer to that will provide all you need.

I'm not being snotty. Terraform is not the best choice for every organization.

Rather, Terraform does not add value within every organizational structure. Not adding value is failing. Having a negative ROI is failing.

None of these infrastructure tools are perfect, and the ways in which they are imperfect mean that some are better or worse matches for an organization's needs.

Therefore your initial statement is oversimplified, presumptuous, and ultimately nonsensical. A logical reframing is "if your organization does not match Terraform's strengths, then your org is the problem", and that is clearly not true.

You're shifting goalposts now and still failed to answer my question. And since you seem to have cracked the long-known problem of measuring infrastructure/devops/etc. team performance (since apparently you have a way to measure the ROI on that) I'm assuming you're far above my expertise here and have it all figured out, and I'm in over my head and have clearly struck a nerve. Glad you figured out a problem that so many haven't! have a good day.

The answer is that they all suck. I've used them, and I've written them. They sucked 20 years ago, and they suck today.

But they suck differently, for different reasons, and they suck in different magnitudes in the hands of different teams, with different needs.

I have never met an org that was happy with their infrastructure tooling! But I have met some that were happier with some tools than with others.

It's horses for courses. Terraform is a contender for some use cases. Nothing more, nothing less.

Following IBM's acquisition of Hashicorp the moves seems unsurprising, they wouldn't want to be beholden to a competitor.

We'll inevitably see others large companies follow suite - it was one thing when hashicorp was independent tech company but it's very different when it's owned by a direct competitor.

>they wouldn't want to be beholden to a competitor.

Which is ironic given that OEL is a direct rip-off of RHEL which IBM also now owns.

IBM prolly got them to agree to do the re-licensing move "as Hashicorp" as part of the take over deal. So it would not look bad on IBM.

From what I have read Hashicorp did this relicensing since IBM was reselling Vault at scale in IBM cloud. They wanted to force IBM and other cloud providers to pay them instead I believe.

IBM employees then initiated the fork of vault which is called openbao. Later IBM buys Hashicorp. The fork might have just been an attempt at leverage in the negotiations but it remains to be seen if it will live on.

OpenTofu hard forked, it's going to be interesting to see what happens if IBM rolls back the licensing changes.

been using terraform heavily for 5 years and have hacked together modules and custom providers for various ad-hoc things.

One of the things that has always really frustrated me about terraform is that it seems to go out of its way to make you do things in a very annoying, inconsistent way. Part of this is necessary due to the nature of the provider ecosystem, you can't guarantee consistency across providers - and I won't burden this post with my gripes about inconsistencies and annoyances within providers, such as the AWS provider.

Really though the interface has always been terrible (IMO). Stuff like iterating through a nested map using a for loop, which is trivial in most languages, is annoying and obtuse to the point of comedy. God help you if this map contains mixed types. Novices have trouble picking it up in general. It's very easy to start a project that sprawls completely out of control, and there doesn't seem to be a standard at all as to how to organize projects/code, so each terraform project I inherit is wildly different and has its own seemingly unique pain points.

A lot of this has gotten better over the years with QoL improvements within terraform itself - but really, as a developer, I've gotten more than a little tired about the hubris that Hashicorp shows with some of the stuff around the terraform ecosystem. Features that people beg for routinely get told by maintainers that they will not be doing that because reasons or because "it's not possible" (such as dynamic provider blocks). OpenTofu is already tackling many of the gripes and feature requests I've had over the years and are doing so eagerly and have some heavy hitters behind it.

Terraform is good, but it was always going to be vulnerable to competition - It's basically just a state-based wrapper around cloud API's. A great idea, but easy to duplicate. I don't know what they were thinking trying to put this behind a walled garden when they could have used it to get people into the hashicorp ecosystem and sell their other enterprise products.

What really grinds my gears is how hard it is to refactor terraform code. Put something in a module, but want to move it elsewhere? Get ready for pain.

I've been using terranix, which uses nix to generate a tf.json file, and oh my god is the experience night and day. I can make functions! I can refactor! And if it's a pure refactor, there is nothing to apply.

How does terranix help you with the "move a resource from a module to somewhere else" problem?

It helps because you don't use terraform modules at all, any abstraction you need can be done in nix before tf.json gets written.

I know many people find it painful but isn't this fairly simple with "terraform state mv?"

my process is roughly:

comment out the resource in the module, run a plan -> get output like:

"module.foo1.aws_resource.bar will be deleted"

Then copy my resource in source to module.foo2.aws_resource.bar, the command becomes:

terraform state mv module.foo1.aws_resource.bar module.foo2.aws_resource.bar

I guess this might be harder if you're using upstream "official" modules, but I avoid those like the plague.

You don't even need to do state mv anymore. They added the `moved` block a while ago. You can then delete it from the source after your apply at your leisure.

"Every change requires two PRs that aren't in the same terraform run" still way way way too much mental overhead just to do a simple refactor.

Yea, there are tools to work around it, but the fact that a pure refactor would impact terraform state at all is the design flaw in my eyes.

Suddenly, just to refactor the source in a way that shouldn't touch any resources, you have to have be able to mutate the terraform state. (Or use the more recently introduced moved blocks, which is still quite a big kludge).

This means any kind of broadly sweeping refactor (which might impact many different state files) is really hard.

If OT want to win all they need to do is actually make it possible to debug the code.

It ain't Infrastructure As Code if you can't put a break point.

Co-founder of OpenTofu here.

Second that. One of my colleagues is working on adding proper tracing to the OpenTofu codebase, to help understand the exact cause of failures.

Oracle making the change due to licensing is like a dictionary definition of hubris, considering how their own license enforcement operates.

Oracle doesn't have some ideological preference for licensing. Oracle just wants what is best for Oracle.

Right - don't anthropomorphize the lawn mower.

why, cause he hates it?

I think you mean hypocritical, instead of hubris.

As much as I dislike Oracle's biz practices (I'd not touch their db product with a stick), they do a lot of FLOSS devt:

https://opensource.oracle.com/ (almost endless list)

But then they have take FLOSS projects and abandoned them, see OOo for instance:

https://en.wikipedia.org/wiki/Apache_OpenOffice#/media/File:...

Looking through that list, most of the big projects (OpenJDK, Mysql, Opengrok) were inherited as part of acquisitions.

Oracle has been a prolific contributor to the Linux kernel.

https://blogs.oracle.com/linux/post/oracle-is-the-1-contribu...

XFS is really important for (their) database performance, so quite a lot comes out of Oracle for it. You might also know that btrfs began at Oracle.

https://www.google.com/search?q=oracle+blog+xfs

https://en.wikipedia.org/wiki/Btrfs

"Chris Mason, an engineer working on ReiserFS for SUSE at the time, joined Oracle later that year and began work on a new file system based on these B-trees."

> Looking through that list, most of the big projects (OpenJDK, Mysql, Opengrok) were inherited as part of acquisitions.

I see this argument a lot, but I'm not sure how it detracts from their continued development. Oracle funds many engineers working on OSS and, despite having CLAs in place, retain the permissive license for most of them. In some cases they've acquired closed source software and made it open source (e.g., JRockit stuff). They're a major contributor to OSS.

Oracle takes hostages, they know how to avoid being taken hostage. Not hubris, just tactics.

It would be hubris if they tried to then take the moral high ground.

It's not hubris or hypocrisy, it's a profit maximizing entity maximizing profit that's it

They wrote the playbook. They know what's coming. Ruthless and smart!

The article is somewhat confusing but it sounds like Oracle packages a cloud infrastructure management tool that’s based on Terraform. Presumably it’s built on 1.6, which was still MPL. Since they offer this product as a service, it directly falls under the restrictions HashiCorp put into place to prevent competition from repackagers and SaaS offerings of their products.

So to move forward with upgrading the Terraform support in their tool, Oracle had two choices: pay HashiCorp (soon IBM) a hefty license fee to resell Terraform, or use OpenTofu which is free and has now proven to be well-run enough to issue a new release with both Terraform compatibility and OpenTofu-specific enhancements, while dodging lazy accusations of code theft from HashiCorp.

This is a no-brainer for Oracle, and it’s great news for the future of OpenTofu.

It will be interesting to see what IBM's army of lawyers think about those lazy accusations of code theft ;)

The move towards OpenTofu is going to be a slow tide, but it is coming. It's an easy migration, the team behind OpenTofu is showing that they're strong, and the community opinion is most definitely shifting in their favor. We made the jump for one client, started a new client project with tofu, and are starting to migrate another client this week.

Good info on our experience here: https://masterpoint.io/updates/opentofu-early-adopters/

"Oracle’s move seems like a straightforward decision to ensure it is using the most permissive underlying IaC tool without having to worry about downstream license complications, no more and no less."

Oracle wins a big competitive talking point versus IBM, as well as crushing the value of IBM's acquisition of Hashicorp, and completely eliminating IBM's Terraform inroad into a large group of Oracle's enterprise customers.

I don't see how any of this could be true considering IBM is also heavily involved in OpenTofu (and did so first)

Exactly right. You're making my point for me. :-) Oracle can now say it has one solution, whereas with IBM the attention is split between Terraform and OpenTofu.

If you're an enterprise customer, do you want your enterprise deployments on a company that knowingly does two near-identical implementations, and can't seem to decide on which one to favor?

I was wondering, once IBM got Hashicorp, if they would reverse the license change for Terraform. Not been that long since the announcement, so still hoping they will.

If they do it likely won’t be until after the deal closes.

Has there ever been notable instances of company regretting and reversing license change of a major project?

We're talking about an acquisition, not the original company making the reversal.

Red Hat used to routinely open-source acquisitions. Sun also did— that's how we got OpenOffice (and by way of it, LibreOffice). StarOffice was proprietary when Sun bought it.

Unity!

Oracle ended OpenSolaris although forks continue. Nokia and friends ended OpenSymbian, no forks afaik.

Lerna, if that's major enough for you.

I believe Hashicorp's move wrt the license of TF was in order to close the IBM takeover deal.

You keep posting this completely unsubstantiated theory.

Way back when the license changed the threads on HN had HashiCorp employees claiming the change was primarily to protect HashiCorp from the fact IBM was reselling Vault. IBM then went ahead and helped fork Vault (OpenBao).

Definitely not the case. HC leadership was totally desperate for any way to increase revenue and/or stock price. See also the announcement in a recent quarterly report that they were going to start doing share buybacks even though they are still operating at a loss.

I think Oracle Linux was a similar approach to let their customers use RedHat Linux without paying RedHat, now also IBM.

Oracle Linux has been a thing for decades.

It's largely because a lot of Oracle DB products where performance mattered (eg. Exadata) needed some sort of a base OS that Oracle could manage and optimize as needed.

> It's largely because a lot of Oracle DB products where performance mattered (eg. Exadata) needed some sort of a base OS that Oracle could manage and optimize as needed

All that’s needed is update sysctl.conf to tune kernel parameters to the workload. Every Linux sysadmin knows how to do this. What kernel parameters need to be updated is heavily documented for any product.

Having these pretuned AND having a dedicated support team doing the tuning for you is the killer app for some buyers, as it allowed Admins to concentrate on other work and also minimize management overhead for the Infra org.

Spending $500k/yr on compute+support SLA is cheaper than $200k/yr on compute and hiring 3 admins dedicated to that piece of compute.

This is the model that every Enterprise Infra vendor pushes (eg. Oracle, AWS, MongoDB, Nvidia), and most mid- and upper-market purchasers are used to it.

> Having these pretuned AND having a dedicated support team doing the tuning Dedicated support team costs a lot more than you think. I guess you never had to deal with Oracle support. If you get hold of someone, all they will do it point to the documentation.

All software products have documentation on how to install the product. Oracle has a large suite of products, their databases, ERPs, etc. For kernel parameters, its just a file, which takes a second https://docs.oracle.com/en/database/oracle/oracle-database/1...

In reality though, all Infra teams, have infrastructure to install OS (and manage the fleet), then post-install customize the OS to which team is requesting, usually done via puppet or ansible to manage the configuration. There will be standardized configuration for application, web, database (just to keep it simple).

I would be shocked if Oracle support (or any other vendor) is given login access to make changes on servers owned by clients. At best, you open a case, you get an incompetent support person who'll send you documentation.

Oracle support does not replace admins. Oracle support gives you access to bug fixes, updates, documentation. I believe you can download most Oracle software for free, but without the docs and updates, its worthless. Other vendors may use the opposite strategy, docs openly available but software downloads are paid/subscriptions.

> Spending $500k/yr on compute+support SLA is cheaper than $200k/yr on compute and hiring 3 admins dedicated to that piece of compute.

In reality though, there will always be admins, then a whole lot DevOps/Cloud Ops/Kubernetes/SRE/etc people added, smooth talking manager/director increasing the spend from what could be done on bare-metal under 20K to a 20 million dollar multi cloud strategy. Why have 3 admins report to you, when you can have an army of 200 people do the same work for 100x more cost? Success stories and promotions all around!

> all Infra teams, have infrastructure to install OS (and manage the fleet), then post-install customize the OS to which team is requesting, usually done via puppet or ansible to manage the configuration.

Yep! And it takes time and effort to maintain your Puppet/Chef/Ansible/Terraform/OpenTofu scripts as well as your golden images as well as triaging escalations as well as other incidental work. This means you don't have as much time to work on tuning or debugging, because you'll have dozens of tools (some in-house, others purchased) to manage.

Furthermore, most people recognize Hardware specialized IT Administration is increasingly a career dead end, so most end up switching to Engineering, Sales Engineering, or Support Engineering due to better career opportunities.

> I would be shocked if Oracle support (or any other vendor) is given login access to make changes on servers owned by clients. At best, you open a case, you get an incompetent support person who'll send you documentation.

This is the norm in most mid- and upper-market support contracts. You'll have a dedicated TAM, Support Eng, and CSM who will handhold teams, and will have access to the underlying infrastructure.

> Oracle support does not replace admins. Oracle support gives you access to bug fixes, updates, documentation. I believe you can download most Oracle software for free, but without the docs and updates, its worthless. Other vendors may use the opposite strategy, docs openly available but software downloads are paid/subscriptions.

Depending on your contract, you would be given a dedicated TAM team and support team to debug any issues in the Oracle stack.

> In reality though, there will always be admins, then a whole lot DevOps/Cloud Ops/Kubernetes/SRE/etc people added, smooth talking manager/director increasing the spend from what could be done on bare-metal under 20K to a 20 million dollar multi cloud strategy. Why have 3 admins report to you, when you can have an army of 200 people do the same work for 100x more cost? Success stories and promotions all around!

That "smooth-talking manager" needs to justify to the CFO, COO, CTO, VP Eng, etc that for $X spent, I can get 1.5 * $X back.

As I've mentioned on multiple different occasions on HN, spend on on-prem infra is treated as part of the Finance+ITOps budget, not the DevOps budget (which is generally within R&D).

Procurement is hard, and you need to JUSTIFY a 1% increase in headcount

For example, let's assume you are hiring 3 IT Admins for $120k. That ends up costing $700-800k/yr because of benefits and incidentals. The compute as well is an additional $200-300k.

This means you are spending $900k/yr AT BEST.

That $200-300k in compute becomes $500k with a support contract, and you can hire 1 person for $120k to manage that.

This means you're spending around $750k/yr AT BEST.

That extra $150K can then be given to Engineering to help give bonuses to attract good dev talent or hire some additional headcount on the Sales side to sell the product you are hired to build.

MongoDB offers a preconfigured Linux to run on?

Or did you just mean Atlas?

I mean MongoDB has a professional services SKU to simplify onboarding and management.

> All that’s needed is update sysctl.conf to tune kernel parameters to the workload.

Mind that they do quite some work on the kernel itself to optimize it for their workloads:

https://blogs.oracle.com/linux/post/oracle-is-the-1-contribu...

The availability of Oracle's uek kernel is a differentiator from standard RHEL.

Oracle has a long history of not documenting all of this stuff and instead suggesting you should hire one of their army of consultants to help tune the OS or Database for you.

If we are talking about tuning for a specific workload, what’s wrong with that?

If your in-house DBA doesn’t have the experience to perform the specific tuning required, then that’s what support contracts are for

The documentation can’t cover every customer’s use case and configuration. That’s just enabling folk to blindly copy inappropriate sysctls they don’t understand like they are building gentoo kernels.

You don't need to cover every use case. You just need to document what stuff does and how it affects to various workloads. A good engineer can from that information infer what they need for their workload. But not documenting that a control exists so that you can be bill you for consulting puts you in my "will not use" category.

Didn't they buy one of these (Solaris)?

That was after the launch of Oracle Linux.

Maintaining an entire separate OS (like Solaris) is hard. Maintaining a fork of a Linux distro is easy.

I wish there was a type safe, algebraic data type using Terraform alternative.

There are Java and C# (somewhat typesafe imho) and this (Kotlin, reasonably typesafe imho):

https://github.com/VirtuslabRnD/pulumi-kotlin

For Pulumi. When I see the pulumi-kotlin example code I much prefer it over my Terraform scripts. (We picked TF before Pulumi was an option, and waaaaay before it had reasonably typesafe lang support)

I made this suck less last year and it was just recently merged: https://github.com/pulumi/pulumi-java/pull/1231

This lets you use Pulumi w/Gradle multi-project builds in Kotlin script.

+1 for pulumi! https://thenewstack.io/pulumi-launches-new-infrastructure-li...

Idk if the APIs look like what you want, but Scala has ADTs and there's a new Pulumi SDK for Scala that just entered public beta: https://virtuslab.github.io/besom/

There's also a first-party Pulumi SDK for F#: https://www.pulumi.com/docs/languages-sdks/dotnet/

If you're into Nix, you might enjoy using this to generate Terraform JSON. The language is inspired by Nix, so it feels familiar to Nixers, but it has a better type system that recently includes ADTs, at least on its master branch: https://github.com/tweag/tf-ncl

You can use dhall for terraform, but no idea if UX for it got better.

We use typescript + pulumi for this. It's pretty amazing. And Pulumi uses Terraform modules under the hood so you get the full power of Terraform with the goodness of Typescript.

Even self hosting your state management in a bucket is simpler with Pulumi since it uses lock files on S3 versus a separate DyanamoDB + S3 combo.

I have been using it in production for 4-5 years and used Terraform for several years before that.

> since it uses lock files on S3 versus a separate DyanamoDB + S3 combo

This is disturbing because S3 does not give you guarantees required to implement real locking.

https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-rea... guarantees that a client's lockfile can always be seen by other clients immediately (which didn't used to be true). If every client backs off and retries after a race, is that enough?

I think not, actually. There would still be cases where a race is not detected. I can think of the following sequence: A checks - no lock, B checks - no lock, A writes - success, A reads - match, success, B writes - success, B reads - match, success. A and B both think they now hold the lock.

For locking to work properly you'd need to have a conditional write that would fail if some prerequisite was not met. GCP offers that operation, S3 AFAIK does not.

I'm no expert but from a quick glance at https://www.pulumi.com/docs/concepts/state/#using-a-self-man... it looks like this might work:

  client A lists s3://bucket/prefix/.pulumi/locks/, sees nothing

  client B lists s3://bucket/prefix/.pulumi/locks/, sees nothing

  client A creates s3://bucket/prefix/.pulumi/locks/unique1.json

  client A lists s3://bucket/prefix/.pulumi/locks/, only sees unique1.json, and proceeds

  client B creates s3://bucket/prefix/.pulumi/locks/unique2.json

  client B lists s3://bucket/prefix/.pulumi/locks/ and sees both unique1.json and unique2.json

  client B assumes it lost a race, deletes s3://bucket/prefix/.pulumi/locks/unique2.json, and retries

In this case you have the opposite issue, with no-one actually guaranteed to get a lock even though nothing is holding one. Fuzzed retries may work in practice but theoretically speaking this is a flawed algorithm.

Hm, I can sort of imagine a way to use lockfile names to claim a random position in a queue of pending changes, but I don't know if anyone has been worried enough to do that. In practice Pulumi seems to give up instead of retrying: https://github.com/pulumi/docs/issues/11679

A giant corporation like Oracle switching to the fork because they don’t want to engage commercially with Hashicorp is peak greedy.

Greedy? Why would you bet your product and customers on another company? If someday Hashicorp suddenly died so that nobody adds new features or fixes bugs, you can't do anything about it because their code isn't "open source" even though available, when a "true" open source project is just next door. Any big enough company will think about what is the safest approach to their product.

(Of course, companies do go out of business, and products stop to be maintained, and the example here is a bit extreme, but the point is that company will do what makes the most business sense)

Why would you bet your product and customers on another company?

Oh so you never heard of “suppliers”?

It is not Oracle who are using terraform, it is their customers. Terraform is the underline tech that powers the tooling suit that the customers use to manage their oracle cloud.

It makes perfect sense for them to push their customers to move to the more permissive licensing to avoid any legal issues.

Only when it isn't legal issues that dump money into Oracle. They absolutely love and adore pushing their customers to less permissive licensing which can encounter legal issues when they are the ones benefiting

Yes, Oracle loves making money.

More than the money, it's the license servers that make your life miserable

How? It seems entirely sensible

They seem to think that just because a company makes non-open-source software, it shouldn't itself prefer to use open-source rather than proprietary software?! That makes no sense, of course. Specially considering the non-OSS is now owned by IBM which directly competes with Oracle on multiple fronts. It seems to me that OpenTofu is actually backed by many companies in a similar position to Oracle, which don't want to have to rely on IBM for things they have tight integrations with.

Fortunately using OpenTofu is just s/terraform/opentofu/g at this point.

> What is OpenTofu?

>

> OpenTofu is a Terraform fork, created as an initiative of Gruntwork, Spacelift, Harness, Env0, Scalr, and others, in response to HashiCorp’s switch from an open-source license to the BUSL. The initiative has many supporters, all of whom are listed here.

I still have no idea what I am looking at. I know that probably means this product isn't for me, but it peeves me when products do this. "What is X? X is like Y!"

Infra as code. Write a template for a Spanner table in your GCP account. If it doesn't already exist, OpenTofu will notice and offer to send the API call to create it.

It's like using AWS CloudFormation or GCP Deployment Manager, but supports quite a few cloud vendors with the same tools.

OpenTofu is Terraform

How are Oracle with contributing to OpenTofu upstream?

This is a pretty interesting development. Anyone know the userbase/impact of "Oracle EBS"?

I don't know much about Oracle's services so can't figure if this is a huge number of users, of a small subset of their clients.

Oracle has a number of departments, but one way you can look at it is:

* Oracle Products (e.g. DB, Fusion, E-Business Suite)

* Oracle Cloud (OCI)

What's telling is that Oracle Cloud's Terraform-as-a-Service (Resource Manager) is still Terraform:

https://docs.oracle.com/en-us/iaas/Content/ResourceManager/C...

Clearly, Oracle must think there is some legal distinction between telling Terraform-as-a-service, and selling+distributing a product _containing_ Terraform that end users then use as Terraform-as-a-service.

Oracle Cloud's Resource Manager only supports Terraform versions up to 1.2.9 which is already quite old and of course open source. The license changes past the 1.6 versions don't affect the tool at all since it's using such an old version of TF.

Version support here: https://docs.oracle.com/en-us/iaas/Content/ResourceManager/R...

Why Oracle Cloud isn't using Terraform version 1.5.7 which is still open source in Resource Manager is anyone's guess. Perhaps the tool isn't getting much attention recently?

And the biggest department:

* Oracle legal

Yeah this sounds like a very narrow use case shifting. That of moving your EBS ERP application to Oracle cloud from on premise. I mean, people are doing that migration and it's exciting if they are actually using iac, but this can't represent large usage of Terraform.

Just don't let them hijack it for their own purposes.

Sun and MySQL precede them.

I just wish Terraform would let me be a grown up and see sensitive values in an output without going through so many hoops.

[dead]

We're seeing an uptick in open source projects getting relicenced to non-open licenses. Some projects are successfully forked and the userbase shifts, other times not.

One theory of mine is that we can measure the risk that a project will be relicensed by looking at things like diversity of contributors, trademark ownership, contributor agreements, and license terms. Low risk projects include the Linux kernel (GPL, DCO) [1]. High risk projects include Kubernetes (Apache, CLA) [2].

If this trend continues developers will need to get a better understanding of how relicencing works and may decide to avoid contributing to projects with elevated risk.

[1] https://alexsci.com/relicensing-monitor/projects/linux/

[2] https://alexsci.com/relicensing-monitor/projects/kubernetes/

I'm not sure how Kubernetes is high risk, given the CLA is to CNCF. Similarly, CLAs to the Apache Foundation, the FSF or similar are probably pretty safe (in that they have a long term interest to be good custodians for the IP), and could be safer than projects that lack a CLA but don't have (or only a few) outside contributors.

To me, the obvious questions are who owns the IP, and what are their incentives to maintain the current licensing.

This is a good critique. Measuring intent of an organization may be difficult to do methodically and impartially, so it's not currently covered. Personally I was surprised to see Redis change license after Redis Labs promised not to change the license. I think that promise was made with good intent but overwhelming financial pressure that emerged later on swayed them.

I'm pretty sure most instances of relicensing have had a previous claim that wouldn't happen, so I wouldn't assign too much weighting to that (if anything, it should be a red flag to look into what the IP situation is).

I think there are a bunch of questions you can ask:

* Why is the software open source (if licensing/contractual requirements make it so, that's more likely to keep the status quo vs. corporate claims of "we <heart> open source")?

* Who owns the copyright/IP (and what's their reputation)?

* What would happen if the the license changes (is there an ecosystem that relies on it being open source, or is it a black box)?

* Who cares what the license is (e.g. BerkeleyDB was relicensed, which got old versions frozen in linux distributions, so no-one upgraded to newer versions, and replacements were written)?

I think you need to rework your algorithm. Kubernetes is no way a high risk project, its IP is owned by the CNCF/Linux Foundation.

Dual licensing also makes it IMHO less likely that a project "continues as proprietary". Example: Qt.

I think "contributor agreements" are the biggest red flag. Though I like them for potentially upgrading a license (say from GPLv2 to v3), not that this always is a good thing.

It's also worth mentioning the specific agreement between KDE and Qt (https://kde.org/community/whatiskde/kdefreeqtfoundation/ and https://www.qt.io/faq/3.2.-why-do-you-have-an-agreement-with...), which shifts the incentives as well.

You don't need contributor license agreements for upgrading to future versions of the GPL. You can just license the code under 'GPL version N or later': https://www.gnu.org/licenses/license-compatibility.html

Regarding Kubernetes and the Apache license, Apache license 2.0 has to be one of the most business friendly licenses around? It's widely used and understood, no requirement to open source changes, automatic patent license for any patents the software uses included. If the corporate lawyer says no to that, what do they say yes to?

> Apache license 2.0 has to be one of the most business friendly licenses around?

Yes, in my experience it is.

Permissive licenses like Apache, MIT, and BSD are easiest for the corporate lawyers to approve but also easy for the project owner to relicense. Relicencing Monitor isn't measuring how easy it is for companies to use the software; risk is solely measuring how easy it is to relicense the software.

Copyleft licenses are lower risk than permissive licenses in this specific context as they are viral. A CLA or a very small number of contributors can negate that, as happened with Emby [1].

SourceGraph is probably the best example here (I need to add them still). They switched off Apache 2 and prompted this [2] helpful blog post.

[1] https://alexsci.com/relicensing-monitor/projects/emby/

[2] https://drewdevault.com/2023/07/04/Dont-sign-a-CLA-2.html

I wonder how accurate this assessment is since the Linux Foundation is a non-profit.

The good news is that projects that prevent forking from happening usually don't have huge OSS communities of contributors because of their attitude towards outside contributors. You need an outside community to be able to step up and take over for a fork to happen.

Mostly things like copyright ownership transfer is not a thing with OSS communities because it strongly discourages third parties from contributing. Copyright transfers are only needed with some licenses (GPL style licenses that insist everything else is licensed the same way) and cannot prevent a retroactive fork even if you have them. Other licenses allow distributing mixed licensed code and you can just create a commercial source distribution for those because the license explicitly allows that. Either way, anyone with the pre-license change version of the code can fork. That's why Elastic, which used the Apache license and had copyright transfers, got forked.

The more widely used an OSS project is, the more likely it is that somebody will fork it if it is re-licensed. Because that usually means lots of external contributors and plenty of interest from wealthy companies that depend on it. Meaning there are skills and money needed to fund the fork. Copyright transfers don't stop this from happening. Unless you specifically want to fire most of your user base, this just doesn't make any sense from a business point of view.

A failure to fork basically indicates the project didn't have a strong developer community and big companies simply didn't care about the project.

I consult some clients on Elasticsearch and Opensearch. Most of my recent clients now default to Opensearch. Because it's the OSS option. They are clearly spending money to get support (from me and others) but Elastic isn't getting any. As far as I can see, Opensearch now represents the vast majority of new users and is becoming a significant source of money for hosting, training, and consulting. But Elastic is getting none of that.

My guess is that the industry will learn from the repeated re-licensing and forking and subsequent community split that has been happening. Elastic, Redis, OpenTofu, Centos, etc. The pattern is the same every time: 1) project gets relicensed 2) a few weeks later a consortium of companies pools resources together and forks 3) most users stick with open source and the company cuts themselves off from those users.

Long term, I would not be surprised to see some of those companies offering support for their OSS forks (in addition to their commercial offerings) or even reverting the license change. This would make a lot of sense for e.g. Elastic as there's a lot of duplicated effort between them and Amazon. And Amazon gets a lot for free from outside contributors.

I’m not sure why you’re being downvoted, this is happening a lot right now, and it’s a real risk when contributing or using an open source project.

I also had the same thought to create some sort of risk metric that could be applied to projects, but I do think your initial metric is lacking some criteria. Foundations like the CNCF and ASF have to be among the lowest risk, and CLAs can be more or less harmful depending on their specific content. I think a big red flag has to be if they’ve taken any VC or PE funding.

However I think the principle of taking this risk more seriously is good and important.