추가로 pdf 보시면 osi 에 부합하지 않는 부분이 어떤 내용인지 설명도 되어 있습니다. 자유의 제약과 별도 저작물 제한이라는 점이라고 하네요.
오...전반적으로 훌륭히 잘 작성된 pdf네요. 링크 감사합니다.
이렇게 보니 AGPL과 다른 점이랑 SSPL을 허용안하는 이유는 이해하겠는데, OSI가 다소 Permissive 함에 치우쳐 있는게 아닌가 하는 생각이 드네요.
추가로 pdf 보시면 osi 에 부합하지 않는 부분이 어떤 내용인지 설명도 되어 있습니다. 자유의 제약과 별도 저작물 제한이라는 점이라고 하네요.
오...전반적으로 훌륭히 잘 작성된 pdf네요. 링크 감사합니다.
이렇게 보니 AGPL과 다른 점이랑 SSPL을 허용안하는 이유는 이해하겠는데, OSI가 다소 Permissive 함에 치우쳐 있는게 아닌가 하는 생각이 드네요.
저도 좀 의문이 있어 검색 중인데요, 이런 자료가 있어서 링크해 봅니다.
https://ceart.kr/component/file/…
발췌
우선 SSPL이 AGPL과 다른 점은 다음과 같다. 이전의 AGPL은 어떤 소프트웨어가 배포되지 않고, 서버 사이드에서 실행될 때도, GPL과 같이 서비스 제공자가 그 소프트웨어에 대하여 행한 수정 및 추가된 부분의 모든 소스코드를 공개해야 한다는 것으로, 서버 그 자체에 한정하고 있는 것에 반하여,
SSPL은 해당 코드뿐만 아니라, As-a-Service 형태로 제공할 때 부수적으로 필요한 관리 소프트웨어, 사용자 인터페이스, API, 자동화 소프트웨어, 모니터링 소프트웨어, 백업 및 저장 소프트웨어 등 As-a-Service 사용자가 실행하는 모든 소프트웨어의 코드를 공개해야 하는 조건이다. 다시 말해 클라우드 사업자들이 MongoDB를 서비스 형태로 제공할 때, 자신의 서비스 경쟁 우위를 유지하기 위해 만든 모든 소프트웨어의 소스 코드까지를 모두 공개해야 한다는 조건인 것이다.