OpenChain KWG

1. OpenChain 표준

Mon, 01 Jan 0001 00:00:00 +0000

ISO/IEC 5230

OpenChain 프로젝트는 2016년 OpenChain 규격 1.0을 제작하여 배포했다. OpenChain 규격은 오픈소스 컴플라이언스를 위한 핵심 요구사항을 정의한 12페이지 분량의 규격으로, 기업의 규모나 업종과 관계없이 모든 분야의 회사에 적합하도록 고안되었다. 2020년 12월 Openchain 규격 2.1은 ISO/IEC 5230 국제표준으로 등록되었다.

ISO/IEC 5230은 기업이 오픈소스 컴플라이언스 달성을 위해 꼭 수행해야 할 여섯 가지 주요 요구사항과 이를 입증하기 위해 필요한 자료 목록을 정의하고 있다.

프로그램 설립
관련 업무 정의 및 지원
오픈소스 컨텐츠 검토 및 승인
컴플라이언스 산출물 생성 및 제공
오픈소스 커뮤니티 참여에 대한 이해
규격 요구사항 적합성

오픈소스 컴플라이언스를 처음 시작하는 기업이라면 이러한 ISO/IEC 5230 표준의 요구사항을 하나씩 충족해가면서 수준을 향상시키는 것이 좋은 전략이다.

1. 오픈소스 정책 (샘플)

Mon, 01 Jan 0001 00:00:00 +0000

Note:

