# 상업용 제품에 넣는 GitHub 코드: 라이선스와 확인할 사항 > MIT, Apache, BSD와 같은 퍼missive 라이선스, GPL/AGPL 카피레프트, LICENSE 파일의 부재, AI가 추가한 코드의 출처 확인. Source: https://ailoot.ai/blog/ko/github-code-commercial-licenses/ Canonical: https://ailoot.ai/blog/ko/github-code-commercial-licenses/ Language: ko Publisher: Ailoot (https://ailoot.ai/) Translation: guide-177 Revision: sha256-3d00dce1b64f89040ca5d2a63ffb94f41bb0afbae50dfbe93913f88614621f25 제품을 만들다가 GitHub에서 바로 쓸 수 있는 것을 발견합니다. 라이브러리나 템플릿, 또는 필요한 기능을 정확히 수행하는 프로젝트 전체일 수도 있습니다. Claude는 이를 프로젝트에 가져오라고 제안합니다. 그러다 잠시 멈춥니다. 코드가 공개되어 있는 것 같지만 실제로 사용해도 될까요? 그 코드를 포함한 제품을 판매하는 것은요? 나중에 저자가 문제를 제기할 수도 있을까요? 차례대로 살펴보겠습니다. GitHub에 공개된 코드가 그 자체로 사용 허가를 의미하지 않는 이유, 코드를 사용하고 제품을 판매할 수 있게 해주는 라이선스, 적용 작업의 대응 소스를 요구할 수 있는 카피레프트 조건, 그리고 코드를 사용하기 전에 1분 안에 라이선스를 확인하는 방법을 알아봅니다. “상황에 따라 다릅니다”라는 답은 하지 않겠습니다. [Ailoot 사용에 관한 실용적인 정보는 문서에서 확인할 수 있습니다](https://ailoot.ai/docs/).
주의 이 자료는 참고용이며, 저는 변호사가 아닙니다. 아래에서는 주요 라이선스의 조건과 규칙을 1차 출처 링크와 함께 설명하지만, 구체적인 상황은 라이선스 원문을 기준으로 확인하고 제품 규모가 크고 상업적이라면 변호사와도 상담하세요. 결정은 직접 내려야 합니다.
## GitHub에 있는 코드는 무료로 사용할 수 있다는 말이 맞을까요?
핵심 내용 아니요. 코드를 볼 수 있다는 사실만으로 자신의 작업에 사용할 수 있는 것은 아닙니다. 기본적으로 모든 코드는 저작권으로 보호되며, 저자가 별도로 허가하지 않는 한 사용할 수 없습니다. GitHub에 게시하는 것만으로 다른 사람이 저장소를 보고 GitHub 안에서 복사본을 만들 수 있게 됩니다. 그 코드를 제품에 넣을 권리는 저자가 저장소에 적용한 라이선스에서 비롯됩니다. GitHub 자체가 그 권리를 부여하지는 않습니다.
여기서 가장 큰 함정은 “공개”라는 말입니다. 소스 코드를 볼 수 있으니, 숨겨져 있지 않다는 이유로 사용해도 된다고 생각하기 쉽습니다. 그 논리는 틀렸습니다. “읽을 수 있도록 공개됨”과 “사용이 허가됨”은 서로 다릅니다. 코드를 포함한 모든 창작물은 만들어지는 순간부터 기본적으로 저작권의 보호를 받습니다. 저자가 명시적으로 허가하기 전까지는 사용할 수 없습니다. GitHub도 자체 라이선스 참고 페이지에서 이렇게 설명합니다.

창작물(코드 역시 창작물입니다)을 만들면 기본적으로 배타적 저작권의 보호를 받습니다. 달리 정하는 라이선스를 첨부하지 않는 한, 다른 사람은 법적 청구나 소송의 위험을 감수하지 않고서는 작품을 복사, 배포 또는 수정할 수 없습니다.

