28년간 LGPL·MIT를 쓴 개발자가 SaaS 허점을 이유로 EUPL 1.2를 기본 라이선스로 변경

비코드 작업에는 나도 점점 CC BY-NC-ND를 쓰게 됨. 늘 그러는 건 아니고, 솔직히 내키진 않지만.

ND는 결과물을 막다른 길로 만들어서 아쉬움. 웹의 재미는 재해석하며 계속 변형되는 데 있는데 ND면 그게 문화적으로 끊김.

크리에이티브 커먼즈도 비상업적 사용을 명확히 정의하지 못했음. 출처만 제대로 밝히고 발표 자료 같은 용도가 상업적인지 따지는 일은 이제 그만두고 있음.

EUPL은 앞에서 조건 없는 권리를 준다고 했다가 뒤에서 조건을 붙이는 문구가 마음에 안 듦. 조건이 실제로 집행 가능한지 바로 확신하기 어려움. 그래도 Distribution뿐 아니라 Communication을 넣은 건 좋음.

코드가 공개돼 있으면 토큰으로 다시 구현하고 출처를 부인하기 쉬운 시대인데, 이런 라이선스가 아직 실효가 있나 싶음.

동형 표절은 싫지만 그 지적은 유효함. 이미 약 9조 달러어치 오픈소스 작업이 가져가졌다는 추산도 있으니 말임.

서비스로 쓰는 회사를 라이선스로 묶으면 기여할 거라는 생각 자체가 잘못됐다고 봄. 회사는 기여하지 않고 그 소프트웨어를 교체함.

LLM이 리눅스 커널 같은 대형 GPL 소프트웨어를 처음부터 안정적으로 대체 구현할 수 있다고 믿는 건 마케팅에 속는 것 같음. 내가 본 LLM은 작은 문제나 명세가 아주 분명한 문제에서만 잘했음.

예전에도 악의가 있고 코드 출처를 거짓말할 사람은 라이선스를 피할 수 있었음. 다만 생성형 AI가 그 표절을 훨씬 쉽게 만든 건 맞음.

나는 FOSS에는 Apache 2.0을 선호함. 내 작업 일부로 사업하는 건 괜찮고, 상업 지원 티켓을 커뮤니티나 원작자에게 떠넘기지만 않으면 됨.

카피레프트는 사업을 막는 게 아니라 수정분을 공개하라고 하는 것뿐임.

글이 LGPL의 어떤 문제가 있었는지 나열하고 EUPL이 각각 어떻게 해결하는지 설명했어야 함. 지금처럼 암시만 해서는 개발자나 HN 독자에게 부족함.

글에서 저자가 말한 건 꽤 분명함. LGPL은 너무 약하고, 주요 관심사는 AGPL도 다루는 SaaS 허점이며 EUPL도 이를 다룬다는 주장임.

취미나 상업 환경의 PoC는 무료로 두되 운영 사용에는 돈을 받는 이중 라이선스를 깔끔하게 할 방법이 있는지 궁금함. 새 프로젝트에서 이게 채택을 죽이는지도 알고 싶음.

Terraform이 쓴 BUSL을 최근 봤는데, 고수익 제품을 무료로 만드는 건 막고 다른 사용에는 비교적 자유로움. 다만 OSI 오픈소스 라이선스는 아님.

제한적 라이선스는 채택을 확실히 해침. 취미 사용자나 실험하는 사람은 먼저 법률 문구를 읽고 싶어 하지 않으니, 사업을 할 거면 공개할 범위를 더 골라서 MIT나 Apache 2.0으로 내는 편이 나음.