Homebrew, HashiCorp에 대해 경고 추가 및 폐기 예정

 (github.com/Homebrew)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Homebrew/homebrew-core PR #139538은 HashiCorp의 라이선스 변경 때문에 terraform formula에 사용자 경고를 추가하고 언젠가 비활성화할 수 있음을 알리는 변경임
  • 변경 이유는 라이선스 변경 이후 homebrew-core에서 terraform의 버전 업데이트가 더 이상 없을 것이라는 점이며, 사용자가 이를 설치 시 인지하도록 하는 데 초점이 있음
  • 검토 과정에서 1.6.0 이전의 향후 릴리스는 수용 가능할 수 있지만, 그런 릴리스가 없을 가능성도 있다는 버전 예외가 논의됨
  • PR은 의존성 정리 후 2024년 4월 4일 다시 리뷰 준비 상태가 됐고, 미래 시제 문구를 제거하라는 피드백을 반영해 terraform: deprecate and add caveat 커밋으로 갱신됨
  • 최종 변경은 2024년 4월 5일 merge queue를 통해 Homebrew master에 커밋 4782218 로 병합됐으며, 관련 terraform 폐기 PR #168090도 병합됨

terraform formula 폐기와 경고 추가

  • PR #139538의 목적은 HashiCorp의 라이선스 변경으로 인해 homebrew-core에서 terraform 버전 업데이트가 더 이상 이뤄지지 않는 상황을 사용자에게 알리는 것임
  • 최초 설명은 “언젠가 이 formula를 비활성화할 수 있음”을 사용자에게 알리는 방향이었음
  • 변경 대상은 Formula/terraform.rb였고, 이후 파일 경로는 Formula/t/terraform.rb로 표시됨
  • PR에는 formula deprecated, busl-license, go, maintainer feedback 등의 라벨이 붙음

버전과 라이선스 관련 논의

  • 검토 중 terraform의 향후 릴리스 중 1.6.0 이전 버전은 수용 가능할 수 있다는 의견이 나옴
    • 다만 그런 릴리스가 실제로 없을 가능성도 함께 제시됨
  • PR 설명은 라이선스 변경 이후 homebrew-core에서 더 이상 버전 업데이트가 없다는 점을 변경의 근거로 삼음
  • 이후 커밋 메시지는 “라이선스 변경 때문에 homebrew-core에서 더 이상 버전 업데이트가 없으므로 언젠가 이 formula를 비활성화할 것”이라는 취지를 담음

리뷰와 변경 반영 흐름

  • 2023년 8월 14일 PR이 열렸고, 여러 maintainer가 Formula/terraform.rb 변경을 리뷰함
  • 2023년 9월 6일에는 리뷰 피드백 반영을 요청하는 ping이 있었고, 작성자는 반영 완료를 알림
  • 2023년 9월 7일 MikeMcQuaid가 변경을 승인했으나, merge queue에서 상태 검사 실패로 제거됨
  • 2023년 9월 20일 chenrui333도 변경을 승인함
  • 2024년 2월 23일 PR은 draft로 표시됨

의존성 정리와 관련 PR

  • 2024년 3월 13일에는 cdktf: deprecate 커밋이 이 PR을 참조함
    • 해당 커밋 메시지는 cdktf가 곧 폐기될 terraform을 사용한다고 밝힘
    • terraform 폐기를 막는 마지막 formula 중 하나라고 설명함
    • cdktf는 월 700회 이상 다운로드되며, HashiCorp GitHub org에 호스팅되어 있어도 BUSL 라이선스 변경의 영향을 받지 않는다고 적음
  • 관련 PR로 cdktf: deprecate #166001이 병합됨
  • 2024년 4월 3일에는 atlantis: vendor terraform #167948이 이 PR을 참조했고 병합됨