This sample open source policy was written with reference to the following two materials. 1. [OpenChain Open Source Policy Template](https://github.com/OpenChain-Project/Reference-Material/blob/master/Open-Source-Policy/Official/2.1/en/Open-Source-Policy-Template-en-OpenChain2.1-ISO5230.xlsx) 2. [Linux Foundation Generic FOSS Policy](https://github.com/todogroup/policies/blob/master/linuxfoundation/lf_compliance_generic_policy.pdf)

1. 목적

(1) 정책의 목적_(3.1.3.1)

이 정책은 OOO 주식회사(이하 “회사"라 함)에서 소프트웨어 개발, 서비스, 배포에 관여하는 전체 조직이 올바르게 오픈소스 소프트웨어(이하 “오픈소스"라 함)를 활용하기 위해 다음과 같은 원칙을 제공한다.

오픈소스 라이선스를 고려한 컴플라이언스 수행 원칙
외부 오픈소스 프로젝트로의 기여 원칙
사내 프로젝트를 오픈소스로 공개하기 위한 원칙

이러한 원칙은 회사의 모든 구성원이 오픈소스의 가치를 이해하고, 오픈소스를 올바르게 사용하며, 오픈소스 커뮤니티에 기여하기 위한 방법을 제공한다.

1. 프로그램 설립

Mon, 01 Jan 0001 00:00:00 +0000

오픈소스를 이용하여 소프트웨어를 개발하고 배포하는 기업이라면 오픈소스를 관리하기 위한 정책과 프로세스를 만들고, 이를 위한 인력과 자원을 적절하게 할당해야 한다.

오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스 활동을 수행하기 위한 일련의 관리 체계를 의미하며, OpenChain 규격의 첫 번째 요구사항은 바로 이 오픈소스 프로그램을 설립하라는 것이다.

1.1 정책

그 첫 번째 요구사항으로 문서화된 오픈소스 정책이 있어야 한다. ISO/IEC 5230과 ISO/IEC 18984 표준에의 3.1.1항에서는 다음과 같이 정책에 대한 요구사항과 입증 자료를 정의하고 있다.

FOSSology

Mon, 01 Jan 0001 00:00:00 +0000

오픈소스 컴플라이언스를 위해 소프트웨어 내에 포함된 오픈소스와 라이선스 정보를 검출하기 위해 소스코드 스캔 도구를 사용할 수 있다.

< https://www.fossology.org/ >

Linux Foundation의 FOSSology 프로젝트는 이러한 스캔 도구를 개발하고 오픈소스로 공개해 누구나 자유롭게 사용할 수 있게 한 도구이다.

주요 특징

FOSSology는 웹기반의 프로그램으로 사용자는 웹사이트에 로그인하여 개별 파일 혹은 소프트웨어 패키지를 업로드할 수 있다. FOSSology는 업로드된 파일 내에 라이선스 텍스트와 Copyright 정보를 검출한다. 개발자는 사용하고자 하는 오픈소스의 라이선스가 무엇인지, Copyright은 어떻게 되는지에 대한 정보를 확인하고자 할때 FOSSology를 이용하는 것이 좋다. FOSSology는 개발자가 업로드한 오픈소스 패키지 내의 모든 파일을 스캔하여 각 파일 내 라이선스 관련 텍스트와 Copyright 정보를 자동으로 검출하고, 이를 리포트로 생성한다. FOSSology 주요 특징에 대한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/features/

2. OpenChain 인증

Mon, 01 Jan 0001 00:00:00 +0000

OpenChain 규격에서의 요구 사항을 모두 준수한다면 OpenChain 적합한 오픈소스 프로그램을 보유했음을 인증받을 수 있다. 오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스 활동을 수행하기 위한 일련의 관리 체계를 의미한다. 이 장에서는 인증 방법과 적합성 선언에 관해 설명한다.

OpenChain 프로젝트에서 제안하는 인증 방법은 세 가지 이다.

자체 인증
독립 평가
타사 인증

각각의 방법을 알아보자.

자체 인증

자체 인증은 OpenChain 프로젝트에서 제일 권장하는 방법이며, 비용이 발생하지 않는다는 장점이 있다. OpenChain 프로젝트는 기업이 자체적으로 OpenChain 규격을 충족하는지 확인할 수 있도록 온라인 자체 인증 웹사이트를 제공한다.

2. 관련 업무 정의 및 지원

Mon, 01 Jan 0001 00:00:00 +0000

오픈소스 프로그램이 효과적으로 운용되기 위해서는 충분한 리소스와 인력 할당이 필요하다. 여기에서는 이를 위한 요구사항을 정의한다.

2.1 접근성

ISO/IEC 5230과 ISO/IEC 18974의 3.2.1항에서는 다음과 같이 접근성에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230

3.2.1 외부 문의 대응 (Access)

외부의 오픈소스 문의에 효과적으로 대응하기 위한 프로세스를 유지해야 한다. 제 3자가 오픈소스 컴플라이언스에 대해 문의 할 수 있는 방법을 공개해야 한다.

입증 자료:

3.2.1.1 제 3자가 오픈소스 라이선스 컴플라이언스에 대해 문의 할 수 있는 공개된 방법 (담당자 이메일 주소, 또는 Linux Foundation의 Open Compliance Directory 활용 등)
3.2.1.2 제 3자의 오픈소스 라이선스 컴플라이언스 문의에 대응하기 위한 내부의 문서화된 절차

3.2.1 Access

Maintain a process to effectively respond to external open source inquiries. Publicly identify a means by which a third party can make an open source compliance inquiry.

Verification material(s):

3.2.1.1 Publicly visible method that allows any third party to make an open source license compliance inquiry (e.g., via a published contact email address, or the Linux Foundation’s Open Compliance Directory).
3.2.1.2 An internal documented procedure for responding to third party open source license compliance inquiries.

SW360

Mon, 01 Jan 0001 00:00:00 +0000

(Updated on August 29, 2023.)

오픈소스를 포함하는 제품을 개발하고 배포하는 기업이라면 각 제품과 릴리스 버전마다 사용한 오픈소스의 버전, 라이선스 등의 정보를 수집하고 추적해야 한다. 이를 통해 기업은 올바른 오픈소스 컴플라이언스 활동을 수행할 수 있다.

특히, NVD (https://nvd.nist.gov/vuln)에서 특정 오픈소스 버전에 보안 취약점이 보고 되었을때, 해당 버전을 사용하고 있는 제품이 무엇인지 추적을 할 수 없다면, 그 기업은 어느 제품에 보안 패치를 적용해야 할 지 알 수 없는 상황에 처하게 되고, 그 기업의 제품들은 보안취약점에 그대로 노출이 될 수 밖에 없다.

3. OpenChain 리소스

Mon, 01 Jan 0001 00:00:00 +0000

OpenChain 프로젝트에서는 기업이 컴플라이언스 프로그램을 구축하는 데 필요한 정책 문서 템플릿, 교육 자료 등 다양한 리소스를 제공한다. 이 자료들은 OpenChain 표준 준수와 일반적인 오픈소스 컴플라이언스 활동을 지원하기 위해 고안됐으며, 누구나 자유롭게 사용할 수 있도록 CC-0 라이선스로 제공된다.

< https://www.openchainproject.org/resources >

이 가이드의 많은 내용도 OpenChain에서 공개한 자료를 기반으로 작성하였다. 각 기업의 오픈소스 담당자는 정책, 프로세스, 교육자료가 필요하다면 OpenChain Resources를 먼저 찾아보기 바란다. 또한 이 자료는 한국어로도 번역되어 공개되고 있다. OpenChain Korea Work Group¹에서 이러한 번역 작업을 주도하고 있다. 한국어 번역은 관심 있는 누구나 참여할 수 있다².

3. 오픈소스 콘텐츠 검토 및 승인

Mon, 01 Jan 0001 00:00:00 +0000

3.1 SBOM (Software Bill of Materials)

ISO/IEC 5230과 ISO/IEC 18974의 3.3.1항에서는 다음과 같이 BOM(Bill of Materials)에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230

3.3.1 BOM

배포용 소프트웨어를 구성하는 오픈소스 컴포넌트(및 식별된 라이선스)에 대한 BOM(Bill of Materials)을 생성하고 관리하는 프로세스가 있어야 한다.

입증 자료:

3.3.1.1 배포용 소프트웨어를 구성하는 오픈소스 컴포넌트에 대한 정보를 식별, 추적, 검토, 승인 및 보관하는 문서화된 절차
3.3.1.2 문서화된 절차가 적절히 준수되었음을 보여주는 배포용 소프트웨어에 대한 오픈소스 컴포넌트 기록

3.3.1 Bill of Materials

A process shall exist for creating and managing a bill of materials that includes each open source component (and its identified licenses) from which the supplied software is comprised.

Verification Material(s):

3.1.1.1 A documented procedure for identifying, tracking, reviewing, approving, and archiving information about the collection of open source components from which the supplied software is comprised.
3.3.1.2 Open source component records for the supplied software that demonstrates the documented procedure was properly followed.

4. 컴플라이언스 산출물 생성 및 제공

Mon, 01 Jan 0001 00:00:00 +0000

4.1 컴플라이어스 산출물

ISO/IEC 5230의 3.4.1항에서는 다음과 같이 컴플라이언스 산출물에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230

3.4.1 컴플라이언스 산출물

배포용 소프트웨어에 대한 컴플라이언스 산출물을 생성하는 프로세스가 있어야 한다.

입증 자료:

3.4.1.1 식별된 라이선스가 요구하는 컴플라이언스 산출물을 준비하고, 이를 배포용 소프트웨어와 함께 제공하기 위한 프로세스를 설명하는 문서화된 절차
3.4.1.2 배포용 소프트웨어의 컴플라이언스 산출물 사본을 보관하기 위한 문서화된 절차
- 산출물 사본은 배포용 소프트웨어의 마지막 배포 이후 합리적인 기간 동안 혹은 식별된 라이선스에서 요구하는 기간 동안 보관해야 한다(둘 중 더 긴 기간을 따름).
- 이러한 절차가 올바르게 수행되었음을 입증하는 기록이 존재해야 한다.

3.4.1 Compliance artifacts

A process shall exist for creating the set of compliance artifacts for the supplied software.

Verification Materials(s):

3.4.1.1 A documented procedure that describes the process under which the compliance artifacts are prepared and distributed with the supplied software as required by the identified licenses.
3.4.1.2 A documented procedure for archiving copies of the compliance artifacts of the supplied software - where the archive is planned to exist for a reasonable period of time (determined by domain, legal jurisdiction and/or customer contracts) since the last offer of the supplied software; or as required by the identified licenses (whichever is longer). Records exist that demonstrate the procedure has been properly followed.

5. 오픈소스 커뮤니티 참여에 대한 이해

Mon, 01 Jan 0001 00:00:00 +0000

5.1 기여

ISO/IEC 5230의 3.5.1항에서는 다음과 같이 컴플라이언스 산출물에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230

3.5.1 기여

조직이 외부 오픈소스 프로젝트로의 기여를 허용하려고 한다면,

외부 오픈소스 프로젝트로의 기여를 관리하는 문서화된 정책이 있어야 한다.
이 정책이 내부에 전파되어야 한다.
정책을 시행하는 프로세스가 있어야 한다.

입증 자료:

조직이 외부 오픈소스 프로젝트로의 기여를 허용하는 경우, 다음 사항이 있어야 한다.:

3.5.1.1 문서화된 오픈소스 기여 정책
3.5.1.2 오픈소스 기여를 관리하는 문서화된 절차
3.5.1.3 모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식하도록 하는 문서화된 절차 (예: 교육, 내부 위키, 또는 기타 실질적인 전달 방법 등)

3.5.1 Contributions

If an organization considers contributions to open source projects, then

a written policy shall exist that governs contributions to open source projects;
the policy shall be internally communicated; and
a process shall exist that implements the policy

Verification Materials(s):

If an organization permits contributions to open source projects, then the following shall exist:

3.5.1.1 A documented open source contribution policy;
3.5.1.2 A documented procedure that governs open source contributions; and
3.5.1.3 A documented procedure that makes all program participants aware of the existence of the open source contribution policy (e.g., via training, internal wiki, or other practical communication method).

6. 규격 요구사항 준수

Mon, 01 Jan 0001 00:00:00 +0000

6.1 적합성

ISO/IEC 5230의 3.6.1항과 과 ISO/IEC 18974의 3.4.1항에서는 다음과 같이 적합성에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230

3.6.1 적합성

프로그램이 OpenChain에 적합하다고 간주하기 위해서는 조직은 프로그램이 이 규격에서 제시한 모든 요구사항을 충족하는지 확인해야 한다.

입증 자료:

3.6.1.1 3.1.4조에서 명시한 프로그램이 이 규격의 모든 요구사항을 충족함을 확인하는 문서

3.6.1 Conformance

In order for a program to be deemed OpenChain conformant, the organization shall affirm that the program satisfies the requirements presented in this document.

Verification Materials(s):

3.6.1.1 A document affirming the program specified in §3.1.4 satisfies all the requirements of this document.

AI 에이전트 역분석 도구, 기업은 어디까지 허용할 수 있을까

Wed, 14 Oct 2026 00:00:00 +0000

이 글은 Claude Code를 이용해 작성했고, 인용한 핵심 사실은 1차 출처로 교차 검증했습니다.

AI 코딩 에이전트에 디컴파일러를 연결해 주는 도구가 빠르게 퍼지고 있습니다. 그중 하나인 REA(Reverse Engineer Anything)는 에이전트가 소스 코드 없이 앱을 살펴보고 그 기능의 동작을 설명한 뒤 “사용자의 프로젝트에 맞는 버전"까지 만들 수 있다고 소개합니다 E3. 한국 저작권법은 프로그램코드역분석을 호환에 필요한 정보를 얻는 목적으로만 허용하므로 A1, 같은 도구라도 호환성 확보, 보안 점검, 기능 복제 중 무엇에 사용하느냐에 따라 법적 판단이 달라집니다. 기업이 이런 도구를 허용하려면 분석 목적 확인, 분석 세션과 구현 세션의 분리, 분석 기록, 디컴파일러 라이선스 확인을 사내 기준에 넣어야 합니다.

CISA 2026 SBOM 최소 요소: 데이터 필드 7개에서 17개로, 무엇을 준비할 것인가

Sun, 09 Aug 2026 00:00:00 +0000

이 글은 Claude Code를 이용해 작성했고, 인용한 핵심 사실은 1차 출처로 교차 검증했습니다.

요약

2026년 7월 29일, 미국 사이버보안·인프라보안국(Cybersecurity and Infrastructure Security Agency, CISA)을 비롯한 18개 기관이 소프트웨어 자재 명세서(Software Bill of Materials, SBOM)가 최소한 담아야 할 요소(Minimum Elements) 개정판을 발행했습니다 A2. 2021년 미국 통신정보관리청(National Telecommunications and Information Administration, NTIA)이 만든 기준을 개정한 것이 아니라 대체(replaces)한다고 문서가 직접 밝힙니다.

요구 수준이 눈에 띄게 올라갔습니다. 데이터 필드가 7개에서 17개로 늘었고 운영 원칙 6개가 함께 규정됐습니다. 신규 요소만 10개입니다.

미국 AI 행정명령(2026-06-02)이 기업 오픈소스 관리자에게 의미하는 것

Wed, 10 Jun 2026 00:00:00 +0000

이 글은 Claude Code를 이용해 작성했고, 인용한 핵심 사실은 1차 출처로 교차 검증했습니다.

요약

2026년 6월 2일 서명된 행정명령 “Promoting Advanced Artificial Intelligence Innovation and Security"는 기업에 어떤 의무도 부과하지 않습니다. 재무부가 이끄는 AI 사이버보안 클리어링하우스(취약점 정보를 한곳에 모아 검증하고 배분하는 중계 기구, 30일 내 구성)와 프런티어 모델의 자발적 사전 공유 체계(60일 내 설계)가 골자이고, 의무 라이선싱과 사전심사는 명시적으로 배제됐습니다 A1. 기업 오픈소스 관리자에게 직접 적용되는 조항도 없습니다. 그런데도 이 명령을 읽어야 하는 이유는 배경에 있습니다. AI가 오픈소스 취약점을 사람보다 빠르게 찾아내는 상황이 이미 현실이 됐기 때문입니다. 행정명령에 앞서 앤트로픽의 미공개 모델은 두 달 만에 오픈소스 프로젝트에서 높음 또는 치명 등급 취약점 6,202건을 찾아냈고, 패치가 그 속도를 따라가지 못하고 있습니다 A6·C1. 오픈소스 관리자가 준비할 것은 행정명령 컴플라이언스가 아니라 패치 처리 능력 점검과 EOL 컴포넌트 정리, 그리고 2026년 9월 11일 시행되는 EU 사이버 복원력법 보고 의무까지 한꺼번에 감당할 대응 체계입니다.

EU 오픈소스 전략: 기술 주권을 위한 오픈소스의 제도화

Tue, 09 Jun 2026 00:00:00 +0000

이 글은 Claude Code를 이용해 작성했고, 인용한 핵심 사실은 1차 출처로 교차 검증했습니다.

요약

유럽연합 집행위원회가 2026년 6월 3일 발표한 「유럽 기술 주권에 관한 통신」(COM(2026) 503 final)에는 EU 오픈소스 전략(EU Open Source Strategy)이 첨부되어 있습니다. 오픈소스를 EU 디지털 정책의 중심에 놓은 첫 사례입니다. 전략은 주권을 위한 활용, 생태계 강화, 공공행정의 개방화, 표준과 국제 협력이라는 네 가지 목표를 제시하고, 향후 7년간 오픈소스 관련 조치에 약 20억 유로를 공공과 민간이 동원하도록 합니다. EU가 미국산 독점 IT에 매년 2,640억 유로를 지출하는 의존 구조를 줄이려는 것입니다. 시민사회(FSFE)와 정책 분석가들은 방향을 환영하면서도 재정 충분성, 오픈 표준과 오픈소스의 관계, 오픈 하드웨어 경시, 실무자 스킬 격차를 한계로 지적했습니다. 한국 공공과 기업 실무자에게는 EU 조달 개방화와 오픈소스 스튜어드 규제, EUDI 지갑의 오픈소스 기본값이 직접 지켜볼 지점입니다.

AI가 만든 코드, 오픈소스 검사를 어디까지 해야 할까

Mon, 08 Jun 2026 00:00:00 +0000

이 글은 Claude Code를 이용해 작성했고, 인용한 핵심 사실은 공개 출처로 교차 검증했습니다.

고지

이 글은 작성자 개인의 분석과 정리이며, 법률 자문이 아닙니다. 인용한 사실은 공개 출처에 근거해 확인했으나, 구체적 사안의 판단은 변호사 등 전문가의 검토를 받으시기 바랍니다.

한 가지 먼저 짚을 점

이 질문에 곧바로 “예"나 “아니오"로 답하기는 어렵습니다. 뒤에서 하나씩 짚겠지만, 답을 좌우하는 것은 AI 자체가 아니기 때문입니다. AI 코딩은 패키지로 선언되지 않은 코드 조각의 유입 속도를 높이지만, 라이선스 의무가 생기는 조건 자체를 바꾸지는 않습니다. 그래서 “AI 시대에 스캔이 의미 있나"보다는 “어떤 조건에서 스니펫 단위 검사가 더 중요해지고, 어떤 조건에서 덜 중요해지나"로 나눠 보는 편이 판단에 도움이 됩니다.

EU 사이버 복원력법(CRA) 취약점 보고 의무 — 2026-09-11 시행 대비 조사보고서

Mon, 18 May 2026 00:00:00 +0000

이 글은 Claude Code를 이용해 작성했고, 인용한 핵심 사실은 1차 출처로 교차 검증했습니다.

요약

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, B1, E1

Rockchip과 FFmpeg의 라이선스 분쟁 사례

Fri, 20 Feb 2026 00:00:00 +0000

이 글은 Claude Code를 이용해 작성했고, 인용한 핵심 사실은 1차 출처로 교차 검증했습니다.

고지

이 글은 작성자 개인의 분석과 정리이며, 법률 자문이 아닙니다. 인용한 사실은 공개 출처에 근거해 확인했으나, 침해 성립 여부와 같은 법적 판단은 다투어질 수 있는 사안이므로 구체적 사안의 판단은 변호사 등 전문가의 검토를 받으시기 바랍니다.

안녕하세요.

임베디드 리눅스 업계에서 화제가 된 Rockchip과 FFmpeg의 라이선스 분쟁을 정리해 보았습니다. 2025년 12월 저장소가 내려간 시점에 처음 썼던 글인데, 그 뒤 Rockchip이 대응에 나서면서 저장소가 복구되었습니다. 경과를 반영해 전면 개정하고, 저장소가 다시 열린 덕분에 확인할 수 있게 된 실제 코드로 근거를 바꿨습니다.

AVM 소송: LGPL-2.1 사용자 권리와 설치정보 제공 의무의 재조명

Mon, 13 Jan 2025 00:00:00 +0000

본 글은 Ars Technica의 “German router maker is latest company to inadvertently clarify the LGPL license” 기사를 바탕으로 작성되었습니다. 해당 기사는 AVM과 Sebastian Steck 간의 소송에 대한 자세한 내용과 LGPL 라이선스 준수의 중요성을 다루고 있습니다.

1. 사건 개요

2025년 1월 9일, Software Freedom Conservancy (SFC)는 독일의 네트워크 장비 제조업체 AVM을 상대로 제기한 소송이 마무리되었다고 발표했습니다. 이 소송의 핵심은 GNU Lesser General Public License (LGPL) 버전 2.1에 명시된 사용자의 권리, 특히 설치 정보 제공 의무에 관한 것이었습니다.

Oracle과 Rimini Street 소송 사례로 알아보는 GPL 파생저작물 범위

Mon, 23 Dec 2024 00:00:00 +0000

들어가며

소프트웨어 지식재산권 침해 논란에서 ‘파생저작물(derivative works)‘이라는 개념은 매우 중요합니다. 특히 GNU General Public License (GPL)과 같은 오픈소스 라이선스를 다룰 때 이 개념은 핵심적인 쟁점이 됩니다. 최근 Oracle과 Rimini Street 간의 소송은 파생저작물의 정의와 관련된 법적 해석을 다시금 주목하게 만들었습니다. 이번 글에서는 이 사건의 배경, 주요 판결 내용, 그리고 오픈소스 라이선스에 미칠 영향을 살펴보겠습니다.

사건의 배경

PeopleSoft와 Rimini Street

PeopleSoft는 Oracle이 제공하는 ERP(Enterprise Resource Planning) 소프트웨어로, 기업의 인사 관리, 재무 관리, 공급망 운영 등을 지원합니다. PeopleSoft는 정기적으로 업데이트를 제공하며, Oracle은 고객들에게 이러한 업데이트를 유지보수 서비스 형태로 제공합니다.

한국 소프트웨어 기업이 알아야 할 EU의 3대 디지털 규제 핵심 내용

Tue, 12 Nov 2024 00:00:00 +0000

서론

유럽연합(EU)이 최근 도입한 3대 주요 법안은 한국 기업에게 매우 중요한 의미를 갖습니다. Product Liability Directive(PLD), Cyber Resilience Act(CRA), 그리고 AI Act는 소프트웨어와 AI 시스템의 개발, 배포, 사용에 관한 포괄적인 규제 프레임워크를 제시하고 있습니다.

이 법안들이 한국 기업에 중요한 이유는 다음과 같습니다:

EU 시장 진출: EU는 세계 최대 단일 시장 중 하나로, 많은 한국 기업이 진출을 목표로 하고 있습니다. 이 법안들을 준수하지 않으면 EU 시장 접근이 제한될 수 있습니다.
글로벌 표준 설정: EU의 규제는 종종 글로벌 표준이 되는 경향이 있습니다. 이른바 ‘브뤼셀 효과‘로, 다른 국가들도 유사한 규제를 도입할 가능성이 높습니다.
기업 책임의 확대: 이 법안들은 기업의 책임 범위를 크게 확대합니다. 특히 PLD의 무과실 책임 원칙은 한국 기업들에게 새로운 도전이 될 수 있습니다.

한국 기업들이 이 법안들을 접근할 때 중요하게 고려해야 할 관점은 다음과 같습니다:

To Mine or Not To Mine: 독일 법원이 AI 시대의 저작권 딜레마에 내린 판결

Wed, 06 Nov 2024 00:00:00 +0000

이 글은 JBB Rechtsanwält:innen의 블로그 포스트 “To Mine or Not To Mine”(https://jbb.de/to-mine-or-not-to-mine/)를 기반으로 작성하였으며, 텍스트 및 데이터 마이닝(TDM)에 관한 최근 독일 법원의 판결을 설명하고 관련 지식을 공유하기 위한 목적으로 공개합니다.

단, 저는 법률 전문가가 아니며, 이 내용은 법적인 근거가 될 수 없음에 유의하여 주시기 바랍니다. 라이선스 및 법적 문제와 관련된 구체적인 상황에 대해서는 반드시 법률 전문가의 조언을 구하시기 바랍니다.

배경

2021년, 독일의 사진작가 로버트 크네슈케(Robert Kneschke)는 자신의 사진이 LAION(Large-scale Artificial Intelligence Open Network)이라는 비영리 단체가 만든 AI 학습용 데이터셋에 무단으로 포함되었다는 사실을 알게 되었습니다.

중국 저작권 침해 소송 사례 “GPL 기반 소프트웨어 제품은 어차피 소스 공개 의무가 있으니 배껴도 되는 것 아닌가요?

Mon, 23 Sep 2024 00:00:00 +0000

오픈소스 소프트웨어의 사용이 널리 퍼지면서, 이와 관련된 법적 문제들도 점점 더 복잡해지고 있습니다. 특히 GPL(GNU General Public License)과 같은 copyleft 라이선스를 사용하는 오픈소스 프로젝트를 기반으로 한 2차적 저작물의 저작권 문제는 많은 기업들에게 골치 아픈 주제입니다. 최근 중국에서 있었던 한 소프트웨어 저작권 침해 소송은 이러한 문제에 대한 중요한 시사점을 제공합니다.

소송 당사자

원고: Wangjing Technology(왕징)
피고:
- Yibang Communication Technology(이방)
- Qi’ao Network Technology(치아오)
- 그리고 3명의 개인(Liu, Wu, Xie)

사건의 개요

2009년, 왕징은 ‘OfficeTen’이라는 융합 통신 스마트 게이트웨이 제품을 개발했습니다.

또 다시 Elasticsearch 라이선스 변경, 기업의 대응 방안은?

Fri, 06 Sep 2024 00:00:00 +0000

서론: 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)를 하면서 주목을 받고 있습니다.

이러한 변화는 오픈소스 커뮤니티뿐만 아니라 이를 사용하는 기업들에도 큰 영향을 미치고 있습니다. 이번 글에서는 Elasticsearch가 왜 다시 라이선스 정책을 변경했는지, 그리고 이를 사용하는 기업들이 어떻게 대응해야 하는지 살펴보겠습니다.

SPDX 3.0 소개와 기업 도입 전략

Fri, 06 Sep 2024 00:00:00 +0000

1. SPDX 3.0 소개

SPDX(Software Package Data Exchange)는 소프트웨어 구성 요소, 라이선스, 저작권 및 보안 정보를 표준화된 방식으로 전달하기 위한 오픈 표준입니다. SPDX 3.0은 이 표준의 최신 버전으로, 2024년 4월에 출시되었으며 소프트웨어 공급망의 투명성과 보안을 크게 향상시키는 중요한 업데이트입니다[2].

SPDX의 정의와 목적

SPDX는 Linux Foundation의 프로젝트로, 소프트웨어 패키지와 관련된 중요 정보를 공유하기 위한 표준 형식을 제공합니다. 주요 목적은 다음과 같습니다:

소프트웨어 구성 요소의 투명성 제공
라이선스 컴플라이언스 개선
보안 취약점 관리 지원
소프트웨어 공급망의 신뢰성 향상

SPDX 3.0의 주요 변경사항

SPDX 3.0은 이전 버전에 비해 큰 변화를 가져왔습니다:

프랑스 법원, 대형 통신사 Orange에게 GPL 위반으로 손해배상 판결

Mon, 19 Feb 2024 00:00:00 +0000

안녕하세요.

오늘은 프랑스 법원이 GPL 위반으로 통신사인 Orange에게 손해배상을 판결한 사건에 대해 살펴보려 합니다. 이 사건은 두 가지 주요 측면에서 특별히 주목할 만한 점이 있어 보였습니다.

첫째, 이 사건의 피고인이 대형 통신사인 Orange라는 점입니다. (제가 통신사에 몸 담고 있다보니…)
둘째, GPL 위반 소송이 주로 임베디드 디바이스에서 발생하는 반면, 이 사건에서는 B2B 형태의 웹서비스 구축에 사용된 오픈소스가 이슈가 되었다는 점입니다. 이는 오픈소스 라이선스 준수가 모든 소프트웨어 개발 영역에서 중요하다는 것을 강조합니다.

이 사건은 이러한 측면들을 통해 오픈소스 라이선스 준수의 중요성을 재확인하는 계기가 될 것으로 보입니다. 이는 기업들이 오픈소스를 사용할 때 라이선스 요구사항을 철저히 이해하고 준수해야 함을 강조하는 중요한 사례가 될 것입니다.

오프라인 모임 준비 checklist

Wed, 05 Apr 2023 00:00:00 +0000

안녕하세요. 지난 3월 28일은 모두에게 기억에 남을 시간을 가졌습니다. 바로 3년 만에 COVID를 지나고 처음 갖는 오프라인 모임이었는데요. 너무 오랜만에 오프라인 모임을 가지면서 생각보다 장소 제공에 많은 ~~잡다한~~준비가 필요하다는 것을 알게 되었습니다.

다음에 언젠가 이런 오프라인 모임을 가지게 될 텐데, 이번 경험을 떠올려 오프라인 모임 준비 체크리스트를 작성해 보았습니다.(다음 모임 주최자가 또 제가 될 수도 있잖아요..?앗, 말조심!)

모임의 준비

모임을 가지기 전에 하면 좋을 작업 목록입니다. Planning Sub-group에서 해야 할 작업도 포함됩니다.

기업의 효과적인 오픈소스 관리 방안 (2) OpenChain Korea Work Group

Mon, 03 Apr 2023 00:00:00 +0000

이전 글에서는 기업의 효과적인 오픈소스 관리 방안으로 글로벌 협력을 위한 OpenChain Project를 소개했습니다. 이번에는 한국 기업이 오픈소스를 효과적으로 관리하기 위한 협업 커뮤니티인 OpenChain Korea Work Group에 대해 소개하려고 합니다.

OpenChain Korea Work Group

OpenChain Korea Work Group(KWG)은 Linux Foundation의 OpenChain Project의 하위 그룹입니다. 이 그룹은 오픈소스 정신인 협업과 공유를 통해 모두가 효과적으로 오픈소스 관리에 성공하기 위한 방법을 고민하고 공유하는 모임입니다. KWG에는 한국의 주요 ICT 기업의 오픈소스 담당자들이 참여하고 있습니다.

OpenChain KWG 정기 미팅

오픈소스 관리를 위한 정책과 프로세스를 이미 구축한 대기업들도, 현대의 거대하고 복잡한 소프트웨어 공급망을 고려한다면 오픈소스 라이선스나 보안 취약점 리스크에서 벗어나기 어렵습니다. 결국, 소프트웨어 공급망 내 모든 기업의 오픈소스 관리 수준을 높이는 것이 중요합니다. 이를 위해서는 오픈소스 관리 방법에 대한 이해도가 높은 기업이 먼저 노하우를 공유하고, 다른 기업에서 쉽게 참여할 수 있도록 안내하는 길잡이가 필요합니다.

기업의 효과적인 오픈소스 관리 방안 (1) 글로벌 협력을 위한 OpenChain Project

Tue, 28 Mar 2023 00:00:00 +0000

기업이 개발하는 제품 소프트웨어의 93% 이상이 오픈소스를 사용한다고 할 정도로 현대 소프트웨어 개발에 오픈소스를 사용하는 건 거의 필수적입니다. 그런데, 사용하는 오픈소스의 53%는 라이선스 컴플라이언스 이슈가 있고, 81%는 보안 취약점이 있다는 보고가 있습니다. 복잡한 현대 소프트웨어의 개발환경과 방대한 Software Supply Chain을 고려한다면, 기업이 오픈소스로 제품을 개발하면서 라이선스 컴플라이언스와 보안 취약점 리스크 최소화를 위한 오픈소스 관리 노력이 필요한데요, Linux Foundation의 OpenChain Project는 이러한 노력을 커뮤니티 차원에서 여러 기업이 공유와 협업으로 함께 하기 위한 Project입니다.

2023년 3월 27일, OpenChain Project의 General Manager인 Shane Coughlan이 SK텔레콤을 방문하여 OpenChain Project의 주요 활동, 오픈소스 관련 국제 표준 및 글로벌 동향에 관해 설명하는 시간을 가졌습니다.

Anaconda 꼭 사서 쓰세요. 아니라면 conda-forge!

Mon, 13 Mar 2023 00:00:00 +0000

안녕하세요.

Python 개발 환경 만들면서 Anaconda 많이 사용하시지 않나요? Python은 간단한 업무 자동화부터 데이터 분석, 인공지능 학습, 모델링 작업 등에 많이 사용되고 있는데요, 여러 Python 프로젝트 개발을 수행하다 보면 package 버전이 충돌하는 불편함이 생길 수 있습니다. Anaconda는 개발 프로젝트별로 가상 환경을 제공하여 버전 충돌을 방지할 수 있다는 장점이 있으며, 홈페이지에서 쉽게 다운받아 설치가 간단하여 널리 사용되고 있습니다.

https://www.anaconda.com/

그런데 Anaconda는 사서 쓰셔야 합니다.

2020년 9월, Anaconda사는 서비스 약관(Terms of Service)를 변경하여 200명 이상의 직원이 있는 기업 또는 정부 조직이 Anaconda Repository를 사용하는 경우 유료로 구매하게 하였습니다.

Akka는 더 이상 오픈소스가 아닙니다.

Fri, 30 Sep 2022 00:00:00 +0000

오픈소스로 시작한 소프트웨어 기업이 라이선스 정책을 변경하는 사례가 증가하고 있는데요, 그동안 Apache-2.0으로 오픈소스 라이선스 정책을 유지해오던 미국의 Lightbend사도 2022년 9월, Akka의 라이선스를 BUSL-1.1 (Business Source License)로 변경한다고 발표하였습니다.
Business Source License가 무엇인지, Lightbend가 Akka의 라이선스를 BSL로 변경한 배경과 그 영향은 무엇인지에 대해 알아보겠습니다.

Akka란?

Akka는 JVM에서 여러 개의 thread가 동시에 작업하는 분산 애플리케이션을 Actor Model을 기반으로 단순화하는 툴킷으로 live chatting 등 주로 고성능이 요구되는 백엔드 플랫폼에 사용된다고 합니다.

라이선스 변경

미국의 Ligntbend 사는 2022년 9월 Akka의 라이선스를 변경하였습니다.

SFC vs. Vizio 판결 겉핥기

Tue, 14 Jun 2022 00:00:00 +0000

안녕하세요, 장학성입니다.

SFC(Software Freedom Conservancy)가 GPL 위반을 이유로 미국의 스마트 TV 제조사인 Vizio에 소송을 제기하였는데요, 지난 2022년 5월 13일, 이와 관련한 미국 연방 법원의 판결이 있었습니다.

이번 판결의 배경과 시사점을 수박 겉핥기로 정리해보았습니다. 제가 법률 전문가가 아니기 때문에 용어나 해석에 오류가 있을 수 있습니다. 여러 전문가분께서 피드백 주시면 고맙겠습니다. ^^

References

먼저 이 글을 작성하면서 참고한 references를 밝힙니다.

PROCEEDINGS: (IN CHAMBERS) ORDER GRANTING PLAINTIFF’S MOTION TO REMAND : https://storage.courtlistener.com/recap/gov.uscourts.cacd.837808/gov.uscourts.cacd.837808.30.0.pdf
Software Freedom Conservancy files right-to-repair lawsuit against California TV manufacturer Vizio Inc. for alleged GPL violations : https://sfconservancy.org/copyleft-compliance/vizio.html
SFC Files GPL Enforcement Suit Against Vizio Advancing Novel Legal Theories : https://heathermeeker.com/2021/11/09/sfc-files-gpl-enforcement-suit-against-vizio-advancing-novel-legal-theories/
First Update on the Vizio lawsuit : https://sfconservancy.org/blog/2021/nov/30/vizio-update-0/
SFC v. Vizio remanded back to California state courts : https://lwn.net/Articles/895405/
Software Freedom Conservancy right-to-repair lawsuit against California TV manufacturer Vizio, Inc. remanded to California State Court : https://sfconservancy.org/news/2022/may/16/vizio-remand-win/
미국 법원 “GPL도 계약”…소비자의 코드 요구권 인정 : https://zdnet.co.kr/view/?no=20220518145132
오픈소스 라이선스 위반과 저작권 침해 : https://olis.or.kr/library/openSwDetail.do?bbsId=103&bbsNum=26400
오픈소스 라이선스에 대한 법적 효력 : https://www.copyright.or.kr/information-materials/trend/the-copyright/download.do?brdctsno=10231&brdctsfileno=4699
연방 법원(Federal Court) 특징 : https://lawandstory.com/연방-법원federal-court-특징/

1. 배경지식

지난 5월 18일, “미국 법원 “GPL도 계약”…소비자의 코드 요구권 인정“이라는 제목의 기사가 나왔는데요, 다음과 같은 문장은 뭔가 중요한 말인 것 같은데 정확히 어떤 의미인지 잘 이해가 되지 않았습니다.

이너소스 도입을 위한 과제와 효과

Sun, 03 Apr 2022 00:00:00 +0000

안녕하세요, 장학성입니다.

이너소스(Inner Source)는 오픈소스 개발방법론을 사내에 도입하여 조직간 공유와 협업을 극대화하고, 빠른 개발 속도와 투명한 커뮤니케이션, 코드 품질 향상 등의 효과를 기대하기 위한 방법입니다.

이너소스를 위한 방법은 여러 문서에서 설명하고 있는데요, 오늘은 다음 자료에서 언급하고 있는 이너소스를 시작하는 방법과 기대효과에 대해 간략히 정리하였으니 참고하시기 바랍니다.

Getting Started with InnerSource (Keys to collaboration and productivity inside your company) / Adny Oram

1. 오픈소스 Practice 주요 사항

먼저, 오픈소스 개발방법론에서 강조하는 주요 Practice를 살펴보겠습니다. 어떻게 거대한 오픈소스 프로젝트가 자발적인 참여로 성장해갈 수 있을까요? 왜 오픈소스 프로젝트에 참여하면 개발자 개인의 성장을 이룰 수 있다고 할까요? 오픈소스 프로젝트에는 다음과 같은 주요 Practice가 있기 때문입니다.

상용 AI 서비스에 공개 Dataset을 사용해도 되나요?

Mon, 14 Feb 2022 00:00:00 +0000

안녕하세요, 장학성입니다.

AI는 사용하지 않는 기업이 없을 정도로 현대 비즈니스에 중요한 기술이 되었습니다. AI 서비스를 만들기 위해서는 많은 양의 data가 필요한데요, 공개 Dataset_{publicly available datasets}도 널리 사용되고 있습니다. 다만 공개 Dataset이라고 하더라도 저작권이 있기 때문에 이를 상용 AI 서비스에 사용하려면 저작권 침해 등 법적 리스크를 최소화하기 위해 라이선스 측면의 확인이 필요합니다.

오늘은 이와 관련하여 최근 발표된 논문인 Can I use this publicly available dataset to build commercial AI software?– A Case Study on Publicly Available Image Datasets을 소개하려고 합니다. : https://arxiv.org/abs/2111.02374

SaaS로 서비스를 제공할 때에도 오픈소스 컴플라이언스가 필요한가요?

Mon, 20 Dec 2021 00:00:00 +0000

대부분의 오픈소스 라이선스는 오픈소스를 실행시키는 것에는 아무 제한을 두지 않으며, 오픈소스를 재배포할 때 소스 코드 공개, 고지 등의 의무 준수를 요구합니다. 여기서 배포라고 하면, 소프트웨어를 탑재한 임베디드 디바이스의 판매, 앱 마켓을 통한 모바일 앱의 배포 등 일반적으로 소프트웨어의 물리적인 전달을 의미합니다.

SaaS 서비스 제공 업체는 서비스를 위해 소프트웨어를 배포하지 않기 때문에 오픈소스를 사용하더라도 라이선스 의무에서 비교적 자유로울 수 있습니다. 하지만, AGPL 등 네트워크를 통한 서비스 제공 시에도 라이선스 의무를 준수하는 오픈소스 라이선스도 있기 때문에 이에 대해서는 주의가 필요합니다.

Log4j 2 보안 취약점 사태 (Log4Shell)

Sun, 12 Dec 2021 00:00:00 +0000

Apache Log4j 2에서 발생한 취약점(CVE-2021-44228, NVD)을 통해 악성코드 감염 등 추가 피해가 발생할 수 있어 전 세계적으로 긴급 보안 업데이트 조치 (2021.12.10)가 있었으며, 관련 내용을 정리합니다.

Log4j

Log4j는 로그를 목적으로 Java 기반의 웹서비스에서 대부분 사용되는 Apache 재단의 오픈소스입니다.

경과

2021.11.24 알리바바 클라우드 보안팀에서 최초로 발견 (Apache 공지)
2021.11.30 Log4j팀, Restrict LDAP access via JNDI pull request 추가 (12/5 Merged)
2021.11.30 Log4j팀, no longer formats lookups in messages by default pull request 추가 (12/5 Merged)
2021.12.09 log4j 2 보안 이슈 PR과 취약성 재현 스샷이 한 트윗에 올라오면서 이슈가 퍼지기 시작
2021.12.10 마인크래프트 기술 책임자가 관련 이슈 수정하였다며 트윗으로 알리면서 본격 이슈화
2021.12.10 Log4j 2.15.0 버전 릴리즈 로 보안 취약성 패치
2021.12.12 Log4j팀, Disable JNDI by default 추가
2021.12.12 Log4j 2.15.1 버전 릴리즈 후보 (JNDI 기본값 Disable)

영향범위

Log4j 2.0-beta9 부터 2.15.x 이전 버전
Spring Boot 관련
- Spring Boot는 또 다른 로그 라이브러리인 Logback을 디폴트로 하고 있으며,
  기본 로깅 시스템을 Log4j2로 전환한 경우 취약점의 영향을 받습니다.
- 2021.12.12 현재 최신 버전인 Spring Boot 2.6.1 에서는 Log4j2 로 전환시 버전을 명시하지 않으면 1.14.1 로 설치됨
- 현재 릴리즈 전인 Spring Boot 2.6.2 에서는 Log4j 2.15.x 로 업데이트 예정

NIPA, 공개소프트웨어의 활용을 위한 가이드 4종 발간

Tue, 23 Nov 2021 00:00:00 +0000

NIPA에서 공개소프트웨어 활용을 위한 4종의 가이드를 발간했습니다. (출처 : https://www.oss.kr/news/show/ef0900db-f5b4-40fb-8745-f1b937fbd8d0)

공개소프트웨어 가이드 4종의 내용은 아래와 같습니다. 참고로 기업 공개소프트웨어 거버넌스 가이드는 현재 OpenChain KWG 운영진이신 장학성, 이서연, 황민호님이 집필에 참여했습니다.

공개소프트웨어 라이선스 가이드 (개정판)

공개 소프트웨어 라이선스 다운로드

중국 첫 GPL 소송 사례, VirtualApp

Mon, 15 Nov 2021 00:00:00 +0000

안녕하세요, 장학성입니다.

지난 2021년 9월, 중국내 최초의 GPL 관련 판결이 있었다는 중국 기사를 통해 공개되었습니다. 번역기를 활용해 이해한 내용을 정리해보았습니다.
제가 법률가도 아니고, 중국어도 모르다보니 틀린 내용이 있을 수도 있음을 감안해주시기 바랍니다. :)
오류를 발견하신 분은 언제든 알려주시면 감사하겠습니다! (haksung@sk.com)

(감수에 도움을 주신 한국저작권위원회 최진영 센터장님께 감사 드립니다. ^^)

출처 : “首例！违反 GPL 协议致侵权，被判赔偿 50 万元” - https://www.oschina.net/news/159435

요약

지난 2021년 4월, 중국에서 저작권 침해 분쟁에 대한 민사 1심 판결이 있었습니다. 피고가 원고가 GPL-3.0으로 공개한 코드를 사용하면서 GPL-3.0의 의무수항을 준수하지 않음으로써 GPL-3.0이 부여한 라이선스 권리가 종료되고, 이로 인해 침해가 구성되었다는 판결입니다. 법원은 침해 사실을 확인하고, 피고에게 500,000 RMB (약 1억 원)의 배상금을 부과하였습니다.

SKT, 오픈소스 컴플라이언스 분야 ISO 국제인증 획득

Thu, 09 Sep 2021 00:00:00 +0000

SK telecom

SK텔레콤이 ‘오픈소스’ 활용을 위한 체계적 관리(컴플라이언스) 시스템을 갖췄음을 국제적으로 인정받았다.

SK텔레콤(대표이사 박정호, www.sktelecom.com)은 국제표준화기구(ISO, Interna-tional Organization for Standardization)로부터 오픈소스 컴플라이언스 관련 표준인증(ISO/IEC 5230)을 획득했다고 9일 밝혔다.

자세한 내용은 기사 원문에서 확인하세요. : https://news.sktelecom.com/147961

GPLv2도 설치정보를 요구한다고?

Sun, 01 Aug 2021 00:00:00 +0000

안녕하세요.

미국의 저명한 오픈소스 라이선스 전문 변호사인 P. McCoy Smith는 최근 JOLTS_{Journal of Open Law, Technology & Society}에 GPLv2가 ‘설치정보’를 요구하는가를 주제로 글을 게재하였습니다.

지난 2021년 3월, SFC_{Software Freedom Convervancy}의 블로그에 “Understanding Installation Requirements in GPLv2“라는 주제로 GPLv2에서도 설치 정보 제공을 요구한다는 글이 올라왔었는데, 이에 대한 분석과 GPLv3의 ‘설치 정보’ 요구 사항은 GPLv2에서는 해당하지 않는다는 의견을 자세한 근거를 들어 설명하였습니다.

여기서는 원문을 번역하되 Readability를 고려하고 독자의 이해를 돕기 위해 가능한 배경 설명을 추가하여 작성하였습니다.

혹시, 오류를 발견하였거나 추가 의견이 있으신 분들은 언제든 연락해주세요. haksung@sk.com

감사합니다. :)

삼성전자, 오픈소스 국제 표준 인증 획득

Thu, 08 Jul 2021 00:00:00 +0000

삼성전자가 ‘오픈체인(OpenChain) 프로젝트’의 표준 준수 기업으로 국제 인증(ISO/IEC 5230:2020)을 획득했다.

‘오픈체인 프로젝트’는 2016년 미국의 비영리단체인 리눅스 재단(Linux Foundation)의 주도로 시작됐으며, 효과적이고 일관성 있는 오픈소스 컴플라이언스 체계를 갖추고 있는 기업들에게 인증을 부여한다.

‘오픈체인 프로젝트’는 오픈소스 컴플라이언스 역량 평가 항목으로 각 기업의 ▲사내 정책과 시스템의 적정성 ▲담당 조직과 인력의 전문성 ▲사내 구성원의 교육 수행 여부 등에 대해 기준 충족 여부를 심사한다.

OpenChain

삼성전자는 이번 인증 획득으로 오픈소스 활용 역량을 인정 받아 자사 소프트웨어의 공신력을 높일 것으로 기대하고 있다.

오픈소스SW 관리 툴 ‘포스라이트’ 공개한 LG전자, “글로벌 표준 거듭나겠다”

Mon, 28 Jun 2021 00:00:00 +0000

최근 LG전자가 자체 개발해 2014년부터 운영해오고 있는 오픈소스 SW관리 도구인 ‘포스라이트(FOSSLight ; Free and Open Source Software Light)’를 공개해 주목을 받고 있다. 포스라이트는 개발자의 SW를 분석해 오픈소스를 사용했는지, 오픈소스 사용 조건이나 의무사항을 준수했는지 등을 검증해 주는 툴이다.

LG전자 오픈소스 태스크. 사진 왼쪽부터 방재권 선임, 김소임 선임, 최혜성 책임, 김경애 리더, 석지영 선임, 박원재 선임
백지영 기자

‘포스라이트’라는 이름으로 외부에 공개하면서 안정성과 기능을 확대하는 한편 글로벌 인지도를 높일 수 있게 할 계획이다. 포스라이트에는 ‘세상에 빛을 밝혀줄 오픈소스’라는 의미가 담겼다.

한 달 걸리던 카카오톡 오픈소스 관리, 이틀이면 충분

Mon, 28 Jun 2021 00:00:00 +0000

“한 달이 걸리던 카카오톡 오픈소스 관리 작업을 올리브를 사용하면 하루 이틀이면 충분할 것이다.”

카카오의 황은경 오픈소스기술파트장은 오픈소스 관리 서비스 ‘올리브’의 정식 버전에 대해 소개하며 위와 같이 말했다.

카카오가 오픈소스 관리플랫폼 '올리브'를 29일 정식 출시한다(이미지=카카오)
카카오

올리브는 복잡한 오픈소스 라이선스 관리를 자동화하는 개발 지원 도구다. 자동으로 소프트웨어를 분석해 오픈소스를 사용했는지, 오픈소스 사용 조건이나 의무사항 등을 목록별로 정리해 제공한다.

자세한 내용은 기사 원문에서 확인하세요. : https://zdnet.co.kr/view/?no=20210628143239

SK텔레콤, 개발자와 소통하는 커뮤니티 ‘DEVOCEAN’ 론칭

Mon, 14 Jun 2021 00:00:00 +0000

SK텔레콤이 스타트업·대학 등 외부 개발자들과 소통하는 오픈 커뮤니티를 론칭하며 SK의 ICT 역량을 적극 공유에 나선다.

‘데보션’은 개발자들을 위한 영감의 바다(Developer’s Ocean)라는 뜻으로, 개발자들이 지식과 경허을 공유하는 커뮤니티를 ‘바다’에 비유했다.

SK텔레콤은 SK하이닉스, SK㈜C&C, SK브로드밴드, SK플래닛 등 SK ICT패밀리사 개발전문가들과 외부 개발인재간 소통과 기술 공유를 위한 디벨로퍼 릴레이션 채널인 ‘데보션’을 론칭했다. 사진=SK텔레콤
SK텔레콤

자세한 내용은 기사 원문에서 확인하세요. : https://www.fntimes.com/html/view.php?ud=202106140855478693645ffc9771_18

Dockerfile 배포 시 컴플라이언스 책임은 누구에게?

Tue, 04 May 2021 00:00:00 +0000

안녕하세요!

2021년 4월, 독일의 유명한 오픈소스 변호사인 Till Jaeger는 Dockerfile이 생성하는 Docker image내 포함될 오픈소스에 대한 라이선스 컴플라이언스 책임은 누구에게 있는가에 대한 글을 발표하였습니다. Till은 독일법과 유럽 연합 사법 재판소_CJEU의 판례를 근거로 Dockerfile 제공자가 라이선스 의무를 준수해야 한다고 설명하였습니다.

여기서는 Till의 영어 원본을 국문으로 번역하였습니다. 이해를 돕기 위해 이미지를 추가하였고, 군데군데 개인 의견을 인용구(높임말)로 작성하였습니다.

번역 오류나 문의는 이메일로 연락주시기 바랍니다. : haksung@sk.com

감수에 도움 주신 카카오의 Sean에게 깊이 감사드립니다. ^^

This paper was translated by Haksung Jang from the English version available at the Distribution of Dockerfiles: . The original document is licensed under CC-BY-4.0. The original author, Till Jaeger, has not reviewed this translation.

OSPO란?

Sun, 18 Apr 2021 00:00:00 +0000

This paper was translated by Haksung Jang from the English version available at the OSPO Definition. The original document is licensed under CC-BY-SA-4.0.

안녕하세요!

TODO Group¹은 Talk Openly, Develop Openly를 표방하며 협업을 통해 성공적인 오픈소스 프로젝트와 프로그램을 만들어가고자 하는 Linux Foundation 산하의 그룹²입니다. TODO 그룹에서는 오픈소스 가이드³, 도구⁴ 등을 함께 만들어서 공개하며 오픈소스에 관심 있는 누구나 활용할 수 있게 하고 있습니다.

기업 등의 조직이 오픈소스를 효과적으로 관리하고 사용하기 위해서는 OSPO_{Open Source Program Office}를 설립하여 개발자 교육, 컴플라이언스 보장, 커뮤니티 참여 및 구축, 오픈소스 공개, 코드 점검 등의 활동이 필요하다고 합니다. 이 글에서는 OSPO가 무엇이고, 어떤 역할을 하는지에 대해 TODO Group에서 정의한 글⁵을 옮겼습니다.

Elastic License 2.0 그리고 진화하는 오픈소스 라이선스

Sun, 28 Mar 2021 00:00:00 +0000

This paper was translated by Haksung Jang from the English version available at this white paper. The original author, Heather Meeker, has not reviewed this translation.

안녕하세요.

미국의 오픈소스 전문 변호사인 Heather Meeker가 2021년 3월 11일 공개한 Elastic License에 대한 White Paper를 기반으로 아래의 글을 작성하였습니다. 대부분 원글을 번역하는 방식이며, 제 의견은 인용구로 추가하였습니다.

참고로, Heather Meeker는 이 백서를 자신의 개인적인 견해임을 나타내면서도 일부 Elastic의 자금 지원이 있었다고 밝혔습니다. 그래서인지, 원글은 Elastic License에 호의적인 입장을 보입니다.

(조금 찾아보니, Elastic License 2.0을 Heather Meeker가 작성하였군요.)

여하튼 시대가 변하며 소프트웨어 배포 방식이 바뀌는 상황에 따라 상용 오픈소스 기업들이 개발과 사업을 병행하기 위해 어떤 라이선스 모델을 도입해야 할지 고민해야 했고, Elastic License가 나온 배경에 대한 한 측면을 이해하는 데 도움이 되는 글이라 생각합니다. 글에 오류가 있다면 언제든 연락해주세요. :-)

