원문: Understanding the AGPL: The Most Misunderstood License | by Sayan | The Startup | Medium
오픈소스의 등장은 전체 소프트웨어 산업을 완전히 바꿔놓았습니다. 하지만 누가 오픈 소스 코드로 무엇을 할 수 있는지에 대한 통제는 어려운 과제였으며, 지금도 여전히 어려운 과제입니다. 바로 그때 오픈소스 라이선스가 등장했습니다. 하지만 항상 기억하세요. 돌이 없는 땅은 없고 뼈가 없는 고기는 없다는 사실을요. OSI에서 승인한 라이선스는 80개가 넘고 그 수는 계속 증가하고 있으며, 각 라이선스마다 장단점이 있기 때문에 오픈소스 개발자는 프로젝트에 적합한 라이선스를 선택하기가 어렵습니다. Affero 일반 공중 라이선스의 줄임말인 AGPL은 이러한 라이선스 중 하나이며, 특히 강력한 카피레프트 라이선스이며, 가장 많은 오해를 받는 라이선스 중 하나입니다.
왜 다른 GPL일까요?
잠깐, 뭐라고요? 또 다른 GPL이라고요? 네, 맞습니다. AGPL은 섹션 13에 추가된 조항을 제외하고는 GPL과 거의 동일합니다:
본 허가서의 다른 조항에도 불구하고, 당신이 프로그램을 수정하는 경우, 당신의 수정된 버전은 컴퓨터 네트워크를 통해 원격으로 상호작용하는 모든 사용자에게 (당신의 버전이 그러한 상호작용을 지원하는 경우) 소프트웨어 복사를 용이하게 하는 표준 또는 관례적인 수단을 통해 네트워크 서버로부터 해당 소스에 대한 액세스를 무료로 제공함으로써 당신의 버전의 해당 소스를 받을 수 있는 기회를 눈에 띄게 제공해야 합니다. […]
여기에는 한 가지 직접적인 의미가 있습니다. 사용자가 네트워크를 통해 AGPL 라이선스가 부여된 소프트웨어에 액세스할 수 있도록 한다면, 그것도 배포의 한 형태가 됩니다. 이것이 바로 GPL이 놓치고 있던 부분입니다. 클라우드 시대의 붐과 함께 SaaS가 폭발적으로 증가하면서 개발자와 공급업체는 소프트웨어를 직접 배포하는 대신 디지털 방식으로 소프트웨어를 제공하기 시작했습니다.
Bob이 개발한 바이너리 애플리케이션(라이브러리가 아님)을 예로 들어 보겠습니다. 웹 앱의 리소스가 부족할 때마다 자동으로 더 많은 리소스를 할당하는 데 사용할 수 있는 이 애플리케이션을 쉽게 설명하기 위해 XBin이라고 부르기로 하겠습니다. (참고: 이것은 예시입니다.)
1단계: 밥이 GPL 사용
밥은 GPL을 사용하기로 결정합니다. 모든 사용자가 버그를 발견하거나 기능이 추가되기를 원할 때마다 그에게 패치를 보내주기 때문에 밥에게 매우 유용합니다. 밥은 기꺼이 그들의 코드를 병합하고 행복해합니다! 그러던 어느 날 대형 클라우드 제공업체인 ProviderX가 더 많은 기능을 갖춘 프로젝트 관리 제품군의 일부로 XBin을 제공하고 있다는 사실을 알게 됩니다. 그는 이 사실에 대해 불만을 품게 되는데, 그 이유는 ProviderX가 이러한 기능을 패치로 제출하여 XBin을 개선했으면 좋았을 것이기 때문입니다. 이제 밥은 GPL이 네트워크 배포를 다루지 않기 때문에 법적으로 아무것도 할 수 없습니다!
2단계: 밥은 AGPL로 전환합니다.
GPL 라이선스의 단점을 깨달은 Bob은 다음 릴리스부터 AGPL로 전환합니다. 이제 ProviderX가 변경 사항을 적용하여 사용자에게 서비스로 배포할 때마다 동일한 라이선스에 따라 소스 형태로 변경 사항을 제공해야 합니다. 따라서 Bob은 개선 사항을 자신의 소스 코드에 병합할 수 있습니다. 이제 공정한 경쟁이 시작되었습니다! 그 이후로 밥은 행복하게 코딩을 했습니다.
수용 문제
하지만 대형 클라우드 업체들은 이를 좋아하지 않았습니다! 몇몇 회사는 이와 같은 자체적인 AGPL 정책을 가지고 있으며, 일부 사람들은 AGPL이 독성이 있다며 채택 및 사용에 반대하는 목소리를 내기도 했습니다. 하지만 여러 SaaS 제공업체 사이에서 AGPL 채택이 계속 증가하고 있으며, DBaaS 제공업체가 가장 많이 채택하고 있습니다. 대부분의 사람들이 놓치고 있는 요점은 AGPL은 배포를 네트워크 배포로 정의하는 GPL의 상위 집합일 뿐 그 이상은 아니라는 점입니다!
이제 AGPL 라이선스 바이너리를 사용할 때의 찬성과 반대에 대해 살펴보겠습니다. 제 프로젝트인 Skytable을 예로 들어보겠습니다.
시나리오 1: 수정되지 않은 AGPL 바이너리 사용
밥이 다시 돌아왔지만 이번에는 데이터를 저장하는 데 AGPL 라이선스 데이터베이스인 Skytable을 사용하면서 웹 앱을 구축하기로 결정했습니다. 그의 앱을 통해 사람들은 자신이 좋아하는 책을 등록하고 저장할 수 있으며, 이 데이터는 AGPL 라이선스 데이터베이스에 저장됩니다.
밥은 혼란스러워합니다: 앱의 코드를 오픈소스화해야 하나요?
정답은: 아니요! AGPL은 밥의 앱과는 아무런 관련이 없습니다! 밥은 데이터베이스를 수정하지 않았고, 단지 바이너리 형태로 “있는 그대로” 사용하고 있기 때문에 앱을 개선하는 것 외에는 아무것도 할 필요가 없습니다!
시나리오 2: 수정된 AGPL 바이너리 사용
밥은 이제 스카이테이블에 쿼리 유형 X가 있었다면 더 편리했을 것이라는 사실을 깨닫습니다. 그래서 그는 소스 코드를 다운로드하여 수정합니다. 이제 그는 파생 저작물이라고 할 수 있는 것을 만들었지만 직접 배포하지는 않았습니다.
밥은 혼란스러워합니다: 앱의 코드를 오픈소스화해야 하나요?
답은 간단합니다: 아니요! 사용자가 데이터베이스에 직접 액세스할 수 있도록 하지 않았기 때문에 데이터베이스에 대한 변경 사항을 돌려줄 필요도 없습니다. 앱의 코드는 여전히 자신의 소유입니다.
시나리오 3: 비공개로 수정된 버전 사용
Bob의 사무실 직원들은 수정된 버전의 Skytable이 마음에 들어 회사 내에서 사용하고 싶어 합니다. Bob의 동료 직원들도 직장 사용자가 자신을 인증할 수 있도록 Skytable에 몇 가지 인증 기능을 추가했습니다. 하지만 이 코드는 Skytable의 작성자(즉, 저입니다!)에게 돌려주어도 안전하지 않습니다.
밥은 혼란스러워합니다: 변경 사항을 공개해야 하나요?
정답은 아니요! Bob은 조직 내에서 내부적으로 사용하고 있기 때문에 다른 사람에게 배포하지 않습니다. 수정된 AGPL 소프트웨어의 사본은 변경 사항을 공개하지 않고 보관할 수 있습니다.
이 예시를 충분히 잘 따랐다면, AGPL은 여러분의 앱이나 AGPL 바이너리를 백엔드로 사용하는 서비스에 대해 신경 쓰지 않고, 대신 여러분이 AGPL 라이선스 바이너리로 무엇을 하는지에 대해 신경 쓴다는 것을 분명히 알 수 있을 것입니다.
결론
간단히 한 줄로 요약하자면, AGPL 라이선스 바이너리를 수정하지 않고 “있는 그대로” 사용한다면 많은 생각을 할 필요 없이 그냥 작업만 하면 됩니다! 그러나 AGPL 코드를 변경하여 배포하는 경우, 법적으로 올바른 상태를 유지하기 위해 사용자가 소스 형태로 수정 사항을 사용할 수 있도록 해야 합니다.
이제 댓글 섹션을 날려버리기 전에 한 가지 말씀드리자면, 이 글은 어떤 식으로든 법률적인 조언이 아닙니다! 제가 여러분과 저를 오도한 부분이 있다면 언제든지 바로잡아 주세요.
흥미로운 읽을거리
오픈 소스에 대한 리더십 부족으로 인한 소스 사용 가능 라이선스 문제
소스 사용 가능 대 오픈 소스 대 자유 소프트웨어
오픈소스에 대한 아마존 효과
방금 읽은 내용이 마음에 드신다면 
에 방문하여 이 글을 공유해 주세요! 또한, 깃허브의 스카이테이블도 살펴보세요!