▲

Liquibase, 라이선스 변경 후에도 "오픈 소스"로 계속 홍보

 (github.com/liquibase)
1P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • Liquibase가 기존 오픈 소스 라이선스에서 Functional Source License(FSL) 로 전환함
  • FSL은 오픈 소스 이니셔티브(OSI) 기준상 공식 오픈 소스 라이선스가 아님에도, README 등에서 여전히 오픈 소스 프로젝트로 소개되는 문제 제기임
  • 커뮤니티에서는 FSL이 공식 오픈 소스 기준을 위배한다는 의견과, FSL이 오픈 소스 요건을 충족한다는 상반된 의견이 제시됨
  • 프로젝트 내에서는 README에서의 오픈 소스 언급은 수정 작업이 진행 중임
  • FSL이 경쟁적 사용을 제한하는 조항 등으로 인해 OSI Open Source Definition(오픈 소스 정의) 의 일부 조항에 저촉된다는 지적임

이슈 개요

  • Liquibase 프로젝트의 라이선스가 최근 Functional Source License(FSL) 로 변경됨
  • 하지만 README.md 등 공식 문서에서 여전히 Liquibase를 오픈 소스 프로젝트로 소개하고 있어 커뮤니티 내에서 혼란과 이견이 발생함

보고 내용 및 논란

  • 이슈 작성자는 Liquibase가 FSL로 전환했음에도 불구하고 여전히 오픈 소스임을 명시하는 점이 문제임을 지적함
  • FSL은 Liquibase 스스로도 오픈 소스 라이선스가 아니라고 언급한 바 있음
  • 프로젝트 문서에서 오픈 소스란 용어가 더 이상 사용되지 않도록 README 및 기타 문서 수정이 요구됨

커뮤니티 및 관련 인사 의견

  • 일부 참가자는 FSL이 OSI 승인 오픈 소스 라이선스의 기준을 충족한다고 주장하며, FSL이 정식 리뷰를 거쳐 OSI 승인 라이선스가 되면 문제가 없다는 입장임
  • 이와 달리, 다른 참가자들은 FSL 내 “허용 목적” 조항 등으로 인해 OSI의 오픈 소스 정의의 여러 조항(1, 3, 5, 6항)에 위배됨을 강조함
  • “Fair Source”와 “진짜 오픈 소스”의 구분을 강조하며, FSL은 Fair Source로 분류되어야 한다는 의견도 있음

이슈 해결 과정 및 문서 수정

  • 프로젝트의 기여자가 문제 제기에 대응해 README.md를 수정하고, 오픈 소스 언급을 점진적으로 제거하고 있음
  • 하지만 저장소 곳곳에 여전히 몇몇 ‘open source’, ‘oss’ 표현이 남아 있어 추가 검토와 정리가 이뤄질 예정임

오픈 소스 정의와 FSL(Functional Source License) 문제

  • Richard Fontana 등 오픈 소스 진영의 대표 인사는 FSL이 경쟁적 사용 금지 등 조항으로 OSI 오픈 소스 정의를 위반함을 명확히 함
  • 오픈 소스 정의는 “분야 및 개인, 단체 차별 금지” 등 조항이 존재하며, 경쟁적 용도 금지 등은 이에 반함
  • FSL은 2년 후에 MIT 또는 Apache License로 전환되어 완전한 오픈 소스가 될 예정이나, 그 전까지는 제한적 조건이 남아있음