감수에 도움 주신 카카오의 Sean, Robin 그리고 LG전자의 김경애님에게 깊은 감사 드립니다.

기업별 Github 활동 순위와 라이선스 현황

Thu, 14 Jan 2021 00:00:00 +0000

EPAM, 2020년도 기업별 Github 활동 순위와 라이선스 현황 (OSCI)

Enterprise Software 개발 및 컨설팅을 하는 EPAM 에서는 Github 사용량을 측정하여 OSCI (Open Source Contributor Index) 이라는 랭킹 서비스를 제공하고 있습니다. 공개적으로 활용 가능한 Github 커밋 이벤트 데이터를 사용하여 상업 조직의 구성원들의 기여를 측정합니다. 대학, 연구기관 및 무료 이메일 공급자의 기여는 포함되지 않았다고 합니다. 10개 이상의 커밋을 수행한 기여자가 대상이며, 자체 연구한 알고리즘으로 활동량 점수를 측정한다고 합니다. 알고리즘은 OSCI Github 에 공개되어 있습니다.

OpenChain, ISO 표준 등록

Wed, 16 Dec 2020 00:00:00 +0000

지난 2020년 12월 15일, OpenChain 규격 2.1이 국제 표준인 ISO/IEC 5230:2020로 공식 Publication 되었습니다.

