▲

Bear가 이제 소스 공개 라이선스로 전환됨

 (herman.bearblog.dev)
5P by GN⁺ 21시간전 | ★ favorite | 댓글 3개
  • Bear 프로젝트가 MIT 라이선스에서 Elastic License로 전환됨
  • 이전 MIT 라이선스는 코드의 자유로운 사용과 포크를 허용했지만, 새로운 라이선스는 이를 호스팅 서비스 제공에 제한함
  • 여러 오픈소스 프로젝트들도 무료 경쟁 방지를 위해 유사한 라이선스 변경을 도입하는 추세임
  • 인공지능 시대에는 코드 복제 및 서비스화가 매우 쉬워진 상황임
  • 코드의 공개성도 중요하지만, 사용자 커뮤니티와 지속적인 운영 의지가 Bear의 핵심임

Bear 소스 공개 라이선스 전환 배경

  • Bear 프로젝트는 초기에 MIT 라이선스로 소스를 공개하며, 학습 및 감사 가능성, 사용자에게 프라이버시와 보안에 대한 신뢰성 제공을 목표로 하고 있었음
  • 하지만 시간이 지나면서, Bear 프로젝트의 코드를 기반으로 한 경쟁 서비스가 등장하는 사례가 있었음
    • 본인 소프트웨어를 애정으로 개발했지만, 소스가 쉽게 복제되어 경쟁으로 돌아오는 현상에서 상실감과 경제적 위기감 발생
    • 오픈소스의 가치를 믿었지만, 실질적으로 어려움을 겪는 상황임

라이선스 변경 결정

  • 최근 사건을 계기로, MIT 라이선스에서 Elastic License(Elastic Search에서 도입된 카피레프트 방식)로 라이선스 변경을 결정함
    • Elastic License는 MIT와 유사하지만, 소프트웨어를 호스팅 또는 관리형 서비스로 제공하는 행위를 금지함
    • 구체적인 라이선스 조항은 GitHub 링크에서 확인 가능

오픈소스 생태계 동향

  • 조사 결과, 다수의 오픈소스 프로젝트들이 최근 몇 년간 “무임승차 경쟁” 을 막기 위해 라이선스를 제한하는 추세임
    • 예시: Plausible, Fathom, Grafana, Snowplow, ScyllaDB, Sentry 등 여러 프로젝트가 유사 결정 시행

인공지능 시대와 경쟁 심화

  • AI 코딩 툴의 등장으로, “이 레포지토리를 포크하고 이름을 바꾼 후 EC2에 배포해봐”와 같은 빠른 복제 및 서비스화가 가능해짐
  • 이러한 환경 변화는 원저작자에게 더 큰 부담과 리스크를 안기게 됨

Bear의 특별한 가치

  • Bear 플랫폼의 진정한 가치는 단순히 소스 자체가 아니라, 이를 사용하는 커뮤니티와 운영자의 장기적인 책임감에서 비롯됨
  • 앞으로 코드 수준의 제한이 일부 생기더라도, 플랫폼 자체는 성실히 유지 관리하겠다는 의지를 표명함
▲
ndrgrd 20시간전  [-]

사실 오픈 소스 프로젝트는 이용자들의 관심과 기여가 거의 유일한 자원인데
완전히 자리를 잡은 수준이 아니면 아무나, 특히 대기업이 포크해가서 관심을 독점해버린다면 남 좋은 일만 한 것이 되죠.

애초에 이런 라이센스들은 시작부터 이용자의 자유를 위한 것이지 개발자를 위한 것은 아니었습니다.

윈도우의 CLI 패키지 매니저인 winget도 다른 이의 프로젝트를 마이크로소프트가 그대로 포크해서 이름만 바꿔 출시했다는 사실을 아시나요.
원본 프로젝트인 appget의 저자가 작성한 글도 있습니다.
The Day AppGet Died.

(특히 대기업이나 바이럴에 능한 분들을 위한) 남 좋은 일만을 원하지 않고 자신의 시간에 가치를 두시는 분이라면 오픈 소스 라이센스를 채택하는 것을 다시 고려할 필요가 있습니다.
같은 자원봉사라도 기여에 대한 존중을 받는 것과 철저히 무시당하는 것에는 큰 차이가 있습니다.

Hacker News 댓글에 달린 것과 같은 대안들을 살펴보세요.

답변달기
▲
coremaker 19시간전  [-]

GLPv3 와 AGPL 은 이 라이선스 원작자 의도대로 사용되지 않는 것 같습니다.
대부분 듀얼 라이선스를 허용하는 바람에 결국은 상업적 이용을 강제하는 장치로 사용되는 경우를 너무 많이 봤어요.