결론 및 현재 상황

  • 해당 이슈는 Liquibase의 오픈 소스 표기 수정 과정에 있어 커뮤니티의 투명성 요구와 오픈 소스의 본질에 대한 논의를 촉진함
  • README 등 공식 문서의 수정 작업이 개시되었으며, Fair Source와 오픈 소스의 구분 기준이 실제 사례로 논의됨
  • OSI 승인 여부와 관계 없이, 라이선스의 실제 조건이 국제 오픈 소스 커뮤니티에서 상당한 의미를 가지는 상황임
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 4.x 버전을 더 이상 쓸 수 없을 경우를 대비해 대안을 찾는 작업을 시작함
    OSS 라이선스에서 유료화로의 전환은 누군가가 유용한 소프트웨어로 수익을 내고자 하는 것에 대해 이해함
    하지만 오픈소스에서 라이선스를 바꾸는 것은 일종의 미끼상품 전환 전술이라 생각함
    이런 결정은 곧바로 신뢰를 무너뜨리고, 당장 수익화가 어렵지만 장기적으로 가능성 있는 사용자층도 잃게 됨
    Elastic과 TerraForm 사례에서 이미 중요한 교훈을 얻었을 거라 기대했음
    Flyway도 언제든 비슷한 길을 갈 수 있기에 신뢰가 떨어진 느낌임
    포크가 나오지 않는다면 우리 실사용에 맞는 migration 라이브러리를 아예 직접 만드는 것도 고려 중임
    Liquibase는 그저 편리해서 쓴 것이지 절대 대체 불가한 건 아님

    • EventstoreDB(지금은 KurrentDB)와 NATS도 서비스 신뢰성에서 의심받는다고 봄
      EventstoreDB는 이미 라이선스를 바꿨고, NATS도 사용자 반발 때문에 계획만 접음
      이제는 이런 행보가 일종의 비즈니스 전략이 되어버린 느낌임

    • 오픈소스의 가장 큰 장점은 이전 버전을 언제든 포크해서 쓸 수 있다는 점임
      제품 가격을 올리는 것과 본질적으로 다를 게 없는 전환이라고 봄

    • Postgres 전용이긴 하지만 자동화를 한 단계 더 발전시킨 pgroll이라는 프로젝트도 있음

    • Flyway(Apache 라이선스) 외에도 Atlas(Apache), Sqitch(MIT)처럼 아직 오픈소스인 라이선스도 충분히 있음

    • Elastic의 라이선스 변경이 정말 그들 관점에서 실패였나 궁금함
      주가가 한동안은 떨어졌지만, 실제 회사는 여전히 건재한 상태임
      내가 아는 검색과 RAG 분야 개발자 모두 여전히 Elastic NV가 제공하는 Elasticsearch만 사용 중임(오픈소스 포크나 대안 X)
      특히 Elastic이 가장 중요시하는 주요 고객군(유료 고객)만 보면, 오히려 신뢰 파괴가 아니라 역효과가 발생한 듯함
      실제 매출도 2020년 대비 두 배로 성장함

  • 아직 오픈소스라고 주장하는 의견이 있지만, Liquibase에서는 직접 FSL이 오픈소스 라이선스가 아니라고 밝힘
    Liquibase 공식 블로그 공지 참고

    • 이 변화가 한 달도 채 안 됐기에 아직 README에 제대로 반영되지 않은 걸 수도 있다고 생각함
      최근에 소스만 공개하면서 오픈소스인 척 브랜딩하는 프로젝트가 많은 게 아쉬움

  • Liquibase가 강한 copyleft(예: GNU AGPL)가 아닌 Apache를 택했으면 당연히 타사가 폐쇄형 소스 파생물을 만드는 걸 예상했어야 함
    결국 Liquibase 스스로 선택한 일이기에 그 책임도 Liquibase에게 있다고 생각함

    • 일정 기간 후에 Apache로 자동 전환되는 구조로 보임
      이게 더 나은 건지, 아닌 건지는 잘 모르겠음

    • 기업들은 사실 AGPL 같은 라이선스로도 충분히 자사 목표를 이룰 수 있음
      Redis도 전환했고 커뮤니티 반응도 긍정적이었음
      Liquibase가 AGPL 듀얼 라이선스를 택한다고 해서 사용자들이 불만 가질 것 같진 않음

  • "2년 딜레이 오픈소스" 혹은 "2년 후 오픈소스"라고 불러야 할 것 같음
    실제로는 "쓸모 없을 때쯤 오픈소스"라 생각함
    이런 식이면 진정한 자유를 존중한다는 이미지만 주고 실제로는 그렇지 않은 게 본질이라 생각함

    • 그 정도로 빨리 구 버전이 무용지물이 되는 것도 드묾
      이것이 내 자유에 대한 존중 부족이라고 보지 않음
      목표는 기업(사람이 아님)에 일부 제한을 거는 데 있음

    • 엔터프라이즈 분야에서 오픈소스의 핵심은 '자유'보다는 신뢰와 투명성이라 생각함
      소스 공개만 해도 법적/수익화 문제 없이 FOSS의 이점은 누릴 수 있음
      온라인에서는 오픈소스 모델에 대한 맹목적인 신뢰가 지나치게 나타나는 경향이 있음
      2년 혼용 정책도 충분히 합리적이라 생각하며, 새로운 라이선스를 원치 않으면 구버전 쓰면 됨

    • 딜레이된 오픈소스, 영어의 'late'처럼 이중적 의미를 담고 있음

    • #source-washing

  • 새 라이선스에 익숙하지 않았다면 FSL 상세 설명 링크 참고

    • FSL 관련 추가 맥락 제공: Sentry가 만든 것으로, 왜 이 라이선스가 필요했고 어떤 문제를 해결하려 했는지 Sentry 블로그에서 확인 가능

    • 개인적으로 유일하게 허용할 만한 폐쇄형 소스 라이선스는 BuSL "Business Source License"임
      유효기간 4년 후 무조건 오픈소스가 되며, 그 전까지는 소스 공개됨
      불필요한 라이선스 난립도 방지함
      Business Source License 위키도 참고하면 좋음

    • 2년이라는 기간이 너무 짧은 건 아닌지 의문임
      큰 기업 입장에서는 5년 된 소프트웨어도 잘만 쓰고, 나도 Redis 2012년 버전이나 Postgres 2020년 버전도 충분히 괜찮음

  • 이런 케이스들의 히스토리와 기업 리스트를 정리한 적 있음
    관련 블로그 포스팅에 정리해두었으니 추가로 더 알면 공유 부탁함

  • 프로 기능이 커뮤니티 버전의 문법을 자꾸 깨서 투명성은 전혀 없다고 느꼈음
    물론 작업에 대한 정당한 보상이 필요하긴 한데, "우린 오픈소스였다가 슬쩍 아니게 됨"은 너무 흔해지고 있음
    이런 전환은 아무도 눈치채지 않길 바라는 마음에서 항상 조용히 진행되는 듯함

    • 실제로 FSL은 평범한 개발자 입장에서 일상 흐름에 큰 영향 없음
      실질적인 피해나 주된 문제가 뭔지 궁금함
      오히려 경쟁 분야와 비경쟁 분야의 구분이 마음에 듦

  • 댓글 분위기가 조금 이상하게 느껴짐
    대부분 "base"만 보고 아무 상관 없는 서비스 추천하거나, 소스 공개만 했으면 오픈소스라고 주장하는 분위기임

  • Liquibase가 라이선스를 변경한 줄 몰랐었음
    사실 거의 모든 웹 프레임워크에 대안이 있고, Alembic과 Flyway 처럼 프레임워크 독립적인 대안도 많음
    이 시점엔 좀 이상해 보임

  • 이번 이슈가 Keycloak 같은 OSS 프로젝트에도 문제를 일으킬 수 있음
    CNCF 정책상 비오픈소스 라이선스는 사용할 수 없으므로, Keycloak이 Liquibase를 쓸 수 없음
    Debian, Fedora 등에서도 OSS 라이선스 조건이 있기 때문에 이런 배포판에서 Liquibase 의존 프로젝트가 포함될 수 있을지 궁금함
    Keycloak 이슈 상세 링크

    • Liquibase가 Debian, Fedora의 메인 레포에는 포함될 수 없음
      하지만 개별 저장소나 rpm fusion non-free처럼 커스텀 레포에서는 포함 가능함
답변달기