이에 대한 자세한 사항은 다음 기사를 참고하시기 바랍니다. : https://www.einpresswire.com/article/532735099/iso-iec-5230-2020

카카오 교육 자료 공개

Tue, 24 Nov 2020 00:00:00 +0000

Kakao 오픈소스 기술파트에서는 사내 개발자를 위한 오픈소스 교육자료를 누구나 열람할 수 있도록 공개하였습니다.

Download

교육자료는 다음 페이지에서 다운로드 받을 수 있습니다.

http://t1.kakaocdn.net/olive/assets/opensource_guide_kakao.pdf

NCSOFT 교육자료 공개

Mon, 23 Nov 2020 00:00:00 +0000

NCSOFT에서는 오픈소스의 공유 정신에 따라 사내 오픈소스 교육자료를 누구나 사용할 수 있도록 강의 교안(PPT)과 강의 스크립트를 GitHub에 공개하였습니다.

소프트웨어를 개발/배포하는 기업에서 사내 오픈소스 교육을 준비하면서 이 교안을 직접 사용하거나, 필요한 부분을 발췌/수정하여 사용할 수 있습니다.

교육자료에 대한 수정과 보완은 GitHub을 통해 누구나 참여할 수 있습니다.

Download

교육자료와 강의 스크립트는 다음 페이지에서 다운로드 받을 수 있습니다.