그런 의미에서 Apache 나 MIT 초기 의도대로 동작하는 몇 안되는 오픈소스 라이선스라고 생각합니다.
(단, 완전 무결한 오픈소스 라이선스가 있다고 생각하진 않습니다.)

답변달기
▲
GN⁺ 21시간전  [-]
Hacker News 의견

  • 내가 이해한 바로는, 'Open Source' 진영은 Amazon이 AWS 서비스로 제공할 수 없다면 그건 진정한 오픈 소스가 아니라는 입장이 있음, 그리고 누군가 그렇다고 주장하면 굉장히 불쾌해함.
    모두가 이 글쓴이가 말하는 '무임승차 경쟁' 현상에 대해 좀 더 인정을 해줬으면 함. Herman이 하고 있는 일은 모두에게 도움이 되는 일임, 그래서 "source-available"보다 더 따뜻하고 커뮤니티 프로젝트를 제대로 담아내는 새로운 용어가 있었으면 함.
    아래 댓글에서 내 생각을 잘 요약했기에 덧붙임:
    시장의 자연스러운 독식 구조는 자유 오픈 소스 소프트웨어(FOSS) 미션에 도움이 안 됨. 대기업이 이런 방식으로 수익을 거두는 것을 막지 않으면, 오히려 오픈 소스의 사명을 심각하게 훼손하는 문제임. 그리고 이 과정에서 사용자가 대기업의 독점 소프트웨어와 FOSS를 결합한 함정에 빠지게 함

    • 본래 오픈 소스 진영의 태도는 GPL → GPLv3 → AGPL 같은 라이선스였음, 이런 문제를 명확히 막아주는 방식을 지지했음
      MIT/BSD/Apache 같은 모든 권한을 주는 라이선스가 널리 쓰이게 된 건, 기업의 이해관계에 따라 자유 소프트웨어 이념을 약화시키려고 한 의도적인 흐름으로 보임

    • 대부분 사람들은 오픈 소스가 아닌 소프트웨어에도 별로 불만이 없음
      문제는 Terraform 같은 프로젝트가 오픈 소스였기에 인기를 얻고 성장했는데, 그 관리자가 폐쇄 라이선스로 바꾸면서 원래 성공의 기반이 사라진 상황에 나옴
      거기에 기여자들이 CLA(기여자 동의서)를 써서, 그 사람들 코드까지도 마음대로 폐쇄 라이선스로 바꿔버리는 경우는 두 배로 실망스러움

    • 오픈 소스에 관심 없으면 안 쓰면 되는 것임, 그동안 오픈 소스는 분명하고 일관된 의미를 가지고 있었음
      각각 자유롭게 소프트웨어를 만들면 되고, 믿는 가치에 따라 선택해서 쓰면 됨, 굳이 문제라 할 게 없음

    • 누구든 원하는 라이선스를 쓸 수 있지만, 왜 대부분 오픈 소스 개발자가 MIT처럼 관대한 라이선스를 선택하는지 생각해볼 필요가 있음
      현실적으로 시장에 좋은 오픈 소스가 많아 선택권이 넓음, 라이선스에 제약을 두면 사람들은 그냥 다른 대안을 택함
      그래서 GPL류로 라이선스를 하면 프로젝트가 대중적으로 쓰이기 어려워짐. 물론 예외로 Linux나 WordPress는 크게 성공했지만 딱히 일반적인 현상은 아님
      MIT 같은 관대한 라이선스로도 수익화가 어렵지만, 사용자부터 없어지면 더 힘듦
      이게 좋은지 나쁜지는 논란이지만, 실제로 다들 합리적으로 행동하고 있는 걸로 보임. 본질적으로 소프트웨어는 그만큼 희소하지 않음

    • AGPL이 바로 이런 경우를 위해 만들어진 것 아닌지?
      AGPL은 네트워크 서비스로 소프트웨어를 제공할 때 제한을 두는, OSI가 인정한 오픈 소스 라이선스임

  • 유지자가 Fair Source를 살펴봤는지 궁금함 fair.io
    Fair Source는 'source-available'보다 우수하다고 생각함, DOSP(opensource.org/dosp) 아래에서 완전한 오픈 소스가 되는 경로이기도 해서 무료 및 유료 사용자 모두에 유익하고, 특히 Bear 같은 블로그 플랫폼에 이상적인 모델임
    FCL(fcl.dev) Fair Source License도 Bear Blog License의 기조와 비슷하며, Bear manifesto(herman.bearblog.dev/manifesto/)에도 잘 맞아떨어짐
    설령 Bear PTY LTD가 없어지더라도, Bear 자체는 계속 남는 구조를 만들 수 있음(DOSP로 규정 가능)
    나는 Fair Source 작성에도 관여한 입장임

    • 우리 제품(morphik.ai)은 BSL(Business Source License)로 라이선스를 적용했고, 공식적으로는 그냥 레포지토리가 공개된다는 정도로만 안내함 (github.com/morphik-org/morphik-core)
      그래도 'fair source'라는 용어가 괜찮게 들림
      Apache나 MIT처럼 시간이 지나면 오픈 소스가 되는 소프트웨어라면 fair source에 해당된다고 생각하면 되는지, 아니면 좀 더 복잡한 기준이 있는지 궁금함

  • 어떤 사람은 적당히 순진했다고 봄. MIT 라이선스를 선택하면 누가 내 코드를 어떻게 쓰든 자유로움. 나중에 돈 벌고 싶어지면 해결을 위해 별난 라이선스로 바꿈
    결국 선택지는 MIT/BSD, GPL, LGPL, AGPL이고, 그 외 라이선스는 쓸데없는 호환성 문제만 만들 뿐임

    • 나도 이 견해에 동의함. 정말 '조건 없이' 소스 공개가 좋을 땐 MIT를 고르면 됨
      이번의 경우는 명백하게 그렇게 생각하고 고른 게 아니라, 다소 모호하게 '착한 척'과 '사업가 척'을 둘 다 하려던 게 아닐까 싶음

    • MPL(Mozilla Public License)도 꽤 유용하고 과소평가되는 라이선스라고 봄
      GPL류보다는 확실히 덜 감염성이고, MIT/BSD보다는 더 제약이 있음(변경 사항은 배포 시 소스 공개가 필요함)

    • MIT와 BSD는 특허 권리 보장이 없으니, Apache License로 가는 게 좋은 이유가 됨

    • Guy(만든 사람)는 그냥 본인 프로젝트를 만들고, 소스를 공개하는 데 의미를 둔 것으로 보임
      특별히 다른 전략적 목적은 없다고 생각함

    • 오픈 소스 프로젝트가 영원히 오픈 소스일 거라 믿는 사용자도 순진함
      라이선스 바꿀 권리를 저자들이 가지고 있고, 이에 놀라는 것도, 오픈 소스로 사업화가 쉬울 거라 믿는 것도 결국 다 순진한 태도임

  • 경쟁 사용을 원천 봉쇄하고 싶다면 이렇게 하는 게 보통임. 더 이상 오픈 소스란 용어를 쓰지 않는 것도 옳은 선택임
    하지만 대부분의 상황에선 AGPL이 더 나은 대안이라 생각함. AGPL이면 대기업이 내부 규정 때문에 코드를 못 써 대형 사업자 진입을 막는 효과가 있음

    • AGPL을 사실상 OSI가 승인한 source-available 라이선스로 쓰라고 추천하는 건 부끄러운 일임
      오픈 소스의 본뜻을 배반하는 일임

  • "MIT로 오픈했다가, 내 코드를 누군가가 사업에 써서 돈을 벌고 있다. 이런 결과를 예상 못 했다는 게 신기하다"
    왜 이런 일이 계속 반복되는지? 왜 이렇게 많은 개발자가 이런 당연한 결과를 못 보는지 궁금함

    • MIT는 깃허브에서 새 프로젝트 만들 때 그냥 드롭다운 고르면 자동 선택되는, 진입장벽이 낮은 기본값이었음
      프로젝트가 새롭고 어떻게 발전할지 모를 때는, 나중에 라이선스 걱정을 해야 할 정도로 큰 프로젝트가 될 거라 상상하기 힘듦

    • MIT 라이선스는 본래 프로젝트가 언제든 새로 재라이선스하는 걸 허락함
      Bear 관리자가 처음엔 관대한 라이선스를 선택했다가, 상황이 바뀌자 좀 더 엄격한 라이선스로 바꾼 것임
      나에겐 아주 합리적인 의사결정임

    • 15~20년 전 BSD 진영이 오픈 소스 문화 전쟁에서 이겼기에 그렇다고 봄
      만약 GNU 라이선스 진영이 전쟁을 이겼다면 오늘날 생태계는 어떻게 달라졌을지 궁금함

  • Bear가 오픈 소스라서 후원했는데, 그게 아니면 더 이상 후원할 이유가 없어 구독을 해지했음
    이게 AGPL로 돌아간다면 정말 바랄 만함

    • Bear도, 나도 각각 공정하게 선택을 내렸다고 생각함
      Bear는 원하는 라이선스를 쓸 자유가 있고, 나는 그것을 쓸지 말지 결정할 수 있음
      오픈 소스 라이선스의 목적은 기본적으로 금전적 이익이 아닌 공유 자체임
      오픈 소스 프로젝트만 후원하는 것도 완전히 이해함
      수익을 창출해야 하는 시점이 오면, 오픈 소스 라이선스는 더 이상 적절하지 않을 수 있음
      일부 개발자는 오픈 소스가 소득을 지켜줄 거라 오해하고, 일부 사용자는 프로젝트가 영원히 오픈 소스로 남으리라 착각함
      source-available이나 shipped-with-source 같은 모델도 일종의 독점(프로프라이어터리) 라이선스임, 꼭 오픈 소스일 필요는 없음

  • “사용자는 소프트웨어의 주요 기능을 제공하는 서비스로 호스팅하거나 관리형 서비스로 제공하면 안 됨”
    나는 변호사는 아니지만, 이 제한이 직접 설치해서 사내 또는 개인 용도로 Bear를 운영하는 것도 제한하는지 궁금함
    사실 그게 안 된다면 MIT 라이선스를 썼던 이유가 뭔지 모르겠음
    Bear Blog License 원문

    • 개인이나 기업이 내부 용도나 개인 용도로는 Bear를 직접 호스팅해도 됨
      하지만 다른 사람이나 기업에 서비스 형태로 제공하는 것은 안 됨
      참고: Elastic License FAQ

  • 허탈감은 공감하지만, 새 라이선스가 좀 애매함
    "호스팅/관리형 서비스를 통한 기능 제공 불가"라 했을 때, 일반적인 VPS 사업자(패키지 매니저로 설치하는)도 제한되나?
    1-click 설치 같은 셋업 스크립트가 있으면 어떻게 되는지, 서비스 과정에서 안내만 안 하면 괜찮은 건지 모호함
    제3자가 설치 스크립트를 제공하면 괜찮고, 서비스 단계에서 언급만 안 하면 다 된다는 식의 '연극'처럼 느껴짐

    • 여기서 '사용자'는 최종 사용자임
      즉, 소프트웨어를 서비스(무료/유료) 형태로 다른 이에게 제공하면 안 되는 거고, 자기만 쓰는 건 괜찮음
      핵심은, 계정 제공 자체가 금지된다고 봐야 함
      턴키 호스팅 제공도 금지이긴 한데, 이때 호스팅을 제공하는 쪽이 아니라 그 호스팅 인스턴스에서 사용자 계정을 만들어 파는 쪽이 문제임
      이 워딩은 Amazon 같은 대기업이 데이터베이스 인스턴스를 외부에 제공하고 거기에서 계정만 발급해주는 걸 막기 위한 것임
      반면, 단순히 VM에서 페키지 매니저로 설치하는 건 괜찮음
      그래도 이런 식의 라이선스는 굉장히 혼란스럽고 명확하지 않음
      만약 오픈 소스로 남겨 놓을 생각이면, 많은 사람이 쓰길 원할 텐데, 막상 타인이 호스팅하는 걸 원치 않으면 굳이 코드 공유할 필요 없이, 'All rights reserved'로 내버려 두면 그만임

  • 동기와 소스 공개 의도는 이해하지만, 경쟁이 우려였다면 MIT 대신 AGPL을 검토했을 법한데 궁금함

    • AGPL도 결국 다른 사람이 코드 고치지 않고 그대로 상업적으로 다시 팔 수 있지 않나?
      AGPL은 수정 사항 소스 공개만 강제할 뿐임
      여기서는 Bearblog를 거의 그대로, 아니면 이름만 살짝 바꿔 상업적으로 제공하는 사례가 문제라는 듯함

    • 아마도 처음엔 경쟁이 문제라고 생각하지 않았고, 점점 문제가 되자 라이선스를 바꾼 것임

  • 이 방식(소스 공개 + 호스팅 제한 등)이 개인적으론 최고의 라이선스 모델이라 생각함
    내 취향에 맞게 코드를 확인하고 바꿀 수 있으면서도, 프로젝트와 메인테이너가 과한 경쟁 부담 없이 자신만의 기반을 지킬 수 있음
    처음부터 이렇게 시작하면 나중에 갑자기 바뀌어서 분란이 일거나, 포크가 원본을 뛰어넘는 일도 막을 수 있음
    Bear가 그만큼 크게 반향을 불러올 프로젝트 정도는 아니었다고 보지만
    나는 mataroa.blog도 가끔 잘 쓰고 있고, Bear 유지자도 본인 프로젝트에서 보람을 느끼길 바람

답변달기