— choosealicense.com (GitHub 참고 프로젝트), https://choosealicense.com/no-permission/
두 번째로 살펴볼 것은 GitHub 자체입니다. 코드를 게시하면서 GitHub의 규칙에 동의했으니, 그곳에서 다른 사람의 코드도 사용할 수 있다고 생각하는 경우가 있습니다. 규칙은 정반대라고 명시합니다. 저장소를 공개하면 저자는 다른 사람이 저장소를 보고 포크하도록 허용할 뿐입니다. 즉, GitHub 안에서 복사본을 만들 수 있게 하는 것입니다. 이것이 그 코드를 자신의 작업에 사용하는 권한을 주지는 않습니다.

저장소를 공개하면 다른 사용자에게 서비스의 GitHub 기능 범위 안에서 자료를 사용, 표시하고 (포크를 통해) 복제할 수 있는 비독점적이고 전 세계적인 라이선스를 부여합니다. 라이선스를 첨부하면 추가 권리를 부여할 수 있습니다.

— GitHub 서비스 약관, D절, https://docs.github.com/en/site-policy/github-terms/github-terms-of-service
핵심 문구는 마지막 문장에 있습니다. “GitHub 기능 범위 안에서”, “추가 권리는 라이선스에서 비롯됩니다.” 포크는 GitHub 안에 머뭅니다. 자신의 제품에 코드를 사용하려는 순간, 판매하려는 경우는 말할 것도 없이, 저자의 별도 라이선스가 필요합니다. 라이선스가 없으면 권리도 없습니다. 코드가 바로 눈앞에 공개되어 있어도 마찬가지입니다. ## 다른 사람의 코드를 사용할 수 있는지는 무엇으로 결정될까요?
핵심 내용 저장소에 있는 라이선스 파일이 결정합니다. 보통 LICENSE 또는 LICENSE.md라는 이름을 사용합니다. 이 파일은 저자가 부여한 허가이며, 코드로 할 수 있는 일과 할 수 없는 일을 정합니다. 라이선스는 세 가지 질문에 답합니다. 코드를 상업용 제품에 사용할 수 있는가? 수정할 수 있는가? 자신의 소스 코드를 비공개로 유지할 수 있는가? 라이선스마다 답이 다르므로, 먼저 이 파일을 확인한 다음에 코드를 열어봐야 합니다.
결국 파일 하나에 달려 있습니다. 제대로 관리되는 저장소에는 라이선스 파일이 있습니다. 대개 LICENSE, 때로는 LICENSE.md라는 이름을 쓰며, README에 직접 언급되기도 합니다. 이 파일은 코드를 사용할 수 있는 조건을 정하는 저자의 허가입니다. GitHub는 보통 파일을 열어보기도 전에 저장소 페이지의 사이드바에 라이선스 이름을 표시합니다. 법률 문구에 길을 잃지 않으려면 자신의 상황에 관한 세 가지 질문을 기준으로 라이선스를 읽으면 좋습니다. 1. **사람들이 돈을 내는 상업용 제품에 이 코드를 사용할 수 있는가?** 2. **필요에 맞게 코드를 수정할 수 있는가?** 3. **나중에 제품의 소스 코드를 공개해야 하는가, 아니면 비공개로 유지할 수 있는가?** 라이선스 간 차이는 거의 모두 세 번째 질문에 대한 답에서 비롯됩니다. 앞의 두 질문에 대해 널리 쓰이는 오픈 라이선스는 대개 “예”라고 답합니다. 사용하고, 수정하고, 판매해도 됩니다. 하지만 자신의 코드를 공개해야 하는지에서 많은 사람이 어려움을 겪습니다. 이제 이 세 가지 질문을 기준으로 주요 라이선스 유형을 살펴보겠습니다. ## 어떤 라이선스가 코드를 사용하고 제품을 판매하도록 허용할까요?
핵심 내용 상업용 제품에 가장 편리한 것은 MIT, Apache 2.0, BSD와 같은 퍼missive 라이선스입니다. 코드 사용과 수정, 제품 판매, 자체 소스 코드 비공개 유지까지 거의 모든 것을 허용합니다. 의무는 하나 있습니다. 라이선스 전문과 저작자 표시를 보존해야 합니다. Apache 2.0은 특허 청구로부터 보호하고 수정한 파일을 표시하도록 요구하기도 합니다. 다른 사람의 코드에 이 라이선스 중 하나가 적용되어 있다면 상업용 제품에 안심하고 사용할 수 있습니다.
먼저 반가운 소식부터 보겠습니다. 판매할 제품을 만드는 사람에게 가장 좋은 선택은 퍼missive 라이선스라고 불리는 라이선스 그룹입니다. 종류는 여러 가지지만 가장 흔한 세 가지는 MIT, Apache 2.0, BSD입니다. 세 라이선스 모두 앞의 두 질문에 “예”라고 답하며, 자체 소스 코드를 비공개로 유지할 수 있게 합니다. 가장 흔하고 간단한 것은 MIT입니다. 전문이 한 문단에 들어갑니다.