https://github.com/ncsoft/oss-basic-training/tree/master/source

Maintainer

Name	Company	Email
Peter Jiho Han	NCSOFT	yulica37@ncsoft.com
Dasom Han	NCSOFT	dasom12@ncsoft.com

License

CC-BY 4.0

Open Source Compliance in the Enterprise 요약 자료

Mon, 23 Nov 2020 00:00:00 +0000

Open Source Compliance in the Enterprise 책 소개

이 책은 Ibrahim Haddad가 저술하고 Linux Foundation에서 발간하였습니다.

기업에서 오픈소스 컴플라이언스 프로그램을 구축할때 고려해야 사항들을 자세히 설명하며 다음 링크에서 누구나 다운로드 가능합니다. : Download

한국어 요약

NCSOFT에서는 이 책의 주요 내용을 한글로 요약하였고 저자인 Ibrahim으로부터 허가를 받은 후 국내 기업의 오픈소스 담당자들이 참고할 수 있도록 공개하였습니다.

특히, 이를 GitHub에 공유하여 누구나 참고하고, 개선하여 계속 발전시킬 수 있게 하였습니다.

GitHub : https://github.com/ncsoft/osc-enterprise-ko/
License : CC BY 4.0
발표자료 : OSC-Enterprise-ko_Openchain_KWG_20200317_FN.pdf

