HashiCorp, Business Source License 채택
(hashicorp.com)- HashiCorp는 향후 제품 릴리스의 소스 코드 라이선스를 MPL 2.0에서 Business Source License v1.1로 바꾸며, 커뮤니티와 제품 투자를 지속하려 함
- 기존 오픈소스 모델은 큰 생태계를 만들었지만, 일부 벤더가 커뮤니티 작업을 상업적으로 활용하면서 실질적 기여는 하지 않는 문제가 커졌다고 봄
- BSL 1.1은 복사·수정·재배포와 비상업적 사용, 조건부 상업적 사용을 허용하는 소스 공개형 라이선스이며, API·SDK·대부분의 라이브러리는 MPL 2.0으로 남음
- 최종 사용자, 파트너, 엔터프라이즈 및 클라우드 관리형 제품 고객은 대체로 기존 사용을 이어갈 수 있지만, HashiCorp와 경쟁하는 제품 제공은 예외가 됨
- HashiCorp 커뮤니티 제품 위에 경쟁 서비스를 제공하는 벤더는 향후 릴리스, 버그 수정, 보안 패치를 더 이상 통합하기 어려워짐
라이선스 변경 범위
- 향후 모든 HashiCorp 제품 릴리스의 소스 코드 라이선스가 Mozilla Public License v2.0(MPL 2.0) 에서 Business Source License(BSL 또는 BUSL) v1.1로 변경됨
- HashiCorp API, SDK, 거의 모든 다른 라이브러리는 MPL 2.0을 유지함
- 제품 소스 코드와 업데이트는 계속 HashiCorp의 GitHub 저장소와 배포 채널에 공개됨
- HashiCorp는 커뮤니티, 파트너, 고객에 대한 영향을 최소화하면서 소스 코드를 널리 공유하고 무료 사용을 가능하게 하는 방식을 목표로 함
오픈소스 모델과 상업화 부담
- HashiCorp가 창업 당시 제품을 오픈소스로 공개한 이유는 세 가지였음
- 실무자가 소스 코드를 자유롭게 다운로드하고 검토하며 직접 문제를 해결할 수 있어야 함
- 제품 주변에 생태계와 커뮤니티를 만들어 폭넓은 통합을 가능하게 해야 함
- 사용자에게 투명성이 중요함
- 10년 넘게 무료 오픈소스 라이선스로 새 제품과 기능을 제공했고, 사용자·기여자·파트너·고객으로 이루어진 큰 커뮤니티가 형성됨
- 매년 오픈소스 제품 연구개발에 수천만 달러를 투자하며, 미션 크리티컬 인프라에서 HashiCorp와 협력하는 상업 고객들이 이 모델을 가능하게 함
- 클라우드 제공자와 긴밀히 협력해 공동 사용자와 고객을 위한 통합을 제공했고, 수백 개 기술 파트너와도 협력해 왔음
BSL 1.1 적용 방식
- BSL 1.1은 복사, 수정, 재배포, 비상업적 사용, 특정 조건의 상업적 사용을 허용하는 소스 공개형 라이선스임
- 최근 몇 년간 Couchbase, Cockroach Labs, Sentry, MariaDB도 비슷한 경로를 택했으며, MariaDB는 2013년에 이 라이선스를 개발함
- Confluent, MongoDB, Elastic, Redis Labs 등도 상업적 사용 제한을 포함하는 대체 라이선스를 채택한 사례로 언급됨
- HashiCorp의 BSL 적용에는 소스 코드의 폭넓은 허용적 사용을 가능하게 하는 추가 사용 허가가 포함됨
- 라이선스 개발 과정에서 OSS 라이선스 전문가와 업계 이해관계자에게 자문을 구해 업계 관행에 맞추려 했음
사용자·파트너·고객 영향
- 최종 사용자는 HashiCorp와 경쟁하는 제품을 제공하는 경우를 제외하고, 모든 비상업적·상업적 용도로 코드를 계속 복사, 수정, 재배포할 수 있음
- 파트너는 공동 고객을 위한 통합을 계속 구축할 수 있음
- 클라우드 서비스 제공자와는 계속 긴밀히 협력해 상호 기술에 대한 깊은 지원을 유지할 계획임
- 엔터프라이즈 및 클라우드 관리형 HashiCorp 제품 고객에게는 변화가 없음
- 커뮤니티 제품을 기반으로 HashiCorp와 경쟁하는 서비스를 제공하는 벤더는 향후 릴리스, 버그 수정, 보안 패치를 HashiCorp 제품에 통합할 수 없게 됨
후속 안내
- HashiCorp는 커뮤니티, 파트너, 고객에 대한 약속은 변하지 않았다고 밝힘
- 추가 질문을 위해 frequently asked questions를 제공함
댓글과 토론
Hacker News 의견들
-
여기서 얻는 결론은 HashiCorp가 더 이상 오픈소스 회사가 아니라는 것뿐임
“순수 OSS 모델과 커뮤니티 작업을 상업적 목표에 이용하면서 실질적 기여를 돌려주지 않는 벤더”가 있다는 건 오픈소스 정신에 100% 부합함
그게 문제라면 AGPL처럼 개발자가 코드를 공개하도록 강제하는 오픈소스 라이선스를 채택하면 됨
이건 HashiCorp가 예전 오픈소스 프로젝트를 자기들만 상업화할 수 있게 하려는 방식일 뿐이고, 그 자체는 괜찮지만 그러면 그냥 폐쇄 소스로 가고 인정해야지 양쪽을 다 가지려 해서는 안 됨- Pulumi 창업자/CEO임
블로그 글은 솔직하지 않음. Terraform 제공자에 여러 번 업스트림 수정 기여를 시도했지만 HashiCorp가 받아준 적이 없어서 포크를 유지해야 했음
HashiCorp는 오래전에 OSS DNA를 잃었고, 이번 조치는 관에 마지막 못을 박은 셈임
다행히 시간이 지나며 Terraform 제공자 대부분의 책임을 파트너들에게 넘겨둔 상태라, 제공자 생태계는 계속 활발하고 열려 있을 수 있기를 기대함
오픈소스를 깊이 믿고 있음. Microsoft에서 마지막으로 했던 프로젝트도 .NET을 오픈소스·크로스플랫폼으로 만드는 일이었고, CTO는 TypeScript 창립에 관여했으며, Pulumi도 Apache 오픈소스 프로젝트임. HashiCorp는 더 이상 그렇지 않아 보임 - 이념은 사람들이 먹고살 필요가 생기기 전까지는 훌륭함. 그래서 매출이 필요함
큰 틀에서 시대가 바뀌었고, 소스 공개는 “전부 공짜로 내놓지 않으면 진짜가 아니다”가 아니라 만드는 쪽과 쓰는 쪽의 상호 이익 관계여야 한다고 봄
사용자는 실행 중인 것을 소스로 이해하고 확장할 수 있고, 프로젝트 관리·유지·소유자는 그 일을 계속할 수 있어야 함
이건 도달해야 할 균형점이 아니라 긴장 속에서 유지해야 하는 균형임 - 실용적으로는 완전 폐쇄 소스보다 BSL이 낫고, 전환 기간과 라이선스가 합리적이라면 100% 폐쇄 소스 제품보다 BSL 제품을 쓸 가능성이 더 큼
- 여러 전 직장 경험상 소프트웨어 회사는 상장 후 약 1.5년이 지나면 눈에 띄게 내리막을 타기 시작하는 것 같음
Wikipedia를 확인해 보니 HashiCorp는 2021년 11월 29일 IPO 조건을 정했다고 함
점점 이 가설이 맞는 것 같아짐. 반례든 지지 사례든 일화 자료는 환영함 - 오픈소스의 반대는 폐쇄 소스가 아니라 제한적 라이선스임
오픈소스가 아니라고 해서 소스를 못 보게 해야 하는 건 아니고, OSI 승인 라이선스의 모든 특성을 제거해야 하는 것도 아님
물론 자유 소프트웨어였다면 더 좋았겠지만, 모든 소프트웨어가 자유 소프트웨어라면 더 좋다는 말과도 같음
문제는 OSI 승인을 받을 수 없는 라이선스를 오픈소스라고 가장할 때 생김. HashiCorp는 여전히 오픈소스라고 주장하지 않고 이제 “소스 공개(source-available)”라고 부르고 있음
- Pulumi 창업자/CEO임
-
꽤 실망스러움. 개인적으로 Vault 말고는 많이 쓰지 않았고 Terraform은 써봤지만 즐기거나 그 위에 뭘 만들지는 않았는데, 이건 HashiCorp 제품에서 가장 좋게 봤던 점과 정반대임
심지어 Vault에서 내가 가장 많이 쓰는 코드 일부인 인증서 관리에도 기여했는데, 이제 앞으로 고객에게 그 서비스를 써보라고 할 수 있을지, 다시 기여할지 재검토해야 함
VC 자금이 마르는 시대가 되면서 GPL류가 아닌 라이선스들의 최악의 미래가 드러나는 느낌임
언젠가 그 지식을 활용해 서비스를 만들고 스스로의 보스가 되면서, 여기까지 오게 해준 OSS에 계속 돌려주겠다는 꿈으로 OSS와 그 운영만 의도적으로 배워온 사람들에게는 안타까운 일임- 이 주제에 대한 다른 댓글도 읽었고, 이런 일을 겪게 되어 안타깝게 생각함
회사 인프라 전반에서 애플리케이션 비밀값 관리를 위해 엔터프라이즈 Vault를 구현·운영한 경험이 많음
Vault를 도입하고 계약을 협상하던 몇 년 동안 영업 엔지니어들이 사용 사례에 “필요한” 기능에 대해 부정확하거나 오해의 소지가 있는 말을 하고, 지킬 수 없는 장기 기능 약속을 하는 모습을 봤음
Vault에서 빠져나오는 마이그레이션이 사실상 불가능하거나 위험할 수 있는 통합 방식을 권장하기도 했고, 영원히 무료일 줄 알았던 기능을 계속 빼앗았음. Okta/MFA 로그인이 가장 큰 예였고, 진지한 컴플라이언스는 그 없이는 통과하기 어려운데 Vault에 크게 의존하는 팀은 결국 이 기능에 돈을 낼 수밖에 없다는 걸 HashiCorp가 깨달은 듯함
전반적으로 강한 벤더 종속처럼 보였고, 매년 같은 기능 또는 더 적은 기능에 더 큰 비용을 내게 됐음. 엔지니어들조차 설명 못 하는 가격 정책도 계속 임의로 바뀌었음
Vault 자체는 훌륭한 소프트웨어라고 보지만 HashiCorp에 대한 신뢰를 잃었기 때문에, 개인적으로 중요한 일에는 의존하지 않을 것 같음 - 글에 따르면 “최종 사용자는 HashiCorp의 경쟁 제품을 제공하는 경우를 제외하면 비상업·상업적 용도로 코드를 계속 복사, 수정, 재배포할 수 있다”고 되어 있음
문자 그대로라면 바뀐 건 없고, 실망스러운 게 아니라 똑똑한 선택임. 오픈소스 커뮤니티의 선의를 반복적으로 남용한 클라우드 제공자들로부터 스스로를 보호하는 것임 - 큰 차이는 코드 저작권이 어디에 있느냐임
기여자에게 저작권 양도를 요구하는 OSS 프로젝트는 신뢰하면 안 되고, 애초에 선의의 기여를 받아서도 안 됨
그렇지 않으면 오늘은 Apache 2.0이어도 내일은 아무에게도 허락받지 않고 상업용으로 바뀔 수 있음. 관리자가 코드 100%를 소유하기 때문임
상업적 주체가 뒷받침하는 OSS 프로젝트가 외부 기여자에게 의미 있는 양의 기여를 받는 경우는 보통 드물지만, 그래도 OSS에서 생각해야 할 중요한 세부사항임
- 이 주제에 대한 다른 댓글도 읽었고, 이런 일을 겪게 되어 안타깝게 생각함
-
“상업적 오픈소스 모델이 진화해야 생태계가 개방적이고 자유롭게 이용 가능한 소프트웨어를 계속 제공할 수 있다”는 식으로 말하면서, BUSL 같은 비오픈소스 라이선스를 오픈소스 모델의 진화 일부인 것처럼 암시하는 건 심각한 혼동이거나 의도적인 오도임
의미 있는 규모의 누군가가 HashiCorp 제품을 이용해 HashiCorp와 실질적으로 경쟁한 적이 있나?- 어떤 라이선스가 관련되는지는 확인하지 않았지만, Pulumi는 Terraform 제공자를 폭넓게 사용함[1]. 그리고 Pulumi는 분명 HashiCorp 경쟁자로 볼 수 있음
[1]: https://www.pulumi.com/docs/concepts/vs/terraform/#:~:text=U...
Pulumi는 어떤 Terraform Provider든 Pulumi에서 사용할 수 있게 변환할 수 있어, Terraform Providers 생태계가 지원하는 모든 인프라를 Pulumi 프로그램으로 관리할 수 있음 - 아직 아무도 시도하지 않았다고 해서 앞으로도 안 일어난다는 뜻은 아님
기업들이 이런 조치를 하는 건 Amazon 같은 회사들이 자유·오픈소스 라이선스를 이용해 오픈소스 프로젝트의 자체 호스팅 버전을 세우기 때문임 ctrl+f로 “open source”를 찾아보면 어디서부터 그 표현을 멈추는지 보임
HashiCorp는 이번 변경을 “오픈소스” 유지가 아니라 개방적이고 자유롭게 이용 가능한 제품을 유지하기 위한 것이라고 설명함
라이선스를 바꾸면서도 “오픈소스”로 남는다고 말하지 않는 점에서는 다른 곳보다 더 정직하다고 봄. 그렇게 불렀을 때 받을 반발을 알고 있는 게 분명함- 바로 떠오르는 제품은 Pulumi임. 서비스 쪽으로는 env0, SpaceLift 같은 것들도 있음
- Fly.io는 한동안 Nomad 위에 만들어졌음. 새 라이선스 세계에서는 그게 허용되지 않을 것임
- 어떤 라이선스가 관련되는지는 확인하지 않았지만, Pulumi는 Terraform 제공자를 폭넓게 사용함[1]. 그리고 Pulumi는 분명 HashiCorp 경쟁자로 볼 수 있음
-
@mitchellh가 대화에 참여하지 않는 게 흥미로움. 과거에는 HN에서 직접 소통했고, 이 결정에도 최종적인 영향력이 있었을 것 같음
전반적으로 패배자의 수처럼 보임. Elasticsearch에 무슨 일이 있었는지 보면 됨. 나와 대부분의 사람들에게 ES는 더 이상 존재하지 않음. OpenSearch로 기분 좋게 옮겼고, 불쌍한 kimchi는 돌아보지 않음. 자기 행동 때문에 Elasticsearch는 더 이상 관련성이 없어졌음
HashiCorp의 이번 움직임이 Terraform과 다른 도구의 마지막 오픈소스 라이선스 버전을 포크하려는 비슷한 노력을 촉발할까? 만든 쪽이 쩨쩨하고 불안해져서, 함께 만들어준 오픈소스 커뮤니티에 적대적으로 나오면 다른 선택지가 뭐가 있겠나
HashiCorp 리더십에 극도로 실망했음. MitchellH와 Armon Dadgar는 커뮤니티에 이보다 더 나은 대우를 해야 했음
2016년에 HashiCorp 면접을 봤고 결국 입사를 거절했는데, 그 결정을 조금 후회한 적도 있었음. 이제 본색이 드러났으니 올바른 선택이었다고 확신함
신뢰에 관한 말이 있지 않나. 신뢰는 쌓는 데 몇 년, 깨지는 데 몇 초, 회복하는 데 영원이 걸림
똑똑하다고 생각했던 사람들이 이렇게 어리석을 수 있다는 게 놀라움- Mitchell은 꽤 오래전부터 HashiCorp 리더십에 있지 않았고, 그 사실을 여러 번 말했음
많은 일을 해낸 사람을 모욕할 필요는 없음 - mitchellh는 리더십 역할에서 물러난 것 아닌가? 왜 이 결정에 “최종 영향력”이 있다고 보는지 모르겠음
- 좀 공격적으로 보임. 회사이고 돈을 벌어야 함
이들의 소프트웨어는 오픈소스였고, 좋은 것들은 포크될 테니 HashiCorp를 미워할 필요는 없음
“신뢰는 쌓는 데 몇 년, 깨지는 데 몇 초, 회복하는 데 영원”이라는 말에도 동의하지 않음. 너무 공격적임
HashiCorp는 훌륭한 것들을 만들었고 오픈소스 기반 사업을 시도했음. 계약을 어기거나 비도덕적인 일을 한 건 아니고, 이건 그들의 선택임 - Terraform에 실제로 돈을 내는 사람이 있나? “workspace” 호스팅 제품 말고는 모든 제공자가 무료로 풀려 있는 것 아닌가?
- Mitchell은 꽤 오래전부터 HashiCorp 리더십에 있지 않았고, 그 사실을 여러 번 말했음
-
공짜 돈이 끝난 뒤 모든 오픈소스 회사가 맞는 불가피한 결말처럼 보임. 거슬리는 건 문구가 꽤 모호하다는 점임
HashiCorp는 경쟁 제품을 “조직 외부의 사용자나 고객에게 제공되는 제품 또는 서비스 중 HashiCorp 상업 제품·서비스의 기능과 상당히 겹치는 것”으로 본다고 함
예를 들어 비용 추정 서비스가 없어서 뭔가를 만들었고 그게 유명해졌다고 해보자: https://github.com/infracost/infracost
2년 뒤 Terraform Cloud가 따라오면 어떻게 되나? 사업을 접어야 하나?- Apache/MIT 경로는 라이브러리 묶음을 유지하는 데는 “잘” 작동해 온 것 같음
하지만 데이터베이스 같은 더 큰 업무 핵심 제품에서는 자체 호스팅을 어렵게 만들거나 필수 기능에 제한을 거는 등 훨씬 이상한 꼬임이 보임
폐쇄 소스보다는 낫지만 이상적이지는 않음. 한동안 라이선스가 실용적인 탈출구일 가능성이 크다고 생각해 왔지만, 널리 이해되고 공정하며 명확해야 함
“조직 외부 사용자나 고객에게 제공되고 기능이 상당히 겹치는 제품 또는 서비스”라는 표현은 아픔. 문구상 (1) 불명확하고 (2) 그 모호성에 대한 권한이 회사 쪽에 기울어 있어 선택적 집행의 길을 열어줌
법적 문서에 서명하는 상황에서 “걱정 말라, 아무도 쫓아가지 않을 것”은 설득력이 없음. 계약에서 현재는 부드럽게 보이거나 미래에 행사할 수 있는 권한을 쌓아두는 건 큰 위험 신호라고 봄
이 라이선스 자체에 대해 다른 사람들은 어떻게 보는지 궁금함 - 회사를 미끼와 전환에서 막는 유일한 방법은 회사 정관을 바꾸는 것 같음: https://opencoreventures.com/blog/2022-10-preventing-the-bai...
“2년 뒤 Terraform Cloud가 따라온다”는 정말 좋은 지점임. 회사의 범위는 바뀜
- Apache/MIT 경로는 라이브러리 묶음을 유지하는 데는 “잘” 작동해 온 것 같음
-
https://www.couchbase.com/blog/couchbase-adopts-bsl-license/에 따르면 BSL은 보통 1~4년 사이의 변경일을 두고, 그때 BSL 라이선스가 GPL, AGPL, Apache 등 오픈소스인 변경 라이선스로 전환된다고 함
그래서 가장 중요한 질문은 변경 라이선스가 무엇이고 얼마나 걸리느냐임
1년 뒤 MPL 2.0으로 간다면 괜찮음. 하지만 훨씬 더 길고 제한적이라면 완전한 태도 전환이고, 오픈소스 버전은 최신 버전과 너무 멀어져 사실상 쓸 수 없게 됨
수정: 4년 뒤 MPL 2.0임
https://www.hashicorp.com/license-faq#What's-the-difference-...
보안이 관련될 때 4년은 사실상 “역사적 관심사”일 뿐임 -
다른 회사는 모르겠지만, 이런 회사들의 소프트웨어가 처음부터 비자유 라이선스였다면 지금 어디에 있었을지 늘 스스로 묻게 됨
이건 코드를 “훔쳐” 서비스로 돌리려는 거대 기업뿐 아니라 최종 사용자, 작은 개인과 회사에도 적대적임
HashiCorp 소프트웨어를 성공적으로 운영하고 사용하다가 경쟁자로 간주되면 HashiCorp가 당신을 막아버리기로 결정할 수 있음- 의존성들이 같은 태도를 취했다면 어땠을까?
예를 들면 https://github.com/hashicorp/vault/blob/main/go.mod#L25 - 맞음. 오픈소스가 마케팅으로 쓰였음
처음부터 BSL로 시작했다면 이렇게 널리 채택되지는 못했을 것 같음 - BSL에 대해 아는 범위에서는 내게 바뀌는 건 거의 없고, “진짜 오픈소스 정신”이 무엇인지에 대한 관념만 달라짐
- 의존성들이 같은 태도를 취했다면 어땠을까?
-
두 달 전 HashiCorp의 CLA 페이지: https://web.archive.org/web/20230610041432/https://www.hashi...
“HashiCorp가 지속 가능한 사업을 만들 수 있게 하면서도 프로젝트가 MPL2 같은 자유·오픈소스 라이선스로 유지되도록, 외부 기여자에게 기여자 라이선스 계약(CLA) 서명을 요구한다”고 되어 있었음
“HashiCorp는 비상업 소프트웨어에 진정한 자유·오픈소스 소프트웨어(FOSS) 라이선스를 적용하겠다고 약속한다. CLA는 사용자가 자기 프로젝트나 사업에서 사용할 권리, 수정 소스 재공개, 완전한 포크 등 표준 FOSS 라이선스가 부여하는 모든 권리를 유지하면서도 HashiCorp가 제품을 안전하게 상업화할 수 있게 한다”고도 했음
페이지의 비법률 문구가 CLA 서명이 HashiCorp 프로젝트를 오픈소스로 유지하는 데 도움이 된다고 반복적으로 암시했지만, 실제 계약 문구는 그런 보장을 하지 않았다는 점이 실망스러움- “CLA는 MPL2나 MIT 같은 표준 오픈소스 라이선스 조건을 바꾸지 않는다. 여전히 프로젝트를 자기 프로젝트나 사업에서 쓰고, 수정 소스를 재공개할 수 있다. 기여 대상 프로젝트의 해당 라이선스를 참고하라”고 되어 있음
CLA의 전제, 즉 기여물이 비FOSS로 재라이선스되는 상황이 바뀌었을 때 누군가 도전해봐야 함
대부분의 CLA는 매우 건조하지만, HashiCorp는 자기 CLA에 여러 선언을 넣어뒀기 때문에 곤란해질 수도 있음 - CLA에 서명하면 안 됨
그런 걸 요구하는 유일한 이유는 재라이선스이고, 이미 FOSS라면 재라이선스하려는 유일한 이유는 독점 소프트웨어로 가기 위해서임
Linux는 기여에 CLA를 요구하지 않음. 오픈소스 흉내를 내는 이 광대들이 요구할 뿐임
- “CLA는 MPL2나 MIT 같은 표준 오픈소스 라이선스 조건을 바꾸지 않는다. 여전히 프로젝트를 자기 프로젝트나 사업에서 쓰고, 수정 소스를 재공개할 수 있다. 기여 대상 프로젝트의 해당 라이선스를 참고하라”고 되어 있음
-
우리 OSS 회사는 Apache 2.0으로, Nomad를 핵심에 두고 만들었음
그 주변에 몇 가지 서비스를 붙여 게임 서버 오케스트레이션을 제공하는데, 이게 HashiCorp에 “경쟁 제품 제공”으로 오해될 수 있음
라이선스가 의도적으로 모호하기 때문에 Nomad 버전은 마지막 MPL 버전에서 동결할 예정임
CockroachDB도 쓰고 있고 그건 BSL이지만, 우리는 그쪽과 전혀 경쟁하는 제품을 제공하지 않음
조언을 구하는 사람에게 HashiCorp 제품인 Nomad, Consul, Terraform, Packer를 계속 추천할 가능성은 높지만, 이번 변경은 실망스럽게 들림
궁금한 사람을 위해 간단한 SBOM을 유지하고 있음: https://github.com/rivet-gg/rivet/blob/main/docs/infrastruct...- 연락해 달라: schmichael at hashicorp
Nomad 엔지니어링 리드임. 라이선스는 내 통제 밖이지만, 언젠가 경쟁으로 해석될 수 있는지 몰라 불안해하는 사용자들이 많이 있음
약속은 못 하지만 Nomad가 여전히 당신 일에 맞는 도구라는 확신을 줄 수 있도록 가능한 한 뭐든 해보겠음 - 빨리 빠져나가겠음. 가장 오래되고 인기 있는 도구에 이런 일을 할 수 있다면, 곧 모든 코드의 라이선스를 바꿀 것이라고 봐도 이상하지 않음
- 나도 같은 생각임. 하지만 오래가지는 않을 것임. 보안 버그가 나타나면 그때는 어떻게 할 건가?
- 연락해 달라: schmichael at hashicorp
-
개인적으로는 문제가 없다고 봄. 최종 목표가 SaaS 플랫폼이 되는 것이라면 더 많은 오픈소스 프로젝트가 처음부터 비즈니스 소스 라이선스로 시작했으면 함
대기업들이 자기 금전적 이익을 위해 오픈소스 정신을 남용하고, 아무것도 되돌려주지 않으며, 악의적으로 행동하는 모습을 반복해서 봐왔음- 오픈소스 정신을 남용한다고? 경쟁자를 원하지 않았다면 라이선스를 읽고 이해했어야지, 오픈소스를 단순히 마케팅용 유행어로 쓰면 안 됐음
- 많은 사람에게 오픈소스 정신은 상업적이든 아니든 어떤 방식으로든 쓰도록 허용하는 것임
공개되어 이용 가능하게 만든 것을 쓰는 게 악의적이라고 보지 않고, 무료로 나눠주는 것도 기꺼이 함
그렇지 않다면 오픈소스가 아님. 물론 모든 소프트웨어가 오픈소스일 필요는 없으니 그것도 괜찮음
오픈소스 정신을 남용하는 건 사용에 대해 임의의 규칙을 만드는 쪽임 - “더 많은 오픈소스 프로젝트가 비즈니스 소스 라이선스로 시작했으면 한다”고 했지만, 정의상 그러면 오픈소스 프로젝트가 아님
그래도 처음부터 명확히 하는 편이 낫긴 함