Terraform mu OpenTofu mu: lisans meselesi ve gerçek teknik farklar

Terraform yazan bir ekip için 2023 sonrası dünya iki dallı. Elinizdeki HCL dosyaları neredeyse aynı kalıyor, ama onları çalıştıran ikili dosyanın lisansı, sağlayıcıları çektiği kayıt defteri ve sahip olduğu dil özellikleri ayrışmış durumda. Karar çoğu yerde "hangisi teknik olarak daha iyi" sorusundan değil, "hukuk tarafı BUSL metnini okuyunca ne diyecek" ve "beklediğimiz üç özellik hangi tarafta var" sorularından çıkıyor. Aşağısı o kararı verirken bakılması gereken somut ayrım noktaları.

Lisans olayının aslı

10 Ağustos 2023'te HashiCorp, Terraform dahil ürün portföyünü Mozilla Public License 2.0'dan Business Source License 1.1'e taşıdı. Terraform 1.5.x son MPL sürümü oldu, 1.6.0 ilk BUSL sürümü.

BUSL bir açık kaynak lisansı değil, kaynağı görünür bir ticari lisans. İki ayağı var. Birincisi Change Date: her sürüm yayımlandıktan dört yıl sonra otomatik olarak MPL 2.0'a dönüyor. İkincisi Additional Use Grant: üretim kullanımı serbest, ancak yazılımı üçüncü taraflara barındırarak ya da gömerek lisans sahibinin ticari ürünleriyle rekabet eden bir teklif sunamıyorsunuz.

Pratikte bu, kendi bulut altyapısını Terraform ile yöneten sıradan bir şirketi doğrudan kısıtlamadı. Isırdığı yer başkaydı: IaC platformu satan şirketler, yönetilen hizmet sağlayıcılar, müşteri hesaplarında Terraform çalıştıran danışmanlıklar. Bir de ölçülmesi zor bir belirsizlik maliyeti çıktı. "Rekabet eden teklif" bir sözleşme ifadesi, teknik bir tanım değil; uyum ekipleri böyle bir ifadenin altına imza atmak yerine riski sıfırlamayı tercih ediyor. İç platform ekiplerinin yıllardır yaptığı iş, yani Terraform'u sarmalayan bir self servis arayüz yazmak, bir anda hukuk incelemesi gerektiren bir konu hâline geldi.

İkinci darbe kayıt defteri tarafından geldi. Terraform Registry kullanım şartlarına, indirilen sağlayıcı ve modüllerin yalnızca Terraform ile ya da Terraform'u desteklemek amacıyla kullanılabileceği eklendi. Bu, ayrışmayı yalnız kod tarafında değil dağıtım tarafında da zorunlu kıldı.

Çatalın kurumsallaşması

Tepki önce bir manifesto olarak toplandı, sonra OpenTF adıyla kod hâline geldi ve Eylül 2023'te Linux Foundation çatısına OpenTofu adıyla girdi. Kod tabanı Terraform 1.5.x'ten çatallandı ve MPL 2.0 altında kaldı. İlk kararlı sürüm 1.6, 10 Ocak 2024'te yayımlandı.

Vakıf altına girmenin doğrudan teknik bir karşılığı yok, ama satın alma kararında teknik maddelerden ağır basıyor: projeyi tek bir şirketin ticari kararıyla yeniden lisanslama ihtimali yapısal olarak kapanıyor. HashiCorp tarafında ise sahiplik değişti; IBM satın almayı 27 Şubat 2025'te kapattı.

İki alet bugün nerede

Terraform 1.15 29 Nisan 2026'da, OpenTofu 1.12 14 Mayıs 2026'da çıktı; OpenTofu 1.13 beta aşamasında. Sürüm numaraları benzer görünse de takvimler bağımsız ve özellik listeleri birbirinden ayrı ilerliyor.

Gerçekten fark yaratan CLI özellikleri

Durum dosyası şifreleme

Terraform CLI durum dosyasını düz metin JSON olarak yazar. Backend tarafında diskte şifreleme (örneğin S3 sunucu tarafı şifreleme) deponuzu korur, dosyanın kendisini değil. terraform state pull çıktısı, CI günlüğüne düşen bir plan dosyası, geliştirici makinesindeki yerel çalışma dizini hâlâ açık metindir. Veri tabanı parolası ya da özel anahtar üreten her kaynakta bu gerçek bir sızıntı yüzeyi.

OpenTofu 1.7 (Nisan 2024) şifrelemeyi dilin içine aldı:

terraform {
  encryption {
    key_provider "pbkdf2" "passphrase" {
      passphrase = var.state_passphrase
    }

    method "aes_gcm" "default" {
      keys = key_provider.pbkdf2.passphrase
    }

    state {
      method   = method.aes_gcm.default
      enforced = true
    }

    plan {
      method   = method.aes_gcm.default
      enforced = true
    }
  }
}

Parola sağlayıcısı yerel geliştirme için makul; üretimde AWS KMS, GCP KMS ya da OpenBao anahtar sağlayıcıları kullanılır. enforced = true yanlışlıkla şifresiz yazmayı engeller, fallback bloğu ise anahtar rotasyonu sırasında eski anahtarla çözüp yeni anahtarla yazmayı mümkün kılar.

Erken değişken değerlendirme

Backend yapılandırmasında, modül kaynağında ve şifreleme bloğunda değişken kullanamamak, sarmalayıcı betiklerin doğduğu yerdir: ortam başına backend.tf üreten şablon motorları, CI adımında sed ile dosya değiştiren hileler. OpenTofu 1.8 bu blokları, kaynaklara ve veri kaynaklarına bağlı olmadıkları sürece değişkenlerle ve yerel değerlerle beslenebilir hâle getirdi. Terraform 1.15, modül source ve version alanlarında değişkene izin vererek farkı daralttı; backend ve şifreleme yapılandırması tarafında ayrım duruyor.

Sağlayıcı for_each

Çok bölgeli ya da çok hesaplı kurulumlarda bölge başına elle sağlayıcı bloğu yazmak eski bir dert. OpenTofu 1.9 bunu çözdü:

variable "regions" {
  type = map(object({
    cidr = string
  }))
}

provider "aws" {
  alias    = "by_region"
  for_each = var.regions
  region   = each.key
}

resource "aws_vpc" "main" {
  for_each   = var.regions
  provider   = aws.by_region[each.key]
  cidr_block = each.value.cidr
}

Kısıtları bilerek dar tutulmuş: sağlayıcının alias alması zorunlu, for_each ifadesi statik olarak çözülebilmeli (kaynak veya veri kaynağı çıktısı kullanılamaz), kaynağın for_each ifadesi sağlayıcınınkiyle aynı olmamalı. Terraform tarafında eşdeğeri yok.

exclude

-target yıllardır var, tersi yoktu. OpenTofu 1.9 ile -exclude, 1.10 ile -target-file ve -exclude-file geldi. Yüzlerce kaynaklı bir yığında tek bir sorunlu kaynağı dışarıda bırakıp geri kalanını uygulamak, elle -target listesi yazmaya göre bambaşka bir iş. Terraform tarafında bu hâlâ açık bir istek.

Diğerleri

OpenTofu 1.10 ile OCI kayıt defterlerinden sağlayıcı aynası (hava boşluklu ortamlar için değerli), DynamoDB tablosu gerektirmeyen yerel S3 durum kilitleme ve OpenTelemetry izleri geldi. 1.11 enabled meta-argümanını ekledi; count = var.enabled ? 1 : 0 kalıbının okunabilir hâli. 1.12 ise prevent_destroy değerinin değişkenden gelmesine izin verdi, yani aynı modül üretim ve test ortamında farklı korumayla kullanılabiliyor.

Akış ters yönde de var. Geçici (ephemeral) kaynaklar ve yalnız yazılabilir argümanlar önce Terraform tarafında çıktı, OpenTofu'ya 1.11 ile (Aralık 2025) geldi. Terraform 1.14'ün getirdiği liste kaynakları (.tfquery.hcl dosyaları ve terraform query) ile eylem blokları şu an OpenTofu'da yok. Stacks, Sentinel politikaları ve HCP tarafındaki her şey ise zaten çatalın konusu değil.

Ekosistem gerçekte ne kadar bölündü

Beklenenden çok daha az. Sağlayıcılar ve SDK'lar MPL 2.0 altında kaldı, lisans değişikliği yalnızca ürünlerin kendisini kapsadı. OpenTofu kendi kayıt defterini işletiyor ama aynı yukarı akış depolarından besleniyor; hashicorp/aws gibi kısa adresler doğrudan çözülüyor. Modül tarafında bağımlılık zaten zayıf, çünkü modül kaynağı git, https ya da nesne deposu olabiliyor.

Kırılma ihtimali dar bir noktada toplanıyor: yalnızca tek bir kayıt defterine yayımlanan niş satıcı sağlayıcıları. Geçişten önce terraform providers çıktısındaki her adresi karşı kayıt defterinde aratmak beş dakikalık bir iş ve sürprizi baştan bitiriyor.