기여자 현황

Name	Company	Email	Role
Dasom Han	NCSOFT	dasom12@ncsoft.com	Maintainer
Peter Jiho Han	NCSOFT	yulica37@ncsoft.com	Contributor

블로그 작성 방법

Sat, 29 Aug 2020 00:00:00 +0000

OpenChain Korea Work Group 웹사이트의 블로그는 오픈소스에 관한 글을 공유합니다.

OpenChain Korea Work Group의 멤버라면 누구나 글을 작성할 수 있습니다.

다음 페이지의 가이드를 참고하시기 바랍니다. : 블로그 작성 방법

샘플 블로그입니다.

Sat, 29 Aug 2020 00:00:00 +0000

Text can be bold, italic, or ~~strikethrough~~. Links should be blue with no underlines (unless hovered over).

There should be whitespace between paragraphs. There should be whitespace between paragraphs. There should be whitespace between paragraphs. There should be whitespace between paragraphs.

There should be no margin above this first sentence.

Blockquotes should be a lighter gray with a border along the left side in the secondary color.

There should be no margin below this final sentence.

Search Results

Mon, 01 Jan 0001 00:00:00 +0000

OpenChain KWG

1. OpenChain 표준

ISO/IEC 5230

1. 오픈소스 정책 (샘플)

