[HN Gopher] Oracle dumps Terraform for OpenTofu
___________________________________________________________________
Oracle dumps Terraform for OpenTofu
Author : p1nkpineapple
Score : 231 points
Date : 2024-05-15 10:50 UTC (12 hours ago)
(HTM) web link (www.thestack.technology)
(TXT) w3m dump (www.thestack.technology)
| benrutter wrote:
| 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.
| amiga386 wrote:
| 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.
| cies wrote:
| And the biggest department:
|
| * Oracle legal
| pwarner wrote:
| 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.
| robertlagrant wrote:
| How are Oracle with contributing to OpenTofu upstream?
| jph wrote:
| "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.
| pwarner wrote:
| I think Oracle Linux was a similar approach to let their
| customers use RedHat Linux without paying RedHat, now also IBM.
| alephnerd wrote:
| 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.
| thelastgallon wrote:
| > 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.
| alephnerd wrote:
| 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.
| twoodfin wrote:
| MongoDB offers a preconfigured Linux to run on?
|
| Or did you just mean Atlas?
| alephnerd wrote:
| I mean MongoDB has a professional services SKU to
| simplify onboarding and management.
| thelastgallon wrote:
| > 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!
| alephnerd wrote:
| > 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.
| zaphar wrote:
| 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.
| mingus88 wrote:
| 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.
| zaphar wrote:
| 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.
| johannes1234321 wrote:
| > 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.
| growse wrote:
| Didn't they buy one of these (Solaris)?
| Kwpolska wrote:
| Maintaining an entire separate OS (like Solaris) is hard.
| Maintaining a fork of a Linux distro is easy.
| claudex wrote:
| That was after the launch of Oracle Linux.
| dralley wrote:
| I don't see how any of this could be true considering IBM is
| also heavily involved in OpenTofu (and did so first)
| EspadaV9 wrote:
| 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.
| pquki4 wrote:
| Has there ever been notable instances of company regretting
| and reversing license change of a major project?
| webwielder2 wrote:
| Unity!
| baobun wrote:
| Lerna, if that's major enough for you.
| toast0 wrote:
| Oracle ended OpenSolaris although forks continue. Nokia
| and friends ended OpenSymbian, no forks afaik.
| cies wrote:
| I believe Hashicorp's move wrt the license of TF was in
| order to close the IBM takeover deal.
| glenngillen wrote:
| 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).
| skywhopper wrote:
| 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.
| skywhopper wrote:
| If they do it likely won't be until after the deal closes.
| jph wrote:
| 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?
| loloquwowndueo wrote:
| A giant corporation like Oracle switching to the fork because
| they don't want to engage commercially with Hashicorp is peak
| greedy.
| klysm wrote:
| How? It seems entirely sensible
| brabel wrote:
| 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.
| trueismywork wrote:
| More than the money, it's the license servers that make your
| life miserable
| m1keil wrote:
| 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.
| freedomben wrote:
| 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
| m1keil wrote:
| Yes, Oracle loves making money.
| pquki4 wrote:
| 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)
| loloquwowndueo wrote:
| Why would you bet your product and customers on another
| company?
|
| Oh so you never heard of "suppliers"?
| Lockal wrote:
| "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
| croes wrote:
| Oracle owns MySQL but not Terraform
| ethbr1 wrote:
| Ah, so they meant avoiding 'downstream license complications'
| _they don 't cause_.
| baobun wrote:
| I wouldn't expect Oracle to have a license complication
| with itself...
| dijit wrote:
| it's mostly just hypocritical.
|
| If everyone acted like Oracle; there would be no mysql
| users. Which is the point being made.
| snapcaster wrote:
| 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?
| dijit wrote:
| 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;
| disintegore wrote:
| This is a slam dunk for free software. Even Oracle can't
| deny the benefits.
| freedomben wrote:
| Especially ironic, given that Oracle is one of the nastiest and
| most aggressive companies at enforcing license terms.
| Timshel wrote:
| In a way they know the worst that can happen :D
| SteveNuts wrote:
| Yeah this is absolutely projection on Oracle's part
| globular-toast wrote:
| 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.
| sneak wrote:
| 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.
| globular-toast wrote:
| > 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.
| therealpygon wrote:
| 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.
| lolinder wrote:
| > 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.
| bigstrat2003 wrote:
| > 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.
| Pet_Ant wrote:
| 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.
| kees99 wrote:
| 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.
| Pet_Ant wrote:
| > 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_hob
| byist_p...
|
| [4]
| https://en.wikipedia.org/wiki/Server_Side_Public_License
|
| [5] https://web.archive.org/web/20230411163802/https://li
| sts.ope...
|
| [6] https://www.theregister.com/2013/06/10/openvms_death_
| notice/
| kstrauser wrote:
| 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.
| skissane wrote:
| > 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.
| totaldude87 wrote:
| At oracle-
|
| Hey, what if they do - what we do to other companies ... to
| us ...
|
| presses a red button
| geodel wrote:
| 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.
| talldayo wrote:
| 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.
| scarface_74 wrote:
| 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"
| talldayo wrote:
| 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.
| wcedmisten wrote:
| 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/
| jayd16 wrote:
| 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.
| geodel wrote:
| 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_.
| sangnoir wrote:
| > 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?
| vlovich123 wrote:
| 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.
| jayd16 wrote:
| 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.
| matt_heimer wrote:
| 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.
| oschvr wrote:
| Full circle of corporate facepalm
| skywhopper wrote:
| Oracle owns the most permissive possible license to MySQL.
| lenerdenator wrote:
| Just don't let them hijack it for their own purposes.
|
| Sun and MySQL precede them.
| ig1 wrote:
| 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.
| cies wrote:
| 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.
| alemanek wrote:
| 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.
| candiddevmike wrote:
| OpenTofu hard forked, it's going to be interesting to see what
| happens if IBM rolls back the licensing changes.
| tw04 wrote:
| >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.
| rswail wrote:
| Oracle making the change due to licensing is like a dictionary
| definition of hubris, considering how their own license
| enforcement operates.
| manishsharan wrote:
| They wrote the playbook. They know what's coming. Ruthless and
| smart!
| cies wrote:
| 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:...
| thayne wrote:
| Looking through that list, most of the big projects (OpenJDK,
| Mysql, Opengrok) were inherited as part of acquisitions.
| chasil wrote:
| 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."
| nirvdrum wrote:
| > 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.
| silveraxe93 wrote:
| I think you mean hypocritical, instead of hubris.
| kube-system wrote:
| Oracle doesn't have some ideological preference for licensing.
| Oracle just wants what is best for Oracle.
| bigstrat2003 wrote:
| Right - don't anthropomorphize the lawn mower.
| toolslive wrote:
| why, cause he hates it?
| __MatrixMan__ wrote:
| 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.
| snapcaster wrote:
| It's not hubris or hypocrisy, it's a profit maximizing entity
| maximizing profit that's it
| 8organicbits wrote:
| 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/
| janosdebugs wrote:
| I wonder how accurate this assessment is since the Linux
| Foundation is a non-profit.
| cies wrote:
| 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.
| aragilar wrote:
| 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.
| candiddevmike wrote:
| 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.
| aragilar wrote:
| 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.
| jillesvangurp wrote:
| 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.
| jamesrr39 wrote:
| 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?
| datadeft wrote:
| I wish there was a type safe, algebraic data type using Terraform
| alternative.
| ParetoOptimal wrote:
| You can use dhall for terraform, but no idea if UX for it got
| better.
| cies wrote:
| 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)
| andrewfromx wrote:
| +1 for pulumi! https://thenewstack.io/pulumi-launches-new-
| infrastructure-li...
| jpgvm wrote:
| 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.
| maineldc wrote:
| 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.
| fishnchips wrote:
| > 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.
| erik_seaberg wrote:
| 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?
| fishnchips wrote:
| 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.
| erik_seaberg wrote:
| 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
|
| There's another mode where both clients pessimistically
| retry, but fuzzing a retry delay could eventually choose
| a winner randomly.
| fishnchips wrote:
| 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.
| erik_seaberg wrote:
| 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
| skywhopper wrote:
| 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.
| empressplay wrote:
| It will be interesting to see what IBM's army of lawyers think
| about those lazy accusations of code theft ;)
| nunez wrote:
| Fortunately using OpenTofu is just s/terraform/opentofu/g at this
| point.
| JohnMakin wrote:
| 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.
| hamandcheese wrote:
| 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.
| cdchn wrote:
| How does terranix help you with the "move a resource from a
| module to somewhere else" problem?
| JohnMakin wrote:
| 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.
| rjbwork wrote:
| 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.
| nprateem wrote:
| If OT want to win all they need to do is actually make it
| possible to debug the code.
| fishnchips wrote:
| 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.
| toolslive wrote:
| It ain't Infrastructure As _Code_ if you can 't put a break
| point.
| cube2222 wrote:
| 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
| x86a wrote:
| 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.
| andreasmetsala wrote:
| Could it be because it weakens the business case for using
| their SAAS?
| x86a wrote:
| 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.
| colechristensen wrote:
| 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?
| cube2222 wrote:
| > 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
| hintymad wrote:
| The trend will continue. A company will be crazy to trust that
| IBM would give them fair-priced high quality support.
| solatic wrote:
| Do you appreciate the irony of that comment on a post about
| _Oracle_ adopting OpenTofu?
| organsnyder wrote:
| 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.
| playingalong wrote:
| Yep. Funny.
|
| In this case Oracle is the user, not the vendor.
| bloopernova wrote:
| 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
| }
|
| Preconditions and postconditions fail the apply run if their
| condition doesn't validate, so those can't be used.
|
| 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.
| cube2222 wrote:
| 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
| zug_zug wrote:
| 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.
| scarface_74 wrote:
| 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
| zug_zug wrote:
| 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.
| waynesonfire wrote:
| 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.
| JohnMakin wrote:
| if moving to terraform fails for your org, you have much deeper
| issues that likely aren't related to terraform
| quesera wrote:
| > _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".
| JohnMakin wrote:
| 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.
| quesera wrote:
| 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.
| JohnMakin wrote:
| 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.
| quesera wrote:
| 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.
| zug_zug wrote:
| 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.
| culi wrote:
| If you think devops has it bad, don't ever work in front-end.
| Or web development in general
| playingalong wrote:
| Would you classify k8s in this bucket?
| zug_zug wrote:
| 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.
| dylmye wrote:
| I just wish Terraform would let me be a grown up and see
| sensitive values in an output without going through so many
| hoops.
| darknavi wrote:
| > 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!"
| outside1234 wrote:
| OpenTofu is Terraform
| erik_seaberg wrote:
| 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.
___________________________________________________________________
(page generated 2024-05-15 23:01 UTC)