이 소프트웨어의 사본을 취득하는 모든 사람에게, 위 저작권 표시와 이 허가 표시를 모든 사본에 포함하는 조건으로 소프트웨어를 제한 없이 사용할 수 있는 권한을 무료로 부여합니다. 여기에는 사본의 사용, 복사, 수정, 병합, 게시, 배포, 재라이선스 및 판매 권리가 포함됩니다.

— MIT 라이선스, opensource.org, https://opensource.org/license/mit
쉽게 말해 MIT는 제품을 판매하고 자체 소스 코드를 비공개로 유지하는 것을 포함해 코드로 거의 무엇이든 할 수 있게 해줍니다. 유일한 의무는 라이선스 전문과 저작자 표시를 포함하는 것입니다. 예를 들어 Babel, .NET, Rails는 MIT로 배포되므로, 여러분도 이 라이선스가 적용된 코드를 이미 사용했을 가능성이 매우 높습니다. Apache 2.0도 비슷하지만 중요한 점 두 가지를 추가합니다. 첫째, 특허 청구에 대한 명시적 보호입니다. 코드의 저자는 이 코드와 관련된 특허로 여러분을 고소하지 않겠다고 약속합니다. 둘째, 사용과 관련한 몇 가지 공식 요건이 더 있습니다.

수정 여부와 관계없이 모든 매체에서 저작물 또는 2차적 저작물의 사본을 복제하고 배포할 수 있습니다. 단, 수령인에게 이 라이선스의 사본을 제공하고, 수정한 파일을 표시하고, 저작권 및 특허 고지를 유지하며, NOTICE 파일이 있는 경우 읽을 수 있는 사본을 포함해야 합니다.