Geçiş ve kırılacak yerler

Tipik bir yığında geçiş bir öğleden sonra sürer:

terraform state pull > state-backup.json
cp .terraform.lock.hcl lock-backup.hcl

tofu init -upgrade
tofu providers lock -platform=linux_amd64 -platform=darwin_arm64
tofu plan -detailed-exitcode

Aranan sonuç, plan çıktısında sıfır değişiklik. Fark çıkıyorsa sağlayıcı sürümü kaymıştır; sorun geçişte değil, sürüm kısıtlarınızdadır.

Başa gelecek somut sorunlar:

1. Kilit dosyası. .terraform.lock.hcl sağlayıcı adreslerini kayıt defteri ana makine adıyla birlikte tutar ve sağlama toplamları iki kayıt defteri arasında farklı olabilir. -upgrade olmadan ilk init sağlama toplamı uyuşmazlığıyla düşer. CI birden fazla mimaride koşuyorsa providers lock komutuna kullandığınız tüm platformları verin, yoksa hata sizi ilk boru hattında bulur.
2. Durum meta verisi tek yönlü bir kapı. İlk apply durum dosyasına kendi sürüm bilgisini yazar; sonrasında eski araca dönmek "daha yeni bir sürümle oluşturulmuş" hatası verir. Geri dönüş planınız yedek dosyayı geri yüklemek olmalı, "eski ikiliyi çalıştırırız" değil.
3. Şifrelemeyi ilk gün açmayın. Şifreli durumu diğer araç okuyamaz; geçişi doğrulamadan bu kapıyı kapatmak geri dönüş seçeneğini de kapatır. Önce geçiş, birkaç başarılı uygulamadan sonra şifreleme.
4. terraform_remote_state ile birbirine bağlı yığınlar. Kademeli geçişte henüz taşınmamış bir yığın, taşınmış bir yığının durumunu okumaya devam eder; şifreleme açıldığı anda o okuma kırılır. Bağımlılık yönünü çıkarın, yaprakları önce taşıyın.
5. Araç zinciri. İkili dosyanın adı değişiyor; sarmalayıcı betikler, pre-commit kancaları, orkestrasyon araçları ve CI şablonları tek tek gözden geçirilmeli. .tf uzantısı çalışmaya devam eder; .tofu isteğe bağlıdır ve karşı araç bu dosyaları görmez, ki bazen tam olarak istenen budur.
6. Sürüm kısıtları. Modüllerdeki required_version ifadeleri, hangi aracı çalıştırıyorsanız onun sürüm numarasına göre değerlendirilir. Terraform 1.14 isteyen bir topluluk modülü OpenTofu 1.12 altında reddedilir; kısıtın gerçekten gerekli olup olmadığına bakmak gerekir.

Hangisi, ne zaman

CLI'yi kendiniz çalıştırıyorsanız varsayılan OpenTofu olmalı. Gerekçe üç maddede toplanıyor: lisans belirsizliği tamamen ortadan kalkıyor, özellik hızı en az eşit ve durum şifrelemesi gibi noktalarda açık ara önde, geçiş maliyeti ise bir öğleden sonra. Buna karşılık "ne olur ne olmaz, resmî olanda kalalım" tercihi ölçülebilir hiçbir teknik fayda üretmiyor.

Terraform'da kalmanın savunulabilir olduğu durumlar da net. HCP Terraform ya da Terraform Enterprise'a, Sentinel politikalarına veya Stacks'e bağlıysanız çatal sizin probleminizi çözmüyor, sadece CLI katmanını değiştiriyor. Tek elden kurumsal destek sözleşmesi satın alma sürecinizin şartıysa, OpenTofu tarafında bunun karşılığı ticari platform satıcılarından gelir, projenin kendisinden değil. Liste kaynakları ve eylem blokları gibi yeni yeteneklere bugün ihtiyacınız varsa beklemek yerine kalmak mantıklı.

Yapmayın dediğim tek şey ikisini birden desteklemeye çalışmak. "Sarmalayıcı hangisi kuruluysa onu çağırsın" kurgusu kilit dosyasında ve durum meta verisinde sürekli çatışma üretir; iki aracın sağlama toplamlarını aynı depoda tutmaya çalışan ekipler bunu genelde ikinci haftada anlar.

Dört yıllık Change Date sayesinde BUSL altında çıkan her Terraform sürümü sırası geldiğinde MPL 2.0'a dönecek. Ama o tarih geldiğinde elinizde dört yıl öncesinin kodu olacak, bugünkü sorunuzun cevabı değil.