1. 목적

(1) 정책의 목적(3.1.3.1)

1. 프로그램 설립

1.1 정책

FOSSology

주요 특징

2. OpenChain 인증

자체 인증

2. 관련 업무 정의 및 지원

2.1 접근성

SW360

3. OpenChain 리소스

3. 오픈소스 콘텐츠 검토 및 승인

3.1 SBOM (Software Bill of Materials)

4. 컴플라이언스 산출물 생성 및 제공

4.1 컴플라이어스 산출물

5. 오픈소스 커뮤니티 참여에 대한 이해

5.1 기여

ISO/IEC 5230

6. 규격 요구사항 준수

6.1 적합성

AI 에이전트 역분석 도구, 기업은 어디까지 허용할 수 있을까

CISA 2026 SBOM 최소 요소: 데이터 필드 7개에서 17개로, 무엇을 준비할 것인가

요약

미국 AI 행정명령(2026-06-02)이 기업 오픈소스 관리자에게 의미하는 것

EU 오픈소스 전략: 기술 주권을 위한 오픈소스의 제도화

AI가 만든 코드, 오픈소스 검사를 어디까지 해야 할까

한 가지 먼저 짚을 점

EU 사이버 복원력법(CRA) 취약점 보고 의무 — 2026-09-11 시행 대비 조사보고서