— Apache 라이선스 2.0, 제4절, https://www.apache.org/licenses/LICENSE-2.0
BSD(2조항 및 3조항 버전)는 본질적으로 MIT와 비슷합니다. 사용하고, 수정하고, 판매할 수 있으며 저작권 표시를 보존해야 합니다. 한눈에 차이를 볼 수 있도록 세 라이선스를 표로 정리했습니다. | 라이선스 | 제품 판매 | 소스 코드 비공개 유지 | 해야 할 일 | 특허 보호 | |----|----|----|----|----| | MIT | 예 | 예 | 저작권 표시와 라이선스 전문 보존 | 관련 조항 없음 | | Apache 2.0 | 예 | 예 | 저작권 표시, NOTICE 파일, 수정 사항 표시 | 예 | | BSD (2조항 및 3조항) | 예 | 예 | 저작권 표시 보존 | 아니요 | 자신의 상황에 적용하면 이렇습니다. 다른 사람의 코드에 MIT, Apache 2.0 또는 BSD가 표시되어 있다면 안심해도 됩니다. 상업용 제품에 사용하고, 수정하고, 자체 소스 코드를 비공개로 유지할 수 있습니다. 가져온 부분에서 라이선스 파일과 저작자 표시를 제거하지 않으면 됩니다. ## GPL과 AGPL의 소스 의무는 어떻게 적용되나요?
핵심 내용 GPL·AGPL은 상업적 사용을 허용합니다. GPL 소스 의무는 적용 작업을 전달할 때 발생하며 사본 전달 없는 일반 서버 이용 자체가 그 계기는 아닙니다. AGPLv3는 수정 버전과 원격 상호작용하는 사용자에게 소스 제공을 요구합니다. 별도 독립 구성 요소가 자동으로 모두 포함되는 것은 아닙니다.
카피레프트는 해당 조건에서 적용 작업과 파생물의 같은 라이선스를 유지합니다. GPLv3 적용·결합 파생 작업의 소스나 목적 코드 배포에는 라이선스와 대응 소스 의무를 따라야 하지만 같은 제품·서버의 모든 독립 프로그램에 자동 적용되지는 않습니다. 서버에 GPL 라이브러리를 두고 사용자에게 사본을 주지 않는 것만으로 서비스 전체 공개가 요구되지는 않습니다. 결합 앱을 고객에게 배포하면 의무가 발생할 수 있으므로 통합 방식과 라이선스를 확인하세요. 사용자에게 전달하는 브라우저 클라이언트는 별도 배포 문제입니다. AGPLv3 프로그램을 수정하고 사용자가 그 버전과 원격 상호작용한다면 대응 소스를 눈에 띄게 제공해야 합니다. AGPL 구성 요소를 호스팅했다는 이유로 독립 서비스 전체가 공개된다는 말보다 정확합니다. 비공개 제품에서는 적용 작업, 결합 방식, 사본 배포, AGPL 네트워크 조건을 확인하세요. 충족할 수 없다면 호환 허용 라이선스 대안이나 별도 허가를 구하세요. 상업 사용 자체보다 실제 라이선스·통합 준수가 문제입니다. ## 저장소에 라이선스 파일이 전혀 없다면 어떻게 해야 할까요?
핵심 내용 라이선스 파일이 없으면 코드를 사용할 수 없습니다. 이는 “무료”라는 뜻이 아닙니다. 오히려 라이선스가 없으면 코드는 저자의 완전한 저작권 보호 아래 남고, 여러분에게는 이를 사용하거나 복사하거나 수정할 권리가 없습니다. GitHub 안에서 보고 포크할 수 있다는 허가도 도움이 되지 않습니다. 코드를 제품에 넣을 권리를 주지 않기 때문입니다. 정말 필요한 코드라면 저자에게 연락해 허가를 요청하거나, 라이선스가 추가될 때까지 기다리는 것이 유일하게 올바른 방법입니다.
흔히 하는 실수는 라이선스가 없으면 제한도 없으니 코드를 자유롭게 사용해도 된다고 생각하는 것입니다. 반대입니다. 라이선스가 없다는 것은 허가가 아닙니다. 기본적으로 허가가 없다는 뜻입니다. 라이선스가 없는 코드는 저자의 완전한 저작권 보호 아래 있으므로 건드릴 수 없습니다. 처음에 설명한 규칙이 다시 적용됩니다. 코드는 기본적으로 저작권의 보호를 받으며, 명시적 허가 없이는 복사, 수정 또는 배포할 수 없습니다. GitHub 안에서 보고 포크할 수 있다고 해서 이 장벽이 사라지는 것은 아닙니다. 자신의 제품에 코드를 사용할 권리를 부여하지 않습니다. 라이선스가 없지만 코드가 꼭 필요한 경우 실제로 할 일은 다음과 같습니다. 1. **저자에게 연락하세요.** 저장소의 토론 섹션이나 이메일로 직접 코드 사용이 가능한지, 어떤 조건인지 물어보세요. 저자가 라이선스 추가를 깜빡했을 뿐이라면 요청을 받고 추가할 수도 있습니다. 2. **대체 코드를 찾아보세요.** 거의 모든 작업에는 비슷한 저장소가 두 번째, 세 번째, 열 번째까지 있습니다. 그중에는 적절한 MIT 또는 Apache 라이선스가 적용된 저장소가 있을 것입니다. 3. **사용하지 마세요.** 허가도 없고 대체 코드도 없다면 그 코드는 여러분의 것이 아니며, 판매하려는 제품에 넣을 수 없습니다. “누가 알아차리겠어?”라고 생각하고 싶은 마음은 제품이 돈을 벌고 주목을 받기 시작할 때 문제를 일으킵니다. ## Claude가 다른 사람의 코드를 프로젝트에 추가했다면 어떻게 해야 할까요?
핵심 내용 이는 별개의 사례이므로 저장소에서 코드를 직접 복사하는 경우와 혼동하지 않는 것이 중요합니다. 특정 저장소에서 직접 코드를 가져오면 해당 라이선스를 따라야 합니다. Claude나 다른 AI가 요청에 따라 코드를 생성하는 경우에는 보통 다른 사람의 파일을 복사하기보다 작업에 맞춰 자체 텍스트를 만들어내므로, 생성된 코드의 권리 문제로 초점이 옮겨갑니다. 하지만 AI가 다른 사람의 라이선스 적용 코드를 알아볼 수 있을 만큼 명확히 재현했다면 라이선스 조건은 여전히 적용됩니다. 두 경우 모두 출처를 확인하는 편이 좋습니다.
여기에는 두 번째 측면이 있으며 첫 번째와 혼동하기 쉽습니다. 저장소에 방문해 파일을 복사하는 것은 앞서 설명한 라이선스 의무가 직접 적용되는 경우입니다. Claude가 요청에 따라 코드를 작성하는 경우는 다릅니다. 일반적인 경우 AI는 다른 사람의 파일을 복사하기보다 작업에 맞춰 자체 텍스트를 생성합니다. 그러면 질문은 다른 영역으로 옮겨갑니다. 생성된 코드는 누구에게 속하며 판매할 수 있을까요? 이는 별도의 큰 주제이며, AI가 작성한 코드는 누구의 소유인가라는 글에서 다뤘습니다. 하지만 기억해야 할 예외가 있습니다. 때로 AI는 유명한 라이브러리의 함수 전체처럼 다른 사람의 코드를 알아볼 수 있을 정도로 거의 한 글자씩 그대로 생성하기도 합니다. 이 경우 키를 실제로 누른 사람이 누구든 라이브러리의 라이선스가 계속 적용됩니다. 따라서 Claude가 통째로 가져온 큰 코드 블록은 직접 복사한 것처럼 확인해야 합니다. ## 코드를 사용하기 전에 라이선스를 확인하는 방법: 따라 할 단계
핵심 내용 절차는 다음과 같습니다. 저장소 페이지를 열어 사이드바의 라이선스 이름을 확인하고, LICENSE 파일을 직접 열어보세요. 유형이 퍼missive(MIT, Apache, BSD)인지 카피레프트(GPL, AGPL)인지 파악하고 자신의 상황과 비교한 뒤 코드를 사용할지 대체 코드를 찾을지 결정하세요. 라이선스가 전혀 없다면 코드를 사용하지 마세요. 확인에는 몇 분이면 충분하며, 코드가 프로젝트에 들어간 뒤가 아니라 들어가기 전에 해야 합니다.
프로젝트에 넣기 전에 모든 타사 코드를 확인할 수 있도록 짧은 점검 목록으로 정리해보겠습니다. 위에서부터 차례대로 진행하세요. 1. ### 저장소 페이지에서 라이선스 이름 찾기 GitHub에서 저장소를 여세요. 라이선스 이름은 보통 오른쪽 열이나 파일 목록 아래에서 볼 수 있습니다. 예를 들면 “MIT License”, “Apache-2.0”, “GPL-3.0”입니다. 표시가 비어 있고 라이선스 파일도 없다면 이미 경고 신호입니다. 마지막 단계에서 다시 확인하세요. 2. ### 라이선스 파일 직접 열기 파일 목록에서 LICENSE, LICENSE.md 또는 COPYING을 찾아 여세요. 이름이 사이드바에 표시된 것과 일치하는지, 라이선스가 저장소의 별도 부분만이 아니라 사용하려는 코드에도 적용되는지 확인하세요. 3. ### 유형 확인: 퍼missive 또는 카피레프트 MIT, Apache 2.0, BSD는 퍼missive 라이선스이므로 비공개 상업용 제품에 코드를 사용할 수 있습니다. GPL·AGPL은 카피레프트이므로 적용 작업, 배포, AGPL 네트워크 조건을 확인한 뒤 소스 의무를 정하세요. 이름만으로 독립 구성 요소의 포함 범위를 알 수는 없습니다. 4. ### 자신의 상황과 비교하기 세 가지 질문에 답하세요. 제품을 판매하나요? 코드를 수정하나요? 소스 코드를 비공개로 유지하고 싶나요? MIT, Apache, BSD는 판매용 비공개 제품에 적합합니다. GPL·AGPL은 어떤 적용·결합 작업의 대응 소스가 언제 필요한지 정하고 의무 충족 가능성을 평가하세요. 5. ### 라이선스가 없으면 사용하지 않기 라이선스 파일이 없고 README에도 허가에 관한 내용이 없다면 코드를 사용할 수 없습니다. 저자에게 연락해 허가를 요청하거나 적절한 라이선스가 적용된 동등한 코드를 찾으세요. “공개되어 있다”는 것은 허가가 아닙니다. 이 점검은 제품이 성장하고 돈을 벌기 시작해 누군가 제품 안의 타사 코드를 묻기 전까지는 번거롭게 느껴집니다. 시작할 때 들이는 2분이 나중에 분쟁을 해결하는 것보다 비용이 적게 듭니다. 출시 뒤 제품이 멈추지 않도록 무엇을 해야 할지도 별도로 다뤘습니다. [AI로 제품을 만들었어요. 이제 무엇을 해야 할까요?](https://ailoot.ai/blog/ko/ai-product-maintenance-after-launch/).
### 자주 묻는 질문 GitHub에서 가져온 다른 사람의 코드가 들어간 제품을 판매할 수 있나요? 네, 코드에 MIT, Apache 2.0 또는 BSD와 같은 퍼missive 라이선스가 적용되어 있다면 가능합니다. 이 라이선스는 상업용 제품에 코드를 사용하고, 제품을 판매하며, 자체 소스 코드를 비공개로 유지할 수 있게 합니다. 라이선스 전문과 저작자 표시만 보존하면 됩니다. GPL·AGPL도 상업 사용을 허용하지만 소스 의무는 적용 작업과 배포 또는 해당 AGPL 네트워크 조건에 달려 있습니다. 라이선스 파일이 없다면 코드를 전혀 사용할 수 없습니다. GitHub 저장소에 라이선스가 없다는 것은 무슨 뜻인가요? 코드를 사용할 수 없다는 뜻입니다. 라이선스가 없으면 기본적으로 허가가 없다는 뜻이며, “무료”라는 뜻이 아닙니다. 코드는 저자의 완전한 저작권 보호 아래 남습니다. GitHub 안에서 저장소를 보고 포크할 수 있어도 제품에 코드를 사용할 권리는 생기지 않습니다. 코드가 필요하다면 저자에게 연락해 허가를 요청하거나 오픈 라이선스가 적용된 동등한 코드를 찾으세요. 제품에서 MIT와 GPL은 어떻게 다른가요? MIT는 코드를 사용하고 수정하고, 제품을 판매하며, 자체 소스 코드를 비공개로 유지할 수 있게 해줍니다. 의무는 라이선스 전문을 보존하는 것뿐입니다. GPL도 상업 사용을 허용합니다. 적용 결합·파생 작업 전달 시 대응 소스와 같은 라이선스 의무를 준수해야 합니다. 사본 없는 호스팅은 다르며 별도 독립 요소가 자동 포함되지는 않습니다. MIT 라이선스 코드를 사용하면 해야 할 일이 있나요? 네, 한 가지 간단한 일이 있습니다. 프로젝트에서 사용한 코드의 MIT 라이선스 전문과 저작자 표시를 보존하세요. 보통 원본에 첨부된 LICENSE 파일이 이에 해당합니다. MIT는 그 밖의 의무를 요구하지 않습니다. 코드를 수정하고, 제품을 판매하고, 소스 코드를 비공개로 유지할 수 있습니다. 내가 아니라 Claude가 다른 사람의 코드를 추가했다면 어떻게 해야 하나요? 그래도 출처를 확인해야 합니다. AI는 보통 작업에 맞는 자체 텍스트를 생성하므로, 이 경우 생성된 코드의 권리라는 별도 문제로 초점이 옮겨갑니다. 하지만 AI가 유명한 라이브러리의 다른 사람 코드를 알아볼 수 있을 만큼 거의 그대로 재현했다면 그 라이브러리의 라이선스는 계속 적용됩니다. 통째로 가져온 큰 코드 블록은 직접 복사해 붙여넣은 경우처럼 확인하세요.
### 출처 - [choosealicense.com - 라이선스 선택을 위한 GitHub 참고 프로젝트](https://choosealicense.com/) - [choosealicense.com - 라이선스가 없다는 것의 의미](https://choosealicense.com/no-permission/) - [GitHub 서비스 약관, D절(다른 사용자에 대한 라이선스 부여)](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service) - [MIT 라이선스 (opensource.org)](https://opensource.org/license/mit) - [Apache 라이선스 2.0 (apache.org)](https://www.apache.org/licenses/LICENSE-2.0) - [GNU General Public License v3.0 (gnu.org)](https://www.gnu.org/licenses/gpl-3.0.en.html) - [GNU Affero General Public License v3.0 (gnu.org)](https://www.gnu.org/licenses/agpl-3.0.en.html)
[Ailoot 열기](https://ailoot.ai/). ## 상업용 제품에 넣는 GitHub 코드: 라이선스와 확인할 사항: 자주 묻는 질문 ### GPL 라이브러리를 호스팅하면 웹서비스 전체를 공개해야 하나요? 사본 전달 없는 호스팅 자체는 GPL 배포 계기가 아닙니다. 적용 결합·파생 앱을 배포하면 해당 작업의 소스 의무가 생길 수 있지만 독립 요소는 자동 포함되지 않습니다. ### AGPLv3가 웹서비스에 더하는 조건은 무엇인가요? 원격 네트워크 상호작용을 지원하는 수정 AGPL 프로그램은 그 사용자에게 대응 소스를 제공해야 합니다. 소스가 전혀 필요 없거나 모든 독립 서비스를 공개해야 한다고 가정하지 말고 적용 프로그램과 통합을 확인하세요. ## Ailoot · 회사와 그 프로젝트 포트폴리오 Ailoot는 축적된 운영 경험, 폭넓은 고객 기반, 안정적인 서비스, 지속적인 KPI 관리를 바탕으로 합니다. 회사와 그 프로젝트 포트폴리오: 수백만 고객, 매월 수십억 규모의 매출. Ailoot는 이러한 운영 경험을 고객의 제품, 에이전트, 애플리케이션, 자동화에서 AI 기능을 이용할 수 있는 API 접근에 활용합니다.