최종 정리와 병합

  • 2024년 4월 4일 작성자는 “모든 의존성을 처리했으므로 이제 괜찮다”고 알리고 PR을 review ready로 전환함
  • p-linnane은 이미 해당 상황이 발생했으므로 미래 시제 표현을 제거할 수 있다고 피드백함
  • 작성자는 이를 반영했고, terraform: deprecate and add caveat 커밋 1c7b99b로 브랜치를 갱신함
  • p-linnane, MikeMcQuaid, chenrui333이 최종 변경을 승인함
  • 2024년 4월 5일 PR은 merge queue를 통해 Homebrew master에 커밋 4782218로 병합됨
  • 같은 날 terraform: deprecate and add caveat #168090도 병합된 PR로 참조됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 의존 패키지를 바로 폐기하지 않고 대체품으로 바꿀 수 있는지 보려고 보류 중이라는 점이 중요함
    예를 들어 Terraform에 의존하는 프로그램은 OpenTofu를 대체품으로 쓸 수 있을 가능성이 큼
    아쉽게도 Vault, Consul, Nomad에는 오픈소스 대안이 나올 것 같지 않음. 특히 Nomad는 HashiCorp가 투자를 멈추기 전까지 좋은 제품이었는데, 이제 비공개 소스가 된 이상 채택될 가능성은 거의 없어 보여서 웃기기까지 함

    • 누군가 Vault 공개 포크를 시작한다면 시간이 나는 대로 기여하고 싶음
      추가: https://github.com/hashicorp/vault/graphs/contributors?from=...
    • Nomad를 꽤 좋아함. k3s보다도 더 가볍고, 내 저예산 프로젝트들에 아주 잘 맞았음
      이렇게 흘러가는 걸 보니 조금 아쉬움
    • Nomad는 세상 모든 걸 실행하려는 목표가 너무 과했음. 결국 널리 자리 잡지 못했고, 설정하려면 Consul도 필요했음
      Docker Swarm은 Nomad보다 단순하고 더 나은 해법이며 Docker Engine 자체에 내장되어 있음
    • 솔직히 HashiCorp 제품들은 전반적으로 정말 좋음. 다만 너무 빨리 움직이는 증후군을 겪었다고 봄
      상장을 밀어붙였고, 최근의 결함 대부분은 주가를 올리려는 시도까지 거슬러 올라갈 수 있음
      초기 HashiCorp는 대단했음. 오픈소스의 수호자였고, 떠오르는 Red Hat이나 Canonical처럼 보였음. 제품들은 획기적이었고 오픈소스 생태계에 엄청난 가치를 더했음. 하지만 Terraform이 크게 뜨면서 다른 제품에도 관심을 끌었고, 회사가 너무 유명해졌음
      상장 이후로는 어떤 대가를 치르더라도 돈과 기업 고객을 얻으려는 모습이 분명해졌음
      Terraform 자체도 버전 1 이후로는 유지보수 모드처럼 느껴짐. Terraform provider는 자주 깨지고, 운영 환경에서는 provider를 패치 버전까지 고정해야 한다고 봄. 최근 몇 년간 작은 패치 업데이트에서도 여러 번 문제가 있었음. HashiCorp에 사업적 가치가 없는 오픈소스 기여는 거절하기 시작한 것으로도 유명함. Terraform이 v1에 도달한 뒤로는 거의 모든 관심이 Terraform Cloud와 Terraform Enterprise로 향한 듯함. HashiConf에서는 모든 발표가 이 제품들을 밀어붙이는 선전처럼 느껴지고, 이제는 그것만 신경 쓰는 것 같음
      Nomad는 한동안 HashiCorp가 매우 기대하던 제품이었지만, 기업 시장 장악을 추구하는 과정에서 길가에 버린 듯함. 아마 대부분의 기업이 Kubernetes에 올인했고 Nomad는 빠르게 움직이는 스타트업에 더 유용하다는 걸 알게 된 뒤였을 것임
      Vault는 특히 오픈소스 영역에서 훌륭한 도구였음. 하지만 지난 몇 년간 Vault의 오픈소스 버전과 라이선스 버전을 크게 갈라놓았고, 오픈소스 버전은 HashiCorp에게 부담처럼 느껴지기 시작했음. 작년에 회사에서 Vault 전환을 진지하게 검토하면서 HashiCorp와 이야기했을 때, 오픈소스 셀프 호스팅 해법을 “진짜 Vault”의 평가판처럼 대했고 실제로도 그렇게 느껴졌음. 설정 중 부딪힌 거의 모든 문제에 대해 “엔터프라이즈 버전에서는 괜찮다”는 식으로 답했음
      전체적으로 제품의 오픈소스 버전을 지원하는 데 필요한 최소한의 노력만 남기고 물러났고, 한동안 완전히 기업 중심 회사였음. 돈을 벌어야 하니 비난만 할 수는 없지만, HashiCorp가 될 수 있었던 모습의 예로 Red Hat과 Canonical을 떠올리지 않을 수 없음
      지금은 자식이 잠재력을 다 발휘하지 못한 걸 지켜보는 부모 같은 기분임. 대부분 탐욕이나 과도한 야망 때문으로 보임. HashiCorp를 생각하면 “화난 게 아니라 실망했을 뿐”이라는 말이 떠오름. OpenTofu가 Terraform의 빈자리를 채워주길 기대함. Vault는 이미 지나쳤고 대형 클라우드 사업자의 비밀 관리 도구를 쓰고 있음. 훨씬 덜 마음에 들지만 더 싸고 덜 복잡함. Nomad 대신 Kubernetes를 쓰는데, 어차피 표준이 되었으니 괜찮음. 나는 잘 지내겠지만 HashiCorp에는 실망했음
    • Nomad가 정말 비공개 소스가 된 건가?

  • HashiCorp는 자체 tap을 유지함
    https://github.com/hashicorp/homebrew-tap
    https://www.hashicorp.com/blog/announcing-hashicorp-homebrew...

  • 왜 그런가? Homebrew는 그냥 패키지 관리자 아닌가? 비자유 라이선스가 HashiCorp 도구 포함을 왜 제한해야 하는지 모르겠음
    아니면 자유 소프트웨어만 포함한다는 정책이 있는 건가
    수정: 실제로 꽤 엄격한 지침이 있음: https://docs.brew.sh/License-Guidelines

    • Homebrew에는 자유 소프트웨어만 포함한다는 정책이 있음 [1]
      “Debian Free Software Guidelines 라이선스를 쓰거나, DFSG의 퍼블릭 도메인 소프트웨어 지침에 따라 퍼블릭 도메인으로 공개된 formula만 homebrew/core에 받는다”
      [1]: https://docs.brew.sh/License-Guidelines
    • Homebrew는 단순한 패키지 관리자만은 아님
      brew라는 소프트웨어, 즉 패키지 관리자이기도 하지만, 기본으로 연결되는 homebrew-core 패키지 저장소이기도 함. 이 패키지 저장소는 신중히 관리되며 오픈소스 라이선스만 받음
      원하는 저장소를 brew로 tap해서 쓰는 건 자유지만, 이 PR은 core 저장소만 다루고 있음
    • 이건 일부만 맞음
      기본적으로 Homebrew는 homebrew/core와 homebrew/casks 두 저장소를 지원, 즉 Homebrew 용어로 tap함
      Core는 자유 소프트웨어만 받고, Homebrew 개발자가 직접 빌드하며 /opt/homebrew 등에 설치됨. Casks는 상용 소프트웨어와 소스 코드가 없는 소프트웨어까지 거의 무엇이든 받음. 이런 소프트웨어는 대개 개발자 쪽에서 직접 내려받아 원하는 위치, 보통 /Applications에 설치됨

  • Homebrew가 제공하는 서비스는 좋아하지만, Terraform은 brew 밖에서 관리하는 편이 나은 예외 사례 중 하나임. 지금은 tf-switch가 가장 인기 있는 선택지라고 봄
    Terraform은 실수로 상태 파일을 업데이트하면 위험할 수 있어서 특정 버전을 고정해야 하는 일이 많음. 물론 1.0 이전 시절보다 Terraform 업데이트가 훨씬 덜 골치 아파진 건 맞음

    • 나는 rtx, 즉 rust asdf https://github.com/jdx/rtx를 씀. 언어들을 한 도구로 설치할 수 있고, direnv 같은 프로젝트 환경 변수도 다룰 수 있음
    • 맞음. 특정 버전 패키지를 설치하고 쉽게 전환할 수 있는 MacPorts 안에서 관리하는 게 가장 좋음
    • 여러 Terraform 버전을 설치하려면 tfenv도 Homebrew에서 쓸 수 있음

  • 대신 cask에 들어가면 됨. 실무적으로는 별로 큰 영향이 없음

    • 맞음. HashiCorp가 Homebrew로 계속 배포하고 싶다면 cask로도 충분히 가능함. 다만 그럴 것 같지는 않음. 이미 지난 몇 년간 서버에서 바이너리를 직접 설치하라고 권장해 왔고, Terraform 설치 문서도 한동안 그런 방식이었음
      더 큰 영향은 여기서 보듯 Terraform에 의존하는 다른 도구들에 있음: https://github.com/Homebrew/homebrew-core/pull/139538#pullre...
      atlantis와 infracost 같은 도구도 Terraform에 의존해서 제거되고 있음. 그래서 그런 작은 도구들의 배포가 조금 더 어려워질 것임. 다행히 그 스레드에서는 OpenTofu가 안정화되면 의존성을 대체품으로 바꾸거나 아예 제거할 수 있도록 보류한다고 되어 있음. 하지만 실제 영향은 이런 주변 도구들에 있다고 봄

  • Homebrew는 정말 유용하지만 이상한 설계 선택도 있음. 왜 새 전용 Python을 설치하는가? 그리고 왜 그 Python이 최신이어야 하는가?
    그런데 각 formula가 Python 버전을 지정해야 해서 실제로는 항상 최신이 되지도 않고, 온갖 버전을 지정한 formula들이 생김. 왜 다른 패키지 관리자처럼 시스템 Python을 쓰지 않는지 모르겠음. 이미 설치된 Python이 너무 많은데 하나 더 필요하지 않음. 특히 뭔가 제대로 동작하게 하려고 pip 패키지를 설치해야 할 때 더 헷갈림

    • 가장 이상한 선택까지 옹호하려는 건 아니지만, 시스템 Python을 쓰면 보통 문제가 더 많아짐. macOS에는 이제 시스템 Python이 없음
      이렇게 쓰면 됨:
      pythonX.Y -m pip install foo
      모호함을 없애려면 별칭을 써도 됨. 업무 프로젝트에는 pyenv와 가상 환경을 쓰면 좋음

  • 정치적인 결정처럼 보임. Homebrew에는 더 이상 업데이트를 받지 않을 패키지가 많이 있지만 폐기되지는 않음

    • 업스트림이 새 버전을 내지 않아서 업데이트되지 않는 formula와, 라이선스가 더 이상 오픈소스가 아니라서 Homebrew에서 새 업데이트를 받을 수 없는 formula는 다름
      Homebrew의 Cask가 아닌 부분은 오픈소스 라이선스를 요구하고, 이 경우는 후자임
    • 패키지가 죽은 것과는 별개임. 업스트림에 없는 업데이트를 Homebrew가 마법처럼 만들어주지 않는다는 건 사용자가 예상할 수 있음
      반면 업데이트는 존재하지만 Homebrew가 법적으로 배포할 수 없어서, 오래되고 취약한 버전을 설치하게 될 수 있다면 사용자에게 경고할 가치가 있음
    • Homebrew Core에는 오픈소스 라이선스, 구체적으로는 Debian Free Software Guidelines와 호환되는 라이선스의 앱만 들어감. GPL, Apache, BSD, MIT 등이 해당함
      https://wiki.debian.org/DFSGLicenses#DFSG-compatible_License...
답변달기