IaC: Terraform, a mudança de licença e o fork OpenTofu

Infraestrutura como Código (IaC) deixou de ser tendência para virar requisito básico de qualquer operação séria de software. Provisionar servidores, redes, bancos e clusters clicando em consoles não escala, não audita e não reproduz. A resposta para isso é descrever a infraestrutura em arquivos versionados, tratados com o mesmo rigor de código de aplicação. O Terraform popularizou esse modelo — e, em 2023, virou também o centro de uma das mudanças de licenciamento mais comentadas do ecossistema, que deu origem ao fork OpenTofu. Vamos aos fundamentos, ao que mudou e às práticas que separam um setup confiável de uma dor de cabeça.

O que é Infraestrutura como Código

IaC é a prática de definir recursos de infraestrutura em arquivos legíveis e versionáveis, em vez de configurá-los manualmente. Três propriedades sustentam a abordagem.

Declarativo. Você descreve o estado desejado ("quero uma VPC, três subnets e um bucket"), não a sequência de comandos para chegar lá. A ferramenta calcula o caminho. Isso reduz a carga cognitiva e torna o resultado previsível.

Idempotente. Aplicar a mesma configuração várias vezes converge sempre para o mesmo resultado. Se o recurso já existe como descrito, nada acontece; se divergiu, a ferramenta corrige a diferença. Não há efeito colateral acumulado por reexecução.

State. Ferramentas como o Terraform mantêm um arquivo de estado que mapeia os recursos do código aos recursos reais no provedor. É esse mapeamento que permite calcular o diff entre o que você declarou e o que existe — e, por isso mesmo, é a peça mais sensível de toda a operação.

resource "aws_s3_bucket" "logs" {
  bucket = "minha-empresa-logs-prod"
}

resource "aws_s3_bucket_versioning" "logs" {
  bucket = aws_s3_bucket.logs.id
  versioning_configuration {
    status = "Enabled"
  }
}

A mudança de licença de 2023

Por anos, o Terraform foi distribuído sob a Mozilla Public License 2.0 (MPL), uma licença open source reconhecida pela OSI. Em agosto de 2023, a HashiCorp anunciou que migraria a maioria de seus produtos — incluindo o Terraform — para a Business Source License (BSL/BUSL) 1.1, uma licença source-available. A mudança valeu para as versões dali em diante; as versões já publicadas sob MPL continuaram sob a licença anterior.

A diferença é importante. Source-available significa que o código continua visível e utilizável para muitos casos, mas com restrições. A BSL, em particular, impede que terceiros usem o software para oferecer um produto concorrente ao da HashiCorp. Na prática, o código deixou de ser open source no sentido estrito da OSI: as liberdades passaram a ter ressalvas comerciais.

Para a maioria dos times que apenas usam o Terraform internamente, o impacto direto é pequeno. A controvérsia veio do ecossistema — fornecedores, mantenedores e empresas que construíam ferramentas em torno do Terraform passaram a operar sob incerteza jurídica.

O fork OpenTofu

A resposta da comunidade foi rápida. Surgiu um fork do último código do Terraform ainda sob MPL, inicialmente chamado de OpenTF e depois renomeado para OpenTofu. O projeto foi doado à Linux Foundation, ganhando governança aberta e neutra em vez de pertencer a uma única empresa.

O OpenTofu nasceu como substituto compatível: a linguagem de configuração HCL, os comandos e o fluxo de trabalho são, em grande parte, intercambiáveis. A migração para versões iniciais costuma ser direta — em muitos casos, trocar o binário terraform pelo tofu:

# antes
terraform init && terraform plan && terraform apply

# depois
tofu init && tofu plan && tofu apply

Com o tempo, os dois projetos seguem caminhos próprios e divergências de funcionalidades tendem a aparecer, então vale acompanhar o roadmap de cada um. A decisão entre Terraform e OpenTofu hoje envolve licenciamento, governança e necessidade de recursos específicos — não há resposta única, mas é uma decisão consciente que todo time deveria tomar.

Boas práticas que valem para os dois

Independentemente da ferramenta escolhida, alguns princípios são inegociáveis em uso de produção.

Remote state. Nunca deixe o arquivo de estado apenas na máquina local. Guarde-o em um backend remoto (S3, GCS, Azure Blob, Terraform/OpenTofu Cloud) com versionamento e locking. O lock evita que duas pessoas apliquem mudanças simultâneas e corrompam o estado.

terraform {
  backend "s3" {
    bucket         = "minha-empresa-tfstate"
    key            = "prod/network.tfstate"
    region         = "sa-east-1"
    dynamodb_table = "tf-locks"
    encrypt        = true
  }
}

Plan antes de apply. O comando plan mostra exatamente o que será criado, alterado ou destruído antes de qualquer ação. Trate-o como o code review da infraestrutura: leia o plano, principalmente as linhas de destruição. Em pipelines, gere o plano, revise e só então aplique o artefato revisado — não rode um apply direto contra produção.

Módulos. Extraia padrões repetidos (uma VPC, um serviço, um banco) em módulos reutilizáveis e parametrizados. Isso reduz duplicação, padroniza configurações entre ambientes e facilita auditoria. Um módulo bem desenhado vira a unidade de composição da sua infraestrutura.

Não commitar state nem secrets. O arquivo de estado pode conter valores sensíveis em texto puro — senhas, chaves, tokens. Ele jamais deve ir para o repositório Git. Inclua *.tfstate* no .gitignore, use o backend remoto com criptografia e injete segredos via gerenciadores dedicados (Vault, Secrets Manager, SSM), nunca hardcoded no .tf.

*.tfstate
*.tfstate.*
.terraform/
*.tfvars

Conclusão

IaC é, antes de tudo, disciplina: declarar o estado desejado, confiar na idempotência e tratar o state como ativo crítico. O episódio da mudança de licença em 2023 e o nascimento do OpenTofu sob a Linux Foundation mostraram que governança e licenciamento são parte do risco de engenharia, não só uma nota de rodapé jurídica. Escolha a ferramenta conscientemente, mas aplique as boas práticas em qualquer uma delas — é isso que mantém a infraestrutura previsível, auditável e reproduzível.