도메인명과 사이트명 SSPL is BAD 에서 보이듯이, 의도를 가지고 만들어진 웹사이트 입니다.
비약이 어느 정도 심하기도 하고요. 아래 해커뉴스 의견들과 같이 보시기 바랍니다.

Hacker News 의견

• SSPL에 대한 원칙적인 반대 의견이 있지만, 그 배경에 대한 이해도 함께 존재함. 기사 13조에 대한 묘사가 객관적 분석보다는 선정적 의도를 가졌다는 비판도 있음.

  • MongoDB와 Elastic이 AWS가 자신들의 제품을 재포장하여 서비스로 제공하고 경쟁자가 될 것으로 예상하지 못했음. Elasticsearch가 사용하던 Apache 라이선스는 이를 허용했지만, 윤리적으로는 막았어야 했다는 의견.
  • AWS가 OEM 계약이나 파트너십을 통해 '윈-윈' 관계를 형성할 수도 있었지만, 그렇게 하지 않아 SSPL 같은 불쾌한 형태의 차단을 유발했다는 지적.
  • SSPL이 투자자들을 기쁘게 하기 위해 만들어졌다는 불만이 있지만, 오픈소스 소프트웨어라 하더라도 회사가 비영리를 목적으로 한 것은 아니므로, Elastic이나 MongoDB를 비난하고 AWS를 비난하지 않는 것에 대한 이해가 안 된다는 의견.

• SSPL은 사용자에게 나쁜 것으로, SSPL이 독점을 촉진하고 커뮤니티 참여를 줄여 결국 모든 사용자에게 영향을 미친다는 주장.

• 사람들이 돈을 벌고자 하는 것은 당연한 일이며, SSPL 프로젝트를 사용하지 않기로 선택할 수도 있음. SSPL 라이선스로 발행된 소프트웨어가 없는 것보다는 낫다는 관점 제시.

• 현재의 생태계가 10년 전과 크게 달라졌으며, 소규모 회사들이 경쟁에서 살아남고 성장할 수 있는 길을 원한다는 의견. BSL(비즈니스 소스 라이선스)과 같은 라이선스가 완벽하지 않을 수 있지만, 건강한 중간길을 찾기 위한 노력으로 볼 수 있음.

• SSPL에 대한 비판을 하면서 AGPL을 언급하지 않은 것이 이상하다는 의견. 자유 소프트웨어를 사용하고자 하지만 기여를 하고 싶지 않은 사람들에 대한 지적.

• 어떤 한 쪽에 치우치지 않고, 각 경우에 따라 다르게 접근해야 한다는 의견. SSPL이 클라우드 거대 기업에 맞서 생존하려는 일부 회사들에게는 좋을 수 있지만, 기여자들을 이용하려는 일부 회사들에게는 나쁠 수 있음.

• MongoDB, Elasticsearch, Graylog 제품을 고객에게 직접 제안하는 것이 금지되어 있음. SSPL의 '직접'이라는 단어가 법적인 논쟁의 여지를 제공하고, 이로 인해 사람들이 우려하는 부분이 있음.

• FSL(Functional Source License)은 Apache 2.0이나 MIT로 2년 후에 자동으로 변환되는 좋은 대안 라이선스임. 간단하고, 소스를 공개하면서 SaaS 회사가 기능할 수 있는 합리적인 방법을 제공함.

• SSPL이 2008년에 도입되었다는 잘못된 정보에 대한 정정. 실제로는 2018년에 도입됨.

• 저작권의 미래에 대한 한 가지 차원적인 관점에 대한 비판.