Rockchip과 FFmpeg의 라이선스 분쟁 사례

AVM 소송: LGPL-2.1 사용자 권리와 설치정보 제공 의무의 재조명

1. 사건 개요

Oracle과 Rimini Street 소송 사례로 알아보는 GPL 파생저작물 범위

들어가며

사건의 배경

PeopleSoft와 Rimini Street

한국 소프트웨어 기업이 알아야 할 EU의 3대 디지털 규제 핵심 내용

서론

To Mine or Not To Mine: 독일 법원이 AI 시대의 저작권 딜레마에 내린 판결

배경

중국 저작권 침해 소송 사례 “GPL 기반 소프트웨어 제품은 어차피 소스 공개 의무가 있으니 배껴도 되는 것 아닌가요?

소송 당사자

사건의 개요

또 다시 Elasticsearch 라이선스 변경, 기업의 대응 방안은?

서론: Elasticsearch 라이선스 배경

SPDX 3.0 소개와 기업 도입 전략

1. SPDX 3.0 소개

SPDX의 정의와 목적

SPDX 3.0의 주요 변경사항

프랑스 법원, 대형 통신사 Orange에게 GPL 위반으로 손해배상 판결

오프라인 모임 준비 checklist

모임의 준비

기업의 효과적인 오픈소스 관리 방안 (2) OpenChain Korea Work Group

OpenChain Korea Work Group

OpenChain KWG 정기 미팅

기업의 효과적인 오픈소스 관리 방안 (1) 글로벌 협력을 위한 OpenChain Project

Anaconda 꼭 사서 쓰세요. 아니라면 conda-forge!

그런데 Anaconda는 사서 쓰셔야 합니다.

Akka는 더 이상 오픈소스가 아닙니다.

Akka란?

라이선스 변경

SFC vs. Vizio 판결 겉핥기

References

1. 배경지식

이너소스 도입을 위한 과제와 효과

1. 오픈소스 Practice 주요 사항

상용 AI 서비스에 공개 Dataset을 사용해도 되나요?

SaaS로 서비스를 제공할 때에도 오픈소스 컴플라이언스가 필요한가요?

Log4j 2 보안 취약점 사태 (Log4Shell)

Log4j

경과

보도자료 (국내)

대응방안

대응 사례 (참고)

영향범위

NIPA, 공개소프트웨어의 활용을 위한 가이드 4종 발간

(1) 정책의 목적_(3.1.3.1)