Terraform og OpenTofu beskriver servere, netværk og klynger som kode, så infrastrukturen kan genskabes et andet sted. Selve værktøjet er også en afhængighed. Terraform skiftede licens fra udgave 1.6.0 og ejes i dag af IBM, mens OpenTofu er en afgrening af koden, en fork, under Linux Foundation med den gamle åbne licens.
Infrastruktur som kode betyder, at I skriver ned, hvilke ressourcer der skal findes, og lader værktøjet oprette dem gennem udbyderens API. Til hver udbyder findes en provider, et modul, der oversætter beskrivelsen til netop den udbyders API. Værktøjet holder styr på, hvad der er oprettet, i en tilstandsfil. Det gør det muligt at bygge et miljø op igen, men beskrivelsen er skrevet til én udbyders ressourcer, og ved et skifte skal den skrives om til den nyes.
De to værktøjer efter samme felter, pr. november 2026
Felterne er hentet fra projekternes egne licensfiler og sider, læst 8. november 2026. Rækkefølgen er ikke en rangering.
Terraform.
- Ejer: HashiCorp, som IBM afsluttede købet af 27. februar 2025 ifølge IBM’s egen meddelelse.
- Licens: Business Source License 1.1, med International Business Machines Corporation som licensgiver, gældende for “Terraform Version 1.6.0 or later”. Brug i produktion er tilladt, så længe brugen ikke omfatter at tilbyde værket til tredjeparter i konkurrence med IBM’s betalte udgaver. Hver udgave overgår til den åbne licens MPL 2.0 fire år efter udgivelsen.
- Gengivelsen er en forenkling af licensteksten. Hvordan den rammer netop jeres brug, afgøres af ordlyden og er et spørgsmål til advokat, hvis I er i tvivl, især hvis I selv leverer drift til kunder.
OpenTofu.
- Ejer: et projekt under Linux Foundation, startet som en fork af Terraform som reaktion på licensskiftet.
- Licens: MPL 2.0.
- Overgang: OpenTofu kan ifølge projektet bruge tilstandsfiler fra Terraform op til udgave 1.5.x. Projektets svar om Terraforms licens står i dets egen FAQ og er et partsindlæg.
Fælles. Begge bruger providers til de enkelte udbydere. Hvilke europæiske cloududbydere der vedligeholder providers til OpenTofu, og om de er de samme som til Terraform, er ikke undersøgt her. Det er det første, I skal spørge en ny udbyder om.
Licensskiftet som eksempel på en afhængighed
Skiftet viser, at et værktøj, der bruges til at gøre infrastrukturen flytbar, selv kan ændre vilkår. For de fleste brugere ændrer det lidt i praksis, fordi brug i egen drift efter ordlyden er tilladt. Det viser til gengæld, at hver del af kæden har en ejer, og at ejeren kan skifte. Samme vurdering gælder for de øvrige værktøjer i byggekæden, se Kildekode og byggekæde.
Det, der binder i selve koden
Skiftet mellem Terraform og OpenTofu er det lille spørgsmål. Det store er, at koden beskriver én udbyders ressourcer. En virtuel server, et netværk og en load balancer hedder noget forskelligt og har forskellige felter hos hver udbyder, og koden skal skrives om pr. ressource. Et lag af egne moduler med neutrale navne kan gøre skiftet mindre, fordi kun modulernes indre skal ændres.
Tre ting gør flytningen lettere, uanset værktøj:
- Moduler med jeres egne navne · applikationsteams kalder “database” og “netværk” og kender ikke udbyderens egne ressourcenavne.
- Tilstanden et sted, I ejer · tilstandsfilen bør ligge i et lager, I selv styrer, uafhængigt af den udbyder, I måske forlader.
- Låste versioner · både af værktøjet og af hver provider, så et skifte sker, når I vælger det.
Når I vælger mellem de to
Står I med Terraform i dag, er der intet, der tvinger et skifte. Spørgsmålene er, om licensen passer til jeres brug, om I ønsker et værktøj med en åben licens og en fondsejer, og om de providers, I har brug for, findes til OpenTofu i samme stand. Bruger I en udgave efter 1.5.x, skal I se på, hvordan tilstanden kan føres over, før I skifter.
Står I foran en flytning til en europæisk udbyder, er det et naturligt tidspunkt at tage beslutningen, fordi koden alligevel skal skrives om til den nye udbyders ressourcer.
Hvad det kræver, og hvad det koster at lade være
At gennemgå licens og providers for jeres egen brug tager en til to dage. Et skifte af værktøj for et mindre kodegrundlag med få moduler kan klares på nogle dage; med mange moduler, flere miljøer og en tilstand fra en nyere Terraform-udgave skal der regnes i uger. Omskrivningen til en ny udbyders ressourcer er den største post og hører under selve flytningen.
Lader I spørgsmålet ligge, er risikoen lav på kort sigt. Over tid bliver koden mere bundet til det valgte værktøj og den valgte udbyder, og jo længere I venter, jo mere skal skrives om på én gang.
Det skal I lade være med
- At antage, at koden flytter med til en ny udbyder · ressourcerne skal skrives om.
- At skifte værktøj midt i en flytning · tag én ændring ad gangen.
- At lade tilstandsfilen ligge hos den udbyder, I forlader · flyt den til et lager, I selv ejer.
Det skal valget kunne vise
- ☐ Hvilket værktøj og hvilken udgave I bruger, og under hvilken licens.
- ☐ Om de nødvendige providers findes hos den nye udbyder til det valgte værktøj.
- ☐ Hvor tilstanden ligger, og hvem der ejer lageret.
- ☐ En vurdering af licensen mod jeres egen brug, skrevet ned.
Kilder
- Terraforms licensfil, læst 8. november 2026.
- IBM Newsroom, IBM Completes Acquisition of HashiCorp, 27. februar 2025, læst 8. november 2026.
- OpenTofu, OpenTofu FAQ og OpenTofus licensfil, læst 8. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find den udgave af værktøjet, I kører i dag, og listen over providers. Spørg derefter den nye udbyder, hvilke af dem der findes og vedligeholdes.
Læs også: AWS- og Azure-tjenester oversat til europæiske byggesten · Også den europæiske udbyder skal kunne forlades
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
