diff --git a/content/ko/about/welcomepackage/_index.md b/content/ko/about/welcomepackage/_index.md index 84ac71bb52..90ca54ce08 100644 --- a/content/ko/about/welcomepackage/_index.md +++ b/content/ko/about/welcomepackage/_index.md @@ -33,7 +33,7 @@ KWG는 설립 이후 다음과 같은 주요 성과와 마일스톤을 달성했 4. **커뮤니티 확장**: 현재 약 70명의 멤버가 활발히 활동하며, 5-6년 이상의 지속적인 커뮤니티 활동을 통해 높은 수준의 전문성을 갖추게 되었습니다. 5. **온라인 플랫폼 구축**: [GitHub](https://github.com/OpenChain-KWG)를 통해 문서와 자료를 공유하고, Discord 채널을 통해 멤버 간 소통을 활성화했습니다. -KWG는 이러한 활동을 통해 한국 기업들의 오픈소스 관리 수준을 높이고, 글로벌 오픈소스 생태계에 기여하는 중요한 역할을 수행하고 있습니다. 앞으로도 지속적인 협력과 지식 공유를 통해 더 많은 기업들이 효과적으로 오픈소스를 활용하고 관리할 수 있도록 지원할 예정입니다. +KWG는 이러한 활동을 통해 한국 기업들의 오픈소스 관리 수준을 높이고, 글로벌 오픈소스 생태계에 기여하고 있습니다. 앞으로도 지속적인 협력과 지식 공유를 통해 더 많은 기업들이 효과적으로 오픈소스를 활용하고 관리할 수 있도록 지원할 예정입니다. ## 2. OpenChain KWG 활동 안내 @@ -288,7 +288,7 @@ KWG 회원들은 다음과 같은 다양한 방법으로 활동에 참여하고 ### 모임 장소 및 물품 후원 -KWG 활동에 대한 장소나 물질적 지원도 매우 중요한 기여 방법입니다. +KWG 활동에 대한 장소나 물질적 지원도 중요한 기여 방법입니다. - 정기 모임, 서브그룹 모임 등 다양한 KWG 모임을 위한 장소를 제공합니다. - 예: 회사 회의실이나 강당을 KWG 모임에 무상으로 대여 @@ -299,9 +299,9 @@ KWG 활동에 대한 장소나 물질적 지원도 매우 중요한 기여 방 - 모임의 원활한 진행을 돕고 참석자들의 만족도를 높입니다. - 후원 기업의 이미지를 긍정적으로 홍보할 수 있는 기회가 됩니다. -- KWG 커뮤니티의 결속력을 강화하고 지속적인 활동을 가능하게 합니다. +- KWG 커뮤니티의 결속력을 강화하고 지속적인 활동을 할 수 있게 합니다. -물질적 지원을 통한 기여는 직접적인 기술적 기여만큼이나 KWG의 성장과 발전에 중요한 역할을 합니다. 이는 커뮤니티의 지속가능성을 높이고, 더 많은 참여자들이 편안한 환경에서 지식을 공유하고 네트워킹할 수 있는 기회를 제공합니다. +물질적 지원을 통한 기여는 직접적인 기술적 기여만큼이나 KWG의 성장과 발전에 크게 보탬이 됩니다. 이는 커뮤니티의 지속가능성을 높이고, 더 많은 참여자들이 편안한 환경에서 지식을 공유하고 네트워킹할 수 있는 기회를 제공합니다. ### 왜 기여해야 하나요? 나에게 무슨 도움이 된다고? diff --git a/content/ko/blog/2021/20210115-opensource-license-used-by-it-companies/index.md b/content/ko/blog/2021/20210115-opensource-license-used-by-it-companies/index.md index 79eb101f97..b88a3e6a72 100644 --- a/content/ko/blog/2021/20210115-opensource-license-used-by-it-companies/index.md +++ b/content/ko/blog/2021/20210115-opensource-license-used-by-it-companies/index.md @@ -16,13 +16,13 @@ resources: ![featured-github](featured-github.png) Enterprise Software 개발 및 컨설팅을 하는 [EPAM](https://www.epam.com/) 에서는 Github 사용량을 측정하여 [OSCI (Open Source Contributor Index)](https://solutionshub.epam.com/osci) 이라는 랭킹 서비스를 제공하고 있습니다. -공개적으로 활용 가능한 Github 커밋 이벤트 데이터를 사용하여 상업 조직의 구성원들의 기여를 측정합니다. 대학, 연구기관 및 무료 이메일 공급자의 기여는 포함되지 않았다고 합니다. 10개 이상의 커밋을 수행한 기여자가 대상이며, 자체 연구한 알고리즘에 의해 활동량 점수를 측정한다고 합니다. 알고리즘은 [OSCI Github](https://github.com/epam/OSCI) 에 공개되어 있습니다. +공개적으로 활용 가능한 Github 커밋 이벤트 데이터를 사용하여 상업 조직의 구성원들의 기여를 측정합니다. 대학, 연구기관 및 무료 이메일 공급자의 기여는 포함되지 않았다고 합니다. 10개 이상의 커밋을 수행한 기여자가 대상이며, 자체 연구한 알고리즘으로 활동량 점수를 측정한다고 합니다. 알고리즘은 [OSCI Github](https://github.com/epam/OSCI) 에 공개되어 있습니다. ### OSCI (Open Source Contributor Index) [https://solutionshub.epam.com/osci](https://solutionshub.epam.com/osci) ![contributing-ranking](contributing-ranking.png) -분석 점수에 따르면 구글이 선두에 위치해 있으며, 마이크로소프트, 레드햇이 각각 다음 순위를 차지했습니다. 한국 기업으로는 삼성이 29위, LG 전자가 71위에 랭크 되어 있습니다. +분석 점수에 따르면 구글이 선두에 있으며, 마이크로소프트, 레드햇이 각각 다음 순위를 차지했습니다. 한국 기업으로는 삼성이 29위, LG 전자가 71위에 랭크 되어 있습니다. ## 기업별 라이선스 현황 OSCI를 통해 수집된 데이터로 추출된 [오픈소스 라이선스 사용조사](https://solutionshub.epam.com/blog/post/examining-open-source-license-usage) 도 주목해 볼만 합니다. Google Big Query 같은 툴을 이용하여 측정은 가능했지만 어뷰징 제거 등 유효한 데이터 필터링 안되어서 신뢰도가 낮은편이었는데, OSCI를 구축하면서 의미있는 Github 저장소들을 대상으로 통계를 낸 거라 유용할 것으로 보입니다. @@ -68,7 +68,7 @@ Apache는 Google, IBM 및 Red Hat에서 가장 선호하는 라이선스입니 ![gitlab-license-usage](gitlab-license-usage.png) -라이선스 파일이없는 리포지토리를 제외하면 아래 이미지는 MIT가 37 %로 가장 인기가 많았고, 사용자 지정 라이선스 텍스트가 21 %, GPL 3.0이 17 %, Apache 2.0이 10 %로 그 뒤를이었습니다. GitLab에서 요약하면 허용 라이선스 유형이 다시 가장 많이 사용되는 유형이지만 MIT가 리더이며 Apache 2.0 사용량은 GitHub보다 훨씬 적습니다. 카피 레프트 라이선스는 GitLab과 GitHub에서 비슷하게 적은 점유율을 가지고 있습니다. +라이선스 파일이없는 리포지토리를 제외하면 아래 이미지는 MIT가 37 %로 가장 인기가 많았고, 사용자 지정 라이선스 텍스트가 21 %, GPL 3.0이 17 %, Apache 2.0이 10 %로 그 뒤를이었습니다. GitLab에서 요약하면 허용 라이선스 유형이 다시 가장 많이 사용되는 유형이지만 MIT가 리더이며 Apache 2.0 사용량은 GitHub보다 훨씬 적습니다. 카피 레프트 라이선스는 GitLab과 GitHub에서 비슷하게 적은 점유율을 보입니다. ![gitlab-license-excluded-no-license](gitlab-license-excluded-no-license.png) diff --git a/content/ko/blog/2021/20210328-ElasticLicense/index.md b/content/ko/blog/2021/20210328-ElasticLicense/index.md index da1ccd5549..f566cc356d 100644 --- a/content/ko/blog/2021/20210328-ElasticLicense/index.md +++ b/content/ko/blog/2021/20210328-ElasticLicense/index.md @@ -107,7 +107,7 @@ MongoDB는 "[듀얼 라이선스](http://monty-says.blogspot.com/2009/08/thought ### SSPL -매우 강한 카피레프트 접근 방식은 2018년 [SSPL](https://www.mongodb.com/licensing/server-side-public-license)Server Side Public License을 만든 MongoDB에 의해 시도되었다. +매우 강한 카피레프트 접근 방식은 2018년 [SSPL](https://www.mongodb.com/licensing/server-side-public-license)Server Side Public License을 만든 MongoDB가 시도하였다. ~~~ 1. Offering the Program as a Service. @@ -140,19 +140,19 @@ MongoDB는 SSPL을 [OSI](https://opensource.org/approval)Open Source Initia ### 제한 조건을 갖는 소스 공개 라이선스 -다른 사람들은 또 다른 경로를 따랐다. 일부 회사는 Salil Deshpande가 주도한 [Commons Clause](https://commonsclause.com/)를 채택했으며, 어떤 회사는 Elastic이 Elastic License 1.0을 만든 것처럼 [Redis](https://redislabs.com/legal/licenses/), [Confluent](https://www.confluent.io/confluent-community-license), [CockroachDB](https://www.cockroachlabs.com/cockroachdb-community-license/)와 같은 자체 라이선스를 제작하였다. SSPL과는 달리, 이 라이선스들은 오픈소스 정의를 충족시키기 위한 것이 아니었다. 대신, 이들은 무상 사용을 겨냥한 제한 조건을 갖고 있다. +다른 사람들은 또 다른 경로를 따랐다. 일부 회사는 Salil Deshpande가 주도한 [Commons Clause](https://commonsclause.com/)를 채택했으며, 어떤 회사는 Elastic이 Elastic License 1.0을 만든 것처럼 [Redis](https://redislabs.com/legal/licenses/), [Confluent](https://www.confluent.io/confluent-community-license), [CockroachDB](https://www.cockroachlabs.com/cockroachdb-community-license/)와 같은 자체 라이선스를 제작하였다. SSPL과는 달리, 이 라이선스들은 오픈소스 정의를 충족시키기 위한 것이 아니었다. 대신, 이들에게는 무상 사용을 겨냥한 제한 조건이 있다. 왜 이렇게 두 가지 경로로 갈렸을까? 이는 [Freedom Zero](https://www.gnu.org/philosophy/free-sw.en.html), "어떤 목적으로든 원하는 대로 프로그램을 실행할 수 있는 자유"와 관련이 있다[^free]. [^free]: The Free Software Definition is similar to the Open Source Definition, but shorter and clearer. -오픈소스 또는 자유소프트웨어 라이선스의 주요 특징은 라이선스 제약이나 제한이 없다는 것이다[^limitation]. 일반적인 상용 소프트웨어 라이선스와 비교해보자. 개인용으로 사용하겠다는 라이선스 조건에 클릭하여 수락하는 형태의 최종 사용자 라이선스End User license Agreement는 소프트웨어를 사용하는 것만 허용하며, 변경하거나 배포할 수 없다. 엔터프라이즈 라이선스는 소프트웨어를 사용할 수 있는 사용자, 서버 또는 물리적 위치의 수에 대한 제한을 설정하고, 기업은 해당 사용을 감시해야 한다. 그러나 오픈소스 라이선스에는 그러한 제한이 없다. 따라서, 소스 코드를 무료로 제공한다고 하더라도 상업적 사용 불가와 같은 제한을 갖고 있다면 정의상 오픈소스가 아니다. +오픈소스 또는 자유소프트웨어 라이선스의 주요 특징은 라이선스 제약이나 제한이 없다는 것이다[^limitation]. 일반적인 상용 소프트웨어 라이선스와 비교해보자. 개인용으로 사용하겠다는 라이선스 조건에 클릭하여 수락하는 형태의 최종 사용자 라이선스End User license Agreement는 소프트웨어를 사용하는 것만 허용하며, 변경하거나 배포할 수 없다. 엔터프라이즈 라이선스는 소프트웨어를 사용할 수 있는 사용자, 서버 또는 물리적 위치의 수에 대한 제한을 설정하고, 기업은 해당 사용을 감시해야 한다. 그러나 오픈소스 라이선스에는 그러한 제한이 없다. 따라서, 소스 코드를 무료로 제공한다고 하더라도 상업적 사용 불가와 같은 제한이 있다면 정의상 오픈소스가 아니다. [^limitation]: Open source licenses can contain conditions, such as notices or source code sharing. But these are not limitations that tell you what you cannot do with software, they only require that if you elect to do certain things, you also must do others. 즉, 모든 라이선스 제한은 오픈소스 범주에서 벗어나게 한다. -2018년 이후 발생한 라이선스 변경의 물결 가운데 출시된 모든 라이선스는 거의 비슷한 제한을 갖고 있다. 각각 고유한 조건이 있지만, 이들은 모두 사용자가 소프트웨어를 무료로 사용할 수 있도록 허용하는 동시에 경쟁 호스팅 서비스 제공을 위한 소프트웨어 사용을 금지하는 데 초점을 맞추고 있다. +2018년 이후 발생한 라이선스 변경의 물결 가운데 출시된 모든 라이선스에는 거의 비슷한 제한이 있다. 각각 고유한 조건이 있지만, 이들은 모두 사용자가 소프트웨어를 무료로 사용할 수 있도록 허용하는 동시에 경쟁 호스팅 서비스 제공을 위한 소프트웨어 사용을 금지하는 데 초점을 맞추고 있다. ## Elastic License 2.0 @@ -180,7 +180,7 @@ any functionality in the software that is protected by the license key. ## 왜 듀얼 라이선스를 사용하였는가? -Elasticsearch는 사용자에게 SSPL과 Elastic License 중 하나를 선택할 수 있게 하는 특이한 경로를 택하였다. 오늘날 많은 기업이 "오픈 코어open core" 모델을 사용하고 있으며, 실제로 Elasticsearch도 전에는 이 모델을 사용하였다. 둘의 차이는 미묘하다고 할 수 있다. 오픈 코어 모델은 (대부분 Apache 2.0과 같은 허용적인permissive) 오픈소스 라이선스로 핵심 소프트웨어를 제공한다. 그런 다음 제한된 라이선스로 또는 서비스로만as a service 추가 기능(대개 기업이 대규모로 배포하는 데 유용한 기능)을 제공한다. 그러나 Elasticsearch는 동일한 소프트웨어를 두 개의 다른 라이선스로 사용할 수 있는 듀얼 라이선스 모델을 고수하였다. 이 듀얼 라이선스 모델은 MySQL에 의해 개척되었고, 일반적으로 무료 라이선스 선택지로 GPL, AGPL 또는 SSPL과 같은 카피레프트 라이선스를 사용한다. 그러나 이 모델은 오픈소스 라이선스와 클라우드 서비스 간의 충돌 때문에 최근 몇 년 동안 인기가 시들해졌다. +Elasticsearch는 사용자에게 SSPL과 Elastic License 중 하나를 선택할 수 있게 하는 특이한 경로를 택하였다. 오늘날 많은 기업이 "오픈 코어open core" 모델을 사용하고 있으며, 실제로 Elasticsearch도 전에는 이 모델을 사용하였다. 둘의 차이는 미묘하다고 할 수 있다. 오픈 코어 모델은 (대부분 Apache 2.0과 같은 허용적인permissive) 오픈소스 라이선스로 핵심 소프트웨어를 제공한다. 그런 다음 제한된 라이선스로 또는 서비스로만as a service 추가 기능(대개 기업이 대규모로 배포하는 데 유용한 기능)을 제공한다. 그러나 Elasticsearch는 동일한 소프트웨어를 두 개의 다른 라이선스로 사용할 수 있는 듀얼 라이선스 모델을 고수하였다. 이 듀얼 라이선스 모델은 MySQL이 개척하였고, 일반적으로 무료 라이선스 선택지로 GPL, AGPL 또는 SSPL과 같은 카피레프트 라이선스를 사용한다. 그러나 이 모델은 오픈소스 라이선스와 클라우드 서비스 간의 충돌 때문에 최근 몇 년 동안 인기가 시들해졌다. Elastic의 선택은 SSPL과 Elastic License 2.0의 두 가지 무료 라이선스 선택권을 제공하였다는 점에서 더욱 이례적이었다. 듀얼 라이선스는 일반적으로 하나의 무료 옵션만 제공한다. 이러한 이례적인 방법을 통해 Elasticsearch는 거의 모든 사용자가 소프트웨어를 무료로 사용할 수 있도록 하는 유연성을 강조하였다. @@ -220,7 +220,7 @@ It describes a software model where software: 이 계획은 아직 초기 단계에 있지만, 이로써 사용자와 개발자 모두에게 공정한 패러다임의 필요성을 업계가 인식하기 시작하고 있으며, 오픈소스 상용 기업이 오픈소스 모델보다 더 유연한 방식으로 둘 사이의 균형을 맞출 수 있도록 하고 있음은 분명하다. 한 전문가는 최근의 라이선스 발전을 "[오픈소스 이후 시대](https://monetize.substack.com/p/open-source-eras)"라고 부르기까지 하였다. 하지만 실제로는 이러한 소스 공개 라이선스는 비즈니스 및 라이선스 모델이 계속 발전함에 따라 일반적으로 오픈소스 라이선스와 함께 사용된다. 따라서 두 모델은 엄격한 대체품이 아니라 보완품이다. -또 다른 표준화된 라이선스 옵션도 있다. 2020년, 한 변호사 그룹은 [PolyForm Project](http://www.polyformproject.org/)를 시작하여 소스 공개 라이선스 템플릿 모음을 작성하였다. 이러한 라이선스는 오픈소스 라이선스와 독점 라이선스 모두에 경험이 있는 변호사에 의해 상호 리뷰되었다. 개방형 콘텐츠 라이선싱을 위한 [Creative Commons](https://creativecommons.org/)와 마찬가지로 비상업적, 평가 전용, 경쟁 방지 라이선스 등의 옵션 메뉴를 제공한다. Elastic License 2.0과 같이 모두 무료로 소스 코드에 대한 접근을 제공하며 필요한 특허 라이선스를 부여한다. PolyForm Perimeter 및 PolyForm Shield는 선조라고 할 수 있는 Confluent Community License와 유사하며, Elastic License 2.0은 이러한 추세에 따라 사용 가능한 옵션을 발전시켰다. +또 다른 표준화된 라이선스 옵션도 있다. 2020년, 한 변호사 그룹은 [PolyForm Project](http://www.polyformproject.org/)를 시작하여 소스 공개 라이선스 템플릿 모음을 작성하였다. 이러한 라이선스는 오픈소스 라이선스와 독점 라이선스 모두에 경험이 있는 변호사들이 상호 리뷰하였다. 개방형 콘텐츠 라이선싱을 위한 [Creative Commons](https://creativecommons.org/)와 마찬가지로 비상업적, 평가 전용, 경쟁 방지 라이선스 등의 옵션 메뉴를 제공한다. Elastic License 2.0과 같이 모두 무료로 소스 코드에 대한 접근을 제공하며 필요한 특허 라이선스를 부여한다. PolyForm Perimeter 및 PolyForm Shield는 선조라고 할 수 있는 Confluent Community License와 유사하며, Elastic License 2.0은 이러한 추세에 따라 사용 가능한 옵션을 발전시켰다. 질문이 있거나 더 자세한 내용을 알아가고 싶다면 다음과 같은 몇 가지 자료를 참조하라. diff --git a/content/ko/blog/2021/20210504-dockerfiles/index.md b/content/ko/blog/2021/20210504-dockerfiles/index.md index 7e1acafdb3..b85045de97 100644 --- a/content/ko/blog/2021/20210504-dockerfiles/index.md +++ b/content/ko/blog/2021/20210504-dockerfiles/index.md @@ -30,7 +30,7 @@ This paper was translated by Haksung Jang from the English version available at {{% alert title="개요" color="success" %}} -컨테이너 기술은 Target 시스템과 관계 없이 통합 소프트웨어 배포를 가능하게 한다. 이런 장점으로 Docker를 이용하는 배포가 점점 더 인기를 얻고 있다. 그런데 이때 FOSS 라이선스 컴플라이언스에 대한 새로운 의문이 제기되었다. Docker 환경에서는 "Docker image" 형태의 전체 소프트웨어를 배포하는 것뿐만 아니라, Dockerfile만을 배포할 수도 있다. Dockerfile은 스크립트 파일과 유사한 형태로 외부 Repository로부터 소프트웨어를 다운로드받게 하는 일종의 명령만을 포함하고 있다. 이러한 분산형 배포decentralized distribution의 형태는 라이선스 컴플라이언스를 누가 책임을 져야 하는지에 대한 의문을 제기하였다. 이 글에서는 프리 라이선스를 설명하기 위한 출발점으로 유럽 저작권법에 따른 "배포distribution"의 개념을 설명한다. 연구를 통해 저작권법 의미에서의 배포가 항상 물리적인 배포여야 하는 것은 아니라는 점이 밝혀졌다. +컨테이너 기술은 Target 시스템과 관계 없이 통합 소프트웨어를 배포할 수 있게 한다. 이런 장점으로 Docker를 이용하는 배포가 점점 더 인기를 얻고 있다. 그런데 이때 FOSS 라이선스 컴플라이언스에 대한 새로운 의문이 제기되었다. Docker 환경에서는 "Docker image" 형태의 전체 소프트웨어를 배포하는 것뿐만 아니라, Dockerfile만을 배포할 수도 있다. Dockerfile은 스크립트 파일과 유사한 형태로 외부 Repository로부터 소프트웨어를 다운로드받게 하는 일종의 명령만을 포함하고 있다. 이러한 분산형 배포decentralized distribution의 형태는 라이선스 컴플라이언스를 누가 책임을 져야 하는지에 대한 의문을 제기하였다. 이 글에서는 프리 라이선스를 설명하기 위한 출발점으로 유럽 저작권법에 따른 "배포distribution"의 개념을 설명한다. 연구를 통해 저작권법 의미에서의 배포가 항상 물리적인 배포여야 하는 것은 아니라는 점이 밝혀졌다. 이 글은 [OSADL](https://www.osadl.org/)Open Source Automation Development Lab로부터 자금 지원을 받고, 공동으로 작성하였다. {{% /alert %}} @@ -78,7 +78,7 @@ Docker는 컨테이너에 프로그램을 설치하고 배포하는 기술이다 ### Docker 엔진 -Docker 컨테이너용 관리 소프트웨어인 "Docker 엔진"은 Dockerfile의 명령을 순차적으로 처리하여 Docker image를 생성한다. 일반적으로, Base image나 개별 레이어를 위한 각 컴포넌트는 내부 또는 외부 저장소에서 다운로드된다. 이는 제공자가 Dockerfile을 제공하더라도 물리적인 프로그램 코드를 전달하지 않는 것이 가능함을 의미하고, 이런 일은 실제로 관례적이다. 고객은 전달받은 Dockerfile을 가지고 자체적으로 공개 저장소로부터 전체 혹은 일부 프로그램 코드를 받아와서 Docker 컨테이너를 구축할 수 있다. +Docker 컨테이너용 관리 소프트웨어인 "Docker 엔진"은 Dockerfile의 명령을 순차적으로 처리하여 Docker image를 생성한다. 일반적으로, Base image나 개별 레이어를 위한 각 컴포넌트는 내부 또는 외부 저장소에서 다운로드된다. 이는 제공자가 Dockerfile을 제공하더라도 물리적인 프로그램 코드를 전달하지 않을 수 있음을 의미하고, 이런 일은 실제로 관례적이다. 고객은 전달받은 Dockerfile을 가지고 자체적으로 공개 저장소로부터 전체 혹은 일부 프로그램 코드를 받아와서 Docker 컨테이너를 구축할 수 있다. {{< imgproc docker Fit "768x768" >}}
https://cultivatehq.com/posts/docker/
@@ -159,7 +159,7 @@ Dockerfile의 제공자가 Dockerfile이 참조하는 소프트웨어를 배포 추가 레이어를 사용하면 이미 설치된 프로그램도 수정할 수 있다. 이 경우, Docker 컨테이너는 수정되지 않은 프로그램을 한 레이어에 포함하고 수정한 프로그램을 다른 레이어에 포함하여 수정된 프로그램이 실행되도록 한다. 이러한 상황에서도 Dockerfile에는 적용될 수정사항이 정의되어 있기 때문에 Dockerfile 제공자는 "필수적 역할"의 책임을 맡아야 한다. 따라서, Dockerfile 제공자가 수정사항에 대한 라이선스 의무를 준수해야 한다. -이는 두 버전이 모두 수신자에게 배포되기 때문에 (수정된 버전만 실제 사용되더라도) 수정된 버전 뿐만 아니라 원 버전에도 적용된다는 사실에 주의해야 한다[^armijn19]. 프로그램이 새 레이어에 의해 제거되더라도 Docker image에 물리적으로 여전히 포함된 경우에도 마찬가지이다. +이는 두 버전이 모두 수신자에게 배포되기 때문에 (수정된 버전만 실제 사용되더라도) 수정된 버전 뿐만 아니라 원 버전에도 적용된다는 사실에 주의해야 한다[^armijn19]. 새 레이어가 프로그램을 제거하더라도 Docker image에 물리적으로 여전히 포함된 경우에도 마찬가지이다. [^armijn19]: See Hemel Armijn, ibid n. 1, p. 19. @@ -188,7 +188,7 @@ Base image도 시스템 요구 사항으로 간주할 수 있을까? 일반적 지금까지 제시된 견해에 따르면, Base image의 Repository 운영자와 제공자는 Base image의 배포에 필수적인 역할을 하는 반면, Dockerfile이 단지 참조하는 Base image는 시스템 요구 사항을 쉽게 취득하게 하기 위한 것이다. 그러므로, Repository의 운영자가 일반 대중에게 전달하는 행위를 수행하는 것이고, Repository 운영자는, 최소한 이러한 제공이 합법적이라면, 포함된 FOSS의 라이선스 의무를 단독으로 준수해야 한다. -위에서 언급한 해석은 본 연구 저자의 법적 의견이다. 일반적으로 컴퓨터 프로그램 및 특히 Dockerfile에 대한 이러한 특정 상황에 관한 판례는 없다. 다른 해석들도 분명 논쟁의 여지가 있다(특히 Base image를 포함하는 모든 참조 레이어가 Dockerfile의 제공자에 의해 배포되는 경우). +위에서 언급한 해석은 본 연구 저자의 법적 의견이다. 일반적으로 컴퓨터 프로그램 및 특히 Dockerfile에 대한 이러한 특정 상황에 관한 판례는 없다. 다른 해석들도 분명 논쟁의 여지가 있다(특히 Base image를 포함하는 Dockerfile의 제공자가 모든 참조 레이어를 배포하는 경우). 한가지 언급해야 할 사항은 현재 수많은 Repository 운영자들이 FOSS의 라이선스 의무를 올바르게 준수하지 않고 있으며 (예: GPL 및 LGPL 구성 요소의 소스 코드를 적절하게 제공하지 않음), 이는 저작권 침해의 책임이 있다는 점이다. 이 경우, 만약 Dockerfile의 제공자가 라이선스 위반을 알고 있다면 혹은 알고 있어야 한다면, 라이선스를 위반하는 참조를 포함하는 Dockerfile을 제공하는 것은 독립적인 배포 행위로 간주되거나 최소한 기여 저작권 침해(즉, 라이선스 위반에 대한 선동 또는 방조)로 간주될 수 있다. 따라서 Dockerfile 제공자는 지정된 Repository에서 제공하는 Base image가 라이선스를 준수하는지 여부를 검토해야 한다[^redhat]. diff --git a/content/ko/blog/2021/20210728-GPLv2InstallationInformation/index.md b/content/ko/blog/2021/20210728-GPLv2InstallationInformation/index.md index 3004e24a3a..e9ef0366cc 100644 --- a/content/ko/blog/2021/20210728-GPLv2InstallationInformation/index.md +++ b/content/ko/blog/2021/20210728-GPLv2InstallationInformation/index.md @@ -35,7 +35,7 @@ This paper was translated by Haksung Jang from the English version available at GPLv3GNU General Public License version 3 에서 추가된 주요 특징 중 하나는 소프트웨어 배포 시 소스 코드뿐만 아니라 '설치 정보'를 제공해야 한다는 요구사항이다. 이는 GPLv2에 존재하는 loophole ([Tivoization](https://opensource.stackexchange.com/questions/7020/what-exactly-is-tivoization-and-why-did-linus-torvalds-not-like-it-in-gplv3))을 해결하기 위해 GPLv3에 새롭게 추가되었다. 그런데 최근에 이 설치 정보 요구 사항이 GPLv2에서도 요구한다고 봐야한다는 주장이 제기되었다. -이 글에서는 GPLv3에 '설치 정보' 요구 사항을 포함하게 된 역사적 근거를 검토하고, 이 요구 사항은 GPLv2가 아닌, GPLv3에서 새롭게 적용된 것임을 설명한다. 또한, GPLv2 텍스트 분석을 통해서도 같은 결과를 도출한다. +이 글에서는 GPLv3에 '설치 정보' 요구 사항을 포함하게 된 역사적 근거를 검토하고, 이 요구 사항은 GPLv2가 아닌, GPLv3에서 새롭게 적용된 것임을 설명한다. 또한, GPLv2 텍스트 분석으로도 같은 결과를 도출한다. ## 1. Introduction @@ -70,7 +70,7 @@ GPLv3GNU General Public License version 3 에서 추가된 주요 특 ## 2. GPLv3의 '설치 정보' 요구 사항 -GPLv2가 광범위하게 사용되던 15년 동안 제기된 문제와 우려를 해결하기 위해 GPLv3에는 수많은 기능이 추가되었다. 그중에서도 가장 주목할만한 (그러면서도 가장 논란이 되는[^9]) 부분은 (1) '설치 정보'를 정의한 조항과 (2) GPLv3에 따라 라이센스가 부여된 소프트웨어를 '전달convey[^10]'할 때 어떤 상황에서 설치 정보를 제공해야 하는지를 명시한 조항이다. GPLv3에서의 '설치 정보' 요구 사항이 GPLv2에서 요구하는 요소를 어느 정도 포함하는지, 어느 것은 포함하지 않는지를 이해하려면 두 라이선스에서의 표현과 역사에 대한 자세한 검토가 필요하다. +GPLv2가 광범위하게 사용되던 15년 동안 제기된 문제와 우려를 해결하기 위해 GPLv3에는 수많은 기능이 추가되었다. 그중에서도 가장 주목할만한 (그러면서도 가장 논란이 되는[^9]) 부분은 (1) '설치 정보'를 정의한 조항과 (2) GPLv3에 따라 라이선스가 부여된 소프트웨어를 '전달convey[^10]'할 때 어떤 상황에서 설치 정보를 제공해야 하는지를 명시한 조항이다. GPLv3에서의 '설치 정보' 요구 사항이 GPLv2에서 요구하는 요소를 어느 정도 포함하는지, 어느 것은 포함하지 않는지를 이해하려면 두 라이선스에서의 표현과 역사에 대한 자세한 검토가 필요하다. [^9]: Burnette, Ed, ‘Tivo and GPL: Beauty and the Beast?,’ ZDNet, (October 2, 2006) https://www.zdnet.com/article/tivo-and-gpl-beauty-and-the-beast/ (accessed March 29, 2021). @@ -162,7 +162,7 @@ https://www.youtube.com/watch?v=bV3cKq26nKQ [^23]: Barr, Joe, ‘Torvalds versus GPLv3 DRM restrictions,’ Linux.com (February 2, 2006) https://www.linux.com/news/torvalds-versus-gplv3-drm-restrictions/ (accessed April 8, 2021). -GPLv3의 '설치 정보' 요구사항에 대해 Torvalds의 의견은 여러 주요 커널 개발자들에 의해 아래와 같이 공유되었다[^24]. Torvalds는 10년이 지난 후에도 일관된 입장을 유지했으며, 이는 오늘날까지 Linux Kernel이 'GPLv2 only' 라이선스를 유지하고 있는 이유 중 하나이다[^25]. +GPLv3의 '설치 정보' 요구사항에 대한 Torvalds의 의견은 여러 주요 커널 개발자도 아래와 같이 공유했다[^24]. Torvalds는 10년이 지난 후에도 일관된 입장을 유지했으며, 이는 오늘날까지 Linux Kernel이 'GPLv2 only' 라이선스를 유지하고 있는 이유 중 하나이다[^25]. >       “I give you source code, you give me your changes back; we’re even. … That’s my take on GPL version 2 and it’s that simple. … Version 3 extended that in ways that I personally am really uncomfortable with. Namely I give you source code, that means if you use that source code, you can’t use it on your device unless you follow my rules. And to me that’s a violation of everything version 2 stood for. And I understand why the FSF did it, because I know what the FSF wants, but to me it’s not the same license at all. So I was very upset, and made it very clear, and this was months before version 3 was actually published.”[^26] @@ -303,7 +303,7 @@ Installation script[^44]는 일반적으로 특정 장치에 특정 프로그램 따라서, 텍스트 해석의 관점에서, GPLv2의 ‘scripts used to control … installation of the executable’ 제공 의무가 GPLv2 executable code를 설치하는데 필요한 체크섬, 해시, 승인/서명키, 또는 기타 숫자 데이터를 포함하여 제공하는 것으로 해석될 수 없다는 것은 의심의 여지가 없어 보인다. 이러한 데이터는 'script'에 대한 일반적인 범위에 속하지 않는다. -차라리 이보다 흥미로운 해석상의 문제라고 한다면, 어떤 형태로든 executable의 유효성 검증을 위한 설치 프로그램을 실행하는 펌웨어가 하드웨어 디바이스 자체에 포함된 경우이다(예를 들어, executable에 수정을 가했을 경우, 유효하지 않은 것으로 판단하여 설치를 제한시키는 기능). 하지만 이런 경우라고 하더라도 GPLv3의 초안 작성 및 공개 과정 동안 FSF와 Linux Kernel 개발자 모두가 오랜 기간 동안 일관되게 GPLv2하에서는 (TiVo와 같이 PROM-loaded information을 사용한 경우 등) 어떠한 설치 유효성 검사도 허용된다는 입장을 고수했음을 고려하면, 펌웨어에서 즉시 검사하는 기능이 있더라도 이것이 GPLv2의 'scripts used to … installation of the executable' 요건에 의해 설치 정보를 제공해야 한다고 주장하기는 어려울 것이다. +차라리 이보다 흥미로운 해석상의 문제라고 한다면, 어떤 형태로든 executable의 유효성 검증을 위한 설치 프로그램을 실행하는 펌웨어가 하드웨어 디바이스 자체에 포함된 경우이다(예를 들어, executable에 수정을 가했을 경우, 유효하지 않은 것으로 판단하여 설치를 제한시키는 기능). 하지만 이런 경우라고 하더라도 GPLv3의 초안 작성 및 공개 과정 동안 FSF와 Linux Kernel 개발자 모두가 오랜 기간 동안 일관되게 GPLv2하에서는 (TiVo와 같이 PROM-loaded information을 사용한 경우 등) 어떠한 설치 유효성 검사도 허용된다는 입장을 고수했음을 고려하면, 펌웨어에서 즉시 검사하는 기능이 있더라도 이것이 GPLv2의 'scripts used to … installation of the executable' 요건에 따라 설치 정보를 제공해야 한다고 주장하기는 어려울 것이다. ## 7. 설치 정보 요구 사항을 GPLv2로 Backporting diff --git a/content/ko/blog/2021/20211115-VirtualApp_GPL/index.md b/content/ko/blog/2021/20211115-VirtualApp_GPL/index.md index 522f33284b..43513927dd 100644 --- a/content/ko/blog/2021/20211115-VirtualApp_GPL/index.md +++ b/content/ko/blog/2021/20211115-VirtualApp_GPL/index.md @@ -73,7 +73,7 @@ http://www.downcc.com/soft/359746.html 4. 그런데, 2017년 1월 24일, 갑자기 "[당신은 이 프로젝트를 무료로 사용할 수 있는 권한이 없다](https://github.com/asLody/VirtualApp/commit/7c8bfa40b2b301828cbaafefca122a3b5fc141d9)"는 안내가 추가됩니다. * 이후, 2017년 3월부터 7월까지 이 프로젝트를 상용으로 이용하기 위해서는 상용 라이선스 취득이 필요하다는 안내가 여러 차례 추가됩니다. * 이러한 라이선싱 정책 변화에 대해 중국 내 한 변호사는 Lody가 개발 초기에는 VirtualApp을 오픈소스 라이선스 하에 무료로 공개하였지만, 나중에 이를 이용하여 수익을 창출하려고 마음이 바뀐 것으로 추측하였습니다. - * 다만, 이렇게 GPL로 공개한 오픈소스에 조건을 추가하는건 GPL에서 허용하지 않은 방식인데요, Lody는 오픈소스 라이선스에 대하여 제대로 이해하지 못하고 있었기 때문에 GPL-3.0에 위반하는 라이선싱 정책을 시도한 것으로 보인다고 중국 변호사는 언급한 바 있습니다. + * 다만, 이렇게 GPL로 공개한 오픈소스에 조건을 추가하는건 GPL에서 허용하지 않은 방식인데요, Lody는 오픈소스 라이선스를 제대로 이해하지 못하고 있었기 때문에 GPL-3.0에 위반하는 라이선싱 정책을 시도한 것으로 보인다고 중국 변호사는 언급한 바 있습니다. 5. 2017년 8월, Lody는 VirtualApp(원고)을 설립합니다. 본격적으로 VirtualApp으로 비즈니스를 하겠다는 거죠. 6. 그리고, Lody는 결국, 2017년 10월 29일, GitHub에서 [오픈소스 라이선스를 제거](https://github.com/asLody/VirtualApp/commit/44529892fc2e6198928196c80c5766e6453bf81e)합니다. * https://github.com/asLody/VirtualApp/commit/00f152f98a922ced0d858c31e1a9c2f0afb53ab6 diff --git a/content/ko/blog/2021/20211123-nipa-opensource-guide/index.md b/content/ko/blog/2021/20211123-nipa-opensource-guide/index.md index 370833ee05..0d9fdcf676 100644 --- a/content/ko/blog/2021/20211123-nipa-opensource-guide/index.md +++ b/content/ko/blog/2021/20211123-nipa-opensource-guide/index.md @@ -19,7 +19,7 @@ NIPA에서 공개소프트웨어 활용을 위한 4종의 가이드를 발간했 참고로 기업 공개소프트웨어 거버넌스 가이드는 현재 OpenChain KWG 운영진이신 장학성, 이서연, 황민호님이 집필에 참여했습니다. ## 공개소프트웨어 라이선스 가이드 (개정판) -📖[공개 소프트웨어 라이선스 다운로드](https://www.oss.kr/oss_guide/show/a17c94f3-a470-4e1d-8cfe-d5d15d6535f7) +[공개 소프트웨어 라이선스 다운로드](https://www.oss.kr/oss_guide/show/a17c94f3-a470-4e1d-8cfe-d5d15d6535f7) 공개소프트웨어 라이선스 개요 및 소개, 의무사항 준수 방법, 저작권 및 특허권 관련 검토사항, 라이선스 관련 체크리스트, 관리방안, 주요 분쟁사례, 자주하는 질문 등 기업이나 조직에 적용할 핵심 내용을 파악하여 다양한 환경에서 활용 가능하도록 구성 @@ -30,18 +30,18 @@ NIPA에서 공개소프트웨어 활용을 위한 4종의 가이드를 발간했 ## 공공 공개소프트웨어 거버넌스 가이드 -📖[공공 공개소프트웨어 거버넌스 가이드 다운로드](https://www.oss.kr/oss_guide/show/824f56c5-8ed7-40cc-84d1-a03fa2f42bb1) +[공공 공개소프트웨어 거버넌스 가이드 다운로드](https://www.oss.kr/oss_guide/show/824f56c5-8ed7-40cc-84d1-a03fa2f42bb1) 가이드공공부문에서 정보화사업의 ▷기획 단계 ▷계획수립 단계▷사업자 선정 및 계약 단계 ▷사업수행 단계 ▷검사 및 운영 단계 ▷성과평가 단계 등 각 단계별 공개소프트웨어 활용 시 확인해야 할 관련 법령·지침, 고려 및 점검 사항을 제공 -공공 공개소프트웨어 거버넌스 가이드는 국내외의 공개소프트웨어 관련 정책 동향과 기술 동향을 수집하여 분석한 결과를 반영하고 국내 공공부문에서 정보화사업을 추진함에 있어 공개소프트웨어를 활용하고 관리할 때 필수적으로 확인해야 하는 관련 법령·지침 및 고려해야 할 실무 관점의 정보들과 접근법을 제공한다.각 장은 ▲정보화사업 공개소프트웨어 관리 필요성 ▲정보화사업 공개소프트웨어 관리로 구성된다.‘정보화사업 공개소프트웨어 관리 필요성’에서는 국내외 각국 정부의 공개소프트웨어 정책 및 활용 사례를 소개하고 정보화사업의 관련 법령 및 지침, 해설서를 정리하고 공개소프트웨어 관리를 위한 관련조항을 설명한다.‘정보화사업 공개소프트웨어 관리’에서는 ▷기획 단계 ▷계획수립 단계 ▷사업자 선정 및 계약 단계 ▷사업수행 단계 ▷검사 및 운영 단계 ▷성과평가 단계 등 단계별 기본 관리점검 프로세스 소개와 단계별로 실무담당자가 참고할 수 있는 지침 및 해설서 목록을 제공하며 공개소프트웨어 관리 점검을 위한 관리요소 및 검토사항 등을 제공한다. +공공 공개소프트웨어 거버넌스 가이드는 국내외의 공개소프트웨어 관련 정책 동향과 기술 동향을 수집하여 분석한 결과를 반영하고 국내 공공부문에서 정보화사업을 추진함에 있어 공개소프트웨어를 활용하고 관리할 때 필수적으로 확인해야 하는 관련 법령·지침 및 고려해야 할 실무 관점의 정보와 접근법을 제공한다.각 장은 ▲정보화사업 공개소프트웨어 관리 필요성 ▲정보화사업 공개소프트웨어 관리로 구성된다.‘정보화사업 공개소프트웨어 관리 필요성’에서는 국내외 각국 정부의 공개소프트웨어 정책 및 활용 사례를 소개하고 정보화사업의 관련 법령 및 지침, 해설서를 정리하고 공개소프트웨어 관리를 위한 관련조항을 설명한다.‘정보화사업 공개소프트웨어 관리’에서는 ▷기획 단계 ▷계획수립 단계 ▷사업자 선정 및 계약 단계 ▷사업수행 단계 ▷검사 및 운영 단계 ▷성과평가 단계 등 단계별 기본 관리점검 프로세스 소개와 단계별로 실무담당자가 참고할 수 있는 지침 및 해설서 목록을 제공하며 공개소프트웨어 관리 점검을 위한 관리요소 및 검토사항 등을 제공한다. ## 기업 공개소프트웨어 거버넌스 가이드 -📖[기업 공개소프트웨어 거버넌스 다운로드](https://www.oss.kr/oss_guide/show/2f7c25e8-df31-4ad9-9d25-1d8234c322c0) +[기업 공개소프트웨어 거버넌스 다운로드](https://www.oss.kr/oss_guide/show/2f7c25e8-df31-4ad9-9d25-1d8234c322c0) 기업에서 소프트웨어 개발 및 공급 시 실무에서 활용 가능하도록 공개소프트웨어를 활용하는 세 가지 경우(사용/기여/공개)로 구분하여 설명하고, 마지막으로는 기업의 공개소프트웨어 거버넌스를 위해 필요한 조직의 구성 방안 제공 @@ -52,7 +52,7 @@ NIPA에서 공개소프트웨어 활용을 위한 4종의 가이드를 발간했 ## 개방형OS 도입가이드 -📖[개방형OS 도입가이드 다운로드](https://www.oss.kr/oss_guide/show/0e9ad67e-9d2a-4a0a-8f2d-092226e3ea07) +[개방형OS 도입가이드 다운로드](https://www.oss.kr/oss_guide/show/0e9ad67e-9d2a-4a0a-8f2d-092226e3ea07) 업무용 PC의 개방형OS 전환 시 필요한 개방형OS 소개, 종류, 도입 절차/범위, 유지관리, 적용 사례 등 소개하여 실무담당자가 개방형OS 도입을 검토함에 있어 전체적인 사업계획에 대한 가이드를 제시 diff --git a/content/ko/blog/2021/20211220-SaaS_Compliance/index.md b/content/ko/blog/2021/20211220-SaaS_Compliance/index.md index b3d5b88c5c..901bb8de2e 100644 --- a/content/ko/blog/2021/20211220-SaaS_Compliance/index.md +++ b/content/ko/blog/2021/20211220-SaaS_Compliance/index.md @@ -51,7 +51,7 @@ MIT의 경우도 다음과 같이 요구합니다. > *The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.* > -이런 조항을 고려하면, SaaS 시스템 내 별도의 웹페이지에서 라이선스 고지를 하는 방법도 충분하지는 않다는 주장이 있을 수도 있습니다. 물론, 이런 방법이라도 제공하는 것이 안하는 것보다는 훨씬 낫겠지만요. 🙂 +이런 조항을 고려하면, SaaS 시스템 내 별도의 웹페이지에서 라이선스 고지를 하는 방법도 충분하지는 않다는 주장이 있을 수도 있습니다. 물론, 이런 방법이라도 제공하는 것이 안하는 것보다는 훨씬 낫겠지만요. ### Minified Javascript는 소스 코드 공개 방법으로 적절한가? @@ -68,7 +68,7 @@ MIT의 경우도 다음과 같이 요구합니다. ``` -예를 들어, 위의 코드를 Minify하면 다음과 같이 변환되고, 당연히 가독성은 떨어지게 됩니다. +예를 들어, 위의 코드를 Minify하면 다음과 같이 변환되고, 당연히 가독성은 떨어집니다. ```jsx (function(domain,translations){varlocaleData=translations.locale_data[domain]||translations.locale_data.messages;localeData[“”].domain=domain;wp.i18n.setLocaleData(localeData,domain);})(“default”,{“locale_data”:{“messages”:{“”:{}}}}); @@ -115,7 +115,7 @@ Heather가 언급한 SaaS에서의 또 다른 잠재적인 이슈는 네트워 Google은 다음과 같은 이유료 AGPL Policy를 만들었다고 설명합니다. -- AGPL은 AGPL 소프트웨어와 링크하는 모든 것도 AGPL로 라이선스를 부여할 것을 요구한다. → 바이러스 효과 +- AGPL은 AGPL 소프트웨어와 링크하는 모든 것도 AGPL로 라이선스를 부여할 것을 요구한다. (바이러스 효과) - 이런 바이러스 효과가 발생하는 시점은 소프트웨어를 배포할 때 뿐만 아니라 사용자가 제품이나 서비스를 원격 네트워크 인터페이스를 통해 액세스 할 때도 포함한다. - Google의 핵심 제품(Search, Gmail, Map, Youtube 등)은 사용자가 원격 네트워크 인터페이스를 통해 상호작용하는 서비스이기 때문에 엔지니어가 이런 서비스를 AGPL에 의존적으로 개발할 경우 상황은 심각해진다. - 이런 상황을 고려했을때 Google은 AGPL의 네트워크를 통해 사용되는 소프트웨어에 대한 요구사항을 준수하기 매우 어렵다. @@ -132,7 +132,7 @@ Google은 다음과 같은 이유료 AGPL Policy를 만들었다고 설명합니 - Honest Public License - Academic Free License ***[Note: this license is permissive. The others are copyleft.]*** -Heather는 대부분의 회사는 이러한 네트워크 Copyleft 라이선스를 위험도가 높은 라이선스로 분류하고 SaaS 개발에 사용하지 않는 정책을 갖고 있다고 말하였습니다. +Heather는 대부분의 회사는 이러한 네트워크 Copyleft 라이선스를 위험도가 높은 라이선스로 분류하고 SaaS 개발에 사용하지 않는 정책이 있다고 말하였습니다. 사실, 저도 예전에는 AGPL-3.0은 수정한 경우에만 소스 공개 의무를 부여하기 때문에 수정하지 않고 사용하는건 문제가 없다고 생각했습니다. 그래서 굳이 회사에서 정책적으로 AGPL-3.0의 사용을 막을 필요까지는 없는 것 아닌가라는 입장이었습니다. 그런데, AGPL-3.0 오픈소스를 도입하는 시기에는 수정하지 않고 사용한다고 하더라도, 수년이 지나면서도 수정하지 않도록 보장할 수 있는 체계가 회사 내부에 갖춰져 있냐를 봤을때에는 수정하지 않겠다는 것을 장담할 수 없게 됩니다. 따라서, Google과 같이 기본 정책으로는 AGPL-3.0 오픈소스는 사용을 제한하는 정책을 가져가는 것이 라이선스 관리 측면에서 합리적이라고 생각합니다. diff --git a/content/ko/blog/2022/20220214_AI_dataset_copyright/index.md b/content/ko/blog/2022/20220214_AI_dataset_copyright/index.md index d7dec77da3..ce2841ef68 100644 --- a/content/ko/blog/2022/20220214_AI_dataset_copyright/index.md +++ b/content/ko/blog/2022/20220214_AI_dataset_copyright/index.md @@ -109,7 +109,7 @@ Copilot은 GitHub에 개발자의 코드 작성을 돕기 위해 공개된 sourc ![](./featured_procedure.png) -먼저, Phase 1은 AI engineer에 의해 라이선스를 확인하는 과정입니다. 논문에서는 자세한 내용을 아래와 같이 설명합니다. +먼저, Phase 1은 AI engineer가 라이선스를 확인하는 과정입니다. 논문에서는 자세한 내용을 아래와 같이 설명합니다. {{< alert color="success" title="Phase 1 : License identification" >}} #### (Step 1) License extraction @@ -156,7 +156,7 @@ Copilot은 GitHub에 개발자의 코드 작성을 돕기 위해 공개된 sourc {{% /alert %}} -여기까지가 Phase 1인데, 공개 Dataset을 사용하려는 AI engineer가 확인해야 할 내용이 적지 않습니다. 더 큰 문제는 아무리 노력을 기울인다고 해도 웹사이트에서 라이선스 정보를 제공하지 않거나, 틀린 정보를 제공한다면 AI engineer가 확인할 수 있는 범위는 제한적일 수 밖에 없을 것입니다. 아뭏든, 논문 내용을 더 살펴보겠습니다. 다음은, Phase 2이며, 변호사 등 법률전문가에 의해 라이선스의 권리와 의무를 확인하는 단계입니다. +여기까지가 Phase 1인데, 공개 Dataset을 사용하려는 AI engineer가 확인해야 할 내용이 적지 않습니다. 더 큰 문제는 아무리 노력을 기울인다고 해도 웹사이트에서 라이선스 정보를 제공하지 않거나, 틀린 정보를 제공한다면 AI engineer가 확인할 수 있는 범위는 제한적일 수 밖에 없을 것입니다. 아뭏든, 논문 내용을 더 살펴보겠습니다. 다음은, Phase 2이며, 변호사 등 법률전문가가 라이선스의 권리와 의무를 확인하는 단계입니다. {{< alert color="success" title="Phase 2 : License compliance assessment" >}} #### (Step 1) License interpretation @@ -207,7 +207,7 @@ Copilot은 GitHub에 개발자의 코드 작성을 돕기 위해 공개된 sourc {{% /alert %}} -여기까지 Phase 2를 거치면서 법률 전문가에 의해 Enhanced MDL 포맷으로 라이선스 권리와 의무를 문서화하고 이를 활용하는 방법을 살펴 보았습니다. Dataset 뿐만 아니라 Data Source의 라이선스까지 확인해서 Data Source의 라이선스가 상업적 사용 등 제한을 가하면 Dataset을 상업용으로 사용하는 것도 리스크가 있음을 설명하고 있습니다. +여기까지 Phase 2를 거치면서 법률 전문가가 Enhanced MDL 포맷으로 라이선스 권리와 의무를 문서화하고 이를 활용하는 방법을 살펴 보았습니다. Dataset 뿐만 아니라 Data Source의 라이선스까지 확인해서 Data Source의 라이선스가 상업적 사용 등 제한을 가하면 Dataset을 상업용으로 사용하는 것도 리스크가 있음을 설명하고 있습니다. 논문에서는 위와 같은 방식으로 다른 Dataset에 대해서도 Case Study를 진행하였습니다. 그 내용을 살펴보겠습니다. diff --git a/content/ko/blog/2022/20220403_innersource/index.md b/content/ko/blog/2022/20220403_innersource/index.md index 7f94c47140..00188bd370 100644 --- a/content/ko/blog/2022/20220403_innersource/index.md +++ b/content/ko/blog/2022/20220403_innersource/index.md @@ -24,7 +24,7 @@ resources: ![](./featured_innersource.png) ## 1. 오픈소스 Practice 주요 사항 -먼저, 오픈소스 개발방법론에서 강조하는 주요 Practice를 살펴보겠습니다. 어떻게 거대한 오픈소스 프로젝트가 자발적인 참여에 의해 성장해갈 수 있을까요? 왜 오픈소스 프로젝트에 참여하면 개발자 개인의 성장을 이룰 수 있다고 할까요? 오픈소스 프로젝트에는 다음과 같은 주요 Practice가 있기 때문입니다. +먼저, 오픈소스 개발방법론에서 강조하는 주요 Practice를 살펴보겠습니다. 어떻게 거대한 오픈소스 프로젝트가 자발적인 참여로 성장해갈 수 있을까요? 왜 오픈소스 프로젝트에 참여하면 개발자 개인의 성장을 이룰 수 있다고 할까요? 오픈소스 프로젝트에는 다음과 같은 주요 Practice가 있기 때문입니다. ### (1) 조직간 협업 diff --git a/content/ko/blog/2022/20220614_sfc_vizio/index.md b/content/ko/blog/2022/20220614_sfc_vizio/index.md index 80c0ea4a83..356ace3426 100644 --- a/content/ko/blog/2022/20220614_sfc_vizio/index.md +++ b/content/ko/blog/2022/20220614_sfc_vizio/index.md @@ -17,7 +17,7 @@ resources: > > [SFC](https://sfconservancy.org/)(Software Freedom Conservancy)가 GPL 위반을 이유로 미국의 스마트 TV 제조사인 [Vizio](https://www.vizio.com/)에 소송을 제기하였는데요, 지난 2022년 5월 13일, 이와 관련한 미국 연방 법원의 [판결](https://storage.courtlistener.com/recap/gov.uscourts.cacd.837808/gov.uscourts.cacd.837808.30.0.pdf)이 있었습니다. > -> 이번 판결의 배경과 시사점을 수박 겉핥기로 정리해보았습니다. 제가 법률 전문가가 아니기 때문에 용어나 해석에 있어서 오류가 있을 수 있습니다. 여러 전문가분께서 [피드백](https://github.com/haksungjang/haksungjang.github.io/issues/new) 주시면 고맙겠습니다. ^^ +> 이번 판결의 배경과 시사점을 수박 겉핥기로 정리해보았습니다. 제가 법률 전문가가 아니기 때문에 용어나 해석에 오류가 있을 수 있습니다. 여러 전문가분께서 [피드백](https://github.com/haksungjang/haksungjang.github.io/issues/new) 주시면 고맙겠습니다. ^^ ## References @@ -58,7 +58,7 @@ resources: - 계약(합의)의 효력으로서 부담하는 의무에 위반한 경우에는 채무불이행으로 인한 계약 책임만 부담 - 저작권 침해처럼 형사처벌이나 금지 청구를 당할 염려는 없으며 약정된 손해배상액을 물어주어야 함 - 오픈소스 라이선스 하의 저작물을 계약의 성립이 구성된다고 보는 것은 관할권마다 다툼의 여지가 있음 -- 손해배상의 액수나 구제 조치 등에 있어서 제한적 +- 손해배상의 액수나 구제 조치 등에서 제한적 #### 사례 - GPL software의 저작권자가 저작권 침해 주장으로 소송 제기 @@ -77,10 +77,10 @@ resources: - 지역 법원 (District Court), 항소 법원 (Appellate Court), 대법원 (Supreme Court)로 이루어져 있음 - 제한된 사건만 다루고 있음 : 헌법, 연방 범죄, 군법, 지적재산권 등 - 저작권법(Copyright Act)은 연방 법원에서 다룸 -- 미국에서는 연방 법원에서 저작권 주장에 대한 독점적인 관할권을 갖고 있다. +- 미국에서는 연방 법원에 저작권 주장에 대한 독점적인 관할권이 있다. - 따라서, 과거 미국에서의 GPL 소송을 위한 거의 모든 주장은 저작권법에 대한 독점 관할권을 가진 연방 법원(Federal Court)에 제기됐다. - 소장을 엉뚱한 법원에 제출한다면, 사건은 기각되거나 다른 법원으로 이송된다. - - 즉, 주 법원(State Court)에 제기된 action이 연방 법원에 의해 선점(preempt)되는 경우 제거될 수 있음 + - 즉, 주 법원(State Court)에 제기된 action을 연방 법원(Federal Court)이 선점(preempt)하는 경우 제거될 수 있음 ## 2. SFC vs. Vizio 소송 히스토리 @@ -140,7 +140,7 @@ Fulfilling the requirements of a contract in exactly the way the contract specif {{< /alert >}} ### 3-2. Claim Brought in State Court -- 미국에서는 연방 법원에서 저작권 주장에 대한 독점적인 관할권을 갖고 있음 +- 미국에서는 연방 법원에 저작권 주장에 대한 독점적인 관할권이 있음 - 따라서, 과거 미국에서의 GPL 소송을 위한 거의 모든 주장은 저작권법에 대한 독점 관할권을 가진 연방 법원에 제기했다. - 하지만 이번 SFC가 제기한 소송은 Orange County, California 주 법원에 제기하였다. - 주 법원 소송은 연방 법원에 비해 예측 불가하고, 결과가 일관적이지 않으며, 새로운 법률 이론에 대해 예상치 못한 견해를 보일 가능성이 있다. @@ -171,15 +171,15 @@ People who aren’t a party to a GPL agreement, but who would benefit from the 법원은 우선 연방 법원에서 판단해야 할 주요 관건을 다음과 같이 설명하였습니다. - 법원이 결정해야 할 유일한 문제는 federal Copyright Act (연방 저작권법)이 SFC의 claim (breach of contract and declaratory relief)을 완전히 선점(preempt)하여 연방 관할권을 생성하는지 여부이다. -- 만약 claim이 연방 저작권법에서 다루는 일반적인 저작권 범위 내의 권리(복제, 2차 저작물 배포 및 전시에 대한 배타적 권리 등)와 동등하다면 연방 저작권법에 의해 선점되기 때문에 연방 관할권을 생성한다. -- 만약 사건이 연방 저작권법에 의해 선점되지 않는다고 주장하려면, 소송 원인이 저작권이 보호하는 권리 이외의 권리를 보호해야 하고, 이에 해당하는 “extra element”가 있어서 소송의 성격을 변경할 수 있어야 한다. +- 만약 claim이 연방 저작권법에서 다루는 일반적인 저작권 범위 내의 권리(복제, 2차 저작물 배포 및 전시에 대한 배타적 권리 등)와 동등하다면 연방 저작권법이 이를 선점하기 때문에 연방 관할권을 생성한다. +- 만약 사건을 연방 저작권법이 선점하지 않는다고 주장하려면, 소송 원인이 저작권이 보호하는 권리 이외의 권리를 보호해야 하고, 이에 해당하는 “extra element”가 있어서 소송의 성격을 변경할 수 있어야 한다. ### 4-2. 관련 판례 : "Versata Software vs. Ameriprise" - GPL이 derivative work에 대해 소스 공개를 요구하는 건 저작권 의무와는 별개이다. - 피고는 저작권 침해로 소송을 제기당한게 아니다. - 오픈소스 프로그램을 포함하는 파생 저작물에 대한 ‘additional obligation : 소스 공개 의무 미준수’을 위반했기 때문에 원고로부터 소송을 당한 것이다. -- 이처럼 저작권법에 의해 제공되는 권리에 해당하지 않는 “additional contractual promise”은 “extra element”에 해당한다. +- 이처럼 저작권법이 제공하는 권리에 해당하지 않는 “additional contractual promise”은 “extra element”에 해당한다. ### 4-3. SFC의 Claim이 “extra element”인지 여부 @@ -193,16 +193,16 @@ People who aren’t a party to a GPL agreement, but who would benefit from the - Vizio는 오픈소스 라이선스 위반은 저작권 침해라고 주장하지만, SFC는 이번 소송에서 저작권 침해에 대한 claim을 하지 않았다. - 원고가 claim하지 않은 사항을 법원이 판단할 이유는 없다. - 게다가 SFC는 저작권자가 아니기 때문에 그런 주장조차 할 수 없다. - - SFC는 저작권법에 의해 Vizio의 복제, 파생저작물 제작 등을 하는 것을 제한하려는 것이 아니라, 소스 코드를 제공하도록 요청할 뿐이다. + - SFC는 저작권법에 따라 Vizio의 복제, 파생저작물 제작 등을 하는 것을 제한하려는 것이 아니라, 소스 코드를 제공하도록 요청할 뿐이다. - Vizio는 소스 코드 제공이 라이선스의 ‘condition’이므로 이를 위반하는 건 ‘계약 위반'이 아니라 ‘저작권 침해'에 해당한다고 주장하였다. - 따라서 SFC의 ‘contract claim’은 저작권 침해로 전환되어야 한다고 주장하였다. - - 하지만 “수행 의무가 발생하기 전에 반드시 발생해야 하는 행위 또는 사건" 이라는 condition 위반 만이 저작권 침해를 구성할 수 있으며, 이외 다른 모든 license terms, covenants의 위반은 계약법에 의해서만 소송이 가능하다 + - 하지만 “수행 의무가 발생하기 전에 반드시 발생해야 하는 행위 또는 사건" 이라는 condition 위반 만이 저작권 침해를 구성할 수 있으며, 이외 다른 모든 license terms, covenants의 위반은 계약법으로만 소송이 가능하다 - 또한, 모호한 계약 조항은 condition이 아니라 covenant로 해석한다 ### 4-5 판결 -- SFC의 주장이 저작권법에 의해 완전히 선점되지 않았다. +- 연방 저작권법이 SFC의 주장을 완전히 선점하지 않았다. - GPL 계약은 저작권 라이선스뿐만 아니라 계약(contractual agreement)의 기능을 모두 수행한다. - 따라서, 연방 법원은 관할권이 없으며 주 법원으로의 환송 신청을 승인한다(the Motion to Remand is GRANTED). diff --git a/content/ko/blog/2022/20220930_akka_license_change/index.md b/content/ko/blog/2022/20220930_akka_license_change/index.md index a1971d9a57..4e1834a326 100644 --- a/content/ko/blog/2022/20220930_akka_license_change/index.md +++ b/content/ko/blog/2022/20220930_akka_license_change/index.md @@ -32,7 +32,7 @@ resources: - 오픈소스(Apache-2.0)이었던 Akka가 v2.7 부터 새로운 라이선스가 적용된다. - 새로운 라이선스는 [BUSL-1.1](https://spdx.org/licenses/BUSL-1.1.html) (Business Source License)이다. -- 상업적 목적이 아닌 경우 무료로 사용할 수 있으나, 상업용에 대해서는 라이선스 비용을 지불해야 한다. +- 상업적 목적이 아닌 경우 무료로 사용할 수 있으나, 상업용은 라이선스 비용을 지불해야 한다. Lightbend는 지난 십여 년간 Apache-2.0으로 Akka 오픈소스 프로젝트를 지원해 왔지만 이를 지속하기가 어려워졌다고 [밝혔습니다](https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka). @@ -78,7 +78,7 @@ BUSL-1.1 또 다른 특징은 `Change Date`와 `Change License`입니다. BUSL-1 ### Additional Use Grant -BUSL-1.1은 Licensor가 일정 조건 하에 상용 목적의 사용자에게 권리를 부여할 수 있도록 하는 `Additioanl Use Grant` 조항을 갖고 있습니다. +BUSL-1.1은 Licensor가 일정 조건 하에 상용 목적의 사용자에게 권리를 부여할 수 있도록 하는 `Additioanl Use Grant` 조항이 있습니다. > The Licensor may make an Additional Use Grant, above, permitting limited production use. diff --git a/content/ko/blog/2023/20230313_anaconda_miniforge/index.md b/content/ko/blog/2023/20230313_anaconda_miniforge/index.md index b41427d025..c54a62bb87 100644 --- a/content/ko/blog/2023/20230313_anaconda_miniforge/index.md +++ b/content/ko/blog/2023/20230313_anaconda_miniforge/index.md @@ -121,7 +121,7 @@ channels: 한 가지 특이한 점은 conda-forge 운영에는 막대한 호스팅 비용이 필요한데 이를 Anaconda사가 지불하고 있다는 점입니다. Anaconda사는 conda-forge를 계속 무료로 유지하기 위해서라도 Anaconda Repository의 서비스 약관 변경을 통한 수익이 [필요했다](https://conda-forge.org/blog/posts/2020-11-20-anaconda-tos/)고 설명합니다. -결론적으로 개발 편의성과 안정성을 고려하여 가급적 Anaconda Pro를 구매하여 사용하는 것이 좋겠습니다. 구매 전까지 라이선스 이슈 방지를 위해 Miniconda + conda-forge 조합, 혹은 Miniforge를 대안으로 고려할 수 있을 것 같습니다. 🙂 +개발 편의성과 안정성을 고려하여 가급적 Anaconda Pro를 구매하여 사용하는 것이 좋겠습니다. 구매 전까지 라이선스 이슈 방지를 위해 Miniconda + conda-forge 조합, 혹은 Miniforge를 대안으로 고려할 수 있을 것 같습니다. 혹시 틀린 내용이 있다면 알려주시면 감사하겠습니다. ^^ diff --git a/content/ko/blog/2023/20230327_openchain_project/index.md b/content/ko/blog/2023/20230327_openchain_project/index.md index 5f76823741..bbf493dba0 100644 --- a/content/ko/blog/2023/20230327_openchain_project/index.md +++ b/content/ko/blog/2023/20230327_openchain_project/index.md @@ -13,7 +13,7 @@ resources: byline: "" --- -기업이 개발하는 제품 소프트웨어의 93% 이상이 오픈소스를 사용한다고 할 정도로 현대 소프트웨어 개발에 오픈소스를 사용하는 건 거의 필수적입니다. 그런데, 사용하는 오픈소스의 53%는 라이선스 컴플라이언스 이슈가 있고, 81%는 보안 취약점을 갖고 있다는 [보고가 있습니다](https://www.synopsys.com/blogs/software-security/open-source-trends-ossra-report/). 복잡한 현대 소프트웨어의 개발환경과 방대한 Software Supply Chain을 고려한다면, 기업이 오픈소스로 제품을 개발하면서 라이선스 컴플라이언스와 보안 취약점 리스크 최소화를 위한 오픈소스 관리 노력이 필요한데요, [Linux Foundation](https://www.linuxfoundation.org/)의 [OpenChain Project](openchainproject.org)는 이러한 노력을 커뮤니티 차원에서 여러 기업이 공유와 협업으로 함께 하기 위한 Project입니다. +기업이 개발하는 제품 소프트웨어의 93% 이상이 오픈소스를 사용한다고 할 정도로 현대 소프트웨어 개발에 오픈소스를 사용하는 건 거의 필수적입니다. 그런데, 사용하는 오픈소스의 53%는 라이선스 컴플라이언스 이슈가 있고, 81%는 보안 취약점이 있다는 [보고가 있습니다](https://www.synopsys.com/blogs/software-security/open-source-trends-ossra-report/). 복잡한 현대 소프트웨어의 개발환경과 방대한 Software Supply Chain을 고려한다면, 기업이 오픈소스로 제품을 개발하면서 라이선스 컴플라이언스와 보안 취약점 리스크 최소화를 위한 오픈소스 관리 노력이 필요한데요, [Linux Foundation](https://www.linuxfoundation.org/)의 [OpenChain Project](openchainproject.org)는 이러한 노력을 커뮤니티 차원에서 여러 기업이 공유와 협업으로 함께 하기 위한 Project입니다. 2023년 3월 27일, OpenChain Project의 General Manager인 [Shane Coughlan](https://github.com/shanecoughlan)이 SK텔레콤을 방문하여 OpenChain Project의 주요 활동, 오픈소스 관련 국제 표준 및 글로벌 동향에 관해 설명하는 시간을 가졌습니다. diff --git a/content/ko/blog/2023/20230403_openchain_kwg/index.md b/content/ko/blog/2023/20230403_openchain_kwg/index.md index 80cd7f793c..1427224413 100644 --- a/content/ko/blog/2023/20230403_openchain_kwg/index.md +++ b/content/ko/blog/2023/20230403_openchain_kwg/index.md @@ -43,7 +43,7 @@ Linux Foundation의 OpenChain Project General Manager [Shane Coughlan](https://j 오픈소스 컴플라이언스를 위한 표준인 ISO/IEC 5230뿐만 아니라 보안을 위한 표준인 [ISO/IEC 18974](https://www.iso.org/standard/86450.html)도 개발 중입니다. 이 표준은 곧 공식 ISO 표준으로 등록될 예정이며, 기업이 준수해야 할 [Self-Checklist](https://github.com/OpenChain-Project/Reference-Material/blob/master/Self-Certification/Checklist/DIS-18974/en/DIS-18974-Self-Certification-Checklist-2.0.md)도 공개되어 있습니다. 이러한 자료들을 활용하여 기업은 효율적인 오픈소스 리스크 관리를 수행할 수 있습니다. -Shane은 KWG 멤버들을 위한 기념품도 가져와서 큰 호응을 얻기도 하였습니다. (Thank you, Shane 😊 ) +Shane은 KWG 멤버들을 위한 기념품도 가져와서 큰 호응을 얻기도 하였습니다. (Thank you, Shane) ![Untitled](./Untitled_3.png) @@ -97,7 +97,7 @@ OSORI는 오픈소스 정보 데이터를 공개하여 누구나 쉽게 오픈 ![Untitled](./Untitled_12.png) -FOSSLight Project는 2023년 보안 취약점 기능을 개선하고, SBOM 기능 강화, UX개선 등의 로드맵을 가지고 있습니다. +FOSSLight Project는 2023년 보안 취약점 기능을 개선하고, SBOM 기능 강화, UX개선 등의 로드맵이 있습니다. ![Untitled](./Untitled_13.png) @@ -133,4 +133,4 @@ onot은 Package 정보뿐만 아니라 File 정보도 추출하게 되었고, Mu 끝으로, OpenChain KWG는 분기마다 정기 미팅을 개최하고 있습니다. 다음 모임은 카카오에서 만날 수 있을 것 같습니다. -그때까지 모두 행복하세요! 😃 \ No newline at end of file +그때까지 모두 행복하세요! \ No newline at end of file diff --git a/content/ko/blog/2024/20240906_elastic_agpl/index.md b/content/ko/blog/2024/20240906_elastic_agpl/index.md index 4d9c7c22b5..466eacf10c 100644 --- a/content/ko/blog/2024/20240906_elastic_agpl/index.md +++ b/content/ko/blog/2024/20240906_elastic_agpl/index.md @@ -15,7 +15,7 @@ resources: ## 서론: Elasticsearch 라이선스 배경 -Elasticsearch는 오픈소스 프로젝트로 시작했으며, 그동안 여러 번의 라이선스 정책 변경을 겪었습니다. 처음에는 **Apache 2.0 라이선스** 하에 배포되었지만, 2021년 Elastic은 **Elastic License 2.0**과 **Server Side Public License**로 라이선스를 변경했습니다. 이후 2024년 8월 30일에는 다시 **AGPL-3.0**을 추가하는 발표([Elasticsearch is Open Source, Again](https://www.elastic.co/kr/blog/elasticsearch-is-open-source-again))를 하면서 주목을 받고 있습니다. +Elasticsearch는 오픈소스 프로젝트로 시작했으며, 그동안 여러 번의 라이선스 정책 변경을 겪었습니다. 처음에는 Apache 2.0 라이선스 하에 배포되었지만, 2021년 Elastic은 Elastic License 2.0과 Server Side Public License로 라이선스를 변경했습니다. 이후 2024년 8월 30일에는 다시 AGPL-3.0을 추가하는 발표([Elasticsearch is Open Source, Again](https://www.elastic.co/kr/blog/elasticsearch-is-open-source-again))를 하면서 주목을 받고 있습니다. ![](./featured_original-elastic-logos.png) @@ -27,9 +27,9 @@ Elasticsearch는 오픈소스 프로젝트로 시작했으며, 그동안 여러 ## 1. Elasticsearch 라이선스 변경의 역사 ### 1.1 Apache 2.0에서 Elastic License 2.0으로의 전환 -Elasticsearch는 처음에 **Apache 2.0** 라이선스를 사용했으나, 2021년 1월 Elastic은 **Elastic License 2.0**과 **SSPL**로 전환했습니다. Elastic이 이러한 변화를 선택한 이유는 클라우드 제공자, 특히 **AWS**와의 경쟁 때문입니다. AWS는 Elasticsearch를 기반으로 한 자체 서비스를 제공하면서도, 이에 대한 기여나 비용 지불 없이 수익을 창출했기 때문에 Elastic은 이를 견제하고자 라이선스를 변경했습니다. +Elasticsearch는 처음에 Apache 2.0 라이선스를 사용했으나, 2021년 1월 Elastic은 Elastic License 2.0과 SSPL로 전환했습니다. Elastic이 이러한 변화를 선택한 이유는 클라우드 제공자, 특히 AWS와의 경쟁 때문입니다. AWS는 Elasticsearch를 기반으로 한 자체 서비스를 제공하면서도, 이에 대한 기여나 비용 지불 없이 수익을 창출했기 때문에 Elastic은 이를 견제하고자 라이선스를 변경했습니다. -**Elastic License 2.0**은 소스 코드를 공개하지만 상업적인 클라우드 서비스에서의 사용을 제한하는 라이선스로, Elastic의 기술적 자산을 보호하는 수단으로 활용되었습니다. **AWS**는 이에 대응해 **[OpenSearch](https://opensearch.org/)** 프로젝트를 시작하며 Apache 2.0 라이선스를 계속 유지했습니다. +Elastic License 2.0은 소스 코드를 공개하지만 상업적인 클라우드 서비스에서의 사용을 제한하는 라이선스로, Elastic의 기술적 자산을 보호하는 수단으로 활용되었습니다. AWS는 이에 대응해 [OpenSearch](https://opensearch.org/) 프로젝트를 시작하며 Apache 2.0 라이선스를 계속 유지했습니다. 이에 대해서는 이전 블로그, "**[Elastic License 2.0 그리고 진화하는 오픈소스 라이선스](https://openchain-project.github.io/OpenChain-KWG/blog/2021/03/28/elastic-license-2.0-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%EC%A7%84%ED%99%94%ED%95%98%EB%8A%94-%EC%98%A4%ED%94%88%EC%86%8C%EC%8A%A4-%EB%9D%BC%EC%9D%B4%EC%84%A0%EC%8A%A4/)**"에서 자세히 다룬 바 있습니다. @@ -54,7 +54,7 @@ AGPL-3.0에 대한 자세한 가이드는 여기에서 참고하실 수 있습 Elastic이 **AGPL-3.0**을 선택한 이유는 다음과 같습니다: -- **오픈소스 커뮤니티와의 관계 회복**: 이전의 라이선스 변경으로 인해 커뮤니티의 신뢰를 잃었기 때문에, 이를 회복하고자 OSI가 인정하는 AGPL-3.0으로 돌아섰습니다. Elastic의 창립자이자 CTO인 Shay Banon은 "우리는 항상 오픈소스의 정신과 그것이 가능하게 하는 명확성과 투명성을 강하게 믿어왔습니다"라고 [말했습니다](https://www.elastic.co/pricing/faq/licensing). +- **오픈소스 커뮤니티와의 관계 회복**: 이전의 라이선스 변경으로 인해 커뮤니티의 신뢰를 잃었기 때문에, 이를 회복하고자 OSI가 인정하는 AGPL-3.0으로 돌아섰습니다. Elastic의 창립자이자 CTO인 Shay Banon은 "우리는 항상 오픈소스의 정신과 그것이 가져다주는 명확성과 투명성을 강하게 믿어왔습니다"라고 [말했습니다](https://www.elastic.co/pricing/faq/licensing). - **사용자들에게 더 많은 자유와 유연성 제공**: AGPL-3.0은 OSI가 승인한 라이선스로, 사용자들에게 더 많은 권리를 제공합니다. - **신뢰도 향상**: OSI가 승인한 라이선스를 사용함으로써 오픈소스 커뮤니티 내에서의 신뢰도를 높이고자 했습니다. diff --git a/content/ko/blog/2024/20240906_spdx_30/index.md b/content/ko/blog/2024/20240906_spdx_30/index.md index 1e3d75e2d5..f3c7fa3ba5 100644 --- a/content/ko/blog/2024/20240906_spdx_30/index.md +++ b/content/ko/blog/2024/20240906_spdx_30/index.md @@ -109,7 +109,7 @@ SPDX 3.0은 ISO/IEC 5962:2021 표준을 준수하며, 이는 글로벌 소프트 - 다양한 규제 요구사항(예: 미국 정부 EO 14028, EU 사이버 복원력법)을 충족 가능 - 조직 간 소프트웨어 정보 교환의 일관성과 신뢰성 향상 -SPDX 3.0의 이러한 핵심 기능들은 소프트웨어 공급망의 투명성, 보안, 그리고 컴플라이언스를 크게 개선하며, 현대적인 소프트웨어 개발 및 관리 요구사항을 충족시키는 데 중요한 역할을 합니다. +SPDX 3.0의 이러한 핵심 기능들은 소프트웨어 공급망의 투명성, 보안, 그리고 컴플라이언스를 크게 개선하며, 현대적인 소프트웨어 개발 및 관리 요구사항을 충족시킵니다. Citations:
[1] [https://scribesecurity.com/ko/blog/spdx-vs-cyclonedx-sbom-formats-compared/](https://scribesecurity.com/ko/blog/spdx-vs-cyclonedx-sbom-formats-compared/)
@@ -412,7 +412,7 @@ Citations:
1. **자동화된 SBOM 생성** - SPDX 3.0은 CI/CD 파이프라인에 통합되어 자동으로 SBOM을 생성할 수 있습니다[6]. - - 이는 "machine-speed" SBOM 생성을 가능하게 하여, 소프트웨어 릴리스 주기에 맞춰 즉시 SBOM을 업데이트할 수 있습니다. + - 이는 "machine-speed"로 SBOM을 생성할 수 있게 해, 소프트웨어 릴리스 주기에 맞춰 즉시 SBOM을 업데이트할 수 있습니다. 2. **일관된 포맷 사용** - SPDX 3.0은 표준화된 SBOM 포맷을 제공하여 일관성을 보장합니다[6]. - 이를 통해 조직 간 SBOM 데이터 교환이 용이해지고, 자동화된 분석이 가능해집니다. @@ -906,7 +906,7 @@ SPDX 3.0은 기업의 오픈소스 관리자에게 강력하고 유연한 도구 - SPDX 3.0을 기반으로 조직 고유의 오픈소스 관리 모델을 개발합니다. - 이를 통해 업계 내에서 오픈소스 관리의 선도적 위치를 확보합니다. -결론적으로, SPDX 3.0은 기업의 오픈소스 관리자에게 오픈소스 생태계를 효과적으로 관리하고 활용할 수 있는 강력한 도구를 제공합니다. 전략적이고 체계적인 접근을 통해 SPDX 3.0을 활용한다면, 조직은 오픈소스의 이점을 최대화하면서 관련 리스크를 최소화할 수 있을 것입니다. 오픈소스 관리자는 이러한 도구를 통해 조직의 디지털 혁신과 경쟁력 강화에 핵심적인 역할을 수행할 수 있을 것입니다. +SPDX 3.0은 기업의 오픈소스 관리자에게 오픈소스 생태계를 효과적으로 관리하고 활용할 수 있는 강력한 도구를 제공합니다. 전략적이고 체계적인 접근을 통해 SPDX 3.0을 활용한다면, 조직은 오픈소스의 이점을 최대화하면서 관련 리스크를 최소화할 수 있을 것입니다. 오픈소스 관리자는 이러한 도구를 통해 조직의 디지털 혁신과 경쟁력 강화에 핵심적인 역할을 수행할 수 있을 것입니다. diff --git a/content/ko/blog/2024/20241223_oracle_rimini/index.md b/content/ko/blog/2024/20241223_oracle_rimini/index.md index 7f8253593c..e9892b0847 100644 --- a/content/ko/blog/2024/20241223_oracle_rimini/index.md +++ b/content/ko/blog/2024/20241223_oracle_rimini/index.md @@ -16,7 +16,7 @@ resources: ## **들어가며** -소프트웨어 지식재산권 침해 논란에서 '파생저작물(derivative works)'이라는 개념은 매우 중요한 역할을 합니다. 특히 [GNU General Public License (GPL)](https://www.gnu.org/licenses/gpl-3.0.html)과 같은 오픈소스 라이선스를 다룰 때 이 개념은 핵심적인 쟁점이 됩니다. 최근 [Oracle](https://www.oracle.com/)과 [Rimini Street](https://www.riministreet.com/) 간의 소송은 파생저작물의 정의와 관련된 법적 해석을 다시금 주목하게 만들었습니다. 이번 글에서는 이 사건의 배경, 주요 판결 내용, 그리고 오픈소스 라이선스에 미칠 영향을 살펴보겠습니다. +소프트웨어 지식재산권 침해 논란에서 '파생저작물(derivative works)'이라는 개념은 매우 중요합니다. 특히 [GNU General Public License (GPL)](https://www.gnu.org/licenses/gpl-3.0.html)과 같은 오픈소스 라이선스를 다룰 때 이 개념은 핵심적인 쟁점이 됩니다. 최근 [Oracle](https://www.oracle.com/)과 [Rimini Street](https://www.riministreet.com/) 간의 소송은 파생저작물의 정의와 관련된 법적 해석을 다시금 주목하게 만들었습니다. 이번 글에서는 이 사건의 배경, 주요 판결 내용, 그리고 오픈소스 라이선스에 미칠 영향을 살펴보겠습니다. --- diff --git a/content/ko/blog/2025/20250113_LGPL_AVM/index.md b/content/ko/blog/2025/20250113_LGPL_AVM/index.md index 9752f6d7fc..6c76d26f49 100644 --- a/content/ko/blog/2025/20250113_LGPL_AVM/index.md +++ b/content/ko/blog/2025/20250113_LGPL_AVM/index.md @@ -41,7 +41,7 @@ Sebastian Steck이라는 독일의 소프트웨어 개발자가 2021년 5월 AVM ### 소송의 법적 근거 -이 소송의 중요한 특징은 Sebastian Steck이 LGPL-2.1 소프트웨어의 저작권자가 아님에도 불구하고 소송을 제기할 수 있었다는 점입니다. 이는 LGPL-2.1 라이선스가 제3자를 위한 계약의 성격을 가지고 있기 때문입니다. [소장](https://sfconservancy.org/static/docs/avm-Complaint_Klageschrift_EN.pdf)에 따르면 사용자도 LGPL-2.1에 따라 소스 코드를 받을 권리를 갖게 됩니다: +이 소송의 중요한 특징은 Sebastian Steck이 LGPL-2.1 소프트웨어의 저작권자가 아님에도 불구하고 소송을 제기할 수 있었다는 점입니다. 이는 LGPL-2.1 라이선스가 제3자를 위한 계약의 성격이 있기 때문입니다. [소장](https://sfconservancy.org/static/docs/avm-Complaint_Klageschrift_EN.pdf)에 따르면 사용자도 LGPL-2.1에 따라 소스 코드를 받을 권리를 갖게 됩니다: "This license agreement represents a genuine contract in favor of third parties in accordance with Section 328 of the German Civil Code (BGB), namely in favor of the users who receive the software in object code and, in accordance with the wording of the LGPL-2.1 license conditions to be handed over to them, have a direct right to the transfer of the complete corresponding source code." diff --git a/content/ko/blog/2026/20260220_ffmpeg/index.md b/content/ko/blog/2026/20260220_ffmpeg/index.md index f104211ef7..b91b82b4e7 100644 --- a/content/ko/blog/2026/20260220_ffmpeg/index.md +++ b/content/ko/blog/2026/20260220_ffmpeg/index.md @@ -24,7 +24,7 @@ resources: ## 1. 사건 개요: 2025년 GitHub 리포지토리 강제 중단 2025년 12월, 중국의 대표적인 반도체 기업 Rockchip의 GitHub 리포지토리 중 하나인 -`rockchip-linux/mpp` (Media Process Platform)가 GitHub에 의해 비활성화(disabled)되는 +`rockchip-linux/mpp` (Media Process Platform)를 GitHub가 비활성화(disabled)하는 사건이 발생했습니다. 이는 FFmpeg 개발자가 제출한 DMCA(Digital Millennium Copyright Act) Takedown 요청에 따른 조치였습니다. @@ -183,8 +183,8 @@ static MPP_INLINE RK_S32 vpx_rac_get_prob(VPXRangeCoder *c, RK_U8 prob) 변경된 것은 딱 두 가지입니다. -- `av_always_inline` → `MPP_INLINE` (Rockchip 자체 매크로) -- `uint8_t`, `unsigned int` → `RK_U8`, `RK_U32` (Rockchip 자체 타입 정의) +- `av_always_inline`을 `MPP_INLINE`(Rockchip 자체 매크로)로 교체 +- `uint8_t`, `unsigned int`를 `RK_U8`, `RK_U32`(Rockchip 자체 타입 정의)로 교체 알고리즘 로직, 변수명, 연산 순서, 비트 연산 방식은 완전히 동일합니다. @@ -315,7 +315,7 @@ Allwinner 사례에서도 CedarX 라이브러리 내부에 FFmpeg `libavcodec` ### 2) 'Upstream First' 정책 확인 - 벤더가 제공하는 드라이버가 리눅스 메인라인 커널(Upstream)에 병합되어 있는지 확인하십시오. -- 메인라인에 병합된 코드는 전 세계 개발자들에 의해 코드 리뷰와 라이선스 검토를 거친 +- 메인라인에 병합된 코드는 전 세계 개발자가 코드 리뷰와 라이선스 검토를 거친 것이므로, 벤더가 자체적으로 운영하는 GitHub 리포지토리보다 상대적으로 신뢰도가 높습니다. ### 3) 내부 개발팀 가이드: "복사 붙여넣기" 금지 diff --git a/content/ko/blog/2026/20260518_eu-cra/index.md b/content/ko/blog/2026/20260518_eu-cra/index.md index 7ffcc5b62e..d1ebafa972 100644 --- a/content/ko/blog/2026/20260518_eu-cra/index.md +++ b/content/ko/blog/2026/20260518_eu-cra/index.md @@ -9,11 +9,11 @@ tags: ["CRA", "Cyber Resilience Act", "취약점 보고", "SBOM", "사이버보 --- {{% alert title="이 보고서에 대해" color="info" %}} -이 보고서는 Claude Code 하네스를 통해 다수의 전문 AI 에이전트가 협업해 생성되었습니다 — 1차 출처 조사부터 배경·동향 보강, 사실 검증까지. 검증 단계에서 위임법 (EU) 2026/881의 CSIRT 통지 지연 조건 기술 오류 1건이 발견·정정됐고, 과징금 근거에 CRA 원문이 1차 출처로 보강됐습니다. 모든 사실 주장은 EU 1차 출처(CRA 원문·유럽위원회·ENISA·표준)에 근거합니다. +이 보고서는 Claude Code 하네스를 통해 다수의 전문 AI 에이전트가 협업해 생성되었습니다 — 1차 출처 조사부터 배경과 동향 보강, 사실 검증까지. 검증 단계에서 위임법 (EU) 2026/881의 CSIRT 통지 지연 조건 기술 오류 1건이 발견되어 정정됐고, 과징금 근거에 CRA 원문이 1차 출처로 보강됐습니다. 모든 사실 주장은 EU 1차 출처(CRA 원문, 유럽위원회, ENISA, 표준)에 근거합니다. {{% /alert %}} > **요약** -> EU 사이버 복원력법(Cyber Resilience Act, CRA — Regulation (EU) 2024/2847)은 EU 시장에 출시되는 모든 "디지털 요소를 가진 제품(product with digital elements, PDE)"에 수평적 사이버보안 의무를 부과하는, EU 역사상 첫 포괄적 제품 보안 규정이다. 2024년 12월 10일 발효된 이 규정은 단계적으로 적용되며, 2026년 9월 11일부터는 제14조 보고 의무가 발효되어 제조사·수입사·유통사가 실제 악용 중인 취약점과 중대한 보안 사고를 24시간·72시간·14일 시한 안에 ENISA(유럽 사이버보안청)와 회원국 CSIRT에 통지해야 한다. 이 날짜까지 보고 워크플로우가 가동되지 않으면 최대 1,500만 유로 또는 전 세계 연간 매출 2.5%의 과징금 위험이 발생하며, 한국 기업이라도 EU 시장에 제품을 출시하면 즉시 적용 대상이 된다. [A1](#a1)·[B1](#b1)·[E1](#e1) +> EU 사이버 복원력법(Cyber Resilience Act, CRA — Regulation (EU) 2024/2847)은 EU 시장에 출시되는 모든 "디지털 요소를 가진 제품(product with digital elements, PDE)"에 수평적 사이버보안 의무를 부과하는, EU 역사상 첫 포괄적 제품 보안 규정이다. 2024년 12월 10일 발효된 이 규정은 단계적으로 적용되며, 2026년 9월 11일부터는 제14조 보고 의무가 발효되어 제조사, 수입사, 유통사가 실제 악용 중인 취약점과 중대한 보안 사고를 각각 24시간, 72시간, 14일 시한 안에 ENISA(유럽 사이버보안청)와 회원국 CSIRT에 통지해야 한다. 이 날짜까지 보고 워크플로우가 가동되지 않으면 최대 1,500만 유로 또는 전 세계 연간 매출 2.5%의 과징금 위험이 발생하며, 한국 기업이라도 EU 시장에 제품을 출시하면 즉시 적용 대상이 된다. [A1](#a1), [B1](#b1), [E1](#e1) --- @@ -54,7 +54,7 @@ flowchart LR CRA는 "디지털 요소를 가진 제품(product with digital elements, PDE)"에 적용된다. 장치나 네트워크와 논리적·물리적 데이터 연결이 가능한 하드웨어와 소프트웨어를 포괄하며, 독립적으로 시장에 출시된 소프트웨어 구성요소도 포함된다. [B3](#b3) -다음 제품은 적용 범위에서 제외된다. 상업적 활동 없이 공급되는 자유·오픈소스 소프트웨어, 의료기기·자동차처럼 더 엄격한 부문별 사이버보안 규제가 이미 적용되는 제품이 대표적이다. 단, 기존 사이버보안 규제의 적용 대상이어도 CRA가 "보완적"으로 적용될 여지가 있어 부문별 판단이 필요하다. [A1](#a1)·[E2](#e2) +다음 제품은 적용 범위에서 제외된다. 상업적 활동 없이 공급되는 자유 오픈소스 소프트웨어, 그리고 의료기기나 자동차처럼 더 엄격한 부문별 사이버보안 규제가 이미 적용되는 제품이 대표적이다. 단, 기존 사이버보안 규제의 적용 대상이어도 CRA가 "보완적"으로 적용될 여지가 있어 부문별 판단이 필요하다. [A1](#a1), [E2](#e2) ```mermaid %%{init: {'theme':'default', 'themeVariables': {'fontSize':'18px'}, 'flowchart': {'nodeSpacing': 40, 'rankSpacing': 50}} }%% @@ -102,7 +102,7 @@ CRA는 전면 적용이 단일 시점에 이뤄지지 않는다. **Part II — 취약점 처리 요건**: 취약점 식별·문서화, SBOM 유지, 신속한 패치 제공과 무료 배포, 조정된 취약점 공개(Coordinated Vulnerability Disclosure, CVD) 정책, 악용 취약점·사고 보고(Art. 14), 생애 주기 전반에 걸친 취약점 모니터링. -이 요건들은 현 시점에 확정된 조화 표준이 없어 CRA 원문의 기능적 요건으로 직접 이행해야 한다. ENISA·JRC가 공동 발간한 *CRA Requirements Standards Mapping*(2024)이 기존 표준과의 매핑을 제공하며, ISO/IEC 30111(취약점 처리)·29147(취약점 공시)·NIST SP 800-218(SSDF)이 주요 참조점이다. [B5](#b5)·[C1](#c1)·[C2](#c2)·[C6](#c6) +이 요건들은 현 시점에 확정된 조화 표준이 없어 CRA 원문의 기능적 요건으로 직접 이행해야 한다. ENISA와 JRC가 공동 발간한 *CRA Requirements Standards Mapping*(2024)이 기존 표준과의 매핑을 제공하며, ISO/IEC 30111(취약점 처리), ISO/IEC 29147(취약점 공시), NIST SP 800-218(SSDF)이 주요 참조점이다. [B5](#b5), [C1](#c1), [C2](#c2), [C6](#c6) ### 3.2 지원 기간 @@ -122,7 +122,7 @@ CRA Annex I Part II는 소프트웨어 부품 명세서(Software Bill of Materia 제14조는 두 부류의 사건 발생을 제조사의 통지 트리거로 규정한다. [A1](#a1)·[B2](#b2) -하나는 **실제 악용되고 있는 취약점(actively exploited vulnerability)**이다. 취약점이 이론적으로 존재하는 것이 아니라 공격자에 의해 실제 악용되는 것이 확인된 시점이 트리거다. 다른 하나는 **중대한 보안 사고(severe incident)**로, 제품의 보안에 영향을 미치는 심각한 운영 중단·손실·손해를 야기하거나 야기할 가능성이 있는 사건이다. +하나는 **실제 악용되고 있는 취약점(actively exploited vulnerability)**이다. 취약점이 이론적으로 존재하는 것이 아니라 공격자가 실제 악용하는 것이 확인된 시점이 트리거다. 다른 하나는 **중대한 보안 사고(severe incident)**로, 제품의 보안에 영향을 미치는 심각한 운영 중단이나 손실, 손해를 야기하거나 야기할 가능성이 있는 사건이다. 제조사 외에 수입사와 유통사도 비준수를 발견하거나 사고를 인지했을 때 해당 정보를 제조사에 통지해야 한다. @@ -200,13 +200,13 @@ flowchart LR 통지된 정보의 성격에 대한 평가에 비추어 지연이 정당화되는 경우, 수신 CSIRT가 해당 정보의 기밀성을 보장할 수 없는 경우, 단일 보고 플랫폼 자체가 침해되었거나 일시적으로 운영이 불가한 경우다. 또한 트래픽 라이트 프로토콜(Traffic Light Protocol, TLP)·정보 접근 프로토콜(Permissible Actions Protocol, PAP) 등 적절한 도구로 위험을 완화할 수 없을 때, "엄격히 필요한 기간"에 한해서만 지연이 허용된다. -제조사 → CSIRT의 24시간 시한은 이 위임법의 영향을 받지 않는다. 위임법은 CSIRT 간의 추가 전파 단계에 보안 사유의 완화 장치를 마련한 것이다. +제조사가 CSIRT에 통지하는 24시간 시한은 이 위임법의 영향을 받지 않는다. 위임법은 CSIRT 간의 추가 전파 단계에 보안 사유의 완화 장치를 마련한 것이다. ### 4.5 GDPR·NIS2와의 병행 적용 CRA 보고와 다른 규제의 보고 의무가 동시에 발생할 수 있다. 취약점·사고로 침해된 데이터에 개인정보가 포함된 경우, CRA 통지는 GDPR(General Data Protection Regulation) 제33조의 72시간 감독기관 통지 의무를 대체하지 않는다. [A5](#a5) 두 통지는 서로 다른 채널과 수신처(데이터보호당국 vs CSIRT/ENISA)로 별도로 이뤄져야 한다. -NIS2 지침(Directive (EU) 2022/2555) 적용 대상인 필수 서비스·중요 서비스 운영자가 자사 제품에서 취약점·사고를 인지한 경우에도 마찬가지다. CRA 보고와 NIS2 보고가 동시에 필요할 수 있으며, Digital Omnibus 패키지의 "report once, share many" 모델이 두 보고 의무를 통합하는 방향으로 논의 중이나 아직 입법으로 확정되지 않았다. [A4](#a4)·[E2](#e2) +NIS2 지침(Directive (EU) 2022/2555) 적용 대상인 필수 서비스 및 중요 서비스 운영자가 자사 제품에서 취약점이나 사고를 인지한 경우에도 마찬가지다. CRA 보고와 NIS2 보고가 동시에 필요할 수 있으며, Digital Omnibus 패키지의 "report once, share many" 모델이 두 보고 의무를 통합하는 방향으로 논의 중이나 아직 입법으로 확정되지 않았다. [A4](#a4), [E2](#e2) --- @@ -236,9 +236,9 @@ CRA는 본질 요건만 규정하고 기술적 세부는 조화 표준에 위임 | prEN 40000-2-1 (초안) | CEN/CENELEC | CRA 조화 수평 표준 — 2026-08-30 발행 목표 | | BSI TR-03183-2 v2.1.0 | BSI (독일) | CRA 정합 SBOM 필드 매핑 기술 가이드라인 | -[C1](#c1)·[C2](#c2)·[C3](#c3)·[C4](#c4)·[C5](#c5)·[C6](#c6)·[G1](#g1) +[C1](#c1), [C2](#c2), [C3](#c3), [C4](#c4), [C5](#c5), [C6](#c6), [G1](#g1) -유럽 취약점 데이터베이스(European Vulnerability Database, EUVD)는 NIS2 지침 제12조를 이행하는 형태로 ENISA가 2025년 5월 13일 정식 가동했다. [F1](#f1) CRA의 "취약점 모니터링" 요건에서 EUVD는 1차 모니터링 출처로 활용 가능하다. EUVD는 독자적 식별자(`EUVD-YYYY-NNNNNN`)를 사용하되 CVE ID와 CVSS 점수를 함께 표기한다. SRP와는 별개 시스템으로, SRP는 제조사 → 당국 통지 채널이고 EUVD는 공개 데이터베이스다. [B4](#b4)·[F2](#f2) +유럽 취약점 데이터베이스(European Vulnerability Database, EUVD)는 NIS2 지침 제12조를 이행하는 형태로 ENISA가 2025년 5월 13일 정식 가동했다. [F1](#f1) CRA의 "취약점 모니터링" 요건에서 EUVD는 1차 모니터링 출처로 활용 가능하다. EUVD는 독자적 식별자(`EUVD-YYYY-NNNNNN`)를 사용하되 CVE ID와 CVSS 점수를 함께 표기한다. SRP와는 별개 시스템으로, SRP는 제조사가 당국에 통지하는 채널이고 EUVD는 공개 데이터베이스다. [B4](#b4)·[F2](#f2) --- @@ -246,15 +246,15 @@ CRA는 본질 요건만 규정하고 기술적 세부는 조화 표준에 위임 2024년 12월 발효 이후 규제 환경은 위임법·시행규칙·가이던스 세 방향에서 구체화됐다. -시행규칙 (EU) 2025/2392는 2025년 11월 28일 채택돼 12월 21일 발효됐다. CRA Annex III·IV의 "중요(important)·중대(critical) 제품"을 28개 범주로 구분해 Class I·Class II·중대 세 등급에 배치하는 기술 정의를 확정한다. 제조사가 자사 제품의 적합성 평가 경로를 판단할 1차 법적 기준이 이 규칙이다. [A3](#a3) +시행규칙 (EU) 2025/2392는 2025년 11월 28일 채택돼 12월 21일 발효됐다. CRA Annex III과 IV의 "중요(important) 및 중대(critical) 제품"을 28개 범주로 구분해 Class I, Class II, 중대 세 등급에 배치하는 기술 정의를 확정한다. 제조사가 자사 제품의 적합성 평가 경로를 판단할 1차 법적 기준이 이 규칙이다. [A3](#a3) 위임법 (EU) 2026/881은 2025년 12월 11일 채택돼 2026년 4월 20일 관보에 실렸다. CSIRT 간 통지 전파 지연 조건의 법제화가 핵심이다(§4.4 참조). [A2](#a2) -가이던스 문서는 두 단계로 나왔다. 2025년 12월 3일 Commission 첫 공식 FAQ가 발행됐고(12월 19일 업데이트), 위험 평가의 범위·반복성과 "의도된 사용(intended purpose)" 개념을 비구속적이지만 처음으로 풀어냈다. 이어 2026년 3월 3일에는 CRA 제26조에 따른 첫 가이던스 초안이 공개됐다. 총 75쪽 분량 중 약 4분의 1이 오픈소스 스튜어드 정의에 할애된 이 초안은 원격 데이터 처리 솔루션, 자유·오픈소스 소프트웨어, 지원 기간, CRA와 NIS2·DORA 등 타 규정과의 상호관계를 다뤘다. 3월 31일 의견수렴이 마감됐으나 최종본은 2026년 5월 현재까지 미공표다. [E3](#e3) +가이던스 문서는 두 단계로 나왔다. 2025년 12월 3일 Commission 첫 공식 FAQ가 발행됐고(12월 19일 업데이트), 위험 평가의 범위와 반복성, "의도된 사용(intended purpose)" 개념을 비구속적이지만 처음으로 풀어냈다. 이어 2026년 3월 3일에는 CRA 제26조에 따른 첫 가이던스 초안이 공개됐다. 총 75쪽 분량 중 약 4분의 1이 오픈소스 스튜어드 정의에 할애된 이 초안은 원격 데이터 처리 솔루션, 자유·오픈소스 소프트웨어, 지원 기간, CRA와 NIS2·DORA 등 타 규정과의 상호관계를 다뤘다. 3월 31일 의견수렴이 마감됐으나 최종본은 2026년 5월 현재까지 미공표다. [E3](#e3) 오픈소스 커뮤니티의 집단 대응은 2024년 4월 2일 아파치(Apache Software Foundation), 블렌더(Blender Foundation), 이클립스(Eclipse Foundation), OpenSSL, PHP(PHP Foundation), 파이썬(Python Software Foundation), 러스트(Rust Foundation) 등 7개 재단이 안전한 소프트웨어 개발을 위한 공통 표준을 함께 마련하겠다고 발표하면서 가시화됐다. 이 작업은 브뤼셀의 이클립스 재단(Eclipse Foundation AISBL)이 주관했고, 같은 해 9월 24일 Open Regulatory Compliance Working Group(ORC WG)으로 발전해 스튜어드의 의무 범위를 정리한 백서를 공개했다. OpenSSF는 SBOM 표준 정렬 방향을 2025년 10월 22일 공개했다. [F3](#f3)·[D1](#d1) -가장 지속적으로 제기되는 쟁점은 24시간 통지의 실효성이다. HackerOne 등 보안 연구자 측은 "패치가 준비되기 전에 취약점 존재 사실이 당국에 통지되면 미완화 취약점이 노출될 위험이 있다"는 주장을 2024년부터 일관되게 제기해왔다. [E4](#e4) 위임법 (EU) 2026/881은 CSIRT 간 전파 지연 조건만 신설했을 뿐, 제조사 → CSIRT 24시간 시한 자체에는 손대지 않았다. +가장 지속적으로 제기되는 쟁점은 24시간 통지의 실효성이다. HackerOne 등 보안 연구자 측은 "패치가 준비되기 전에 취약점 존재 사실이 당국에 통지되면 미완화 취약점이 노출될 위험이 있다"는 주장을 2024년부터 일관되게 제기해왔다. [E4](#e4) 위임법 (EU) 2026/881은 CSIRT 간 전파 지연 조건만 신설했을 뿐, 제조사가 CSIRT에 통지하는 24시간 시한 자체에는 손대지 않았다. --- @@ -304,7 +304,7 @@ CRA의 두드러진 특징은 수평적 적용(IoT·SW·임베디드를 가리 보고 인프라와 내부 플레이북 구성이 그 다음이다. SRP 사양이 아직 공개되지 않았지만, 인적 체계와 내부 절차는 사양 공개와 무관하게 지금 바로 설계할 수 있다. ENISA 발표를 모니터링하면서 API 사양이 나오는 즉시 통합 시험에 착수할 수 있도록 팀을 준비시켜야 한다. -SBOM 파이프라인 자동화는 9월 11일까지 완료해야 한다. 출고 버전마다 SPDX 또는 CycloneDX 형식의 SBOM이 자동 생성·보관되지 않으면 보고 의무를 이행할 때 필요한 소프트웨어 구성 정보 자체가 없게 된다. [A1](#a1)·[B2](#b2)·[E2](#e2)·[E4](#e4) +SBOM 파이프라인 자동화는 9월 11일까지 완료해야 한다. 출고 버전마다 SPDX 또는 CycloneDX 형식의 SBOM이 자동으로 생성되고 보관되지 않으면 보고 의무를 이행할 때 필요한 소프트웨어 구성 정보 자체가 없게 된다. [A1](#a1), [B2](#b2), [E2](#e2), [E4](#e4) --- diff --git a/content/ko/guide/iso18974_guide/1-program-foundation/1-policy/_index.md b/content/ko/guide/iso18974_guide/1-program-foundation/1-policy/_index.md index 3887d4597c..8c60d67ad5 100644 --- a/content/ko/guide/iso18974_guide/1-program-foundation/1-policy/_index.md +++ b/content/ko/guide/iso18974_guide/1-program-foundation/1-policy/_index.md @@ -26,9 +26,9 @@ description: > - 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을 관리하는 정책을 문서화하고 공식화한다. -- 정책에 취약점 탐지·평가·대응·통보 원칙과 CVD(Coordinated Vulnerability +- 정책에 취약점 탐지, 평가, 대응, 통보 원칙과 CVD(Coordinated Vulnerability Disclosure) 방침을 포함한다. -- 프로그램 참여자(개발자·보안 담당·법무·IT 등)에게 정책을 전파하는 절차를 +- 프로그램 참여자(개발자, 보안 담당, 법무, IT 등)에게 정책을 전파하는 절차를 수립하고 문서화한다. - **정책과 전파 절차 자체를 정기적으로 검토하여 최신 상태를 유지하는 검토 프로세스**를 정책 내에 명시한다. diff --git a/content/ko/guide/iso18974_guide/1-program-foundation/2-competence/_index.md b/content/ko/guide/iso18974_guide/1-program-foundation/2-competence/_index.md index d6d899533d..c981bed258 100644 --- a/content/ko/guide/iso18974_guide/1-program-foundation/2-competence/_index.md +++ b/content/ko/guide/iso18974_guide/1-program-foundation/2-competence/_index.md @@ -13,7 +13,7 @@ description: > {{% /alert %}} {{% alert title="★ 18974 전용 항목 — Documented Evidence 강도" color="warning" %}} -§4.1.2.3·§4.1.2.5·§4.1.2.6은 ISO 18974 전용(★) 항목으로 **Documented Evidence**(문서화된 증거)를 요구한다. 단순 절차 문서로는 부족하며, 실제 수행 기록(참여자 목록·검토 회의록·내부 모범 사례 비교 결과)을 함께 보관해야 한다. 강도 차이의 자세한 설명은 [§4.1.5 표준 관행 — Documented Evidence 안내](../5-standard-practice/#iso-18974-전용-항목의-강도--documented-evidence)를 참고한다. +§4.1.2.3, §4.1.2.5, §4.1.2.6은 ISO 18974 전용(★) 항목으로 **Documented Evidence**(문서화된 증거)를 요구한다. 단순 절차 문서로는 부족하며, 실제 수행 기록(참여자 목록, 검토 회의록, 내부 모범 사례 비교 결과)을 함께 보관해야 한다. 강도 차이의 자세한 설명은 [§4.1.5 표준 관행 — Documented Evidence 안내](../5-standard-practice/#iso-18974-전용-항목의-강도--documented-evidence)를 참고한다. {{% /alert %}} ## 1. 조항 개요 diff --git a/content/ko/guide/iso18974_guide/1-program-foundation/3-awareness/_index.md b/content/ko/guide/iso18974_guide/1-program-foundation/3-awareness/_index.md index 35dd4512fd..afeb7c6616 100644 --- a/content/ko/guide/iso18974_guide/1-program-foundation/3-awareness/_index.md +++ b/content/ko/guide/iso18974_guide/1-program-foundation/3-awareness/_index.md @@ -62,7 +62,7 @@ description: > ISO/IEC 5230 §3.1.3.1과 기본 방법은 동일하나, 인식 평가 문항이 **보안 보증**에 초점을 두어야 한다. 세 가지 핵심 인식 항목은 ①보안 보증 프로그램의 목표(취약점 -식별·평가·대응·CVD), ②자신의 역할이 보안 체계에 기여하는 방법, ③프로세스 +식별, 평가, 대응, CVD), ②자신의 역할이 보안 체계에 기여하는 방법, ③프로세스 미준수 시 발생하는 보안·법적·사업적 위험이다. 평가 결과를 문서로 기록하고 보관하는 방법은 5230과 동일하다. 최소 연 1회 diff --git a/content/ko/guide/iso18974_guide/1-program-foundation/5-standard-practice/_index.md b/content/ko/guide/iso18974_guide/1-program-foundation/5-standard-practice/_index.md index 622e571f9e..1cd97a2079 100644 --- a/content/ko/guide/iso18974_guide/1-program-foundation/5-standard-practice/_index.md +++ b/content/ko/guide/iso18974_guide/1-program-foundation/5-standard-practice/_index.md @@ -14,7 +14,7 @@ description: > {{% alert title="ISO 18974 전용(★) 항목의 강도 — Documented Evidence" color="warning" %}} -ISO/IEC 18974는 ISO/IEC 5230과 달리 9개 전용 항목(★: §4.1.2.3·4.1.2.5·4.1.2.6·4.1.4.2·4.1.4.3·**§4.1.5.1**·4.2.2.3·4.3.2.1·4.3.2.2)에 대해 **"Documented Evidence"**(문서화된 증거)를 요구한다. +ISO/IEC 18974는 ISO/IEC 5230과 달리 9개 전용 항목(★: §4.1.2.3, 4.1.2.5, 4.1.2.6, 4.1.4.2, 4.1.4.3, **§4.1.5.1**, 4.2.2.3, 4.3.2.1, 4.3.2.2)에 대해 **"Documented Evidence"**(문서화된 증거)를 요구한다. 이는 일반 항목의 `documented procedure`(문서화된 절차)·`document`(문서)보다 강한 증거 수준이다. | 강도 | ISO 표현 | 충족 수준 | 인증 심사 | @@ -23,7 +23,7 @@ ISO/IEC 18974는 ISO/IEC 5230과 달리 9개 전용 항목(★: §4.1.2.3·4.1.2 | 중 | `documented procedure` | 문서화된 절차 + 절차 준수 의도 | 절차 본문 검토 | | **강** | **`Documented Evidence`** | **절차 + 실제 수행 기록(증거 팩)** | **수행 이력·로그·티켓·이슈 추적 시스템 결과 등 실증 증거 검증** | -§4.1.5.1은 8가지 방법 각각에 대해 단순 "절차 문서"가 아니라 **수행된 활동의 증거**(스캔 로그·티켓·승인 이력·VEX 발행 기록 등)를 함께 보관해야 인증 심사를 통과할 수 있다. +§4.1.5.1은 8가지 방법 각각에 대해 단순 "절차 문서"가 아니라 **수행된 활동의 증거**(스캔 로그, 티켓, 승인 이력, VEX 발행 기록 등)를 함께 보관해야 인증 심사를 통과할 수 있다. {{% /alert %}} @@ -31,8 +31,8 @@ ISO/IEC 18974는 ISO/IEC 5230과 달리 9개 전용 항목(★: §4.1.2.3·4.1.2 §4.1.5는 ISO/IEC 5230에 없는 18974 전용 신규 조항이다. 오픈소스 취약점을 다루는 **8가지 표준 처리 방법** 각각에 대해 문서화된 절차를 수립하도록 요구한다. -이 조항은 단순히 취약점에 "대응한다"는 선언을 넘어, 위협 식별·탐지·후속 조치· -고객 통보·배포 후 모니터링·지속적 보안 테스트·위험 검증·정보 수출까지 전체 +이 조항은 단순히 취약점에 "대응한다"는 선언을 넘어, 위협 식별, 탐지, 후속 조치, +고객 통보, 배포 후 모니터링, 지속적 보안 테스트, 위험 검증, 정보 수출까지 전체 취약점 생명주기를 절차로 명문화할 것을 요구한다. 이 조항은 §4.3.2 보안 보증과 함께 ISO/IEC 18974의 핵심을 이룬다. diff --git a/content/ko/guide/iso18974_guide/2-relevant-tasks/1-access/_index.md b/content/ko/guide/iso18974_guide/2-relevant-tasks/1-access/_index.md index c29d991f7b..f78622e161 100644 --- a/content/ko/guide/iso18974_guide/2-relevant-tasks/1-access/_index.md +++ b/content/ko/guide/iso18974_guide/2-relevant-tasks/1-access/_index.md @@ -27,7 +27,7 @@ Disclosure) 절차와 연결되어 있으므로, 보안 연구자나 고객이 - 제3자가 취약점 관련 문의를 보낼 수 있는 공개 연락처(이메일 주소, 웹폼 등)를 제품 또는 웹사이트에 명시한다. - 공개 채널을 통해 접수된 취약점 보고를 내부적으로 처리하는 절차를 문서화한다. -- 문의 접수·분류·담당자 배정·대응·종결까지의 처리 단계를 절차에 포함한다. +- 문의 접수, 분류, 담당자 배정, 대응, 종결까지의 처리 단계를 절차에 포함한다. - CVD 원칙(비공개 협력 후 공개)에 따른 처리 방침을 절차에 명시한다. - 문의 접수 및 대응 이력을 기록하고 일정 기간 보관한다. diff --git a/content/ko/guide/iso18974_guide/3-content-review/1-sbom/_index.md b/content/ko/guide/iso18974_guide/3-content-review/1-sbom/_index.md index cd0250fbc7..ccf447c890 100644 --- a/content/ko/guide/iso18974_guide/3-content-review/1-sbom/_index.md +++ b/content/ko/guide/iso18974_guide/3-content-review/1-sbom/_index.md @@ -23,7 +23,7 @@ description: > ## 2. 해야 할 활동 -- 공급 소프트웨어의 오픈소스 컴포넌트를 식별·추적·검토·승인하는 절차를 +- 공급 소프트웨어의 오픈소스 컴포넌트를 식별, 추적, 검토, 승인하는 절차를 수립한다 (5230과 동일). - **소프트웨어 수명주기 동안 지속적으로 SBOM을 기록하고 보관하는 절차**를 수립한다 (18974 강조 사항). @@ -83,7 +83,7 @@ ISO/IEC 5230 §3.3.1.1의 SBOM 관리 절차를 기반으로 하되, **수명주 - **모델 서명 · 빌드 provenance**: 컨테이너·AI 모델을 포함한 SBOM은 OpenSSF Model Signing(Sigstore)으로 서명하고 SLSA L1 이상 provenance를 첨부한다 (구체 절차는 [ISO/IEC 42001 §6.3 OpenSSF Model Signing](../../../iso42001_guide/4-operation/3-supply-chain/#63-openssf-model-signing-도입-절차)). -- **수명주기 단계별 SBOM 유지**: 개발·빌드·배포·배포 후 모니터링 각 단계에서 +- **수명주기 단계별 SBOM 유지**: 개발, 빌드, 배포, 배포 후 모니터링 각 단계에서 SBOM이 최신 상태를 유지하도록 절차를 정의한다. - **아카이브 정책**: 배포된 모든 버전의 SBOM을 버전별로 아카이브하고 보관 기간을 명시한다(최소 해당 소프트웨어 지원 기간 + 3년). diff --git a/content/ko/guide/iso18974_guide/3-content-review/2-security-assurance/_index.md b/content/ko/guide/iso18974_guide/3-content-review/2-security-assurance/_index.md index 0eb4506db0..8e3be92172 100644 --- a/content/ko/guide/iso18974_guide/3-content-review/2-security-assurance/_index.md +++ b/content/ko/guide/iso18974_guide/3-content-review/2-security-assurance/_index.md @@ -13,15 +13,13 @@ description: > {{% /alert %}} {{% alert title="★ 18974 전용 항목 — Documented Evidence 강도" color="warning" %}} -§4.3.2.1·§4.3.2.2는 ISO 18974 전용(★) 항목으로 **Documented Evidence**(문서화된 증거)를 요구한다. 단순 "취약점 대응 절차 문서"가 아니라 **각 CVE에 대한 실제 수행 기록**(스캔 결과·CVSS 점수·조치 이력·VEX 발행·고객 통보 이력 등)을 보관해야 한다. 강도 차이의 자세한 설명은 [§4.1.5 표준 관행 — Documented Evidence 안내](../../1-program-foundation/5-standard-practice/#iso-18974-전용-항목의-강도--documented-evidence)를 참고한다. +§4.3.2.1과 §4.3.2.2는 ISO 18974 전용(★) 항목으로 **Documented Evidence**(문서화된 증거)를 요구한다. 단순 "취약점 대응 절차 문서"가 아니라 **각 CVE에 대한 실제 수행 기록**(스캔 결과, CVSS 점수, 조치 이력, VEX 발행, 고객 통보 이력 등)을 보관해야 한다. 강도 차이의 자세한 설명은 [§4.1.5 표준 관행 — Documented Evidence 안내](../../1-program-foundation/5-standard-practice/#iso-18974-전용-항목의-강도--documented-evidence)를 참고한다. {{% /alert %}} ## 1. 조항 개요 §4.3.2는 ISO/IEC 18974의 핵심 조항으로, ISO/IEC 5230에 없는 18974 전용 신규 -조항이다. SBOM에 포함된 각 오픈소스 컴포넌트에 대해 **취약점 탐지 → 위험 -평가 → 조치 결정 → 고객 동의(필요 시) → 조치 수행 → 배포 후 신규 취약점 -대응 → 지속 모니터링** 의 전 과정을 절차로 수립하고 이행 기록을 유지하도록 +조항이다. SBOM에 포함된 각 오픈소스 컴포넌트에 대해 `취약점 탐지 → 위험 평가 → 조치 결정 → 고객 동의(필요 시) → 조치 수행 → 배포 후 신규 취약점 대응 → 지속 모니터링` 의 전 과정을 절차로 수립하고 이행 기록을 유지하도록 요구한다. §4.1.5가 취약점 처리 방법의 존재를 요구한다면, §4.3.2는 그 방법이 각 컴포넌트에 실제로 적용되어 기록이 남아 있을 것을 요구한다. diff --git a/content/ko/guide/iso18974_guide/_index.md b/content/ko/guide/iso18974_guide/_index.md index aed3fe2278..c86b04222e 100644 --- a/content/ko/guide/iso18974_guide/_index.md +++ b/content/ko/guide/iso18974_guide/_index.md @@ -47,18 +47,18 @@ description: > 각 조항 페이지의 내용은 다음 두 가지로 구분된다. - **[ISO 요구]** — ISO/IEC 18974:2023 표준 본문이 명시적으로 요구하는 사항(`shall` 또는 입증자료 번호로 명시). 누락 시 인증 실패 사유. -- **[본 가이드 권고]** — ISO 표준 본문에는 없으나 OpenChain Korea Work Group이 실무 경험·산업 모범 사례·다른 표준(NIST SSDF·ENISA·CSAF·VEX·EPSS·KEV 등)을 근거로 권장하는 사항. 채택 여부는 조직 재량이며, 미채택이 인증 실패 사유는 아님. +- **[본 가이드 권고]** — ISO 표준 본문에는 없으나 OpenChain Korea Work Group이 실무 경험, 산업 모범 사례, 다른 표준(NIST SSDF, ENISA, CSAF, VEX, EPSS, KEV 등)을 근거로 권장하는 사항. 채택 여부는 조직 재량이며, 미채택이 인증 실패 사유는 아님. 조항 본문의 입증자료 번호(예: `4.3.2.1`)와 함께 제시되는 활동·산출물은 **[ISO 요구]**다. -"~를 권장한다", "~하는 것이 좋다" 표현이나 본 가이드가 추가한 자동화·EPSS·KEV·VEX 4가지 상태값 등은 **[본 가이드 권고]**다. +"~를 권장한다", "~하는 것이 좋다" 표현이나 본 가이드가 추가한 자동화, EPSS, KEV, VEX 4가지 상태값 등은 **[본 가이드 권고]**다. 특히 ISO 18974는 9개 전용 항목(`★`)에 대해 다른 항목보다 강한 **"Documented Evidence"**(문서화된 증거)를 요구한다 — 단순 `document` 보다 한 단계 강한 증거 수준이다(자세한 내용은 [§4.1.5 표준 관행](./1-program-foundation/5-standard-practice/) 참조). {{% /alert %}} {{% alert title="권장 취득 경로" color="success" %}} -오픈소스 보안 보증 인증을 처음 준비하는 기업은 **ISO/IEC 5230 취득 → -ISO/IEC 18974 추가 취득** 순서로 단계적으로 진행하는 것을 권장한다. +오픈소스 보안 보증 인증을 처음 준비하는 기업은 `ISO/IEC 5230 취득 → ISO/IEC 18974 추가 취득` +순서로 단계적으로 진행하는 것을 권장한다. 5230에서 구축한 정책·프로세스·SBOM 인프라를 18974에서 그대로 활용할 수 있어 추가 비용과 노력을 최소화할 수 있다. @@ -74,7 +74,7 @@ ISO/IEC 18974 추가 취득** 순서로 단계적으로 진행하는 것을 권 만들어야 할 산출물을 파악할 수 있고, 각 조항 페이지에서 구체적인 구현 방법과 샘플을 확인할 수 있다. -**[기업 오픈소스 관리 가이드](../opensource_for_enterprise/)** 는 조직·정책·프로세스·도구·교육 +**[기업 오픈소스 관리 가이드](../opensource_for_enterprise/)** 는 조직, 정책, 프로세스, 도구, 교육 영역을 실무 관점으로 설명하는 보완 가이드다. 두 가이드의 각 조항·섹션은 서로 교차 링크로 연결되어 있다. diff --git a/content/ko/guide/iso18974_guide/compare/_index.md b/content/ko/guide/iso18974_guide/compare/_index.md index 7cd463e82a..fda2f355e7 100644 --- a/content/ko/guide/iso18974_guide/compare/_index.md +++ b/content/ko/guide/iso18974_guide/compare/_index.md @@ -11,9 +11,9 @@ description: > ISO/IEC 5230과 ISO/IEC 18974는 모두 OpenChain 프로젝트가 주도하는 오픈소스 관련 국제 표준이지만, 서로 다른 문제를 다룬다. 5230은 오픈소스 라이선스 -컴플라이언스(저작권 의무 이행·SBOM 관리·컴플라이언스 산출물 배포)를 다루고, -18974는 오픈소스 보안 보증(취약점 탐지·평가·대응·CVD)을 다룬다. 두 표준은 -완전한 상위·하위 집합 관계가 아니다. 정책·역량·SBOM 등 9개 공통 조항을 +컴플라이언스(저작권 의무 이행, SBOM 관리, 컴플라이언스 산출물 배포)를 다루고, +18974는 오픈소스 보안 보증(취약점 탐지, 평가, 대응, CVD)을 다룬다. 두 표준은 +완전한 상위·하위 집합 관계가 아니다. 정책, 역량, SBOM 등 9개 공통 조항을 공유하되, 5230에만 있는 조항(라이선스 컴플라이언스·산출물·기여)과 18974에만 있는 조항(표준 관행 구현·보안 보증)이 각각 존재한다. @@ -73,9 +73,9 @@ ISO/IEC 5230과 ISO/IEC 18974는 모두 OpenChain 프로젝트가 주도하는 18974 전용으로 새로 준비해야 하는 항목은 다음과 같다: -- **§4.1.5 표준 관행 구현**: 8가지 취약점 처리 방법(위협 식별·탐지·후속 조치· - 고객 통보·배포 후 분석·보안 테스트·위험 검증·정보 수출) 각각의 절차 문서화 -- **§4.3.2 보안 보증**: CVE 탐지→위험 평가→조치 결정→수행→모니터링 전 과정 +- **§4.1.5 표준 관행 구현**: 8가지 취약점 처리 방법(위협 식별, 탐지, 후속 조치, + 고객 통보, 배포 후 분석, 보안 테스트, 위험 검증, 정보 수출) 각각의 절차 문서화 +- **§4.3.2 보안 보증**: `CVE 탐지 → 위험 평가 → 조치 결정 → 수행 → 모니터링` 전 과정 절차 및 컴포넌트별 취약점 조치 기록 - **공통 조항 보완**: §4.1.2 참여자 목록(4.1.2.3)·주기적 검토 증거(4.1.2.5)· 모범 사례 일치 검증(4.1.2.6), §4.1.4 성과 메트릭(4.1.4.2)·지속 개선 증거 diff --git a/content/ko/guide/iso42001_guide/2-planning/_index.md b/content/ko/guide/iso42001_guide/2-planning/_index.md index bf0a7425f8..bb1544b76f 100644 --- a/content/ko/guide/iso42001_guide/2-planning/_index.md +++ b/content/ko/guide/iso42001_guide/2-planning/_index.md @@ -73,7 +73,7 @@ AI 시스템이 개인, 그룹, 사회에 미칠 수 있는 영향을 평가할 {{% alert title="ISO/IEC 42005:2025 — AI System Impact Assessment" color="info" %}} ISO/IEC 42005:2025(2026-01 발행)는 §6.1.4 AI 시스템 영향 평가의 **구체적 수행 방법**을 제공하는 SC 42 패밀리 표준이다. ISO 42001은 "영향 평가를 수행해야 한다(shall)"고 -원칙만 명시하지만, 42005는 평가 범위·시점·이해관계자·문서 형식까지 안내한다. +원칙만 명시하지만, 42005는 평가 범위, 시점, 이해관계자, 문서 형식까지 안내한다. **활용 권장**: ISO 42001 인증 심사관은 영향 평가 산출물의 구체성을 점검할 때 42005의 8개 평가 영역을 기준으로 사용한다. 42001만 준수하면서 42005를 참고하지 않는 diff --git a/content/ko/guide/iso42001_guide/4-operation/3-supply-chain/_index.md b/content/ko/guide/iso42001_guide/4-operation/3-supply-chain/_index.md index 95a1d14c55..cc263fe7e0 100644 --- a/content/ko/guide/iso42001_guide/4-operation/3-supply-chain/_index.md +++ b/content/ko/guide/iso42001_guide/4-operation/3-supply-chain/_index.md @@ -128,7 +128,7 @@ Llama, Gemma 등 커스텀 라이선스를 사용하는 모델은 **라이선스 ## 5. 상용 AI API §8.8 평가 체크리스트 -OpenAI · Anthropic · Google Vertex AI · AWS Bedrock · Azure OpenAI 등 상용 AI API는 +OpenAI, Anthropic, Google Vertex AI, AWS Bedrock, Azure OpenAI 등 상용 AI API는 오픈소스 라이선스가 직접 적용되지 않지만, ISO/IEC 42001 §8.8은 동일하게 외부 공급 AI 시스템에 대한 평가를 요구한다. 다음 세 영역을 도입 전 검토한다. @@ -159,8 +159,8 @@ AI 시스템에 대한 평가를 요구한다. 다음 세 영역을 도입 전 | **Microsoft (Azure OpenAI)** | Customer Copyright Commitment | Azure OpenAI Service | | **Microsoft (M365 Copilot)** | Copilot Copyright Commitment | M365 Copilot · GitHub Copilot Business/Enterprise | -공통 면책 요건: **콘텐츠 필터 활성화**, **출력물 사후 검수**, **의도적 침해 시도 없음**, -**입력 데이터에 대한 적법한 권리 보유**(사용자가 prompt에 입력한 자료의 저작권·라이선스 적법성 보장). +공통 면책 요건: 콘텐츠 필터 활성화, 출력물 사후 검수, 의도적 침해 시도 없음, +입력 데이터에 대한 적법한 권리 보유(사용자가 prompt에 입력한 자료의 저작권·라이선스 적법성 보장). 면책 청구 가능 손해 범위(법무 자문 비용·합의금 등)는 제공자별로 다르므로 법무팀과 사전 협의. 실제 약관은 자주 변경되므로 도입 전 **약관 원문**을 직접 확인한다. @@ -312,7 +312,7 @@ SLSA 정식 안정 버전은 v1.0(2023-04 GA)이며 v1.1 draft가 진행 중이 4. AI SBOM에 SLSA 레벨 기록(`properties.slsaLevel`) {{% alert title="OpenSSF · Sigstore · SLSA 연계" color="success" %}} -**OpenSSF Model Signing**(서명) + **Sigstore**(투명성 로그) + **SLSA for AI**(provenance)는 +OpenSSF Model Signing(서명), Sigstore(투명성 로그), SLSA for AI(provenance)는 서로 보완하는 3개 표준이다. 모델 배포자는 SLSA L2 이상 provenance를 in-toto attestation으로 생성하고, model-signing CLI로 Sigstore에 서명·등록한 뒤, 검증자는 Rekor 로그를 통해 변조 여부를 확인할 수 있다. 이 조합이 2026년 ML 공급망 보안의 사실상 산업 표준이다. diff --git a/content/ko/guide/iso42001_guide/_index.md b/content/ko/guide/iso42001_guide/_index.md index 98d66d28f3..79814f9515 100644 --- a/content/ko/guide/iso42001_guide/_index.md +++ b/content/ko/guide/iso42001_guide/_index.md @@ -132,7 +132,7 @@ OpenChain Korea Work Group의 **AI Work Group**은 AI SBOM 컴플라이언스 | **KEV** | Known Exploited Vulnerabilities | 실제 악용된 취약점 카탈로그 (CISA) | **라이선스 표기 통일** (가이드 전반): -- Llama 3.x → "Meta Llama 3.x Community License" -- Gemma → "Gemma Terms of Use" -- Falcon → "Falcon License" (TII Falcon LLM License) +- Llama 3.x는 "Meta Llama 3.x Community License"로 표기 +- Gemma는 "Gemma Terms of Use"로 표기 +- Falcon은 "Falcon License" (TII Falcon LLM License)로 표기 - 표준 SPDX 라이선스는 SPDX ID 사용 (예: `Apache-2.0`, `MIT`, `BSD-3-Clause`) diff --git a/content/ko/guide/iso42001_guide/compare/_index.md b/content/ko/guide/iso42001_guide/compare/_index.md index dde0bf61c9..458d81ddc4 100644 --- a/content/ko/guide/iso42001_guide/compare/_index.md +++ b/content/ko/guide/iso42001_guide/compare/_index.md @@ -96,7 +96,7 @@ AI 표준 패밀리의 핵심이다. 인증 심사·실무 적용 시 다음 표 {{% alert title="SC 42 패밀리 도입 우선순위" color="success" %}} ISO 42001 인증을 준비 중인 조직은 다음 순서로 SC 42 패밀리 표준을 검토하는 것을 권장한다: -**(1) 22989(용어) → (2) 23894(리스크) → (3) 42005(영향 평가) → (4) 5338(생애주기) → (5) 42003(구현 가이드, 발행 시)**. +`(1) 22989(용어) → (2) 23894(리스크) → (3) 42005(영향 평가) → (4) 5338(생애주기) → (5) 42003(구현 가이드, 발행 시)`. 이 5개 표준을 42001과 함께 활용하면 인증 심사관이 요구하는 구체성 수준을 무리 없이 충족할 수 있다. {{% /alert %}} @@ -170,14 +170,14 @@ ISO 42001 인증을 준비 중인 조직은 다음 순서로 SC 42 패밀리 표 **오픈소스 컴플라이언스 체계가 없다면** -→ **ISO/IEC 5230** 부터 시작한다. +**ISO/IEC 5230** 부터 시작한다. 라이선스 관리, SBOM, 정책, 교육의 기반을 구축한다. --- **ISO 5230 체계가 있고, AI 개발도 하고 있다면** -→ **ISO/IEC 18974 + ISO/IEC 42001** 을 병행 검토한다. +**ISO/IEC 18974 + ISO/IEC 42001** 을 병행 검토한다. - ISO 18974: AI 시스템에 사용된 오픈소스 취약점 관리 강화 - ISO 42001: AI 시스템 전체 거버넌스 수립 (오픈소스 교차 요건 포함) @@ -188,14 +188,14 @@ ISO 42001 인증을 준비 중인 조직은 다음 순서로 SC 42 패밀리 표 **AI 시스템을 개발·서비스하는 기업이라면** -→ **ISO/IEC 42001** 의 오픈소스 교차 요구사항을 먼저 점검한다. +**ISO/IEC 42001** 의 오픈소스 교차 요구사항을 먼저 점검한다. 이 가이드의 [운영 섹션](../4-operation/)이 AI 시스템에서 당장 확인해야 할 항목을 안내한다. --- **AI SBOM 의무화 동향을 따라가고 싶다면** -→ **ISO/IEC 42003** 동향을 주시한다. +**ISO/IEC 42003** 동향을 주시한다. OpenChain AI Work Group은 AI SBOM 컴플라이언스 가이드를 ISO 42003에 반영하는 것을 추진 중이다. EU Cyber Resilience Act(CRA)도 AI 시스템의 투명성 수단으로 AI SBOM을 요구하는 방향으로 논의되고 있다. diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/1-policy/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/1-policy/_index.md index 7122823bc3..9802ff83b3 100644 --- a/content/ko/guide/iso5230_guide/1-program-foundation/1-policy/_index.md +++ b/content/ko/guide/iso5230_guide/1-program-foundation/1-policy/_index.md @@ -26,8 +26,8 @@ ISO/IEC 5230 프로그램 전체의 기반이 되며, 이후 모든 조항(역 - 오픈소스 라이선스 컴플라이언스를 관리하는 정책 문서를 작성하고 공식화한다. - 정책에 적용 범위(외부 배포 소프트웨어, 기여 활동, 사내 공개 등)를 명확히 정의한다. -- 정책 내에 오픈소스 사용·기여·배포·SBOM 관리·보안 취약점 대응 원칙을 포함한다. -- 프로그램 참여자(개발자·법무·IT·보안 등)에게 정책을 전파하는 절차를 수립하고 문서화한다. +- 정책 내에 오픈소스 사용, 기여, 배포, SBOM 관리, 보안 취약점 대응 원칙을 포함한다. +- 프로그램 참여자(개발자, 법무, IT, 보안 등)에게 정책을 전파하는 절차를 수립하고 문서화한다. - 전파 사실을 증명할 수 있는 기록(교육 이수, 공지 이력 등)을 보관한다. - 정기적으로 정책을 검토하고 변경 시 재전파하는 절차를 정책 내에 포함한다. diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/2-competence/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/2-competence/_index.md index 842d37dfb9..d6ecc72902 100644 --- a/content/ko/guide/iso5230_guide/1-program-foundation/2-competence/_index.md +++ b/content/ko/guide/iso5230_guide/1-program-foundation/2-competence/_index.md @@ -75,7 +75,7 @@ IT 담당, 보안 담당, 개발 문화 담당, 사업 부서가 핵심 역할 **고려사항** -- **역할 식별 범위**: 개발·법무·IT·보안·구매 등 소프트웨어 공급망에 관여하는 +- **역할 식별 범위**: 개발, 법무, IT, 보안, 구매 등 소프트웨어 공급망에 관여하는 모든 조직의 역할을 포함하며, 외주 개발 및 벤더 관리 담당도 검토한다. - **책임 구체화**: 역할별 책임은 추상적 서술이 아닌 구체적 활동 단위로 기술한다. - **겸임 명시**: 한 사람이 여러 역할을 겸임하는 경우 해당 사실을 문서에 명기한다. diff --git a/content/ko/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md b/content/ko/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md index e3090073e7..606c4c360f 100644 --- a/content/ko/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md +++ b/content/ko/guide/iso5230_guide/1-program-foundation/3-awareness/_index.md @@ -35,7 +35,7 @@ ISO/IEC 5230 §3.1.3은 다음 **4가지** 인식 요소를 요구한다(원문 영향에 대해 참여자가 인식하고 있는지 확인한다. 위 4가지 인식 평가를 주기적으로 실시하고, 결과를 문서로 기록·보관한다. 인식이 -미흡한 참여자에 대해서는 추가 교육을 실시하고 재평가 결과를 보관한다. +미흡한 참여자에게는 추가 교육을 실시하고 재평가 결과를 보관한다. ## 3. 요구사항 및 입증자료 @@ -76,12 +76,12 @@ ISO/IEC 5230 §3.1.3은 다음 **4가지** 인식 요소를 요구한다(원문 평가 방법은 온라인 퀴즈, 오프라인 설문, 교육 후 이수 확인, 인터뷰 등 다양하게 조합할 수 있다. 중요한 것은 평가 결과가 문서로 남아야 한다는 점이다. 이 기록이 입증자료 3.1.3.1에 해당한다. 평가는 최소 연 1회 정기적으로 실시하고, 신규 참여자는 -프로그램 합류 시 즉시 초기 평가를 수행한다. 인식이 미흡한 참여자에 대해서는 +프로그램 합류 시 즉시 초기 평가를 수행한다. 인식이 미흡한 참여자에게는 추가 교육을 실시하고 재평가 결과를 함께 보관한다. **고려사항** -- **평가 범위**: 4가지 핵심 인식(**정책 존재·위치**·목표·기여·영향)을 모두 포함하는 +- **평가 범위**: 4가지 핵심 인식(**정책 존재·위치**, 목표, 기여, 영향)을 모두 포함하는 평가 문항을 설계한다. ISO 원문 4 bullet 중 1개라도 누락되면 §3.1.3.1 ⚠️ 판정 위험이 있다. - **평가 주기**: 최소 연 1회 정기 평가를 실시하고, 신규 참여자는 합류 즉시 diff --git a/content/ko/guide/iso5230_guide/3-content-review/1-sbom/_index.md b/content/ko/guide/iso5230_guide/3-content-review/1-sbom/_index.md index 6e54e7aec0..5d8c0be385 100644 --- a/content/ko/guide/iso5230_guide/3-content-review/1-sbom/_index.md +++ b/content/ko/guide/iso5230_guide/3-content-review/1-sbom/_index.md @@ -16,7 +16,7 @@ description: > 공급 소프트웨어에 어떤 오픈소스 컴포넌트가 포함되어 있는지 파악하지 못하면 라이선스 의무를 이행할 수 없고 보안 취약점 대응도 불가능하다. §3.3.1은 공급 -소프트웨어를 구성하는 오픈소스 컴포넌트를 식별·추적·검토·승인·보관하는 +소프트웨어를 구성하는 오픈소스 컴포넌트를 식별, 추적, 검토, 승인, 보관하는 절차를 수립하고, 그 절차가 실제로 이행되었음을 입증하는 컴포넌트 기록(SBOM)을 유지하도록 요구한다. 이 조항은 오픈소스 라이선스 컴플라이언스와 보안 보증의 핵심 인프라인 SBOM을 운영하는 기반이 된다. @@ -61,7 +61,7 @@ description: > **준수 방법** -공급 소프트웨어에 포함된 오픈소스 컴포넌트를 식별·추적·검토·승인·보관하는 +공급 소프트웨어에 포함된 오픈소스 컴포넌트를 식별, 추적, 검토, 승인, 보관하는 일련의 절차를 문서화해야 한다. 절차는 소프트웨어 개발 주기 전반에 걸쳐 오픈소스가 어떻게 관리되는지를 다루며, ①컴포넌트 식별, ②라이선스 확인, ③의무 검토, ④사용 승인, ⑤SBOM 생성 및 등록, ⑥배포 시 SBOM 제공, @@ -141,7 +141,7 @@ SBOM은 소프트웨어 릴리스 버전별로 관리하고, 과거 버전의 SB - **NTIA Minimum Elements 7요소** (2021-07 발행, US EO 14028 기반): 미국 연방 조달과 EU CRA(2024-12 발효) 모두 SBOM 최소 요건으로 채택. ISO/IEC 5230 §3.3.1.2의 - "이름·버전·라이선스·출처"보다 강한 요건이며, 글로벌 공급망 대응 시 필수. + "이름, 버전, 라이선스, 출처"보다 강한 요건이며, 글로벌 공급망 대응 시 필수. | # | 요소 | 내용 | |---|------|------| diff --git a/content/ko/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md b/content/ko/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md index d1cae1a475..ba5558bcac 100644 --- a/content/ko/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md +++ b/content/ko/guide/iso5230_guide/4-artifacts/1-compliance-artifacts/_index.md @@ -131,8 +131,8 @@ GPLv2와 GPLv3는 소스 코드 제공 옵션과 의무 표현이 다르므로 * | **AGPLv3 §13** | 네트워크 상호작용 사용자에게 **무상 다운로드** (수정된 버전을 사용하는 동안 내내) | — | **수정된 버전을 SaaS·네트워크 서비스로 제공 시**, 해당 서비스에 원격 접속하는 모든 사용자에게 **수정된 버전의 Corresponding Source를 네트워크를 통해 무상 다운로드**할 수 있도록 명시적 안내(서비스 UI·푸터·About 페이지 등)를 제공할 의무. written offer만으로는 부족 — **서비스 엔드포인트에 다운로드 링크 노출 필수** | **핵심 주의**: -- **"Corresponding Source"**(GPLv3 §1 정의)는 GPLv2의 "complete corresponding source code"보다 범위가 넓다 — 빌드 스크립트·설치 정보·인터페이스 정의·공유 라이브러리 소스 모두 포함. -- GPLv3는 §6(a)·(b)·(c)·(d)·(e) 5개 옵션 중 선택 가능. **§6(b)와 §6(d)는 별도 옵션**으로, "written offer 면제"라는 표현은 부정확. +- **"Corresponding Source"**(GPLv3 §1 정의)는 GPLv2의 "complete corresponding source code"보다 범위가 넓다 — 빌드 스크립트, 설치 정보, 인터페이스 정의, 공유 라이브러리 소스 모두 포함. +- GPLv3는 §6(a), (b), (c), (d), (e) 5개 옵션 중 선택 가능. **§6(b)와 §6(d)는 별도 옵션**으로, "written offer 면제"라는 표현은 부정확. - GPLv2 §3(b)는 **객체코드의 비상업적 배포에 한정**. 상업 배포는 §3(a) 동봉이 안전. - AGPL 컴포넌트를 SaaS로 사용하면 written offer만으로 부족 — 네트워크 사용자에게 **다운로드 링크** 노출 필수. {{% /alert %}} diff --git a/content/ko/guide/iso5230_guide/6-conformance/1-conformance/_index.md b/content/ko/guide/iso5230_guide/6-conformance/1-conformance/_index.md index 900f5233de..8b43ea2a6c 100644 --- a/content/ko/guide/iso5230_guide/6-conformance/1-conformance/_index.md +++ b/content/ko/guide/iso5230_guide/6-conformance/1-conformance/_index.md @@ -138,7 +138,7 @@ OpenChain이 공인한 인증 기관이 심사하여 공식 인증서를 발급 - 공인 인증 기관 (2024년 기준): ORCRO, PwC, TÜV SÜD, Synopsys, Bureau Veritas {{% alert title="단계적 접근 권장" color="success" %}} -처음 인증을 준비하는 기업은 **자가 인증 → 독립 평가 → 제3자 인증** 순서로 +처음 인증을 준비하는 기업은 `자가 인증 → 독립 평가 → 제3자 인증` 순서로 단계적으로 진행하는 것을 권장한다. {{% /alert %}} diff --git a/content/ko/guide/iso5230_guide/_index.md b/content/ko/guide/iso5230_guide/_index.md index 419ecded46..66cb317260 100644 --- a/content/ko/guide/iso5230_guide/_index.md +++ b/content/ko/guide/iso5230_guide/_index.md @@ -31,7 +31,7 @@ description: > 만들어야 할 산출물을 파악할 수 있고, 각 조항 페이지에서 구체적인 구현 방법과 샘플을 확인할 수 있다. -**[기업 오픈소스 관리 가이드](../opensource_for_enterprise/)** 는 조직·정책·프로세스·도구·교육 +**[기업 오픈소스 관리 가이드](../opensource_for_enterprise/)** 는 조직, 정책, 프로세스, 도구, 교육 영역을 실무 관점으로 설명하는 보완 가이드다. 두 가이드의 각 조항·섹션은 서로 교차 링크로 연결되어 있다. @@ -45,7 +45,7 @@ description: > - **[ISO 요구]** — ISO/IEC 5230:2020 표준 본문이 명시적으로 요구하는 사항(`shall` 또는 입증자료 번호로 명시). 누락 시 인증 실패 사유. - **[본 가이드 권고]** — ISO 표준 본문에는 없으나 OpenChain Korea Work Group이 실무 - 경험·산업 모범 사례·다른 표준(NIST·ENISA·OWASP 등)을 근거로 권장하는 사항. 채택 여부는 + 경험, 산업 모범 사례, 다른 표준(NIST, ENISA, OWASP 등)을 근거로 권장하는 사항. 채택 여부는 조직 재량이며, 미채택이 인증 실패 사유는 아님. 조항 본문에서 입증자료 번호(예: `3.1.1.1`)와 함께 제시되는 활동·산출물은 **[ISO 요구]**다. @@ -231,7 +231,7 @@ OpenChain이 공인한 인증 기관이 심사하여 공식 인증서를 발급 {{% /pageinfo %}} {{% alert title="단계적 접근 권장" color="success" %}} -처음 인증을 준비하는 기업은 **자가 인증 → 독립 평가 → 제3자 인증** 순서로 +처음 인증을 준비하는 기업은 `자가 인증 → 독립 평가 → 제3자 인증` 순서로 단계적으로 진행하는 것을 권장한다. 자가 인증만으로도 많은 공급망 파트너가 요구하는 준수 수준을 충족할 수 있다. {{% /alert %}} diff --git a/content/ko/guide/opensource_for_enterprise/0-openchain/_index.md b/content/ko/guide/opensource_for_enterprise/0-openchain/_index.md index 97433a4690..a96ad3a7c2 100644 --- a/content/ko/guide/opensource_for_enterprise/0-openchain/_index.md +++ b/content/ko/guide/opensource_for_enterprise/0-openchain/_index.md @@ -11,8 +11,8 @@ description: > --- {{% alert title="이 섹션이 다루는 내용" color="success" %}} -OpenChain Project의 설립 배경 · OpenChain 규격이 ISO/IEC 5230 · ISO/IEC 18974 국제 표준으로 -등록된 과정 · 표준 인증의 세 가지 방법(자가 인증·독립 평가·제3자 인증) · 글로벌·국내 기업의 +OpenChain Project의 설립 배경, OpenChain 규격이 ISO/IEC 5230, ISO/IEC 18974 국제 표준으로 +등록된 과정, 표준 인증의 세 가지 방법(자가 인증, 독립 평가, 제3자 인증), 글로벌·국내 기업의 적용 추세를 정리합니다. 이 섹션은 본 가이드의 도입부로, 다음 섹션부터 구체적인 준수 방법을 다룹니다. {{% /alert %}} @@ -28,7 +28,7 @@ OpenChain Project의 설립 배경 · OpenChain 규격이 ISO/IEC 5230 · ISO/IE 2009년 12월, [Busybox](https://busybox.net/)라는 오픈소스 관련된 소송이 있었습니다. Busybox는 임베디드 시스템에 광범위하게 사용되고 있는 GPL-2.0 라이선스가 적용된 오픈소스인데, 국내 회사 두 곳을 포함하여 14개 회사가 소송 대상이 되었습니다. 이 사례에서 주목할만한 점은 이 중에는 제품을 직접 개발하지 않고 배포만 한 회사도 소송을 당하였다는 점입니다. -이와 같은 복잡한 소프트웨어 공급망 환경에서는 어느 한 기업이 아무리 훌륭한 프로세스를 갖추고 있다고 해도 자체적으로 완벽한 오픈소스 컴플라이언스를 달성하는 건 매우 어렵습니다. 결국 한 기업이 오픈소스 컴플라이언스를 제대로 이행하기 위해서는 소프트웨어 공급망의 모든 구성원이 라이선스 의무를 준수하고 올바른 오픈소스 정보를 제공해야 합니다. 공급망 전체에 걸쳐 이런 신뢰가 구축되어야 합니다. +이와 같은 복잡한 소프트웨어 공급망 환경에서는 어느 한 기업이 아무리 훌륭한 프로세스를 갖추고 있다고 해도 자체적으로 완벽한 오픈소스 컴플라이언스를 달성하는 건 어렵습니다. 결국 한 기업이 오픈소스 컴플라이언스를 제대로 이행하기 위해서는 소프트웨어 공급망의 모든 구성원이 라이선스 의무를 준수하고 올바른 오픈소스 정보를 제공해야 합니다. 공급망 전체에 걸쳐 이런 신뢰가 구축되어야 합니다. [Linux Foundation](https://www.linuxfoundation.org/)의 [OpenChain](https://www.openchainproject.org/) 프로젝트는 기업이 오픈소스 컴플라이언스를 위해 준수해야 할 핵심 사항을 간결하고 일관성 있게 정의하고, 이를 모두가 준수한다면 소프트웨어 공급망 전체에 걸쳐 오픈소스 라이선스 측면의 신뢰를 구축할 수 있다는 믿음으로 설립되었습니다. @@ -104,7 +104,7 @@ ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 모두 준수한다면 이 표
https://www.openchainproject.org/get-started/conformance
{{< /imgproc >}} -세 가지 인증 방법은 비용·기간·결과물·시장 신뢰도 측면에서 다음과 같이 다릅니다. +세 가지 인증 방법은 비용, 기간, 결과물, 시장 신뢰도 측면에서 다음과 같이 다릅니다. | 비교 항목 | (1) 자체 인증 | (2) 독립 평가 | (3) 타사 인증 | |---------|-------------|-------------|-------------| @@ -125,7 +125,7 @@ ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 모두 준수한다면 이 표
< 출처 : https://certification.openchainproject.org/>
{{< /imgproc >}} -오픈소스 컴플라이언스 체계를 잘 구축하여 OpenChain 자체 인증의 모든 질문에 Yes로 대답할 수 있다면 이 결과를 웹사이트상에 제출할 수 있습니다(Conforming Submission). 그러면 [Linux Foundation](https://www.linuxfoundation.org/)의 검토 절차를 거친 후 ISO/IEC 5230 인증을 선언할 수 있게 됩니다. 일반적인 처리 흐름은 **(1) 체크리스트 작성 → (2) Conforming Submission 제출 → (3) Linux Foundation Review(영업일 기준 5-10일) → (4) Listing 등재**이며, 전 과정은 보통 1-2주 소요됩니다. +오픈소스 컴플라이언스 체계를 잘 구축하여 OpenChain 자체 인증의 모든 질문에 Yes로 대답할 수 있다면 이 결과를 웹사이트상에 제출할 수 있습니다(Conforming Submission). 그러면 [Linux Foundation](https://www.linuxfoundation.org/)의 검토 절차를 거친 후 ISO/IEC 5230 인증을 선언할 수 있게 됩니다. 일반적인 처리 흐름은 `(1) 체크리스트 작성 → (2) Conforming Submission 제출 → (3) Linux Foundation Review(영업일 기준 5-10일) → (4) Listing 등재`이며, 전 과정은 보통 1-2주 소요됩니다. {{< imgproc sktannounce Fit "900x600" >}}
<예: SK텔레콤 인증 선언 - 출처: https://www.openchainproject.org/featured/2021/09/08/sk-telecom>
diff --git a/content/ko/guide/opensource_for_enterprise/1-teams/_index.md b/content/ko/guide/opensource_for_enterprise/1-teams/_index.md index 7829ef0554..36fade8eaa 100644 --- a/content/ko/guide/opensource_for_enterprise/1-teams/_index.md +++ b/content/ko/guide/opensource_for_enterprise/1-teams/_index.md @@ -9,8 +9,8 @@ description: > --- {{% alert title="이 섹션이 다루는 요구사항" color="success" %}} -**ISO/IEC 5230**: 3.1.2.1 · 3.1.2.2 · 3.2.2.1 -**ISO/IEC 18974**: 4.1.2.1 · 4.1.2.2 · 4.1.2.3 · 4.2.2.1 +**ISO/IEC 5230**: 3.1.2.1, 3.1.2.2, 3.2.2.1 +**ISO/IEC 18974**: 4.1.2.1, 4.1.2.2, 4.1.2.3, 4.2.2.1 {{% /alert %}} 먼저, 기업은 오픈소스 관리 업무를 담당할 조직을 구성해야 합니다. @@ -44,7 +44,7 @@ ISO 표준은 공통적으로 다음과 같이 프로그램 내 여러 참여자 오픈소스 프로그램 매니저는 기업의 오픈소스 프로그램 오피스를 담당합니다. `오픈소스 프로그램 오피스`란 기업의 오픈소스 관리를 위한 조직을 의미하며, `오픈소스 사무국`이라는 용어로도 사용됩니다. -아래의 역량을 가지고 있다면 오픈소스 프로그램 매니저 역할에 적합하다고 할 수 있습니다. +아래의 역량이 있다면 오픈소스 프로그램 매니저 역할에 적합하다고 할 수 있습니다. - 오픈소스 생태계에 대한 이해 및 개발 경험 - 기업의 비즈니스에 대한 폭넓은 이해 @@ -164,7 +164,7 @@ ISO 표준은 공통적으로 다음과 같이 프로그램 내 각 역할을 | 6 | 사업 부서 | 각 개발팀 챔피언 | 팀별 1인(별도 부록 명단) | | 7 | 내부 모범 사례 검증 담당 ★ | OSPO 자체 또는 외부 자문 | 검증 보고서 작성자명 | -> **샘플 표기 원칙**: §3.2.2.1·§4.1.2.3은 "이름"을 명시적으로 요구합니다. 위 표는 익명 표기(OOO)가 아닌 **가상 실명** 또는 **별도 부록 명단 + 직무명** 운영을 권장합니다. 사업 부서는 "전원" 표기를 피하고 **팀별 1인 챔피언** 모델로 매핑하여 책임 소재를 명확히 합니다. +> **샘플 표기 원칙**: §3.2.2.1, §4.1.2.3은 "이름"을 명시적으로 요구합니다. 위 표는 익명 표기(OOO)가 아닌 가상 실명 또는 별도 부록 명단 + 직무명 운영을 권장합니다. 사업 부서는 "전원" 표기를 피하고 **팀별 1인 챔피언** 모델로 매핑하여 책임 소재를 명확히 합니다. 다음 페이지에서는 역할, 책임, 필요 역량 및 담당자 지정 등을 문서화한 샘플을 참고할 수 있습니다. [[부록1]오픈소스 정책(샘플) - Appendix 1. 담당자 현황](../../templates/1-policy/#appendix-1-담당자-현황) @@ -186,7 +186,7 @@ ISO 표준은 공통적으로 다음과 같이 프로그램 내 각 역할을 사실, 문서화하는 것보다 실제 업무를 충실히 수행할 담당자를 지정하고, 담당자가 역량을 확보할 수 있도록 지원하는 것이 더 중요합니다. -한국저작권위원회의 [오픈소스 라이선스 전문 교육](https://www.olis.or.kr/consulting/openswStudy.do)이나 [NIPA의 공개소프트웨어 매니지먼트 아카데미](https://www.oss.kr/oss_data/show/448d2e96-6819-45f4-b114-73cd41b3e9d3)에 참여하여 체계적인 교육을 수강하는 것도 매우 도움이 됩니다. +한국저작권위원회의 [오픈소스 라이선스 전문 교육](https://www.olis.or.kr/consulting/openswStudy.do)이나 [NIPA의 공개소프트웨어 매니지먼트 아카데미](https://www.oss.kr/oss_data/show/448d2e96-6819-45f4-b114-73cd41b3e9d3)에 참여하여 체계적인 교육을 수강하는 것도 도움이 됩니다. 오픈소스 프로그램 매니저와 보안 담당의 역할이 더욱 중요해지고 있습니다. 오픈소스 프로그램 매니저는 오픈소스 보안 보증에 대한 기본 지식도 갖추어야 하며, 보안 담당자는 [SBOM](https://www.cisa.gov/sbom) (Software Bill of Materials) 관리와 같은 새로운 보안 요구사항에 대한 이해도 필요합니다. diff --git a/content/ko/guide/opensource_for_enterprise/2-policy/_index.md b/content/ko/guide/opensource_for_enterprise/2-policy/_index.md index b0fa47750f..0de08f650b 100644 --- a/content/ko/guide/opensource_for_enterprise/2-policy/_index.md +++ b/content/ko/guide/opensource_for_enterprise/2-policy/_index.md @@ -9,8 +9,8 @@ description: > --- {{% alert title="이 섹션이 다루는 요구사항" color="success" %}} -**ISO/IEC 5230**: 3.1.1.1 · 3.1.4.1 · 3.2.1.1 · 3.2.2.2 · 3.2.2.3 · 3.2.2.4 · 3.2.2.5 · 3.5.1.1 -**ISO/IEC 18974**: 4.1.1.1 · 4.1.4.1 · 4.1.4.2 · 4.1.4.3 · 4.2.1.1 · 4.2.2.2 · 4.2.2.3 · 4.2.2.4 +**ISO/IEC 5230**: 3.1.1.1, 3.1.4.1, 3.2.1.1, 3.2.2.2, 3.2.2.3, 3.2.2.4, 3.2.2.5, 3.5.1.1 +**ISO/IEC 18974**: 4.1.1.1, 4.1.4.1, 4.1.4.2, 4.1.4.3, 4.2.1.1, 4.2.2.2, 4.2.2.3, 4.2.2.4 {{% /alert %}} ## 1. 오픈소스 정책 문서화 @@ -224,7 +224,7 @@ ISO 표준은 공통적으로 다음과 같이 내부 책임을 할당하는 문 {{% /alert %}} -오픈소스 프로그램 매니저는 라이선스 컴플라이언스 이슈를 파악하고 이를 해결하기 위해 각 역할의 담당자에게 적절히 책임을 할당해야 합니다. 마찬가지로 오픈소스 보안 취약점 이슈에 대해서는 보안 담당이 이슈를 파악하고 이를 해결하기 위해 적절한 인원에게 책임을 할당합니다. +오픈소스 프로그램 매니저는 라이선스 컴플라이언스 이슈를 파악하고 이를 해결하기 위해 각 역할의 담당자에게 적절히 책임을 할당해야 합니다. 마찬가지로 오픈소스 보안 취약점 이슈에 대해 보안 담당이 이슈를 파악하고 이를 해결하기 위해 적절한 인원에게 책임을 할당합니다. 이를 위해 아래의 예시와 같이 오픈소스 정책에 내부 책임을 할당하는 문서화된 절차를 반영할 수 있습니다. @@ -352,9 +352,9 @@ ISO 표준은 공통적으로 다음과 같이 문제 해결을 위해 내부 {{% /alert %}} -오픈소스 라이선스 컴플라이언스 이슈에 대해서는 회사 내의 법무팀을 통해 우선 담당하고, 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인을 이용할 수 있습니다. +오픈소스 라이선스 컴플라이언스 이슈에 대해 회사 내의 법무팀을 통해 우선 담당하고, 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인을 이용할 수 있습니다. -오픈소스 보안 취약점 이슈에 대해서는 회사 내 보안팀에서 우선 담당하고, 이슈가 복잡하고 첨예한 경우, 외부 보안 전문 기술 업체에 자문을 요청할 수 있습니다. +오픈소스 보안 취약점 이슈에 대해 회사 내 보안팀에서 우선 담당하고, 이슈가 복잡하고 첨예한 경우, 외부 보안 전문 기술 업체에 자문을 요청할 수 있습니다. 이를 위해 기업은 아래의 예시와 같이 오픈소스 정책에 자문을 제공하기 위한 내용을 반영할 수 있습니다. diff --git a/content/ko/guide/opensource_for_enterprise/3-process/_index.md b/content/ko/guide/opensource_for_enterprise/3-process/_index.md index ce58a5e408..d5448dd98b 100644 --- a/content/ko/guide/opensource_for_enterprise/3-process/_index.md +++ b/content/ko/guide/opensource_for_enterprise/3-process/_index.md @@ -9,8 +9,8 @@ description: > --- {{% alert title="이 섹션이 다루는 요구사항" color="success" %}} -**ISO/IEC 5230**: 3.1.5.1 · 3.2.1.2 · 3.3.1.1 · 3.3.2.1 · 3.4.1.1 · 3.5.1.2 -**ISO/IEC 18974**: 4.1.2.5 · 4.1.2.6 · 4.1.5.1 · 4.2.1.2 · 4.3.1.1 · 4.3.2.1 · 4.3.2.2 +**ISO/IEC 5230**: 3.1.5.1, 3.2.1.2, 3.3.1.1, 3.3.2.1, 3.4.1.1, 3.5.1.2 +**ISO/IEC 18974**: 4.1.2.5, 4.1.2.6, 4.1.5.1, 4.2.1.2, 4.3.1.1, 4.3.2.1, 4.3.2.2 {{% /alert %}} 오픈소스 프로세스는 소프트웨어 개발 및 배포 과정에서 기업이 오픈소스 정책을 준수할 수 있도록 하는 실행 가능한 절차입니다. @@ -48,7 +48,7 @@ description: > 어떤 오픈소스를 사용하려고 하는지, 그 라이선스는 무엇인지, 각 라이선스가 부여하는 의무는 무엇인지, 알려진 취약점은 무엇인지 검토하고 기록합니다. -ISO/IEC 5230 표준은 라이선스 컴플라이언스를 위해 일반적인 오픈소스 라이선스의 사용 사례를 다룰 수 있어야 하고, 각 식별된 라이선스에 의해 부여된 의무, 제한 및 권리를 검토하고 기록하기 위한 문서화된 절차를 요구합니다. +ISO/IEC 5230 표준은 라이선스 컴플라이언스를 위해 일반적인 오픈소스 라이선스의 사용 사례를 다룰 수 있어야 하고, 각 식별된 라이선스가 부여하는 의무, 제한, 권리를 검토하고 기록하기 위한 문서화된 절차를 요구합니다. {{% alert title="ISO/IEC 5230 - License Compliance" color="success" %}} @@ -141,7 +141,7 @@ IT 담당은 오픈소스 분석 도구를 사용하여 오픈소스 점검을 오픈소스 라이선스 컴플라이언스 활동의 가장 기본은 공급 소프트웨어에 포함된 오픈소스 현황을 파악하는 것입니다. 공급 소프트웨어에 포함된 오픈소스와 그 라이선스를 식별하여 그 정보를 담고 있는 SBOM(Software Bill of Materials)을 작성하고 관리하는 프로세스를 구축해야 합니다. 공급 소프트웨어의 버전마다 어떤 오픈소스가 포함되어 있는지 알고 있어야 소프트웨어를 배포할 때 각 오픈소스의 라이선스가 요구하는 의무 사항을 준수할 수 있기 때문입니다. 이는 오픈소스 보안 취약점을 발견하고 대응하기 위해서도 꼭 필요한 과정입니다. -모든 오픈소스는 공급 소프트웨어에 통합하기 전에 검토 및 승인되어야 합니다. 오픈소스의 기능, 품질뿐만 아니라 출처, 라이선스 요건을 충족할 수 있는지, 알려진 취약점 또는 새로 발견된 취약점을 해결하였는지 등에 대해 사전 검토가 되어야 합니다. 이를 위해 검토 요청 → 리뷰 → 승인 과정이 필요합니다. +모든 오픈소스는 공급 소프트웨어에 통합하기 전에 검토 및 승인되어야 합니다. 오픈소스의 기능, 품질뿐만 아니라 출처, 라이선스 요건을 충족할 수 있는지, 알려진 취약점 또는 새로 발견된 취약점을 해결하였는지 등에 대해 사전 검토가 되어야 합니다. 이를 위해 `검토 요청 → 리뷰 → 승인` 과정이 필요합니다. ISO 표준은 공통적으로 다음과 같이 공급 소프트웨어에 사용된 모든 오픈소스 소프트웨어가 소프트웨어 수명 주기 동안 지속적으로 기록되도록 하는 문서화된 절차를 요구합니다. @@ -185,7 +185,7 @@ IT 담당은 확정된 SBOM을 시스템에 등록합니다. SBOM에는 공급 오픈소스 프로그램 매니저는 공급 소프트웨어의 버전별 오픈소스 사용 목록을 추적하기 위한 SBOM을 확정합니다. ``` -SBOM 관리를 위한 도구에 대해서는 "[SBOM 관리 도구](../4-tool/#3-sbom-관리-도구)"에서 자세히 설명합니다. +SBOM 관리를 위한 도구는 "[SBOM 관리 도구](../4-tool/#3-sbom-관리-도구)"에서 자세히 설명합니다. 또 이와 같은 오픈소스 프로세스의 모든 과정과 결과는 문서화가 되어야 합니다. 이메일을 사용하는 것보다는 [Jira](https://www.atlassian.com/software/jira), [Bugzilla](https://www.bugzilla.org/) 등의 이슈 트래킹 시스템을 이용하는 것이 이러한 과정을 효율적으로 문서화 할 수 있습니다. @@ -285,7 +285,7 @@ This offer is valid to anyone in receipt of this information. 1. 취약점 데이터베이스 검색: 다음 공개 취약점 데이터베이스를 **병행 조회**하여 누락을 최소화합니다. - [National Vulnerability Database (NVD)](https://nvd.nist.gov/) — CVE 표준 DB - - [OSV.dev](https://osv.dev/) — Google 운영, npm·PyPI·Go·Maven 등 패키지 생태계 통합 + - [OSV.dev](https://osv.dev/) — Google 운영, npm, PyPI, Go, Maven 등 패키지 생태계 통합 - [GitHub Security Advisories(GHSA)](https://github.com/advisories) — 패키지 생태계 최우선 공개 - [KISA KNVD](https://knvd.krcert.or.kr/) — 한국인터넷진흥원, 한국어 권고문 @@ -382,7 +382,7 @@ IT 담당은 새로운 보안 취약점을 모니터링하는 시스템을 구 IT 담당은 알려진 취약점 및 새로 발견된 취약점을 모니터링하는 시스템을 구축하여 운영합니다. 이 시스템은 다음과 같은 기능을 수행합니다: - 복수의 공개 취약점 데이터베이스([NVD](https://nvd.nist.gov/) · [OSV.dev](https://osv.dev/) · [GitHub Advisories](https://github.com/advisories) · [KISA KNVD](https://knvd.krcert.or.kr/))에서 새로운 보안 취약점 정보를 주기적으로 수집하고, [EPSS](https://www.first.org/epss/)·[CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)로 우선순위를 보강합니다. -- 알려진 취약점 또는 새로 발견된 취약점을 갖고 있는 오픈소스 소프트웨어 컴포넌트가 이미 출시된 공급 소프트웨어에 사용된 경우, 해당 공급 소프트웨어의 사업 부서 담당자에게 알림을 보냅니다. +- 알려진 취약점 또는 새로 발견된 취약점이 있는 오픈소스 소프트웨어 컴포넌트가 이미 출시된 공급 소프트웨어에 사용된 경우, 해당 공급 소프트웨어의 사업 부서 담당자에게 알림을 보냅니다. - 알림부터 검토, 조치, 해결 사항이 모두 문서화되어 기록될 수 있도록 [Jira](https://www.atlassian.com/software/jira)와 같은 이슈 추적 시스템을 사용합니다. ### (2) 취약점 평가 및 대응 @@ -560,7 +560,7 @@ ISO 표준은 공통적으로 다음과 같이 제3자의 문의에 대응하기 ## 4. 오픈소스 기여 프로세스 -기업이 외부 오픈소스 프로젝트에 기여를 허용하는 정책을 갖고 있다면, 프로그램 참여자들이 어떤 절차로 외부 프로젝트에 기여할 수 있을지 관리하는 문서화된 절차가 있어야 합니다. +기업이 외부 오픈소스 프로젝트에 기여를 허용하는 정책이 있다면, 프로그램 참여자들이 어떤 절차로 외부 프로젝트에 기여할 수 있을지 관리하는 문서화된 절차가 있어야 합니다. ISO/IEC 5230 표준은 다음과 같이 오픈소스 기여를 관리하는 문서화된 절차를 요구합니다. @@ -705,7 +705,7 @@ OSRB는 매년 정기적으로 검토하여 정책과 프로세스를 개선합 > - [§3.4.1 컴플라이언스 산출물](../../iso5230_guide/4-artifacts/1-compliance-artifacts/) — 산출물 보관 기간·버전 관리 > - [§3.5.1 기여](../../iso5230_guide/5-community/1-contributions/) — 기여 승인 절차 > - [§4.1.5 표준 관행 구현](../../iso18974_guide/1-program-foundation/5-standard-practice/) — 8가지 취약점 처리 방법 -> - [§4.3.2 보안 보증](../../iso18974_guide/3-content-review/2-security-assurance/) — CVE 탐지→평가→조치→통보→모니터링 +> - [§4.3.2 보안 보증](../../iso18974_guide/3-content-review/2-security-assurance/) — CVE `탐지 → 평가 → 조치 → 통보 → 모니터링` > > **AI 사용 시 추가 고려:** > - [§7. AI 컴플라이언스](../7-ai-compliance/) — AI 모델·데이터셋·코딩 도구 프로세스 diff --git a/content/ko/guide/opensource_for_enterprise/4-tool/_index.md b/content/ko/guide/opensource_for_enterprise/4-tool/_index.md index 57147961b9..2ebf038a0e 100644 --- a/content/ko/guide/opensource_for_enterprise/4-tool/_index.md +++ b/content/ko/guide/opensource_for_enterprise/4-tool/_index.md @@ -267,7 +267,7 @@ onot의 설치 및 사용 방법은 [onot 가이드](../../tools/10-onot/)를 ## 6. 오픈소스 컴플라이언스 산출물 보관 -오픈소스 컴플라이언스 산출물을 체계적으로 보관하고 관리하는 것은 오픈소스 라이선스 컴플라이언스를 위해 매우 중요합니다. 특히 GPL, LGPL 등 소스 코드 공개를 요구하는 라이선스의 경우, 공급 소프트웨어 배포 후 최소 3년간 소스 코드를 제공할 수 있어야 합니다. +오픈소스 컴플라이언스 산출물을 체계적으로 보관하고 관리하는 것은 오픈소스 라이선스 컴플라이언스를 위해 중요합니다. 특히 GPL, LGPL 등 소스 코드 공개를 요구하는 라이선스의 경우, 공급 소프트웨어 배포 후 최소 3년간 소스 코드를 제공할 수 있어야 합니다. 이를 위해 ISO/IEC 5230 표준은 다음과 같이 배포용 소프트웨어의 컴플라이언스 산출물 사본을 보관하기 위한 문서화된 절차를 요구합니다. diff --git a/content/ko/guide/opensource_for_enterprise/5-training/_index.md b/content/ko/guide/opensource_for_enterprise/5-training/_index.md index d25d5a2fb3..99935d1054 100644 --- a/content/ko/guide/opensource_for_enterprise/5-training/_index.md +++ b/content/ko/guide/opensource_for_enterprise/5-training/_index.md @@ -9,7 +9,7 @@ description: > --- {{% alert title="이 섹션이 다루는 요구사항" color="success" %}} -**ISO/IEC 5230**: 3.1.1.2 · 3.1.2.3 · 3.1.3.1 · 3.5.1.3 +**ISO/IEC 5230**: 3.1.1.2, 3.1.2.3, 3.1.3.1, 3.5.1.3 **ISO/IEC 18974**: 4.1.1.2 · 4.1.2.4 · 4.1.3.1 {{% /alert %}} @@ -100,7 +100,7 @@ ISO 표준은 공통적으로 다음과 같이 프로그램 참여자의 인식 ``` -평가에 대해서는 아래에서 한번 더 자세히 설명합니다. +평가는 아래에서 한번 더 자세히 설명합니다. 오픈소스 교육에는 오픈소스 기여 정책에 대한 내용도 포함됩니다. 오픈소스 기여 정책을 만들었다 해도 사내 구성원이 이에 대한 존재를 알지 못한다면 무분별한 기여 활동으로 개인과 회사에 피해가 발생할 우려가 있습니다. diff --git a/content/ko/guide/opensource_for_enterprise/7-ai-compliance/_index.md b/content/ko/guide/opensource_for_enterprise/7-ai-compliance/_index.md index b76a47e57f..9c625b600e 100644 --- a/content/ko/guide/opensource_for_enterprise/7-ai-compliance/_index.md +++ b/content/ko/guide/opensource_for_enterprise/7-ai-compliance/_index.md @@ -11,7 +11,7 @@ description: > --- {{% alert title="이 섹션이 다루는 요구사항" color="success" %}} -**ISO/IEC 42001**: §5.2 (AI 정책) · §6.1.2 (AI 리스크 평가) · §7.5 (문서화) · §8.5 (AI 생애주기) · §8.6 (AI 데이터) · §8.8 (외부 AI 조달) +**ISO/IEC 42001**: §5.2 (AI 정책), §6.1.2 (AI 리스크 평가), §7.5 (문서화), §8.5 (AI 생애주기), §8.6 (AI 데이터), §8.8 (외부 AI 조달) {{% /alert %}} AI 시스템은 오픈소스 프레임워크, 사전 훈련된 모델, 오픈 데이터셋을 광범위하게 활용합니다. @@ -92,7 +92,7 @@ ISO/IEC 5230의 오픈소스 관리 프로세스를 적용합니다. {{% alert title="OSAID 1.0 vs Open Weight 구분" color="info" %}} **OSAID 1.0**: 학습 데이터·학습 코드·모델 가중치 3요소가 모두 OSI 승인 오픈소스 라이선스로 공개된 모델만 "오픈소스 AI 모델"로 인정. -**Open Weight**: 가중치만 공개되고 학습 데이터·코드 비공개, 또는 사용 제한 조건이 있는 모델. Llama·Gemma·Falcon 180B 등이 해당합니다. +**Open Weight**: 가중치만 공개되고 학습 데이터와 코드는 비공개, 또는 사용 제한 조건이 있는 모델. Llama, Gemma, Falcon 180B 등이 해당합니다. 심사관 또는 컴플라이언스 검토 시 "이 모델은 OSAID 기준 오픈소스인가, Open Weight인가?"를 명확히 답변할 수 있어야 합니다. {{% /alert %}} @@ -104,7 +104,7 @@ Meta Llama Community License 적용 모델(Llama 3.1·3.3·4 등) 사용 시 다 - [ ] **"Built with Llama" 표기** — 파생 모델 또는 Llama 활용 서비스에 표기 의무 - [ ] **파생 모델명 "Llama" 접두어** — 파생 모델 배포 시 모델명에 "Llama" 포함 (예: "Llama-3-Custom-Finetuned") - [ ] **Acceptable Use Policy(AUP) 동의** — 사용 약관 동의 및 조직 내 전파 -- [ ] **금지 사용 영역 차단** — 군사·핵·생물학·화학 무기 개발, 사이버 공격, 차별 등 금지 (AUP 명시) +- [ ] **금지 사용 영역 차단** — 군사, 핵, 생물학, 화학 무기 개발, 사이버 공격, 차별 등 금지 (AUP 명시) - [ ] **405B 등 대규모 모델 재배포 제한 확인** — Llama 3 405B 등 일부 모델은 가중치 재배포 시 추가 조건 - [ ] **버전별 라이선스 차이 확인** — Llama 2 / 3 / 3.1 / 3.3 / 4 각 버전마다 라이선스 본문이 다름 @@ -331,7 +331,7 @@ US Copyright Office AI 가이드·EU AI Act §50·한국 AI 기본법 의무에 ## 6. Summary AI 컴플라이언스는 기존 ISO/IEC 5230 · 18974 오픈소스 관리 체계의 자연스러운 확장입니다. -AI 시스템의 세 가지 영역(프레임워크·모델·데이터셋)에 대해 라이선스 의무를 식별·이행하고, +AI 시스템의 세 가지 영역(프레임워크, 모델, 데이터셋)에 대해 라이선스 의무를 식별·이행하고, ISO/IEC 42001 AI 관리 시스템의 오픈소스 교차 조항을 적용함으로써 종합적인 컴플라이언스 체계를 구축할 수 있습니다. diff --git a/content/ko/guide/opensource_for_enterprise/_index.md b/content/ko/guide/opensource_for_enterprise/_index.md index 5f5b5abc07..15d287b300 100644 --- a/content/ko/guide/opensource_for_enterprise/_index.md +++ b/content/ko/guide/opensource_for_enterprise/_index.md @@ -65,7 +65,7 @@ ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 준수함으로써 기업은 ### 처음 오픈소스 관리 체계를 구축하는 경우 섹션 순서대로 읽으면서 각 섹션이 안내하는 문서와 절차를 하나씩 만들어가세요: -**1. 조직** → **2. 정책** → **3. 프로세스** → **4. 도구** → **5. 교육** → **6. 준수선언** +`1. 조직 → 2. 정책 → 3. 프로세스 → 4. 도구 → 5. 교육 → 6. 준수선언` ### OpenChain 인증을 준비하는 경우 @@ -119,8 +119,8 @@ PSIRT·CVE 분석·외부 보안 자문 항목을 새로 작성해야 함). ### ISO/IEC 18974 전용 추가 항목 (★ 9개) ISO/IEC 5230 인증을 보유한 경우 아래 9개 항목만 추가로 준비하면 ISO/IEC 18974 인증을 받을 수 있습니다. -나머지 16개 항목(§4.1.1.1·4.1.1.2 · §4.1.2.1·4.1.2.2·4.1.2.4 · §4.1.3.1 · §4.1.4.1 · -§4.2.1.1·4.2.1.2 · §4.2.2.1·4.2.2.2·4.2.2.4 · §4.3.1.1·4.3.1.2 · §4.4.1.1·4.4.2.1)은 +나머지 16개 항목(§4.1.1.1, 4.1.1.2, §4.1.2.1, 4.1.2.2, 4.1.2.4, §4.1.3.1, §4.1.4.1, +§4.2.1.1, 4.2.1.2, §4.2.2.1, 4.2.2.2, 4.2.2.4, §4.3.1.1, 4.3.1.2, §4.4.1.1, 4.4.2.1)은 ISO/IEC 5230 대응 항목(위 표)을 **기반으로 파생**합니다 — 단순 재활용이 아니라 보안 관점에서 검토·보완해야 합니다. diff --git a/content/ko/guide/templates/1-policy/_index.md b/content/ko/guide/templates/1-policy/_index.md index bc314f5486..0a11cf4bf4 100644 --- a/content/ko/guide/templates/1-policy/_index.md +++ b/content/ko/guide/templates/1-policy/_index.md @@ -76,7 +76,7 @@ This sample open source policy was written with reference to the following two m 3. **알려진 취약점 (Known Vulnerability)**: - 이전에 발견된 공개적으로 사용 가능한 보안 취약점을 의미합니다. 이는 NVD, CVE 등과 같은 데이터베이스에서 확인할 수 있습니다. 4. **새로 발견된 취약점 (Newly Discovered Vulnerability)**: - - 이전에 발견되지 않았던 새로운 보안 취약점을 의미합니다. 이는 소프트웨어 사용 중에 발견되거나, 외부 연구자에 의해 보고될 수 있습니다. + - 이전에 발견되지 않았던 새로운 보안 취약점을 의미합니다. 이는 소프트웨어 사용 중에 발견되거나, 외부 연구자가 보고할 수 있습니다. 5. **보안 보증 (Security Assurance)**: - 시스템이 보안 모범 사례에 대한 요구사항을 충족하고, 알려진 취약점에 대해 복원력을 갖추고 있다는 확신을 의미합니다. 6. **검증 자료 (Verification Material)**: @@ -105,7 +105,7 @@ This sample open source policy was written with reference to the following two m | **OSPM** | Open Source Program Manager | 오픈소스 프로그램 **총괄 책임자** (1인 또는 팀 리더) | §3.1.1 의 역할 — 일상 운영 책임 | | **OSRB** | Open Source Review Board | 오픈소스 **의사결정 협의체** (가상 조직, 분기 또는 월간 운영) | §3.1.7 의 역할 — 정책·예외 승인 권한 | -작은 조직에서는 OSPM이 OSPO 기능까지 겸할 수 있으며, OSRB는 OSPM·법무·보안·사업 부서 대표로 구성된 의사결정 회의체로 운영합니다. +작은 조직에서는 OSPM이 OSPO 기능까지 겸할 수 있으며, OSRB는 OSPM, 법무, 보안, 사업 부서 대표로 구성된 의사결정 회의체로 운영합니다. {{% /alert %}} ### 3.1 역할 설명 @@ -296,7 +296,7 @@ This sample open source policy was written with reference to the following two m - EPSS(Exploit Prediction Scoring System)와 CISA KEV(Known Exploited Vulnerabilities) 등재 여부를 보조 지표로 활용합니다. - 취약점의 익스플로잇 가능성, 영향 범위, 그리고 시스템에 미치는 잠재적인 영향을 고려하여 대응 우선순위를 결정합니다. 3. **대응 조치**: - - 고위험 취약점에 대해서는 즉시 패치를 적용하거나 완화 조치를 수행합니다. + - 고위험 취약점은 즉시 패치를 적용하거나 완화 조치를 수행합니다. - 고객에게 영향을 미칠 수 있는 경우, 고객에게 통지하고 해결 방안을 제시합니다. - 공급망 파트너·고객에게 영향 여부를 통지할 때는 **VEX**(Vulnerability Exploitability eXchange) 표준 형식(CSAF 2.0 또는 CycloneDX VEX)을 사용합니다. 4가지 상태값 — `not_affected`(영향 없음·justification 필수) / `affected`(영향 있음) / `fixed`(패치 완료) / `under_investigation`(조사 중). - 취약점 심각도에 따라 다음 기한 내에 조치합니다: Critical(CVSS 9.0 이상) 1주 이내, High(CVSS 7.0~8.9) 4주 이내. (ISO/IEC 18974 §4.3.2.1) @@ -597,7 +597,7 @@ This sample open source policy was written with reference to the following two m - 개선 활동의 진행 상황은 모니터링되고 문서화됩니다. 3. **개선 결과 반영**: - 개선 결과를 다음 평가 주기에 반영하여 프로그램의 효과성을 지속적으로 향상시킵니다. - - 개선 결과는 프로그램 참여자에게 공유되어 지속적인 개선 의지를 고취시킵니다. + - 개선 결과는 프로그램 참여자에게 공유하여 지속적인 개선 의지를 고취시킵니다. ### 10.4 내부 모범 사례 통합 및 개선 @@ -651,7 +651,7 @@ This sample open source policy was written with reference to the following two m 1. **정기적인 검토**: - OSRB는 최소 연 1회 이상 ISO/IEC 5230 및 ISO/IEC 18974의 모든 요구사항에 대한 내부 검토를 수행합니다. - - 검토 결과는 문서화하여 보관하며, 미충족 항목에 대해서는 개선 계획을 수립합니다. + - 검토 결과는 문서화하여 보관하며, 미충족 항목은 개선 계획을 수립합니다. 2. **정기적인 내부 감사**: - 내부 감사는 프로그램 참여자의 역할 수행 여부, 컴플라이언스 산출물의 적합성, 그리고 보안 보증 활동의 효과성을 평가합니다. - 감사 결과에 따라 개선 영역을 식별하고, 필요한 조치를 취합니다. diff --git a/content/ko/guide/templates/2-process-template/_index.md b/content/ko/guide/templates/2-process-template/_index.md index 828bef5305..a275b5df8a 100644 --- a/content/ko/guide/templates/2-process-template/_index.md +++ b/content/ko/guide/templates/2-process-template/_index.md @@ -287,7 +287,7 @@ IT 담당은 취약점이 해결된 SBOM(Software Bill of Materials)을 시스 ### (9) 취약점 공개 타이밍 절차 (CVD) -새로 발견된 취약점(회사 내부 발견 또는 외부 연구자 보고)에 대해서는 조정된 취약점 공개(Coordinated Vulnerability Disclosure, CVD) 절차를 따릅니다. +새로 발견된 취약점(회사 내부 발견 또는 외부 연구자 보고)에는 조정된 취약점 공개(Coordinated Vulnerability Disclosure, CVD) 절차를 따릅니다. 1. **공개 전 조율**: - 취약점 발견 즉시 영향받는 오픈소스 프로젝트 메인테이너에게 비공개로 통보합니다. diff --git a/content/ko/guide/tools/1-fossology/_index.md b/content/ko/guide/tools/1-fossology/_index.md index 9e0d77adcf..af843c5a80 100644 --- a/content/ko/guide/tools/1-fossology/_index.md +++ b/content/ko/guide/tools/1-fossology/_index.md @@ -66,7 +66,7 @@ FOSSology의 기본 사용 절차는 다음과 같다. * 이를 위해 메뉴 > Upload > From File을 선택합니다. * 업로드할 파일을 선택하고 Upload 버튼을 클릭한다. -* 업로드가 완료되면 Job Agent에 의해 자동으로 분석을 수행한다. +* 업로드가 완료되면 Job Agent가 자동으로 분석을 수행한다. * 메뉴 > Jobs > My Recent Jobs에서 분석 중인 Status를 확인할 수 있다. * 분석이 완료되면 메뉴 > Browse에서 분석 결과를 확인할 수 있다. @@ -75,7 +75,7 @@ FOSSology의 기본 사용 절차는 다음과 같다. * 메뉴 > Browser > 파일 혹은 디렉터리를 선택 > Copyright/Email/Url/Author에서는 FOSSology가 검출한 Copyright/Email/Url/Author 정보를 보여다. -사용자는 FOSSology는 이렇게 분석한 결과가 유효한지 여부에 대해 확인 후 잘못 검출된 항목에 대해서는 분석 결과에서 제외시키는 작업을 할 수 있다. FOSSology는 이를 Clearing 과정이라고 설명하며, 자세한 사항은 다음 페이지를 참고할 수 있다. : [https://www.fossology.org/get-started/basic-workflow/](https://www.fossology.org/get-started/basic-workflow/) +사용자는 FOSSology는 이렇게 분석한 결과가 유효한지 여부에 대해 확인 후 잘못 검출된 항목은 분석 결과에서 제외시키는 작업을 할 수 있다. FOSSology는 이를 Clearing 과정이라고 설명하며, 자세한 사항은 다음 페이지를 참고할 수 있다. : [https://www.fossology.org/get-started/basic-workflow/](https://www.fossology.org/get-started/basic-workflow/) 위와 같은 방법으로 사용하고자 하는 오픈소스의 라이선스는 무엇인지, Copyright 정보는 어떻게 되는지를 간단히 확인할 수 있다. diff --git a/content/ko/guide/tools/2-sw360/_index.md b/content/ko/guide/tools/2-sw360/_index.md index eaa44bb51f..f6d0749e5a 100644 --- a/content/ko/guide/tools/2-sw360/_index.md +++ b/content/ko/guide/tools/2-sw360/_index.md @@ -272,7 +272,7 @@ Component는 다음과 같은 정보를 포함한다. Release는 Component에서 하나의 Version을 가리키는 단위이다. 따라서 하나의 Component는 여러 개의 Release를 가질 수 있다. Release는 하나의 Component 하위에 생성되어 관리된다. -Release는 다음과 같은 정보들을 포함한다. +Release는 다음과 같은 정보를 포함한다. * Component Name * Version @@ -334,7 +334,7 @@ SW360은 등록된 Release에 대해 보안 취약점이 있는지 자동으로 ![](https://lh5.googleusercontent.com/lGeLbWHIBk6y2OSOXskcp4A2c5od0eTH6n7U5YG0p4cwTrrX02b6TpeRqJ7VXg5aUE7qDP2X2f8o4Rj1JsPHhZ-CUdLiy80O532Cgw-h_P9r-jHdL61QaXhFOPxIjTlX1cg9XPk5) -이와 같은 방법으로 기업에서 개발/배포하는 소프트웨어를 SW360에 등록하여 관리한다면, 오픈소스 컴플라이언스뿐만 아니라 보안 취약점에 대해서도 리스크를 최소화할 수 있는 형태로 관리가 가능하다. +이와 같은 방법으로 기업에서 개발/배포하는 소프트웨어를 SW360에 등록하여 관리한다면, 오픈소스 컴플라이언스뿐만 아니라 보안 취약점에 대해서도 리스크를 최소화하는 형태로 관리할 수 있다. 또한 SW360은 위와 같은 Web Interface 뿐만 아니라 대부분의 기능을 REST API로 제공하여서 FOSSology 등의 다른 도구와의 연동이 가능하다. : [https://github.com/eclipse/sw360/wiki/Dev-REST-API](https://github.com/eclipse/sw360/wiki/Dev-REST-API) diff --git a/content/ko/guide/tools/4-osvscalibr/_index.md b/content/ko/guide/tools/4-osvscalibr/_index.md index 1d88697466..229b4e265e 100644 --- a/content/ko/guide/tools/4-osvscalibr/_index.md +++ b/content/ko/guide/tools/4-osvscalibr/_index.md @@ -31,7 +31,7 @@ Go 1.21 이상이 설치된 환경에서 아래 명령으로 설치합니다. go install github.com/google/osv-scalibr/binary/scalibr@latest ``` -설치 후 바이너리는 `$(go env GOPATH)/bin/scalibr` 경로에 위치합니다. +설치 후 바이너리는 `$(go env GOPATH)/bin/scalibr` 경로에 있습니다. PATH에 `$(go env GOPATH)/bin`이 포함되어 있으면 `scalibr` 명령으로 바로 실행할 수 있습니다. 또는 소스에서 직접 빌드할 수 있습니다. diff --git a/content/ko/guide/tools/7-dependency-track/_index.md b/content/ko/guide/tools/7-dependency-track/_index.md index 267fb44ae5..1750cc1dcd 100644 --- a/content/ko/guide/tools/7-dependency-track/_index.md +++ b/content/ko/guide/tools/7-dependency-track/_index.md @@ -43,9 +43,9 @@ docker compose up -d ### (1) 웹 UI에서 프로젝트 생성 및 SBOM 업로드 1. `http://localhost:8080` 접속 -2. **Projects** → **Create Project** 클릭 +2. `Projects → Create Project` 클릭 3. 프로젝트 이름·버전 입력 후 저장 -4. 해당 프로젝트 → **Components** 탭 → **Upload BOM** 클릭 +4. 해당 프로젝트에서 `Components 탭 → Upload BOM` 클릭 5. SBOM 파일(`.cdx.json` 또는 `.spdx.json`) 업로드 업로드 후 Dependency-Track이 자동으로 취약점 분석을 시작합니다. diff --git a/content/ko/guide/tools/8-cdxgen-dt/_index.md b/content/ko/guide/tools/8-cdxgen-dt/_index.md index c22ccf90ee..9f9c43f517 100644 --- a/content/ko/guide/tools/8-cdxgen-dt/_index.md +++ b/content/ko/guide/tools/8-cdxgen-dt/_index.md @@ -122,7 +122,7 @@ docker compose ps **권장: 초기에는 NVD + GitHub Advisories 중심으로 시작** -`Administration` → `Vulnerability Sources`에서 아래 표를 참고하여 설정합니다. +`Administration → Vulnerability Sources`에서 아래 표를 참고하여 설정합니다. | 소스 | 권장 설정 | 이유 | |------|----------|------| @@ -188,7 +188,7 @@ docker compose restart dtrack-apiserver Dependency-Track의 정책 엔진(Policy Engine)을 사용하면 라이선스 위반을 자동으로 탐지할 수 있습니다. -좌측 메뉴 → `Policy Management` → 화면 우측 상단 `Create Policy` 클릭 +좌측 메뉴에서 `Policy Management`로 이동한 뒤 화면 우측 상단의 `Create Policy`를 클릭합니다. ### 정책 1: Copyleft 라이선스 경고 @@ -308,16 +308,16 @@ C/C++ 헤더 직접 관리 방식·정적 링크 바이너리는 감지에 한 자동화 스크립트가 Dependency-Track에 SBOM을 업로드하려면 API Key가 필요합니다. -`Administration` → `Access Management` → `Teams` +`Administration → Access Management → Teams` ![Teams 관리 화면](images/dt-teams.png) -1. `+ Create Team` 클릭 → 팀 이름 `Automation Agents` 입력 후 `Create` +1. `+ Create Team`을 클릭한 뒤 팀 이름 `Automation Agents`를 입력하고 `Create` 2. 생성된 팀을 클릭하여 상세 화면 진입 3. **Permissions** 섹션에서 아래 두 항목 체크: - `BOM_UPLOAD` (SBOM 업로드 권한) - `PROJECT_CREATION_UPLOAD` (프로젝트 자동 생성 권한) -4. **API Keys** 섹션 → `+ Create API Key` 클릭 +4. **API Keys** 섹션에서 `+ Create API Key` 클릭 ![API Key 생성 화면](images/dt-apikey.png) @@ -392,7 +392,7 @@ chmod +x scan-upload.sh ### 대시보드 개요 -`http://localhost:8080` → **Dashboard** +`http://localhost:8080`에 접속하면 **Dashboard**가 표시됩니다. ![Dependency-Track 대시보드](images/dt-dashboard.png) @@ -404,7 +404,7 @@ chmod +x scan-upload.sh ### 취약점 Triage 기준 -`Projects` → 프로젝트 선택 → `Audit Vulnerabilities` 탭 +`Projects`에서 프로젝트를 선택한 뒤 `Audit Vulnerabilities` 탭 무조건 모든 Critical 취약점을 긴급 처리할 필요는 없습니다. 아래 3단계로 판단합니다. @@ -427,7 +427,7 @@ flowchart TD ### 라이선스 정책 위반 대응 -좌측 메뉴 → `Policy Violation Audit`에서 전사 위반 항목을 확인합니다. +좌측 메뉴의 `Policy Violation Audit`에서 전사 위반 항목을 확인합니다. - **WARN (경고)**: 개발팀과 라이선스 사용 여부 협의 후 문제없으면 `Approved` 처리 - **FAIL (차단)**: 해당 컴포넌트를 허용 라이선스 버전으로 교체 요청 diff --git a/content/ko/guide/training-slides/_index.md b/content/ko/guide/training-slides/_index.md index 2700060f06..370ac9e50a 100644 --- a/content/ko/guide/training-slides/_index.md +++ b/content/ko/guide/training-slides/_index.md @@ -15,7 +15,7 @@ description: > 이 페이지에서는 기업 오픈소스 거버넌스 전 과정을 담은 교육 슬라이드를 제공합니다. [기업 오픈소스 관리 가이드](/guide/opensource_for_enterprise/) 내용을 4시간 교육용으로 구성한 자료입니다. -전체 화면으로 보기 → +전체 화면으로 보기