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년 대비 두 배로 성장함
이 변화가 한 달도 채 안 됐기에 아직 README에 제대로 반영되지 않은 걸 수도 있다고 생각함
최근에 소스만 공개하면서 오픈소스인 척 브랜딩하는 프로젝트가 많은 게 아쉬움
Liquibase가 강한 copyleft(예: GNU AGPL)가 아닌 Apache를 택했으면 당연히 타사가 폐쇄형 소스 파생물을 만드는 걸 예상했어야 함
결국 Liquibase 스스로 선택한 일이기에 그 책임도 Liquibase에게 있다고 생각함
일정 기간 후에 Apache로 자동 전환되는 구조로 보임
이게 더 나은 건지, 아닌 건지는 잘 모르겠음
기업들은 사실 AGPL 같은 라이선스로도 충분히 자사 목표를 이룰 수 있음
Redis도 전환했고 커뮤니티 반응도 긍정적이었음
Liquibase가 AGPL 듀얼 라이선스를 택한다고 해서 사용자들이 불만 가질 것 같진 않음
"2년 딜레이 오픈소스" 혹은 "2년 후 오픈소스"라고 불러야 할 것 같음
실제로는 "쓸모 없을 때쯤 오픈소스"라 생각함
이런 식이면 진정한 자유를 존중한다는 이미지만 주고 실제로는 그렇지 않은 게 본질이라 생각함
그 정도로 빨리 구 버전이 무용지물이 되는 것도 드묾
이것이 내 자유에 대한 존중 부족이라고 보지 않음
목표는 기업(사람이 아님)에 일부 제한을 거는 데 있음
엔터프라이즈 분야에서 오픈소스의 핵심은 '자유'보다는 신뢰와 투명성이라 생각함
소스 공개만 해도 법적/수익화 문제 없이 FOSS의 이점은 누릴 수 있음
온라인에서는 오픈소스 모델에 대한 맹목적인 신뢰가 지나치게 나타나는 경향이 있음
2년 혼용 정책도 충분히 합리적이라 생각하며, 새로운 라이선스를 원치 않으면 구버전 쓰면 됨
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처럼 커스텀 레포에서는 포함 가능함
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 공식 블로그 공지 참고
최근에 소스만 공개하면서 오픈소스인 척 브랜딩하는 프로젝트가 많은 게 아쉬움
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년 버전도 충분히 괜찮음
이런 케이스들의 히스토리와 기업 리스트를 정리한 적 있음
관련 블로그 포스팅에 정리해두었으니 추가로 더 알면 공유 부탁함
프로 기능이 커뮤니티 버전의 문법을 자꾸 깨서 투명성은 전혀 없다고 느꼈음
물론 작업에 대한 정당한 보상이 필요하긴 한데, "우린 오픈소스였다가 슬쩍 아니게 됨"은 너무 흔해지고 있음
이런 전환은 아무도 눈치채지 않길 바라는 마음에서 항상 조용히 진행되는 듯함
실질적인 피해나 주된 문제가 뭔지 궁금함
오히려 경쟁 분야와 비경쟁 분야의 구분이 마음에 듦
댓글 분위기가 조금 이상하게 느껴짐
대부분 "base"만 보고 아무 상관 없는 서비스 추천하거나, 소스 공개만 했으면 오픈소스라고 주장하는 분위기임
Liquibase가 라이선스를 변경한 줄 몰랐었음
사실 거의 모든 웹 프레임워크에 대안이 있고, Alembic과 Flyway 처럼 프레임워크 독립적인 대안도 많음
이 시점엔 좀 이상해 보임
이번 이슈가 Keycloak 같은 OSS 프로젝트에도 문제를 일으킬 수 있음
CNCF 정책상 비오픈소스 라이선스는 사용할 수 없으므로, Keycloak이 Liquibase를 쓸 수 없음
Debian, Fedora 등에서도 OSS 라이선스 조건이 있기 때문에 이런 배포판에서 Liquibase 의존 프로젝트가 포함될 수 있을지 궁금함
Keycloak 이슈 상세 링크
하지만 개별 저장소나 rpm fusion non-free처럼 커스텀 레포에서는 포함 가능함