2021

• SaaS로 서비스를 제공할 때에도 오픈소스 컴플라이언스가 필요한가요?
• Log4j 2 보안 취약점 사태 (Log4Shell)
• NIPA, 공개소프트웨어의 활용을 위한 가이드 4종 발간
• 중국 첫 GPL 소송 사례, VirtualApp
• GPLv2도 설치정보를 요구한다고?
• Dockerfile 배포 시 컴플라이언스 책임은 누구에게?
• OSPO란?
• Elastic License 2.0 그리고 진화하는 오픈소스 라이선스
• 기업별 Github 활동 순위와 라이선스 현황

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

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

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

미국의 저명한 오픈소스 전문 변호사인 Heather Meeker는 Open Source Compliance for SaaS Vendors라는 글을 게재하여 SaaS 공급업체가 주의해야 할 Open Source Compliance에 대해 설명하였는데요, 오늘은 이 내용을 소개하겠습니다.

1. Client Side로 배포되는 소프트웨어를 고려하라.

Heather는 먼저 Client Side Software에 대해 언급하였습니다. SaaS Platform에서는 대부분의 소프트웨어가 공급업체의 Server-side에 존재하지만, 일부 소프트웨어는 사용자의 컴퓨터(“Client-Side”)로 전달이 되어 동작하게 됩니다.

Heather는 SaaS 형태로 웹사이트 제작 기능을 제공하는 워드프레스를 예로 들어 설명하였습니다. Chrome 브라우저로 워드프레스에 접속하여 블로그를 제작하는 화면을 가정하겠습니다. 거기에서 control-u(맥북 환경에서는 Command + Option + U)를 누르면 page source code를 볼 수 있는데, 3천 라인 가량의 소스 코드가 있는 것을 볼 수 있습니다(물론 블로그 작성 기능을 구성하는 대부분의 소스 코드는 WordPress.com 측 서버에서 구동됩니다).

이러한 Client-side의 코드는 주로 웹페이지 내 입력 ‘form’에 날짜나 주소 등의 값이 유효한지 여부를 체크하는 등 단순한 로직 정도입니다. 이런 small task는 굳이 서버와 연동하느라 시간을 소요할 필요가 없습니다. 이런 Client-side의 코드는 주로 “scripting language” 코드이며, 대개 HTML, Javascript, CSS 입니다. 여기서 주목할 점은 이런 스크립트 코드는 브라우저에서 볼 수 있듯이 항상 소스 코드 형태로 전달이 된다는 겁니다. 그래서, LGPL 같은 Copyleft 라이선스가 적용된 코드라고 하더라도 별도로 소스 코드를 제공해야할 필요가 없습니다.

고지 내용 제공은 어떻게?

Heather는 그래도 고지 의무는 고려해야 한다고 설명하면서 한가지 문제를 제기합니다. 개발자들은 오픈소스인 HTML/CSS/Javascript를 사용할때 로딩 속도를 빠르게 하기 위하여 최소한의 코드만 남기기를 원하고, 이 때문에 코드 내 저작권, 라이선스 표시 부분을 지우는 경우가 많다는 겁니다. 그런데, LGPL과 같은 Copyleft가 적용된 소프트웨어를 배포할 때에는 소스 코드를 제공해야 할 뿐만 아니라 라이선스 전문도 함께 제공해야 합니다.

LGPL-2.1

1. … and distribute a copy of this License along with the Library.

그럼 LGPL인 Javascript 코드를 Client-side로 전달하면서 어떻게 LGPL 라이선스 전문을 전달해야 할까요?

Heather가 제안한 한가지 방법으로는 SaaS 시스템의 대시보드와 같은 화면 내 오픈소스 고지를 위한 페이지를 만들고 여기에 라이선스 전문을 보여주는 링크를 포함하는 것입니다.

하지만 Heather는 이 방법도 100% 라이선스 조건을 충족한다고 볼 수 있을지에 대해서는 다소 의문을 제기합니다. 사실 대부분의 오픈소스 라이선스의 고지 의무 조항은 웹서비스가 존재하기 훨씬 전에 만들어졌고, 당시의 프로그램 전달 방식만을 고려하여 고지 내용이 설치 프로그램과 함께 전달될 것으로 가정하고 있기 때문입니다.

MIT의 경우도 다음과 같이 요구합니다.

MIT

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

이런 조항을 고려하면, SaaS 시스템 내 별도의 웹페이지에서 라이선스 고지를 하는 방법도 충분하지는 않다는 주장이 있을 수도 있습니다. 물론, 이런 방법이라도 제공하는 것이 안하는 것보다는 훨씬 낫겠지만요. 🙂

Minified Javascript는 소스 코드 공개 방법으로 적절한가?

개발자는 Client-side로 전달하는 코드의 로딩 타임을 최소화 하기 위하여 가급적 코드 사이즈를 경량화합니다. 이를 위해 Javascript 코드 내 불필요한 주석을 제거하고, “white space”도 제거하는 등 Minify 처리를 합니다.

<script id=’wp-media-utils-js-translations’>
	( function( domain, translations ) {
		var localeData = translations.locale_data[ domain ] || 
			translations.locale_data.messages;
		localeData[“”].domain = domain;
		wp.i18n.setLocaleData( localeData, domain );
	} )( “default”, { “locale_data”: { “messages”: { “”: {} } } } );
</script>

예를 들어, 위의 코드를 Minify하면 다음과 같이 변환되고, 당연히 가독성은 떨어지게 됩니다.

<scriptid=’wp-media-utils-js-translations’>(function(domain,translations){varlocaleData=translations.locale_data[domain]||translations.locale_data.messages;localeData[“”].domain=domain;wp.i18n.setLocaleData(localeData,domain);})(“default”,{“locale_data”:{“messages”:{“”:{}}}});</script>

그런데, 소스 코드 공개를 요구 하는 오픈소스 라이선스에서는 ‘소스 코드’를 수정이 용이한 형태여야 한다고 정의하고 있습니다.

GPL-2.0

3. … The source code for a work means the preferred form of the work for making modifications to it.

그렇다면, LGPL인 Javascript 코드가 Client-side로 전달되면서 Minified된다면, 이는 소스 코드 제공의 의무를 준수한 것으로 볼 수 있을까요? Minified 상태로는 사용자가 수정이 곤란하기 때문에 Unminify 상태의 가독성 좋은 코드를 별도로 제공해야 하는건 아닐까요?

이에 대해 Heather는 Minified Javascfript 코드라도 대부분의 개발 도구에서는 자동으로 white space를 삽입하는 등의 가독성을 향상시켜주는 기능을 제공하기 때문에 문제가 되지 않는다고 말하고 있습니다. 즉, Minified Javascript 코드를 전달하는 것도 GPL, LGPL에서 소스 코드의 정의로 요구하는 “the preferred form of the work for making modifications”로 볼 수 있다고 설명하였습니다.

2. 네트워크 Copyleft 라이선스를 주의하라.

Heather가 언급한 SaaS에서의 또 다른 잠재적인 이슈는 네트워크 Copyleft 라이선스입니다. AGPL 등 일부 오픈소스 라이선스는 소프트웨어의 물리적인 배포가 없더라도 네트워크를 통해 사용자와 상호 작용(interacting)할 경우 Server-side 소스 코드의 공개를 요구합니다. Heather는 이런 라이선스를 “네트워크 Copyleft 라이선스"라고 불렀는데요, 대표적인 네트워크 Copyleft 라이선스인 AGPL-3.0은 13조에서 Remote Network Interaction에 대한 의무를 아래와 같이 정의합니다.

AGPL-3.0

13. Remote Network Interaction; Use with the GNU General Public License.

… if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.

즉, AGPL 소프트웨어를 다음 두가지 방식으로 사용한다면, 소스 코드를 제공해야 합니다.

1. 소프트웨어를 수정하고,
2. 사용자가 네트워크를 통해 소프트웨어와 상호작용 (interacting)하는 방식으로 사용

그럼, 수정하지 않고 사용하는건 얼마든지 가능한 것 아니냐고 반문할 수 있는데요, 개발자가 처음 AGPL-3.0 오픈소스를 도입하는 단계에서는 수정하지 않고 사용한다고 해도, 시간이 지나면서 수정해야만 하는 경우가 발생할 수 있습니다. 하지만 시간이 지나면서 누군가 다른 개발자가 AGPL 라이선스를 고려하지 않고 기능상, 성능상, 호환성 등의 여러 이유로 수정을 가할 수 있습니다. 따라서, 누군가 AGPL-3.0 오픈소스를 수정하지 않고 사용할테니 라이선스 의무 준수가 필요 없을 것이다라고 주장한다면 당장은 그럴듯해 보이지만, 미래의 변동 가능성까지 책임 질 수는 없습니다.

참고로, Google은 “AGPL Policy”를 만들어서 Google에서는 AGPL하의 코드를 사용할 수 없음을 분명히 하였습니다.

Google’s AGPL Policy

*WARNING: Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.

The license places restrictions on software used over a network which are extremely difficult for Google to comply with. Using AGPL software requires that anything it links to must also be licensed under the AGPL. Even if you think you aren’t linking to anything important, it still presents a huge risk to Google because of how integrated much of our code is. The risks heavily outweigh the benefits.*

Google은 다음과 같은 이유료 AGPL Policy를 만들었다고 설명합니다.

• AGPL은 AGPL 소프트웨어와 링크하는 모든 것도 AGPL로 라이선스를 부여할 것을 요구한다. → 바이러스 효과
• 이런 바이러스 효과가 발생하는 시점은 소프트웨어를 배포할 때 뿐만 아니라 사용자가 제품이나 서비스를 원격 네트워크 인터페이스를 통해 액세스 할 때도 포함한다.
• Google의 핵심 제품(Search, Gmail, Map, Youtube 등)은 사용자가 원격 네트워크 인터페이스를 통해 상호작용하는 서비스이기 때문에 엔지니어가 이런 서비스를 AGPL에 의존적으로 개발할 경우 상황은 심각해진다.
• 이런 상황을 고려했을때 Google은 AGPL의 네트워크를 통해 사용되는 소프트웨어에 대한 요구사항을 준수하기 매우 어렵다.

이와 같이 네트워크 조항을 포함하는 라이선스는 AGPL-3.0말고도 여러 라이선스가 있다고 Heather는 설명합니다.

• Server Side Public License
• Open Software License
• Non-Profit Open Source License
• Artistic 2.0
• Apple Public Source License
• RealNetworks Public Source License
• Reciprocal Public License
• Honest Public License
• Academic Free License [Note: this license is permissive. The others are copyleft.]

Heather는 대부분의 회사는 이러한 네트워크 Copyleft 라이선스를 위험도가 높은 라이선스로 분류하고 SaaS 개발에 사용하지 않는 정책을 갖고 있다고 말하였습니다.

사실, 저도 예전에는 AGPL-3.0은 수정한 경우에만 소스 공개 의무를 부여하기 때문에 수정하지 않고 사용하는건 문제가 없다고 생각했습니다. 그래서 굳이 회사에서 정책적으로 AGPL-3.0의 사용을 막을 필요까지는 없는 것 아닌가라는 입장이었습니다. 그런데, AGPL-3.0 오픈소스를 도입하는 시기에는 수정하지 않고 사용한다고 하더라도, 수년이 지나면서도 수정하지 않도록 보장할 수 있는 체계가 회사 내부에 갖춰져 있냐를 봤을때에는 수정하지 않겠다는 것을 장담할 수 없게 됩니다. 따라서, Google과 같이 기본 정책으로는 AGPL-3.0 오픈소스는 사용을 제한하는 정책을 가져가는 것이 라이선스 관리 측면에서 합리적이라고 생각합니다.

3. SaaS 코드도 언젠가는 배포해야 할 수 있음을 고려하라.

Heather는 SaaS 플랫폼의 서버 측 코드도 거의 항상 언젠가는 배포된다는 점을 고려하여 서버 측 코드에 대해서도 오픈소스 컴플라이언스를 고려해야 한다고 말합니다. SaaS 코드를 배포하게 되는 경우는 다음과 같습니다.

• SaaS 담당 조직의 매각
• SaaS 서버를 고객 서버로 이전
  • 금융, Health 등 강력한 규제 산업의 요구 사항으로 인해 서버 이전
  • 보안 이슈로 서버 이전
  • 국가 간 데이터 이동으로 발생하는 개인 정보 문제 방지를 위해 서버 이전 등
• 내부 SaaS 도구의 제품화 등

Heather는 이러한 상황이 발생할 수 있음을 고려하여 SaaS 서비스를 개발할 때에도 향후 배포될 경우를 고려하여 GPL 또는 AGPL 오픈소스와 자체 개발 코드를 결합하는 것을 피해야 한다고 설명합니다.

과도한 정책이라도 보시는 분들도 있을 것 같지만, 충분히 고려할 만한 주장이라고 생각합니다. 특히, 근래에 들어서 주로 서버에 사용하는 오픈소스가 라이선스를 변경하고 있는 추세를 고려하면 서버용 프로그램에 대해서도 Software BOM을 파악하여 관리하는 체계를 갖추는 것은 기업에 꼭 필요한 절차가 되고 있습니다.

과거에는 기업의 오픈소스 컴플라이언스 정책에서 외부로 배포하지 않고 내부 서버에만 사용하는 오픈소스인 경우에는 오픈소스 점검 대상에서 아예 제외시키기도 하였습니다. 하지만, (1) AGPL과 같은 네트워크 Copyleft 조항이 있는 오픈소스 라이선스나 (2) 오픈소스였다가 상용 소프트웨어러 라이선스 정책을 변경하는 추세를 고려하면 Server-side의 소프트웨어에 대해서도 라이선스 컴플라이언스 측면의 관리 체계가 필요해지고 있습니다. 기업은 이를 위한 정책, 절차를 개선하고, Server-side 소프트웨어에 대한 Bill of Materials를 자동으로 생성할 수 있는 도구를 도입해야 할 것입니다.

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

Apache Log4j 2에서 발생한 취약점(CVE-2021-44228, NVD)을 통해 악성코드 감염 등 추가 피해가 발생할 수 있어 전 세계적으로 긴급 보안 업데이트 조치 (2021.11.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)

보도자료 (국내)

• 2021.12.11 “컴퓨터 역사상 최악 취약점 발견” 전세계 보안업계 화들짝
• 2021.12.11 거의 모든 서버 위협하는 최악의 ‘로그4j’ 보안허점 발견
• 2021.12.11 “컴퓨터 역사상 최악의 취약점 발견” 보도에 국정원 “선제적 조치 취해”
• 2021.12.12 과기정통부, ‘치명적 보안 취약’ 오픈소스 ‘로그4j’ 긴급 보안조치 권고
• 2021.12.12 “최악의 보안 결함”..발칵 뒤집힌 IT업계
• 2021.12.12 전자신문, 피해 파악 어려워..SW 세부 내역 파악해야
• 2021.12.12 IT서버 해킹 우려에 ‘긴급 대응팀’ 가동
• 해외 기사는 “Log4Shell” 로 검색

대응방안

• Log4Shell에 연결된 보안 권고/공고(CVE-2021-44228)
• 2021.12.06 Apache 2.15.0 CVE-2021-44228 관련 내용 고지
• 2021.12.10 Spring, Log4J2 Vulnerability and Spring Boot (영문)
• 2021.12.11 KISA, Apache Log4j 2 보안 업데이트 권고
• 2021.12.12 과기정통부, Apache Log4j 2 웹 서비스 긴급 보안패치 권고 (가이드는 위 내용과 동일)

대응 사례 (참고)

• 2021.12.10 AWS, Apache Log4j2 Issue (영문)
• 2021.12.11 Cloudflare Security의 Log4j 2 취약점 대응 (영문)

영향범위

• 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 로 업데이트 예정

알려진 취약성 검사 스캐너

• Labrador Log4Shell 코드 레벨 점검 도구 (래브라도와 고려대 보안연구소 공동 개발)

• Huntress Log4Shell Testing Application

• Labrador Log4Shell 테스트

  • (Step1) Package Management를 통한 스캔 후, (Step2) Jar 파일 스캔 수행
  • Spring Boot 2.6.1 샘플 프로젝트(Github)로 테스트 (직접 생성하기)
    $java -jar LabradorLog4ShellDetector.jar -project [path]
  • Spring 기본 프로젝트 스캔 수행시 : 취약점 없음
  • Log4j2 로 로깅 시스템 전환 후

취약성 공격 방식

• log4shell 은 RCE(원격코드실행) 취약성으로 분류됩니다.
• 제로데이 Attack (공표되었지만 아직까지 패치되지 않은 보안 취약점을 이용한 공격) 위험이 있습니다.
• 상세 내용 참고 이미지 출처

정부, 오픈소스 사용실태 조사 검토

정부도 오픈소스 소프트웨어의 보안 수위를 높이는 방향을 고민하고 있다. 과기부 관계자는 “오픈소스가 워낙 많다 보니 앞으로 유사 사고가 발생할 가능성이 크다"며 “사용 실태조사 등 후속조치를 고민하고 있다"고 말했다.

(기사내용 발췌)

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

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

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

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

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

공개소프트웨어 라이선스 개요 및 소개, 의무사항 준수 방법, 저작권 및 특허권 관련 검토사항, 라이선스 관련 체크리스트, 관리방안, 주요 분쟁사례, 자주하는 질문 등 기업이나 조직에 적용할 핵심 내용을 파악하여 다양한 환경에서 활용 가능하도록 구성

공개소프트웨어 라이선스 가이드는 기업 및 조직의 개발자, 관리자들이 공개소프트웨어 라이선스에 대한 전반적인 개념과 주요 준수사항에 대해 보다 쉽게 이해하고 실무에 활용할 수 있도록 제반 검토사항에 대한 가이드를 제공한다.▲공개소프트웨어 개념 및 정의 ▲공개소프트웨어 라이선스 개념과 의무사항 ▲공개소프트웨어의 저작권 및 특허 이슈 ▲공개소프트웨어 라이선스 양립성 및 듀얼 라이선스 ▲배포 방식에 따른 공개소프트웨어 라이선스 체크리스트 ▲공개소프트웨어 라이선스 관리 ▲공개소프트웨어 라이선스 분쟁사례 ▲공개소프트웨어 라이선스 관련 지원에 대한 내용으로 구성된다.공개소프트웨어를 사용하는 사용자 관점에서는 동일한 공개소프트웨어를 사용하더라도 사용 라이선스와 사용형태, 배포 방식 등에 따라 검토 및 적용해야 할 의무사항이 차별화됨에 따라 본 가이드에서는 자신의 기업이나 조직에 적용할 핵심 내용을 파악하여 다양한 환경에서 활용할 수 있도록 각 구성 항목별로 이해에 도움을 주는 별도의 팁도 제시하였다.

공공 공개소프트웨어 거버넌스 가이드

📖공공 공개소프트웨어 거버넌스 가이드 다운로드

가이드공공부문에서 정보화사업의 ▷기획 단계 ▷계획수립 단계▷사업자 선정 및 계약 단계 ▷사업수행 단계 ▷검사 및 운영 단계 ▷성과평가 단계 등 각 단계별 공개소프트웨어 활용 시 확인해야 할 관련 법령·지침, 고려 및 점검 사항을 제공

공공 공개소프트웨어 거버넌스 가이드는 국내외의 공개소프트웨어 관련 정책 동향과 기술 동향을 수집하여 분석한 결과를 반영하고 국내 공공부문에서 정보화사업을 추진함에 있어 공개소프트웨어를 활용하고 관리할 때 필수적으로 확인해야 하는 관련 법령·지침 및 고려해야 할 실무 관점의 정보들과 접근법을 제공한다.각 장은 ▲정보화사업 공개소프트웨어 관리 필요성 ▲정보화사업 공개소프트웨어 관리로 구성된다.‘정보화사업 공개소프트웨어 관리 필요성’에서는 국내외 각국 정부의 공개소프트웨어 정책 및 활용 사례를 소개하고 정보화사업의 관련 법령 및 지침, 해설서를 정리하고 공개소프트웨어 관리를 위한 관련조항을 설명한다.‘정보화사업 공개소프트웨어 관리’에서는 ▷기획 단계 ▷계획수립 단계 ▷사업자 선정 및 계약 단계 ▷사업수행 단계 ▷검사 및 운영 단계 ▷성과평가 단계 등 단계별 기본 관리점검 프로세스 소개와 단계별로 실무담당자가 참고할 수 있는 지침 및 해설서 목록을 제공하며 공개소프트웨어 관리 점검을 위한 관리요소 및 검토사항 등을 제공한다.

기업 공개소프트웨어 거버넌스 가이드

📖기업 공개소프트웨어 거버넌스 다운로드

기업에서 소프트웨어 개발 및 공급 시 실무에서 활용 가능하도록 공개소프트웨어를 활용하는 세 가지 경우(사용/기여/공개)로 구분하여 설명하고, 마지막으로는 기업의 공개소프트웨어 거버넌스를 위해 필요한 조직의 구성 방안 제공

기업 공개소프트웨어 거버넌스 가이드는 기업에서 공개소프트웨어를 활용한 소프트웨어 제품 및 서비스의 개발과 출시가 증가함에 따라 공개소프트웨어 기반 소프트웨어 개발 및 공급 시 소스 관리 및 공급 정책, 컴플라이언스 프로세스, 관리 도구, 조직 구성 등 기업에서 공개소프트웨어 거버넌스를 수립에 필요한 가이드는 물론 기업의 입장에서 커뮤니티에 기여하는 방법, 공개하는 방법도 함께 설명한다.각 장은 ▲공개소프트웨어 사용하기 ▲공개소프트웨어 기여하기 ▲공개소프트웨어 공개하기▲OSPO(Open Source Program Office), 공개소프트웨어 프로그램 사무소로 구성된다.각 주제는 이해를 돕기 위해 기업 및 구성원의 입장에 따라 각각 기업 편과 개발자 편으로 나누어 설명한다. 기업 편은 공개소프트웨어 담당자가 정책과 프로세스를 구축하기 위해 알아야 할 사항을 중점적으로 다루고, 개발자 편에서는 기업에 속한 개발자가 공개소프트웨어를 활용하는 데에 필요한 사항을 설명한다.

개방형OS 도입가이드

📖개방형OS 도입가이드 다운로드

업무용 PC의 개방형OS 전환 시 필요한 개방형OS 소개, 종류, 도입 절차/범위, 유지관리, 적용 사례 등 소개하여 실무담당자가 개방형OS 도입을 검토함에 있어 전체적인 사업계획에 대한 가이드를 제시

개방형OS 도입가이드는 공개소프트웨어 관련 정책 중 최근 국내에서 활발하게 논의되고 있는 개방형OS 확산 정책과 관련하여 개방형OS를 도입하고자 하는 기관의 개방형OS에 대한 이해를 돕고 개방형OS 도입의 검토 및 실행과정에 유용한 자료로 활용될 수 있도록 실 도입 사례를 바탕으로 설명한다.각 장은 ▲개방형OS 개요 ▲개방형OS 도입 사례 ▲개방형OS 도입 사전 검토사항 ▲개방형OS 도입 사업추진 절차 ▲개방형OS 유지관리 프로세스 ▲개방형OS 도입 가이드 활용으로 구성된다.개방형OS 도입에 대한 다양한 레퍼런스 모델 및 사례 등을 바탕으로 전체적인 사업계획에 대한 가이드를 제시하고 실무담당자가 개방형OS 도입을 검토함에 있어 도입의 절차와 고려사항을 제공한다.

중국 첫 GPL 소송 사례, VirtualApp

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

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

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

요약

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

분쟁 주체

이 분쟁의 원고와 피고, 그리고 분쟁 대상 소프트웨어는 다음과 같습니다.

원고

원고는 Jining Luohe Network Technology Co., Ltd 이며, VirtualApp 저작권자입니다.

피고

피고는 모두 세 곳의 회사입니다.

1. Fujian Fengling Chuangjing Technology Co., Ltd.
   • Dim Sum Desktop 저작권 소유자
   • Dim Sum Desktop 공식 웹사이트 운영
2. Beijing Fengling Chuangjing Technology Co., Ltd. (Fujian Fengling의 모회사)
   • Dim Sum Desktop 개발사로 표시됨
3. Shenzhen Tencent Computer System Co., Ltd.
   • “Application Bao” (Dim Sum Desktop을 다운로드, 설치 및 운영하기 위한 서비스를 제공) 운영

분쟁 대상 소프트웨어

1. VirtualApp (원고 측 소프트웨어)

원고는 가상 Android 환경을 제공하는 소프트웨어인 VirtualApp을 개발하여 배포하였습니다.

• Gitee : https://gitee.com/mirrors/VirtualApp
• GitHub : https://github.com/asLody/VirtualApp

히스토리를 조금 더 자세히 살펴 보겠습니다.

1. 원고 회사의 설립자 중 한 명이자 VirtualApp의 Original Contributor인 Lody는 2016년 7월 7일, VirtualApp을 GitHub에 공개하였습니다.
2. 2016년 7월 8일, LGPL-3.0을 적용하였으며,
3. 2016년 8월 12일, GPL-3.0으로 라이선스를 변경하였습니다.
   • 당시 시점의 코드를 보면, Repository 내 GPL-3.0 라이선스 사본이 포함되어 있고, README 내 License 정보도 “GPL-3.0"으로 명시하고 있음을 확인할 수 있습니다.
4. 그런데, 2017년 1월 24일, 갑자기 “당신은 이 프로젝트를 무료로 사용할 수 있는 권한이 없다“는 안내가 추가됩니다.
   • 이후, 2017년 3월부터 7월까지 이 프로젝트를 상용으로 이용하기 위해서는 상용 라이선스 취득이 필요하다는 안내가 여러 차례 추가됩니다.
   • 이러한 라이선싱 정책 변화에 대해 중국 내 한 변호사는 Lody가 개발 초기에는 VirtualApp을 오픈소스 라이선스 하에 무료로 공개하였지만, 나중에 이를 이용하여 수익을 창출하려고 마음이 바뀐 것으로 추측하였습니다.
   • 다만, 이렇게 GPL로 공개한 오픈소스에 조건을 추가하는건 GPL에서 허용하지 않은 방식인데요, Lody는 오픈소스 라이선스에 대하여 제대로 이해하지 못하고 있었기 때문에 GPL-3.0에 위반하는 라이선싱 정책을 시도한 것으로 보인다고 중국 변호사는 언급한 바 있습니다.
5. 2017년 8월, Lody는 VirtualApp(원고)을 설립합니다. 본격적으로 VirtualApp으로 비즈니스를 하겠다는 거죠.
6. 그리고, Lody는 결국, 2017년 10월 29일, GitHub에서 오픈소스 라이선스를 제거합니다.
   • https://github.com/asLody/VirtualApp/commit/00f152f98a922ced0d858c31e1a9c2f0afb53ab6
     
7. 2017년 11월 8일, 원고는 VirtualApp v1.0에 대한 소프트웨어 저작권을 등록하여 등록증을 취득하고, 소프트웨어 저작권의 모든 권리를 향유하려고 합니다.
8. 2017년 12월 30일, VirtualApp을 상용으로 사용 시, 아래와 같이 반드시 상용라이선스 구매가 필요함을 알리고, 이후, 더 이상 GitHub Repo에 소스 코드를 업데이트하지 않았습니다.

"VirtualApp(중국명: Luo box)은 2017년 8월에 정식으로 설립되었습니다. 
VirtualApp을 상업적 목적으로 사용해야 하는 경우 반드시 QQ: 10890으로 
연락하여 상업용 라이선스를 구매하시기 바랍니다. 
VirtualApp의 코드를 상업적 이익, 내부 사용을 위해 자신의 코드로 사용하거나 
승인 없이 소프트웨어 시장에 업로드하는 경우 당사에서 직접 경찰에 신고(저작권 침해)
하여 귀하의 회사에 법적 소송 및 형사 책임이 발생합니다."

참고로, VirtualApp은 Lody가 주요 기여자이고, 이후 30여 명의 개발자가 추가로 기여하였습니다.

2. Dim Sum Desktop (피고 측 소프트웨어)

Dim Sum Desktop은 VirtualApp과 마찬가지로 가상 안드로이드 환경을 제공하는 소프트웨어이며, 피고 Fujian Fengling Chuangjing Technology Co., Ltd.가 개발하였습니다.

피고는 Dim Sum Desktop을 개발하면서 GitHub에 공개된 VirtualApp의 2017년 8월 16일자 버전을 받아서 포함하였습니다. 이 버전은 GPL-3.0이 적용된 상태이면서 (앞뒤가 맞지 않지만) 상업적 사용을 금지한다는 문구도 포함하고 있습니다.

2018년 9월, 원고는 “Dim Sum Desktop v6.5.8"이 VirtualApp V1.0의 코드를 사용하고 있음을 확인하였습니다.

• 두 소프트웨어 간 비교 가능한 코드 421개 중 다음과 같은 유사성을 발견하였습니다.
  • 308 codes - substantial similarity
  • 27 codes - high similarity
  • 78 codes - general similarity

청구 취지

원고는 2019년 아래와 같은 청구 취지로 소송을 제기하였습니다.

1. 피고 Fujian Fengling Company와 피고 Beijing Fengling Company는 즉시 원고의 컴퓨터 소프트웨어 저작권 침해를 중단할 것
   • 즉, 인터넷을 통한 모든 버전의 “Dim Sum Desktop” 소프트웨어 다운로드, 설치 및 운영 서비스 제공을 즉시 중단해야 함
2. 피고 Fujian Fengling Company와 피고 Beijing Fengling Company는 원고에게 2천만 위안의 경제적 손실을 배상할 것
3. 피고 Fujian Fengling Company와 피고 Beijing Fengling Company는 침해에 대해 원고에게 50만 위안의 합리 비용을 배상할 것 _{compensate the plaintiff for a reasonable fee of 500,000 yuan for stopping the infringement}
4. 피고 Fujian Fengling Company와 피고 Beijing Fengling Company는 이 case에 대한 소송 비용을 부담할 것

법원 판결

2021년 4월, 법원은 이 사건이 컴퓨터 소프트웨어의 저작권 침해에 관한 분쟁이고 오픈소스와 관련된 문제라고 판결하며 다음과 같은 쟁점에 대한 의견을 제시하였습니다.

쟁점 1. GPL-3.0의 법적 효력 여부

법원은 GPL-3.0이 계약적 성격을 띠고 라이선스 제공자와 사용자 간의 저작권 계약으로 판단할 수 있으며 중국 ‘계약법’의 조정 범위에 해당한다고 판단하였습니다. 더불어 GPL-3.0 위반에 대한 불법 행위 책임을 아래와 같이 설명하였습니다.

GPL-3.0 위반에 대한 불법 행위 책임

• 저작권법은 저작권자의 배타적 권리를 보호함
  • 복제, 수정, 배포 등의 권리는 저작권자에게만 있음 (저작권자 외에는 “공정 이용"의 범위 내에서만 저작물을 사용할 수 있음)
  • 누구든지 허가 없이 이런 행위를 하는 것은 침해에 해당함
• GPL-3.0 8. Termination
  • GPL-3.0의 사용 조건을 위반하는 경우 GPL-3.0을 통해 얻은 권한은 자동으로 종료됨
  • “You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License”
• 중국 민법 총칙 제158조
  • “민사법률행위는 조건이 있을 수 있다… 해제 조건이 있는 민사법률행위는 조건이 충족되면 무효”라고 규정
• 오픈소스 소프트웨어의 특성상 GPL-3.0서에 명시된 사용조건(소스코드 공개, 저작권 / 수정 정보 표시 등)은 라이선스 제공자가 사용자가 이를 사용할 수 있도록 하기 위한 전제조건임
  • 사용자가 사용 전제조건을 위반한 경우 라이선스 제공자와 사용자 간의 GPL-3.0 계약은 자동으로 해지
  • 계약에 따른 사용자의 라이선스는 즉시 종료됨
  • 이후 사용자가 수행하는 복제, 수정, 배포 등의 행위는 권리의 상실로 인한 침해에 해당함

쟁점 2. 원고가 이 소송을 제기할 권리가 있는지 여부

법원은 GitHub에서 여러 기여자가 만든 저작물에 대해 소유권의 성격(예: 단독저작물, 공동저작물, 결합저작물 등)을 명확하게 설명하지는 않았습니다. 다만, 원고가 VirtualApp에 대한 저작권 등록을 했다는 등의 이유로 원고가 저작권을 가지며, 다른 기여자의 동의 없이 소송을 제기할 권리가 있다고 판단했습니다.

1. 코드 호스팅 웹사이트의 업로드 기록과 인증 내역에 따라 원고가 VirtualApp의 저작권 소유자임을 입증할 수 있음
2. 원고는 소송을 제기하는데 기여자의 동의 또는 승인 없이 소송을 제기할 권리가 있음
   • 원고의 주주인 Lody는 프로젝트 Owner로서 원고 주장의 근거가 되는 GitHub에 VirtualApp 초기버전의 소스 코드 중 총 31,097줄을 공개함.
   • 기여자는 GPL-3.0에 따라 VirtualApp 프로젝트에 자신의 소스 코드를 업로드하고, 라이선스도 부여함.
     • 이는 자신이 기여한 기여물에 대한 라이선스를 프로젝트 소유자 및 기타 사용자에게 부여하는데 동의한 것으로 간주.
   • 만약, 모든 기여자의 만장일치 동의 또는 승인이 필요하게 요구한다면 실제로 권리 보호 조치를 시작조차 못하게 될 것임. 이는 오픈소스 프로젝트의 소송 권리 보호에 도움이 디지 않을 것.
   • 즉, 원고는 소송을 시작하기 위해 기여자의 동의나 승인이 필요하지 않음
3. GPL-3.0은 라이선스 제공자가 사용자에 대한 특허권을 주장하는 것을 제한할 뿐 라이선스 계약을 위반한 사용자에 대한 저작권 주장을 제한하지 않음 
   • 따라서 원고의 소송은 분쟁 해결 방식에 관한 GPL-3.0 합의를 위반하지 않았다고 볼 수 있음

다만, 법원은 원고가 VirtualApp을 Relicense할 권리가 있는지에 관해서는 판단하지 않았습니다. 또한, 다른 기여자의 기여물까지 포함하여 Relicense함으로써 GPL-3.0을 오염시킨 부분에 관해서도 판단하지 않았습니다.

쟁점 3. 피고의 행위가 원고의 저작권을 침해했는지 여부

법원은 VirtualApp의 “상용 사용 금지 문구"가 GPL-3.0 (7조 Additional Terms, 10조 Automatic Licensing of Downstream Recipients)을 위반한다고 지적하며, 여전히 GPL-3.0 라이선스가 우선한다고 판단하였습니다.

1. 원고는 VirtualApp을 오픈소스 버전과 상용버전으로 나누고, 후속 오픈소스 버전에서 “GPL-3.0” 라이선스를 삭제함
   • 이와 별도로 원고는 오픈소스 버전의 VirtualApp을 권리 근거로 주장함. 따라서, VirtualApp의 오픈소스 버전과 상용버전의 관계 및 영향을 판단할 필요는 없음
   • GPL-3.0에 따르면 GPL-3.0을 따르는 이전 버전의 파일은 후속 버전에서도 여전히 GPL-3.0에 구속됨
2. GPL-3.0은 사용자가 상업적 사용을 수행할 수 있도록 허용하며, 라이선스 제공자가 이를 제한할 수 없음
   • 따라서, 법원은 원고의 다음 주장을 지지하지 않음 : “Dim Sum Desktop을 상용화하는 것은 GPL-3.0 위반임?”
3. 피고가 “Dim Sum Desktop” 앱(V6.5.8)이 GPL-3.0을 따라 소스 코드를 무료로 공개해야 하지만 피고 Fujian Fengling Company가 이를 이행하지 않았음
   • 이에 따라 GPL-3.0 8조 및 중국 민법 일반원칙 제158조에 따라 피고 Fujian Fengling Company가 획득한 권한은 자동 종료됨
   • 따라서, 피고 Fujian Fengling Company의 VirtualApp 복사, 수정 및 배포는 권리 출처 상실로 인한 침해에 해당함

다만, 법원은 GPL-3.0 8조의 “라이선스 복원 조항” (저작권자가 위반 사실을 알렸을 때 위반 통지를 받은 게 처음이고, 30일 이내에 위반 사항을 시정 시 라이선스 영구 복원)에 대한 언급은 없었습니다. 중국의 한 변호사는 “원고가 피고에게 사전에 위반 사실을 통지하였는지?”, “사전 통지 없이 그냥 바로 소송을 제기한 것은 아닌지?”, “그렇다면 아직 ‘30일 내 시정 시 라이선스 영구 회복’의 기회가 남아있는 것인지?” 등이 궁금하다고 언급하기도 하였습니다. (소송까지 가는 순간 통지한 걸로 봐야하지 않을까요?)

쟁점 4. 침해 사실 확인 시 피고의 법적 책임 범위

원고는 피고의 이익에 기반한 손해배상액 산정을 요청하였습니다. 하지만 법원은 법정손해배상금(statutory damages)에 근거하여 배상금을 정한 것으로 보입니다.

• 피고 Fujian Fengling Company는 “Dim Sum Desktop” 앱(V6.5.8)의 개발자, 운영 및 퍼블리셔로서 법에 따라 VirtualApp의 저작권 침해를 중지할 책임이 있음
  • 피고 Fujian Fengling Company가 피고 Beijing Fengling Company의 전액 출자 자회사라는 사실에 비추어 볼 때, 두 피고가 공동으로 불법 행위 책임을 부담한다는 원고의 주장은 합법적이며 법원의 지지를 받음
• 피고 Tencent는 “AppBao 공식 웹사이트"에서 침해 가능성에 대한 관련 규칙과 불만 제기 채널을 마련하고 고소된 소프트웨어를 즉시 제거함
  • 원고는 또한 피고 Tencent에 대해 구체적인 불만을 제기하지 않았음
  • 따라서 피고 Tencent는 법적 책임을 질 필요가 없음
• 보상 문제
  • 원고는 피고 Fujian Fengling Company와 피고 Beijing Fengling Company의 침해 이익을 기반으로 계산하였다고 주장함
  • 법원은 배상액을 50만 위안으로 결정함

50만 위안은 저작권 침해 법정손해배상액의 최고액 수준이라고 합니다.

마무리

그동안 중국은 저작권법 위반에 관대하다는 인식이 많았는데, 영문을 기반으로 한 오픈소스 라이선스의 법적 효력을 인정하고, 라이선스 위반을 저작권 침해로 판결한 점이 인상적이었습니다. 기업은 오픈소스 라이선스 의무를 준수하기 위한 정책과 프로세스를 갖추어야 이러한 분쟁에 휘말리는 위험을 최소화 할 수 있을 것입니다.

피고는 사건을 대법원에 상고한 것으로 알려졌습니다. 피고가 항소심에서 어떤 주장을 펴나갈지 궁금합니다. :)

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

안녕하세요.

미국의 저명한 오픈소스 라이선스 전문 변호사인 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

감사합니다. :)

Abstract

GPLv3_{GNU General Public License version 3} 에서 추가된 주요 특징 중 하나는 소프트웨어 배포 시 소스 코드뿐만 아니라 ‘설치 정보’를 제공해야 한다는 요구사항이다. 이는 GPLv2에 존재하는 loophole (Tivoization)을 해결하기 위해 GPLv3에 새롭게 추가되었다. 그런데 최근에 이 설치 정보 요구 사항이 GPLv2에서도 요구한다고 봐야한다는 주장이 제기되었다.

이 글에서는 GPLv3에 ‘설치 정보’ 요구 사항을 포함하게 된 역사적 근거를 검토하고, 이 요구 사항은 GPLv2가 아닌, GPLv3에서 새롭게 적용된 것임을 설명한다. 또한, GPLv2 텍스트 분석을 통해서도 같은 결과를 도출한다.

1. Introduction

1991년 FSF_{Free Software Foundation}에서 공개한 GPLv2_{GNU General Public License, version 2}¹은 Copyleft (혹은 Reciprocal) 라이선싱 방식을 채택하였다. Copyleft 방식은 정해진 시기에 지정된 방식대로 소스 코드를 공개하고, 소프트웨어를 재배포할 때에는 동일한 라이선스 적용을 요구한다. 이는 소프트웨어가 “free"로 유지되도록 보장하는 최고의 수단이며, 이는 오늘날에도 여전히 많은 사람에게 인정되고 있다². 여기서 “free"는 다음과 같다³.

• 수정 사항을 공유할 수 있는 자유
• 사용자가 코드로 수행할 수 있는 작업에 대한 자유
• 사용자가 원하는대로 코드를 수정할 수 있는 자유

그럼에도 불구하고 2005년, FSF는 GPLv2를 출시할 당시 고려하지 못한⁴ 법률적⁵ 그리고 기술적⁶ 문제를 해결하기 위해 라이선스 변경의 필요성을 인식하였다. 이에 따라 FSF는 2006년⁷부터 2007년까지 GPL의 신규 버전을 만들기 위해 대규모의 협업과 다국적 노력을 시작하였으며, 2007년 6월 29일 GPLv3를 공개하였다⁸.

2. GPLv3의 ‘설치 정보’ 요구 사항

GPLv2가 광범위하게 사용되던 15년 동안 제기된 문제와 우려를 해결하기 위해 GPLv3에는 수많은 기능이 추가되었다. 그중에서도 가장 주목할만한 (그러면서도 가장 논란이 되는⁹) 부분은 (1) ‘설치 정보’를 정의한 조항과 (2) GPLv3에 따라 라이센스가 부여된 소프트웨어를 ‘전달_convey¹⁰‘할 때 어떤 상황에서 설치 정보를 제공해야 하는지를 명시한 조항이다. GPLv3에서의 ‘설치 정보’ 요구 사항이 GPLv2에서 요구하는 요소를 어느 정도 포함하는지, 어느 것은 포함하지 않는지를 이해하려면 두 라이선스에서의 표현과 역사에 대한 자세한 검토가 필요하다.

GPLv3, Section 6¹¹(GPLv3 코드를 “Non-Source Form으로 Convey"시 의무 사항 명시)에서는 ‘설치 정보’를 위해 특별히 공개해야 할 의무를 정의한다.

“‘Installation Information’ ... means any methods, procedures, authorization keys, or other 
information required to install and execute modified versions of a covered work ... from a 
modified version of its Corresponding Source. The information must suffice to ensure that the 
continued functioning of the modified object code is in no case prevented or interfered with 
solely because modification has been made.”

GPLv3의 ‘설치 정보’ 정의에서 주목할만한 것은 ‘인증키_{authorization key}’ 및 ‘기타 정보’를 구체적으로 언급한 점이다. 이는 GPLv3를 만드는 프로세스가 시작될 당시 FSF가 우려했던 GPLv2 소프트웨어의 특정 남용 사례를 해결하기 위하여 포함된 것이다¹².

GPLv3의 ‘설치 정보’ 의무에 대한 자세한 요구 사항이나 GPLv3에서 설치 정보 제공을 요구하는 방법과 시기는 이 글의 주제를 벗어난다¹³. 그럼에도 불구하고 설치 정보 의무가 GPLv2에서도 해당한다고 주장할 수 있는 유사 부분은 무엇인지, 설치 정보 의무가 GPLv3에만 있는 고유한 부분임을 입증하는 근거는 무엇인지, 또 이런 내용이 어떤 과정을 통해 채택되었는지에 대한 일반적인 이해가 필요하다. 따라서 GPLv3에 ‘설치 정보’ 의무가 추가되었던 역사적 배경과 GPLv3에 추가된 특정 표현이 무엇인지, 해당 표현이 GPLv2에 언급된 의무들과 어떻게 다른지 이해하는 것이 중요하다.

3. ‘설치 정보’ 요구사항의 역사적 배경: ‘Tivoization’

2006년경 GPL의 새로운 버전인 GPLv3가 제안되었을 무렵, FSF는 ‘software freedom’ 개념을 잠재적으로 훼손할 수 있는 관행에 대한 우려를 나타냈었다. FSF는 이 관행을 ‘Tivoization¹⁴‘이라고 명명하였으며, 당시 FSF는 DVR_{digital video recorder} 회사인 TiVo가 사용자의 자유를 침해한다고 보았다.

2000년대 중반, TiVo의 특정 DVR 하드웨어 디바이스에는 GPLv2 라이선스인 Linux 커널이 설치되어 있었다. 이 디바이스에는 TiVo 하드웨어 장치에 설치할 Linux 커널 버전을 확인하는 메커니즘이 포함되어 있었다. 이 유효성 검사 메커니즘은 체크섬 또는 암호화 해시 함수를 사용하여 장치에 설치된 커널 버전과 비교하였고, 설치하려는 버전이 특정 체크섬 또는 암호화 해시¹⁵와 일치하지 않으면 해당 버전의 Linux 커널 설치를 거부하였다. 이러한 방식으로 TiVo 디바이스는 (하드웨어 제조업체로써 내장된 체크섬 또는 해시값에 대한 필요한 정보를 가진 유일한 주체인) TiVo만 디바이스에 Linux 커널의 인증된 버전을 설치할 수 있도록 허용하였다. TiVo 디바이스 사용자(예: 디바이스를 구입한 고객)가 디바이스에 설치된 커널의 소스 코드를 가져와서 해당 커널을 수정한 후 재설치하려면 수정된 커널로는 체크섬 또는 해시가 달라지게 되므로 수정된 커널이 다시 설치 또는 실행되지 않게 되었다¹⁶.

이에 따라 FSF는 2006년, GPLv2 소프트웨어의 수정 버전을 기존 장치에 재설치할 수 없다는 것은 사용자가 소프트웨어에 대해 가져야 하는 자유를 침해하는 것으로 여겼고, 이 관행을 매우 경멸적인 용어로 설명하는 것을 주저하지 않았다.

      “A tyrant is a malicious device that refuses to allow users to install a different operating system or a modified operating system. These devices have measures to block execution of anything other than the ‘approved’ system versions.”¹⁷

4. 역사적 분석: GPLv3의 ‘설치 정보’ 의무와 GPLv2와의 관계

FSF는 ‘Tivoization’의 (수정한 바이너리를 재설치할 수 없게 하는) 관행에 대해 오랫동안 반대해 왔지만, GPLv3 초안 작성 중, FSF의 회장, 수석 변호사 및 Executive Director의 성명을 통해 이러한 관행이 GPLv2에서는 허용될 수 있다는 점도 분명히 했다.

      “[T]he Tivo itself is the prototype of [T]ivoisation. The Tivo contains a small GNU/Linux operating system, thus, several programs under the GNU GPL[v2]. And, as far as I know, the Tivo company does obey GPL version 2. … [T]he trouble begins because the Tivo will not run modified versions, the Tivo contains hardware designed to detect that the software has been changed and shuts down.”¹⁸

      “TiVo is a provider of hardware and software …. Our concern with them is that they have rights as users, but they should respect the rights of the users to whom they sell. Having a personal video recorder … which won’t run software if you modify the box … is not user-respecting conduct. (TiVo) complied with GPL 2 by the skin of its teeth.”¹⁹

      “TiVoization is described by Peter Brown [Executive Director of FSF in 2006-07 during drafting of GPLv3] as circumventing GPL2 ‘in spirit, not technically.’”²⁰

이러한 차이(‘Tivoization’을 금지하는 GPLv3와 허용하는 GPLv2간의 차이)는 Linux Kernel의 저작자인 Linus Torvalds가 GPLv3으로 라이선스를 변경하지 않고 ‘GPLv2 only’로 유지하게 된 결정적인 이유였다.

      “’The FSF is trying to make some things no longer permissible under the GPLv3 that the GPLv2 left open, and I just happen to think that those things were better off being left open.’”²¹

      “‘I don’t think the GPL v3 conversion is going to happen for the kernel, since I personally don’t want to convert any of my code.’ … ‘I think it’s insane to require people to make their private signing keys available, for example. I wouldn’t do it,’ [Torvalds] said.”²²

      “[If] you can not install or run your changes on somebody else’s hardware … it in no way changes the fact that you got all the source code, and you can make changes (and use their changes) to it. That requirement has always been there, even with plain GPLv2. You have the source. The difference? The hardware may only run signed kernels. The fact that the hardware is closed is a hardware license issue. Not a software license issue. I’d suggest you take it up with your hardware vendor, and quite possibly just decide to not buy the hardware. Vote with your feet. … [I]t’s important to realize that signed kernels that you can’t run in modified form under certain circumstances is not at all a bad idea in many cases.”²³

GPLv3의 ‘설치 정보’ 요구사항에 대해 Torvalds의 의견은 여러 주요 커널 개발자들에 의해 아래와 같이 공유되었다²⁴. Torvalds는 10년이 지난 후에도 일관된 입장을 유지했으며, 이는 오늘날까지 Linux Kernel이 ‘GPLv2 only’ 라이선스를 유지하고 있는 이유 중 하나이다²⁵.

      “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.”²⁶

FSF는 GPLv3를 만들고 공개하는 과정에서 GPLv2와는 달리 GPLv3에서는 ‘Tivoization’을 막을 수 있는 내용을 추가하고 있음을 분명히 하였다.

      “There are several primary areas where version 3 is different from version 2. One is in regard to [T]ivoisation.”²⁷

      “The Tivo includes some GPL-covered software. …[Y]ou can get the source code for that, as required by the GPL … and once you get the source code, you can modify it, and there are ways to install the modified software in your Tivo and if you do that, it won’t run, period. Because, it does a check sum of the software and it verifies that it’s a version from them and if it’s your version, it won’t run at all. So this is what we are forbidding, with the text we have written for GPL version three. It says that the source code they must give you includes whatever signature keys, or codes that are necessary to make your modified version run.”²⁸

FSF는 (GPLv3이 처음 제안되었을 때부터 이 글이 발표되는 날까지 계속해서) 실제로 GPLv3에는 GPLv2에 포함된 어떤 요구 사항보다 광범위한 ‘설치 정보’ 요구 사항에 대한 정의가 있음을 분명히 하였다.

      “GPLv2 did not address the use of technical measures to take back the rights that … GPL[v2] granted, because such measures did not exist in 1991 [when GPLv2 was written], and would have been irrelevant to the forms in which software was then delivered to users. … GPLv3 must address these issues: free software is ever more widely embedded in devices that impose technical limitations on the user’s freedom to change it.”²⁹

      “Does GPLv2 have a requirement about delivering installation information?…

      “GPLv3 explicitly requires redistribution to include the full necessary ‘Installation Information.’ GPLv2 doesn’t use that term, but it does require redistribution to include scripts used to control compilation and installation of the executable with the complete and corresponding source code. This covers part, but not all, of what GPLv3 calls ‘Installation Information.’ Thus, GPLv3’s requirement about installation information is stronger.”³⁰

Richard Stallman은 소프트웨어 개발자에게 GPLv2의 기존 문제를 해결하기 위해 라이선싱 정책을 GPLv3으로 “upgrade"할 것을 호소하였고, 개발자가 GPLv3으로 전환해야 하는 첫 번째 이유로 설치 정보 요구 사항이 새롭게 도입되었음을 언급하였다.

      ““Keeping a program under GPLv2 won’t create problems. The reason to migrate is because of the existing problems which GPLv3 will address.

      “One major danger that GPLv3 will block is tivoization. Tivoization means computers (called “appliances”) contain GPL-covered software that you can’t change, because the appliance shuts down if it detects modified software. The usual motive for tivoization is that the software has features the manufacturer thinks lots of people won’t like. The manufacturers of these computers take advantage of the freedom that free software provides, but they don’t let you do likewise.³¹

5. GPLv2의 소스 코드 공개 의무

1991년 공개된 GPLv2와 같은 Copyleft 라이선스의 가장 주목할만한 특징 중 하나는 GPLv2의 조건에 따라 라이선스가 부여된 코드를 배포_{distribute[s]}³²하는 모든 개인이나 단체는 ‘소스 코드’³³를 제공해야 하는 의무가 있다는 것이다. GPLv2의 Section 3은 GPLv2하의 코드가 object 혹은 executable code form으로 배포되는 경우 반드시 제공해야 하는 ‘소스 코드’의 구성 요소를 구체적으로 정의한다³⁴.

“The source code for a work means the preferred form of the work for making modifications to it.
For an executable work, complete source code means all the source code for all modules it 
contains, plus any associated interface definition files, plus the scripts used to control 
compilation and installation of the executable.”

소스 코드를 제공해야 하는 의무에 대한 설명은 주로 컴퓨터 프로그래밍에서의 ‘소스 코드’가 무엇인지에 대한 일반적인 상식과 연결해서 이해할 수 있다.

      “Source Code: … The form in which a computer program (software) is written by the programmer. Source code is written in some formal programming language which can be compiled automatically into object code or machine code or executed by an interpreter.”³⁵

GPLv2에는 또한 라이선스의 ‘소스 코드’ 정의에 해당하는 다른 두 항목도 포함하고 있다.

• ‘associated interface definition files’
• ‘scripts used to control compilation and installation of the executable’

GPLv2의 공개 의무가 GPLv3의 공개 의무와 어떻게 다른지 이해하기 위해서는 이러한 조항의 의미를 검토하는 것이 필요하다.

6. 텍스트 분석: GPLv3의 ‘설치 정보’ 의무와 GPLv2 의 소스 코드 의무

위에서 논의한 바와 같이, executable code 배포에 대한 GPLv3의 공개 의무에는 ‘Corresponding Source’³⁶와 ‘설치 정보’³⁷가 모두 포함된다.

“[A]ll the source code needed to generate, install, and (for an executable work) run the object 
code and to modify the work, including scripts to control those activities.”

“[A]ny methods, procedures, authorization keys, or other information required to install and 
execute modified versions of a covered work ... from a modified version of its Corresponding 
Source.”

GPLv3의 원래 초안에서는 “Corresponding Source"의 정의 내에 인증키를 제공해야 하는 의무가 포함되어 있었다³⁸. 그러나 인증키와 같은 데이터를 소스 코드와 혼용하여 정의하는 것에 대한 반대 의견이 있었고, 이에 따라 FSF는 인증키 요구 사항을 다른 section으로 옮겼다.

      “We have moved the technical restrictions provisions from section 1, where they formed part of the definition of Corresponding Source, to section 6, where they are presented as a condition on the right to convey object code works. Some critics of the provisions in our earlier drafts focused on what they regarded as an inappropriate equation of cryptographic keys with source code. Placing the requirements in section 6 should make their purpose and reasonableness more evident.”³⁹

따라서, GPLv3의 초안 변경 단계에서 FSF는 ‘설치 정보’ 요구 사항이 GPLv2에 존재하다가 GPLv3에도 포함된 ‘Corresponding Source Code’ 의무를 넘어서는 별도의 의무임을 인식하고 인정한 것이다.

GPLv2의 소스 코드 공개 의무는 다음과 같다⁴⁰.

“For an executable work, complete source code means all the source code for all modules it 
contains, plus any associated interface definition files, plus the scripts used to control 
compilation and installation of the executable.”

GPLv2의 ‘corresponding source code’ 요구 사항 내에서 GPLv3의 ‘설치 정보’ 요구 사항과 유사한 부분이 있다면, 이는 별도로 명시된 아래의 두 가지 항목에 대한 것이다.

• ‘any associated interface definition files’
• ‘scripts used to control compilation and installation of the executables.’

‘interface definition file’은 컴퓨터 프로그래밍에서 흔하게 사용되는 용어이다(GPLv2에서는 이 용어에 대한 더 자세한 정의가 없다). 특정 소프트웨어의 프로그래밍 인터페이스에 대한 attribute와 definition을 포함하는 별도의 파일로 해석할 수 있다⁴¹. GPLv2의 이러한 요구 사항이 수정된 바이너리의 설치 또는 실행을 허용하는데 필요한 인증키나 체크섬 또는 기타 정보를 제공해야 하는 의무를 부과하는 것으로 보이지는 않는다. 대신, 배포한 바이너리에 대한 인터페이스를 이해하는데 필요한 정보를 공개할 것을 요구하는 것이다(이는 공개된 소스 코드만으로는 알아내기 어렵기 때문).

반면에, 두 번째 항목인 executable을 컴파일하고 설치하는데 사용되는 script는 분명 GPLv2 대상 executable의 설치와 관련된 자료이다. 다만, 이 요구 사항은 컴퓨팅에서 일반적으로 의미하는 ‘script’ 자체에 대한 것이다.

      “A computer script is a list of commands that are executed by a certain program or scripting engine. Scripts may be used to automate processes on a local computer …. Script files are usually just text documents that contain instructions written in a certain scripting language. … [W]hen opened by the appropriate scripting engine, the commands within the script are executed.”⁴²

      “Script[:] … a sequence of instructions or commands for a computer to execute … especially … one that automates a small task (such as assembling or sorting a set of data).”⁴³

Installation script⁴⁴는 일반적으로 특정 장치에 특정 프로그램을 설치하는 프로세스를 자동화하는데 사용하는 작고 간단한 프로그램이다⁴⁵.

따라서, 텍스트 해석의 관점에서, 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’ 요건에 의해 설치 정보를 제공해야 한다고 주장하기는 어려울 것이다.

7. 설치 정보 요구 사항을 GPLv2로 Backporting

어떤이는 GPLv3의 전체 ‘설치 정보’ 정의 부분을 GPLv2의 소스 코드 의무 부분 내에 backporting하려고 하기도 하는데, 이런 노력은 역사적, 텍스트 해석적으로 잘못된 결과를 초래한다. 완전한 전체 ‘설치 정보’ 정의를 GPLv2의 Section 3에 포함했다고 가정해보자. 그런데 그렇게 하는 순간 딜레마에 빠지게 된다. GPLv3의 ‘설치 정보’ 요구 사항은 의무가 적용되는 대상이 특정 제품으로 한정되어 있다. 바로 ‘User Product’⁴⁶이다. GPLv3에서의 ‘설치 정보’ 제공 요구 사항은 오직 ‘User Product’에만 적용되며 다른 제품에는 적용되지 않는다⁴⁷.

“If you convey an object code work under this section in, or with, or specifically for use in, 
a User Product ... the Corresponding Source conveyed under this section must be accompanied by the 
Installation Information.”

반면에 GPLv2에는 소스 코드 의무가 적용되는 제품 유형에 대한 정의나 제한이 없다. ‘User Product’이든지 아니든지 모두 GPLv2의 의무에 따라 소스 코드를 제공해야 한다. 따라서, GPLv3의 완전한 ‘설치 정보’ 의무 정의가 GPLv2의 기존 공개 의무를 되풀이하거나 명확히 하는 것에 불과했다면 GPLv3은 이러한 공개 의무가 존재할 수 있는 상황을 줄여버리게 된 것이다. 그렇다면 결과적으로 GPLv3은 GPLv2에 비해 더 적은 범위의 일부 소프트웨어만 적용되는 것이 때문에 ‘software freedom’ 측면에서 범위가 축소된 것이 된다. 이러한 해석은 최초 GPLv3을 만들고자 했던 목표와 정반대가 되는 것이다.

       “As a free software license … this license [GPLv3] intrinsically disfavours technical attempts to restrict users freedom to copy, modify, and share copyrighted works. Each of [the licenses] provisions shall be interpreted in light of this specific declaration of the licensor’s intent. We wish courts all over the world to understand that our intent [in creating GPLv3] is to maximise freedom, not to restrict it, and that everything should be so understood when effect is given to its terms”⁴⁸

다시 말하지만, GPLv3는 ‘설치 정보’ 의무 자체가 GPLv2의 공개 의무를 넘어 ‘freedom’을 확장하는 경우여야 원래의 취지대로 freedom을 극대화할 수 있다. 그렇지 않다면, GPLv2 의무가 오히려 특정 제품 유형에 국한되지 않기 때문에, User Product에 대해서만 의무를 부과하는 GPLv3는 ‘freedom’ 범위를 축소한 것이 된다는 해석의 딜레마에 빠지게 된다.

8. GPLv2의 텍스트 및 역사적 수정주의_Revisionism

위에서 상세히 설명한 바와 같이, 텍스트 분석과 과거 기록을 검토한 결과, GPLv3의 ‘설치 정보’ 의무는 GPLv2의 소스 코드 의무에는 존재하지 않는 것이며, 어떤 방식으로도 이를 GPLv2에 backport할 수 없음은 명확하다. 이러한 사실에도 불구하고, 최근 과거 기록을 변경하고, GPLv2의 요구 사항을 재해석하여, GPLv2의 소스 코드 의무를 GPLv3의 ‘설치 정보’ 요구 사항과 동일시하려는 노력이 있다.

       “GPLv2 §3 requires that the source code include ‘meta-material’ like scripts, interface definitions, and other material that is used to ‘control compilation and installation’ of the binaries.”⁴⁹

       “GPLv2 included a clear obligation to provide ‘the scripts used to control … installation’ that function for the GPLv2’d works. GPLv2 assures, to the purchaser of an embedded product, their absolute right to receive the information necessary to install a modified version of the GPLv2’d works. … The GPLv2 was designed to assure bug-fixing. Furthermore, the drafters knew that, on embedded systems and devices, you need to know how to install those fixes. Scripts can be technical [artefacts] like shell scripts, but can also be merely a recipe and/or guidance — written instructions that explain how to succeed at install.”⁵⁰

이러한 진술에서와 같이 GPLv3의 (executable을 설치하고 실행하기 위한 정보, recipe, 가이드, 설명 등) ‘설치 정보’ 요구 사항 개념을 GPLv2에 포함해서 GPLv2에서도 설치를 위한 ‘script’를 제공하게 하려는 노력이 현재 진행 중이다. 이러한 노력은 모두 GPLv2의 실제 요구 사항에 반대되는 텍스트_{conter-textual}일 뿐만 아니라 반역사적이다. 다시 말하지만 GPLv2 의 작성자는 GPLv2로는 Tivo에게 수정한 executable을 Tivo 디바이스에 다시 설치하기 위한 필요 정보의 제공을 의무화할 수 없음을 인정하였다⁵¹.

9. Conclusion

• GPLv3의 텍스트와 역사적 기록은 GPLv2에는 없는 새로운 요구 사항인 ‘설치 정보’ 제공을 추가하기 위해 GPLv3이 특별히 설계되었음을 분명히 한다.
• 이러한 역사적 기록은 또한 GPLv2에서는 (GPLv2 코드의 수정 버전 설치를 막을 수 있는 인증키 또는 기타 하드웨어 내장 정보와 같은) 설치 정보를 제공하지 않고 배포하는 것이 완벽하게 허용되었고, 단지 좁은 범위의 정보 (설치 script)만 요구한다는 것을 분명히 하였다.
• GPLv3의 ‘설치 정보’ 요구 사항을 GPLv2로 backporting하려는 노력은 모두 반역사적이며, GPLv3이 GPLv2보다 ‘freedom’을 제한하게 하는 반 직관적인 결과를 초래한다. 이는 처음부터 결코 GPLv3을 만든 목적이 아니다.
• 이러한 반 직관적인 결과를 주장하는 자들은 software freedom을 사랑하는 개발자들에게 GPLv3보다 GPLv2를 선호하도록 조언했을 것이며, 이는 GPLv3을 만들고 출시하려는 모든 목적에 반대되는 결과이다.

GPLv2에 대한 반역사적이고 텍스트로 뒷받침되지 않는 해석이 어디까지나 단순한 이론적 논쟁인지, 아니면 컴플라이언스 소송의 결과로 재판소에서 최종적으로 판단을 받을 것인지는 두고 봐야 할 일이다. (위에서 자세히 설명한) GPLv3 초안을 만들면서 작성된 많은 진술과 GPLv2의 실제 표현들이 GPLv2의 소스 코드 의무의 범위에 대한 모든 결정에 근거가 될 것이다.

About the author

P. McCoy Smith is Founding Attorney at Lex Pan Law (www.lexpan.law), a full-service intellectual property law firm in Portland, Oregon, U.S.A., that has a sub-speciality in free and open source licensing, as well as Founder at Opsequio (www.opsequ.io), an software licence compliance consultancy. As a member of GPLv3 Discussion Committee B, he was an active participant in the debate over, and revision of, the ‘Installation Information’ requirement in that licence.

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

안녕하세요!

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

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

• 번역 오류나 문의는 이메일로 연락주시기 바랍니다. : haksung@sk.com
• 감수에 도움 주신 카카오의 Sean에게 깊이 감사드립니다. ^^

1. 소개 및 문제점

Docker 기술과 관련된 FOSS 라이선스 컴플라이언스 문제는 최근 몇 년 동안 주요 연구 대상이 되었다. 특히 Docker의 기술적 토대를 설명하고 관련된 라이선스 컴플라이언스 문제를 제기한 Armijn Hemel의 백서인 “Docker Containers for Legal Professionals”¹는 광범위한 분석 내용을 제공한다. Hemel은 Dockerfile의 수신자가 이를 사용하기 위하여 제삼자로부터 소스 파일을 다운로드받게 되는데, 이때 다운받는 소프트웨어 컴포넌트에 대한 라이선스 컴플라이언스 책임은 누구에게 있는가에 대해 공개적으로 질문을 제기하였다.

거의 모든 FOSS 라이선스는 라이선스 의무 준수를 “배포_distribution” (또는 GPL-3.0의 “전달_conveying“와 연결시킨다. 대부분의 라이선스는 라이선스 내에서 “배포” 또는 “전달"이 무엇인지에 대해 추가로 정의하지는 않기 때문에, “배포"의 정의는 적용되는 저작권법에 따라 판단해야 한다².

대부분의 오픈소스 라이선스는 오픈소스를 “재배포"하는 시점에 준수해야 할 라이선스 의무 사항을 요구합니다. 즉, 오픈소스를 재배포하지 않는다면 라이선스 의무 준수가 요구되지 않습니다. “배포"의 범위를 어디까지로 판단해야 할지는 해당 지역에 적용되는 저작권법에 따라 해석해야 합니다.

라이선스 컴플라이언스에 대한 중요성 때문에 “배포"라는 용어는 계속해서 법적인 분석 대상이 되고 있다. Heather Meeker는 미국 저작권 관점에서 오픈소스 라이선스에서의 배포를 주제로 글을 작성하였다³. 많은 오픈소스 라이선스가 미국 저작권법을 배경으로 작성되었지만, 유럽 법원은 CJEU(유럽 연합 사법 재판소)_{Court of Justice of the European Union}에서 정교하게 설명한 “배포"에 대한 정의를 바탕으로 판결할 것으로 예상한다.

이 글에서는 먼저 Docker의 기술적인 기본 사항에 대한 개요와 유럽 저작권법에 따른 “배포"라는 용어에 대한 해석을 제공한다. 이어서 Dockerfile을 배포할 때 라이선스 컴플라이언스를 누가 책임져야 하느냐에 대해 논의하겠다.

2. Docker의 기술적 배경

Docker는 컨테이너에 프로그램을 설치하고 배포하는 기술이다. 모든 Dependency가 하나의 기술 Unit에 존재하고, 호스트 시스템과 대부분 독립적이라는 장점이 있다. Hypervisor를 통한 가상화와 달리 Docker 컨테이너에는 운영 체제 커널이 포함되어 있지 않다. 대신 특정 운영 체제 명령을 사용하면 컨테이너의 파일 시스템 트리가 컨테이너의 모든 프로그램에 대한 루트 디렉터리로 표시된다. 따라서 컨테이너 외부의 나머지 파일 시스템은 컨테이너 프로그램에서 보이지 않게 된다. Docker 컨테이너에는 Unix 계열 운영 체제가 필요하며 주로 Linux 커널과 함께 사용하도록 되어 있다.

Docker image

사전에 구성된 컨테이너는 “Docker image"로 배포될 수 있으며, 기본 프로그램 외에 애플리케이션, 프로그램 코드로서의 Dependency, 필요한 경우 유틸리티 및 구성 파일도 포함할 수 있다. Docker image는 개별적으로 배포될 수 있지만 “Docker Hub"와 같은 공용 Repository를 통해서도 배포될 수 있다. 이는 C 라이브러리, Package Manager, Shell 및 디렉터리 트리와 같은 필수 시스템 구성 요소를 포함하고 특정 Linux 배포를 참조하는 이른바 “Base Image"에도 해당된다. 이 Base image 위에, 추가 기능은 개별 보관 파일로 별도로 배포될 수 있지만 서로 빌드되어 완전한 Docker image를 형성하는 이른바 “레이어"로 추가될 수 있다.

Dockerfile

“Dockerfile"은 스크립트와 유사하게 Docker image를 만들기 위한 단계별 명령을 포함하는 텍스트 파일이다. Dockerfile은 일반적으로 Dockerfile 자체에만 적용되는 자체 라이선스를 가질 수 있으며, 이 라이선스는 Docker 컨테이너에 포함되는 프로그램에는 적용되지 않는다.

Docker 엔진

Docker 컨테이너용 관리 소프트웨어인 “Docker 엔진"은 Dockerfile의 명령을 순차적으로 처리하여 Docker image를 생성한다. 일반적으로, Base image나 개별 레이어를 위한 각 컴포넌트는 내부 또는 외부 저장소에서 다운로드된다. 이는 제공자가 Dockerfile을 제공하더라도 물리적인 프로그램 코드를 전달하지 않는 것이 가능함을 의미하고, 이런 일은 실제로 관례적이다. 고객은 전달받은 Dockerfile을 가지고 자체적으로 공개 저장소로부터 전체 혹은 일부 프로그램 코드를 받아와서 Docker 컨테이너를 구축할 수 있다.

여기서 이러한 Dockerfile을 사용하여 빌드한 Docker image에 포함된 FOSS의 라이선스 의무를 Dockerfile 제공자가 준수해야 하는지 여부와 어떤 라이선스 의무를 준수해야 하는지에 대한 의문이 제기될 수 있다.

3. 법적 배경 - EU 법률에 따른 배포 권한

거의 모든 FOSS 라이선스는 저작권법에 따라 소프트웨어를 배포_distributing 또는 전달_conveying 행위를 위한 조건으로 라이선스 의무 준수를 요구한다. 즉, 프로그램의 사본을 제삼자에게 전달할 때 라이선스 의무를 준수해야 한다. 일부 라이선스는 “배포_distribution“에 대한 정의를 라이선스 내에 포함(예: GPL-3.0은 “전달_convey“이라는 용어 정의를 포함함)하지만, 대부분의 라이선스는 이에 대해 정의하지 않고 있다. 따라서, 해당하는 저작권법이 배포를 어떻게 해석하는가를 참조하는 것이 일반적이다. 독일에서는 독일 저작권법의 §69c no 3 UrhG에서 배포를 “Verbreitung“라는 용어로 사용하여 “컴퓨터 프로그램의 원본 또는 사본을 배포하는 모든 형태(임대 포함)“라고 정의한다. 여기서 “Verbreitung“은 §17 (1) UrhG에서와 같이 컴퓨터 프로그램 말고도 일반적인 저작물을 사용할 수 있는 권리를 제공하는 것으로 이해할 수 있다.

이는 컴퓨터 프로그램의 법적 보호에 관한 유럽 의회 및 이사회의 지침 2009/24/EG 4조_{Directive 2009/24/EG of the European Parliament and of the Council}에 비추어 해석되었다⁴. 독일 및 유럽 최고 법원인 독일 연방 사법 재판소_{German Federal Court of Justice, Bundesgerichtshof (BGH)}와 유럽 연합 사법 재판소_{Court of Justice of the European Union (CJEU)}는 수많은 법원 판결에서 배포권을 해석하는 데 도움이 되는 기여를 했다. 이에 대해서는 아래에서 자세히 설명한다.

4. Dockerfile의 배포 - 분석

이 섹션에서는 먼저 저작권법에 따른 배포가 프로그램 코드의 물리적인 전송을 반드시 요구하는지 여부에 대해 살펴본다. 이후에는 Docker image의 다양한 구성 요소, 즉, Base image, 프로그램 라이브러리, 패치 및 업데이트에 관해 설명한다.

4.1 프로그램 코드의 물리적인 배포가 있어야만 배포인가?

아래의 첫번째 경우뿐만 아니라 두번째 경우도 “배포"에 대한 책임은 Dockerfile 제공자에게 있다.

• 저작권 법에서 정의된 배포의 개념인 프로그램 복사본의 “물리적” 배포
• 제삼자로부터 프로그램 복사본을 취득하게 하는 기타 행위

독일과 EU의 최고 법원이 다음의 두가지를 모두 고려되어야 한다는 판결을 자주 했음을 주목하자.

• 물리적 행위
• 복제 또는 배포와 법적으로 관련된 행위를 물리적으로 수행하는 제삼자는 단순히 당사자의 “도구"로 간주됨

이러한 측면에는 특히 CJEU가 “필수적 역할_{essential role}“이라고 부르는 조직적 통제_{organizational control}를 포함한다⁵. 한가지 예는 독일 연방 사법 재판소_BGH의 “인터넷 라디오 음악 녹음 서비스” 판결이다. 이 판결은 인터넷 서비스에 의한 디지털 라디오 방송국의 완전 자동 녹음이 클라이언트의 개인 복사본인지 (허가) 혹은 서비스 제공자의 복사본인지에 (무허가) 대해 다룬다. 이에 대해 BGH는 다음과 같이 명시하였다⁶.

인터넷 라디오 음악 녹음 서비스에 대한 세부 내용은 한국저작권위원회의 2019년 자료⁷를 참고할 수 있습니다.

이 판결의 원고는 음반 제작자인 독일 소니 뮤직(Sony Music)이며, 피고는 인터넷 라디오에서 방송되는 음악을 녹음하여 제공하는 서비스를 운영하는 MusicMonster.FM입니다.

독일 법원은 피고의 서비스는 복제를 위한 기술적 수단을 단순히 제공하는 것을 넘어서고 사적 이용으로 정당화되는 범위를 초과하기 때문에 피고가 복제 및 공중접근의 행위자이고, 피고가 원고의 복제권과 전송권을 침해하였다고 판결하였습니다.

CJEU는 저작권 침해 행위와 관련하여 누가 “필수적 역할_{essential role}“을 하였는지에 대한 몇 가지 판단을 근거로 삼았다. 이는 특히 §17 UrhG(독일 저작권법)에서 명백하게 드러난다. UrhG는 단순한 “제안_offer” 행위, 즉 물리적 배포의 준비 행위_{preparatory act of a physical distribution}도 배포 행위_{act of distribution}라고 지정하였다⁸.

CJEU의 이 판결과 다른 판결들은 기술적으로 배포하는 것뿐만 아니라, 배포를 위한 준비 행위도, 적어도 배포자가 배포 과정에서 “필수적 역할"을 하는 경우라면, 배포가 될 수 있다는 것을 보여준다. Dockerfile의 경우가 정확히 그렇다. Dockerfile은 (의도된 용도에 따라) Dockerfile의 수신자에게 완전한 기능의 시스템_{complete functioning system}을 전송하기 위해 조직된 명령을 제공하기 때문에 Dockerfile 제공자는 Docker image에 포함된 소프트웨어의 배포에 필수적인 역할을 하는 것이다. 이런 점에서, 조직적 통제권_{organizational control}을 가진 것은 Dockerfile 제공자이다. 따라서, Dockerfile 제공자는 이러한 형태로 배포되는 (Docker image에 포함될) FOSS의 라이선스 의무를 준수해야 한다.

Dockerfile의 제공자가 Dockerfile이 참조하는 소프트웨어를 배포한다는 사실이, Base image나 레이어를 다운로드할 수 있는 저장소의 운영자도 각각 프로그램 코드의 배포 행위를 수행하거나 “공개적으로 이용할 수 있게 한다"는 사실과 충돌하는건 아니다⁹. 이는 대부분의 Base image나 레이어는 특정 컨테이너를 위해서만이 아니라 일반적인 다운로드도 제공하기 때문이다. 일반적인 다운로드의 경우, 저장소 운영자가 아닌 저장소를 통해 Base image나 레이어를 제공하는 개인 또는 단체가 배포(또는 대중과의 통신) 행위를 잠재적으로 수행하는 것으로 볼 수 있다.

4.2 패치

추가 레이어를 사용하면 이미 설치된 프로그램도 수정할 수 있다. 이 경우, Docker 컨테이너는 수정되지 않은 프로그램을 한 레이어에 포함하고 수정한 프로그램을 다른 레이어에 포함하여 수정된 프로그램이 실행되도록 한다. 이러한 상황에서도 Dockerfile에는 적용될 수정사항이 정의되어 있기 때문에 Dockerfile 제공자는 “필수적 역할"의 책임을 맡아야 한다. 따라서, Dockerfile 제공자가 수정사항에 대한 라이선스 의무를 준수해야 한다.

이는 두 버전이 모두 수신자에게 배포되기 때문에 (수정된 버전만 실제 사용되더라도) 수정된 버전 뿐만 아니라 원 버전에도 적용된다는 사실에 주의해야 한다¹⁰. 프로그램이 새 레이어에 의해 제거되더라도 Docker image에 물리적으로 여전히 포함된 경우에도 마찬가지이다.

4.3 시스템 요구 사항 및 Base image

시스템 요구 사항

이 섹션은 오픈소스 라이선스는 오픈소스 소프트웨어를 사용하는 데 필요하지만 라이선스 범위에 포함되지 않는 독립 프로그램에 대한 사용 권한을 부여하는 데까지는 확장되지 않는다는 점에서 출발한다. 애플리케이션을 실행하는 데 필요한 운영 체제 또는 웹 서버가 대표적인 예입니다. 이와 같이 애플리케이션 실행에 필요한 독립 프로그램을 “시스템 요구 사항"이라고 하겠다. Dockerfile을 배포하는 제공자는 Docker 엔진 또는 Linux 커널과 같은 시스템 요구 사항에 대한 라이선스 의무는 준수할 책임이 없다. 이런 시스템 요구 사항은 Dockerfile에서 참조하지도 않는다.

참고로, GPL-2.0 3조에서는 다음과 같이 컴파일러, 커널 등 운영 체제의 주요 컴포넌트는 소스 코드 공개 범위에 포함되지 않는다는 예외를 두고 있습니다.

“3. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."

https://www.gnu.org/licenses/old-licenses/gpl-2.0.html

Base image

Base image도 시스템 요구 사항으로 간주할 수 있을까? 일반적으로 Base image에 포함되는 프로그램은 Docker 컨테이너에서 실행되는 애플리케이션과 독립적이다. Base image에 포함된 프로그램이 수정되지 않은 형태로 사용되는 한, Dockerfile에 다운로드 명령이 포함되어 있다고 해도 Dockerfile 제공자가 Base image의 제공자는 아니기 때문에 Base image는 시스템 요구 사항으로 간주할 수 있다. 또한, Repository 운영자가 액세스를 거부한다면 더 이상 다운로드가 불가능하다. 이런 사실에 비추어볼때 Base image는 Dockerfile 제공자의 통제를 벗어난다. 패치의 경우에도 비슷하지만 패치와 시스템 요구 사항은 다르게 처리해야 한다.

컴퓨터 프로그램은 일반적으로 다른 독립 프로그램과 작동한다. 이는 다른 형태의 저작물과 구별되는 특징이다. 예를 들어 대부분의 애플리케이션은 운영 체제 없이 실행되지 않는다. 하지만 이러한 애플리케이션 실행을 위해 시스템 요구 사항을 설치해야 한다고 해서 애플리케이션 제공자가 시스템 요구 사항 배포의 필수적 역할_{essential role}을 한다는 것을 의미하지는 않는다.

이런 상황은 다운로드 링크와 다소 비슷하다. 저작권이 있는 저작물을 다운로드하는 링크가 저작권법이 적용되는 관련 행위를 구성하는지, 즉 대중에게 전달하는 행위(따라서 저작권 침해를 초래할 가능성이 있음)에 해당하는지 여부에 대한 문제가 EU에서 치열하게 논의되고 있다. CJEU는 이에 대하여 일련의 복합적인 기준을 설정하였다¹¹. 이 기준은 특히 다음과 같은 사례별 질문을 제시한다. : 새로운 구매자 그룹에 공개되어 있는지 여부, 의도된 용도가 상업적 목적인지 여부, 해당 행위가 제안에 중요한 역할을 하는지 여부, 제안이 불법인지 여부. 이렇게 사례별로 다뤄야하며 포괄적인 판단은 거의 불가능하다. 사실 회원국에서는 이러한 기준을 고려하는 경우가 흔하지 않았다. 그럼에도 이런 기준을 만든건 아마도 인터넷 저작권의 법적 상황을 더 잘 조화시키려는 CJEU의 바람 때문일 것이다.

지금까지 제시된 견해에 따르면, Base image의 Repository 운영자와 제공자는 Base image의 배포에 필수적인 역할을 하는 반면, Dockerfile이 단지 참조하는 Base image는 시스템 요구 사항을 쉽게 취득하게 하기 위한 것이다. 그러므로, Repository의 운영자가 일반 대중에게 전달하는 행위를 수행하는 것이고, Repository 운영자는, 최소한 이러한 제공이 합법적이라면, 포함된 FOSS의 라이선스 의무를 단독으로 준수해야 한다.

위에서 언급한 해석은 본 연구 저자의 법적 의견이다. 일반적으로 컴퓨터 프로그램 및 특히 Dockerfile에 대한 이러한 특정 상황에 관한 판례는 없다. 다른 해석들도 분명 논쟁의 여지가 있다(특히 Base image를 포함하는 모든 참조 레이어가 Dockerfile의 제공자에 의해 배포되는 경우).

한가지 언급해야 할 사항은 현재 수많은 Repository 운영자들이 FOSS의 라이선스 의무를 올바르게 준수하지 않고 있으며 (예: GPL 및 LGPL 구성 요소의 소스 코드를 적절하게 제공하지 않음), 이는 저작권 침해의 책임이 있다는 점이다. 이 경우, 만약 Dockerfile의 제공자가 라이선스 위반을 알고 있다면 혹은 알고 있어야 한다면, 라이선스를 위반하는 참조를 포함하는 Dockerfile을 제공하는 것은 독립적인 배포 행위로 간주되거나 최소한 기여 저작권 침해(즉, 라이선스 위반에 대한 선동 또는 방조)로 간주될 수 있다. 따라서 Dockerfile 제공자는 지정된 Repository에서 제공하는 Base image가 라이선스를 준수하는지 여부를 검토해야 한다¹².

Docker image를 단순히 조직 내부에만 사용하려는 수신자라면, FOSS 프로그램의 단순한 실행은 제한되지 않기 때문에, 문제없이 사용할 수 있다. 예를 들어, GPL-2.0 4조에서는 이를 명확히 말하고 있다¹³. 그러나, 수신자가 Docker image를 재배포하려고 한다면, Dockerfile의 배포가 저작권을 침해하는 경우라면 배포권이 소진되는 것이 아니기 때문에, 재배포하려는 수신자는 라이선스 조건의 컴플라이언스를 보장해야 한다(아래의 4.6절 참조).

4.4 프로그램 라이브러리

프로그램과 연결된 라이브러리의 경우, 이러한 라이브러리가 독립적인 프로그램으로 간주되는지 또는 링크된 프로그램의 일부가 되는건지에 대해서는 약간의 의견 차이가 있다¹⁴. 이러한 맥락에서 다음과 같이 구분할 수 있다.

• 시스템 라이브러리
• GPL 및 AGPL 애플리케이션과 연결되는 비시스템 라이브러리_{non-system library}
• GPL 및 AGPL 이외의 다른 라이선스의 애플리케이션과 연결되는 비시스템 라이브러리

GPL-2.0 섹션 3 및 GPL-3.0 섹션 1 (3)에는 라이선스 의무 중 소스 코드를 제공해야 하는 범위 내에 “시스템 라이브러리"는 면제하는 조항이 포함되어 있다¹⁵. 따라서 Dockerfile이 Docker 컨테이너에서 수정되지 않은 이러한 시스템 라이브러리를 사용하라는 명령을 포함하는 경우, 이러한 시스템 라이브러리에 대한 라이선스 의무는 준수할 필요가 없다. 그러므로 이러한 시스템 라이브러리의 법적인 상황은 Base image에 적용되는 상황(위 4.3 참조)과 동일하며, 이때는 배포를 위한 필수적인 역할이 Dockerfile 제공자에게 있는 것은 아니다.

그러나 Dockerfile이 제삼자 Repository에서 (시스템 라이브러리 이외의) 라이브러리를 다운로드하고 이 라이브러리가 Docker 컨테이너 내에서 GPL-3.0 또는 AGPL-3.0 애플리케이션과 링크하는 레이어를 지정하는 경우라면, 이러한 라이브러리에 대해서는 각각 링크하는 애플리케이션의 라이선스(GPL-3.0 또는 AGPL-3.0) 의무를 준수해야 한다. 예를 들어 라이브러리의 소스 코드를 반드시 제공해야 한다 (cf. section 1 GPL-3.0: “Corresponding Source includes …, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, …”). 이는 GPL-2.0에도 동일하게 적용된다. 라이브러리의 물리적 배포의 경우와 마찬가지로 (라이선스 충돌 문제가 없다면) 해당 라이선스 조건을 준수해야 한다. 즉, 분산형 배포 프로세스_{decentralized distribution process}로 카피레프트 요구 사항을 회피할 수 없다.

Dockerfile 제공자는 프로그램 라이브러리를 Dependency로 선택하는 조직적 제어권_{organizational control}을 가졌기 때문에 Dockerfile 제공자가 프로그램 라이브러리를 배포한다고 판단할 수 있다. 따라서, 프로그램 라이브러리의 배포 프로세스에서 Dockerfile 제공자가 필수적인 역할_{essential role}을 한다.

4.5 업데이트

업데이트 처리는 Dockerfile 제공자가 업데이트를 제어하는지 여부에 따라 달라진다. Dockerfile 제공자(또는 대리인)가 직접 Repository에 업데이트를 업로드하여 Dockerfile의 수신자가 이를 받아올 수 있게 하였다면 Dockerfile 제공자가 업데이트를 배포한다고 볼 수 있다. 반면, Repository 운영자의 통제하에 업데이트가 제공된다면 (예 : Dockerfile이 “최신 버전"을 참조하는 경우) 이는 Dockerfile 제공자가 배포하는 것이 아니다. 이 경우, Dockerfile 제공자가 프로그램 버전을 선택하고 Dockerfile 내에 명명하는 것과는 대조적으로, Dockerfile 제공자는 업데이트의 내용에 관련해서 영향을 미치지 않는다.

4.6 라이선스 조건 준수 시점

라이선스 의무는 배포 (또는 대중에게 전달) 시점에 준수해야 한다. 같은 일련의 배포 단계에서 Dockerfile의 전달과 같은 준비 행위는 이미 배포로 간주 될 수 있으므로, 엄격히 말해서, Dockerfile 전달 시 라이선스 의무를 이행해야 한다. 그러나 Repository에서 다운로드 하는 시점에 라이선스 의무를 준수하는 것도 충분하다는 방식으로 오픈소스 라이선스를 해석할 수 있다. 특히 Dockerfile 배포 시, 다운로드되는 레이어에 어떤 프로그램 코드가 포함되는지 명확하지 않다는 점도 이러한 해석을 뒷받침한다. 예를 들어 프로그램 버전을 “latest"로 지정한 경우가 그렇다.

하지만, 만약 관련 Repository에서 라이선스 의무를 완전히 충족하지 않는다면, Dockerfile 제공자는 독립적으로 라이선스 의무를 준수하고 필요한 필수 정보(예 : 라이선스 텍스트, 저작권 고지, 소스 코드 제공)가 포함된 파일을 함께 제공하는 것이 좋다.

5. 결론

• Dockerfile 제공자는 Dockerfile을 build/run 하는 과정에서 Docker 컨테이너에 포함되는 FOSS의 라이선스 조건에 대한 컴플라이언스 책임이 있다. Dockerfile 수신자가 외부 공개 Repository로부터 소프트웨어를 다운로드 받는 방식이라고 해도 Dockerfile 제공자의 책임을 회피할 수는 없다.
• Dockerfile을 제공하는 건 준비 행위_{preparatory acts}에 해당하고, 이는 “배포"에 포함된다는 사실이 유럽 연합 사법 재판소_{Court of Justice of the European Union}의 판례에서 드러났다.
• 하지만, 컴퓨터 프로그램 상호 작용의 특수성을 고려하여 운영 체제, 웹서버 등 “시스템 요구 사항"에 대한 라이선스 컴플라이언스는 Dockerfile 제공자가 책임지지 않는다.
• 단, Docker 레이어가 FOSS 라이선스를 준수하지 않는 상태로 Repository에서 제공된다면. 이를 참조하는 Dockerfile 제공자에게도 위험을 초래한다.
• 따라서, FOSS 라이선스 컴플라이언스는 Dockerfile 제공자와 Docker 레이어를 공개 Repository에 공개한 배포자가 공동으로 책임져야할 사항이다.

OSPO란?

안녕하세요!

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

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

OSPO의 정의

OSPO_{Open Source Program Office}는 조직의 오픈소스 운영을 위해 조직의 중앙에 역량을 집중하도록 설계되었다. 여기에는 오픈소스의 사용, 배포, 선택, 검사 및 관련 정책 수립뿐만 아니라 개발자 교육, 컴플라이언스 보장과 조직에 이익이 되는 커뮤니티 참여와 구축을 촉진하는 활동이 포함될 수 있다.

모든 산업에 걸쳐 적용할 수 있는 오픈소스 프로그램을 구축하기 위한 광범위한 템플릿은 없지만, 여기에서는 일반적인 OSPO의 기능을 세 가지로 분류해보았다.

1. 법적 위험 완화_{Legal Risk Mitigation}
2. 엔지니어 작업 방식 개선_{Improving Engineers’ Practices}
3. 재정적 이익 실현_{Enabling Financial Benefits}

이렇게 세 가지로 분류해보니 각각 두려움_Fear, 사랑Love, 돈_Money이 연상된다.

법적 위험 완화

기업의 주된 관심사는 법적인 컴플라이언스이다. 따라서, OSPO는 기업의 오픈소스 라이선스 컴플라이언스 프로세스를 구축하고 관리한다. 일반적으로 소프트웨어를 배포하는 기업은 이 문제에 가장 관심이 많으며, 이러한 법적 위험을 완화하기 위해 OSPO의 설립을 시작한다.

OSPO는 법적 위험 관리를 위해 다음과 같은 책임을 가진다.

• 오픈소스 라이선스 컴플라이언스 관리 감독
• 인바운드 코드_{주: 오픈소스 등 외부로부터 입수한 코드} 사용을 위한 검토 프로세스 실행
• 오픈소스 프로젝트에 효과적으로 기여하도록 보장

엔지니어 작업 방식 개선

OSPO는 오픈소스 환경에서 코드 관리에 대한 가이드와 정책을 제공함으로써 엔지니어링 기능을 개선한다. 소프트웨어 엔지니어가 많은 기업은 OSPO를 엔지니어링 정책과 작업 방식에 집중한다.

이와 관련한 OSPO의 책임은 다음과 같다.

• 기업의 오픈소스 전략을 기업 내부 및 외부에 명확히 전달
• 조직 내 오픈소스 문화 육성
• 오픈소스 커뮤니티에 고품질의 코드를 자주 공개하도록 보장

재정적 이익 실현

일부 기업은 오픈소스에 관한 재정적 이익에 초점을 맞춘다. OSPO를 활용하여 상용 벤더를 사용할지 아니면 오픈소스 벤더를 사용할지에 대한 전략을 수립한다. 반면 일부 기술 기업은 자신의 OSPO (및 오픈소스 프로젝트)를 활용하여 고객이 자신의 상용 제품을 구매하도록 유도한다.

이와 관련한 OSPO의 책임은 다음과 같다.

• 전략 실행에 대한 오너쉽과 감독
• 상용 제품 및 서비스에서 오픈소스를 효과적으로 사용하도록 촉진
• 전략적 오픈소스 프로젝트이의 채택을 장려하기 위하여 개발자 커뮤니티와 협력

이처럼 각 OSPO는 기업 비즈니스, 제품 및 목표에 맞게 구성된다.

OSPO 가이드

TODO Group은 기업이 OSPO를 설립하고 운영하기 위한 가이드를 제공합니다.

• How to Create an Open Source Program⁶
• Measuring Your Open Source Program⁷
• Tools for Managing Your Open Source Program⁸

OSPO Examples

TODO Group은 Microsoft, Faceboo, Uber 등 오픈소스를 효과적으로 활용하는 기업들이 어떻게 OSPO를 운영하고 있는지, 각 기업의 사례를 취합하여 공개하였습니다.

• Autodesk⁹
• Capital One¹⁰
• Comcast¹¹
• Facebook¹²
• Microsoft¹³
• Red Hat¹⁴
• Salesforce¹⁵
• SAP¹⁶
• Uber¹⁷
• Yahoo/Verizon Media¹⁸

SK텔레콤의 OSPO에 대한 글을 소개 하며 글을 마칩니다. : SK텔레콤 OSPO¹⁹

감사합니다.

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

안녕하세요.

미국의 오픈소스 전문 변호사인 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전자의 김경애님에게 깊은 감사 드립니다.

최근, 2021년 2월, Elastic은 소프트웨어 제품에 Elastic License 2.0이라는 새로운 라이선스를 도입하였다. 이 라이선스 모델은 Elasticsearch, Kibana 등 주요 소프트웨어 제품군에 적용되었다. 이런 변화의 목적과 의미하는 바가 무엇인지 알아보자.

Elastic License 2.0은 개방형 개발 모델_{Open Development Model}로 사업하는 기업이 취할 수 있는 대표적인 라이선스 모범 사례이다. Elastic License 2.0은 오픈소스 라이선스는 아니지만, 소프트웨어의 사용, 공유 및 변경의 자유와 커뮤니티에 해를 끼는 행동 방지 간의 공정한 균형을 유지하는 데 필요한 최소한의 제한 설정을 목표로 한다.

유닉스, 리눅스, 자유소프트웨어, 그리고 오픈소스

Elastic License 2.0과 같은 새로운 라이선스의 추세를 이해하려면 오픈소스 라이선스 운동이 어떻게 성장했는지 살펴보는 것이 도움이 된다.

오픈소스와 자유소프트웨어_{Free Software} 운동은 소프트웨어가 사유화되는 것에 대한 개발자의 우려에서 시작되었다. 이러한 우려의 불씨는 당시 가장 인기있는 운영체제인 유닉스였다. 유닉스의 개발사인 AT&T Bell Labs은 1956년의 동의령_{consent decree}에 따라 유닉스 및 C언어를 포함하는 연구 프로젝트로 이익 얻는 것을 금지¹ 당했으며, 이때문에 수년간 매우 관대한 조건의 라이선스로 유닉스를 배포하였다. 학계, 연구자, 개발자들은 유닉스를 수정/개선하여 공유하기 시작했고, 유닉스는 곧 운영체제 분야의 선두가 되었다. 하지만, 1983년 동의령이 해제되자 AT&T는 유닉스에 수정 사항 공유를 허용하지 않는 조항을 적용하였다. 이에 따라 각 업체별로 각자 수정한 운영체제를 사용하며 유닉스는 많은 호환되지 않는 종류로 쪼개졌고, 사용자들은 더 이상 협업할 수 없게 되었다.

유닉스가 사유화되면서 자유소프트웨어 운동, 그리고 이어서 오픈소스 운동이 생겨났으며, 이들은 인프라 소프트웨어가 폐쇄되는 상황이 다시 발생하는 것을 방지하려고 하였다. 이 운동은 유닉스를 대체하는 자유소프트웨어인 리눅스를 중심으로 이루어졌으며 곧 모든 소프트웨어는 자유_free(무료_free 맥주에서의 Free가 아니라 언론의 자유_free에서의 Free)로워야 한다는 철학에 기반한 더 큰 운동으로 발전하였다. 이러한 운동의 한 요소는 소스 코드에 대한 접근, 개선 및 변경 사항을 만들고 공유할 수 있는 권리이다. 이러한 원칙들은 GNU General Public License (GPL)에서 구현되었으며, 이에 따라 바이너리 배포자들은 해당 소스 코드를 공유해야 한다.

시간이 흐르고, 2000년대 초반 인터넷 붐에 힘입어 오픈소스 라이선스는 더욱 인기를 얻게 되었다. GPL과 같은 일부 라이선스는 복잡한 법적 우려를 불러일으키기도 했지만, 기업이 협업할 수 있는 기반을 마련하였다. 2000년 이후 오픈소스와 이를 통해 가능해진 협업은 모든 기술 부문에 채택되었다. 오늘날, 오픈소스는 전자상거래_e-commerce의 핵심 기술이며, 기업들은 소프트웨어 인프라를 위한 지속해서 협력한다.

클라우드의 출현과 AGPL

GPL과 같은 라이선스는 변경 사항의 공유를 요구한다. 바이너리 배포에 대한 소스 코드 공유 조건을 부과한다. 반면에 “개인 복사본"을 만들어서 사용하는 건 변경 사항을 공유할 필요가 없다. 이러한 조건은 당시 대부분의 소프트웨어를 직접설치_on-premise하는 방식이었기 때문에 공유를 강제하는 데 효과적이었다. 그러나 2000년대 초부터 소프트웨어는 퍼블릭 클라우드로 이동하기 시작하였고, 더 이상 소프트웨어를 배포할 필요가 없었다. 고객은 로컬 사본을 얻지 않고도 소프트웨어를 사용할 수 있게 되었다.

클라우드 서비스 사업이 커지면서, 이러한 패러다임의 변화는 오픈소스 커뮤니티의 기대치와 AWS_{Amazon Web Services}와 같은 클라우드 서비스 공급 업체 사이에 긴장감을 조성하였다. 클라우드 서비스 공급 업체는 개선 사항을 공유해야 하는 법적 의무에서 자유로웠다. 구글이 검색 서비스 강화를 위해 Linux에 의존하는 것으로 잘 알려졌기 때문에 이를 “구글 루프홀_Loophole“이라고도 불렀다. 이에 대응하기 위해 자유소프트웨어 커뮤니티는 Affero GPL (AGPL)이라는 GPL을 부분 변경한 형태의 라이선스를 만들었다. AGPL 3.0은 GPL 3.0과 거의 동일하지만 다음과 같은 원격 네트워크 상호 작용_{Remote Network Interaction} 조항을 포함한다.

[I]f you modify the Program, your modified version must prominently offer 
all users interacting with it remotely through a computer network … 
an opportunity to receive the Corresponding Source of your version by 
providing access to the Corresponding Source from a network server at no 
charge, through some standard or customary means of facilitating copying 
of software….

이 새로운 라이선스는 GPL이 리눅스 배포에 대해 했던 것처럼 클라우드 서비스 공급 업체가 소스 코드 개선 사항을 공유하도록 강제하기 위한 것이다.

AGPL과 듀얼 라이선스

AGPL은 첫 번째 릴리스부터 논란이 있었다. 2007년, GPL 3.0 초안 작성이 마무리되어 가는 과정에서 일부 작성자들은 GPL을 네트워크 카피레프트_Copyleft 모델로 변경하기를 원하였다. 하지만 커뮤니티는 GPL 3.0의 “루프홀"을 그대로 유지하기로 결정했고, 몇 달 후, 이에 대한 대안으로 AGPL을 내놓았다. 그러나 AGPL은 널리 채택되지 않았다. 매우 인기 있는 분산 데이터베이스 제품인 MongoDB가 유일무이한 AGPL의 “킬러 앱_{killer app}“이다. 기업들은 처음에는 AGPL을 이해하고 받아들이기 어려워했지만, 대부분 사용자는 소프트웨어를 변경하거나 서비스로 제공하지 않았기 때문에 AGPL하의 소프트웨어를 사용하겠다는 합리적인 결정을 내릴 수 있었다.

AGPL 3.0의 Remote Network Interaction 조항은 프로그램을 변경하였을 때에 한하여 변경 사항의 소스 코드를 컴퓨터 네트워크를 통한 원격 사용자에게 제공해야 합니다. 즉, 변경하지 않는다면 소스 코드 공개 의무가 발생하지 않습니다.

MongoDB는 “듀얼 라이선스” 비즈니스 모델로 AGPL을 사용하였다. 사용자_licensee에게 AGPL 또는 상용 소프트웨어 라이선스 중 하나를 선택하게 하였다. 사용자는 AGPL의 요구사항을 준수하고 싶지 않거나 준수하기 위한 법적인 검토조차 관여하고 싶지 않다면 상용 라이선스를 선택하였다. 이러한 듀얼 라이선스 비즈니스 모델은 원래 GPL과 상용 라이선스를 선택하게 하는 방식으로 개발되었으나 시간이 지나면서 GPL 대신 보다 카피레프트 범위를 확장한 AGPL이 사용되었다. MongoDB의 이 라이선스 모델은 상당히 성공적이었다. AGPL은 가장 강력한 카피레프트 라이선스였기 때문에 MongoDB가 상업적인 협상을 추진하는 데 유용하였다. 한편, AGPL을 만든 이들은 AGPL이 MongoDB의 사업 수단으로 사용되는 모습이 유해한 갈취_{toxic shakedown}라면서 비판하기도 하였다. 여하튼, 그렇게 강력하다고 평가 받던 AGPL의 소스 코드 공유 조건도 클라우드 공급 업체가 오픈소스를 대규모로 상업적인 사용을 하면서 개발자나 커뮤니티에 아무것도 되돌려 주지 않는 행위를 막기에는 충분하지 않았다.

무상 사용_Strip-mining

클라우드 이용이 GPL 모델을 “파괴_broken“시켰던 것처럼, 2010년대 클라우드 컴퓨팅이 발전하면서 AGPL 듀얼 라이선스 모델도 압박을 받기 시작하였다. 이번에는 문제가 달랐다. GPL 또는 AGPL의 범위는 하나의 단일 실행 가능 프로그램_{single program executable}까지만 확장된다. 이 “기능"은 저작권 라이선스가 단일 저작물에 대해서만 사용 조건을 지정할 수 있다는 이론에 따라 GPL에서 의도적으로 설계된 것이었다. 즉, GPL은 파생 저작물_{derivative work}에 대한 소스 코드 공유 요건을 갖지만, 집합 저작물_{collective work}에 대해서는 아니다. 법적으로 이 둘 간의 경계는 상당히 불분명하지만 GPL이 인기를 얻으면서 단일 프로그램이란 하나의 실행 가능한 프로세스라고 정의하는 것이 일반적인 관행이 되었다. 자유소프트웨어재단_{Free Software Foundation}은 GPL FAQ에서 오랫동안 이런 원칙을 주장해왔다.

하지만 클라우드 서비스가 발전하면서 두 가지 일이 발생하였다. 첫째, 소프트웨어 엔지니어링을 클라우드 구현에 더욱 집중하게 되었다. 클라우드 공급 업체는 한때 클라우드 환경에서 실행하기 위한 소프트웨어를 개선하거나 수정해야 했던 반면, 소프트웨어 엔지니어링이 발전하면서 클라우드 공급 업체는 기존 오픈소스 소프트웨어를 “플러그 앤드 플레이_{plug and play}“형태로 사용할 수 있게 되었다. 그러다 보니 클라우드 공급 업체는 혁신의 주체를 주요 실행 파일이 아닌 곳으로 변화할 수 있었다. 그들은 소프트웨어를 관리, 모니터링 및 배포하기 위한 소프트웨어를 추가로 개발했으며, 이러한 혁신은 클라우드 서비스를 키울 수 있었다. AGPL은 클라우드 공급 업체의 이러한 개선사항에 대해서는 이를 공유하도록 강제하는 데 아무런 도움이 되지 않았다.

이렇게 오픈소스 상용 기업들은 대형 클라우드 공급 업체가 무료로 갖다 쓰기 좋은 상점처럼 되어 버렸다. 특히 “플랫폼 소프트웨어” 또는 미들웨어 (컴퓨터 스택에서 최상위 계측인 응용 프로그램과 운영 체제의 중간에 있는 소프트웨어)에서 문제는 더 심각하였다. 이 범주의 소프트웨어는 최신 컴퓨팅에 필수적이며 클라우드 구현에 매우 유용하다.

이 때문에 비즈니스 세계에서 클라우드 공급 업체의 오픈소스 사용에 대한 비판이 제기되었다. Bain Capital의 Salil Deshpande는 2018년 “분명히 이것은 불법은 아니다. 그러나 우리는 이것이 잘못되었고, 오픈소스 커뮤니티의 지속 가능성에 도움이 되지 않는다고 생각한다"라고 하였다. 또 다른 전문가는 “AWS는 오픈소스의 아킬레스건을 건드리고 있다. 다른 사람의 저작물을 무료로 가져다가 이에 대한 접근 권한을 임대하는 사업을 하는 것이다.“라고 하였다. 문제는 모든 주요 오픈소스 라이선스는 이런 방식으로 소프트웨어를 사용하는 것을 제지하지 않는다는 것이다.

주요 오픈소스 라이선스가 작성되었던 시점에는 AWS의 “Program as a Service” 형태의 프로그램이 없었으니, 이에 대한 조건도 고려하지 않았을 테지요.

오픈소스 상용 기업들은 오픈소스 프로그램을 개발해서 듀얼 라이선스 모델 (GPL or 상용)로 사업을 하고 있었는데, 클라우드 제공 업체에서 이 오픈소스 프로그램을 그대로 가져다가 클라우드 서비스로 제공하는 사업을 하고, 자기네한테는 아무런 이윤도 안겨주지 않으니, 사업 또는 개발 측면에서 모두 좋지 않은 영향을 미쳤을 것은 충분히 추측할 수 있습니다.

클라우드 공급 업체가 MongoDB를 Amazon DocumentDB나 Azure Cosmos DB로 서비스하며 고객을 확보하는게 대표적인 예라고 볼 수 있을 것 같습니다.

오픈소스 상용 기업들과 투자자들은 이런 오픈소스 모델의 한계 때문에 고민이 되었다. GPL, AGPL 등 어떤 라이선스도 저작권법을 사용하여 클라우드 공급 업체가 변경 사항을 공유하도록 강제할 수 없었다. 또한 AWS, Azure 또는 Google Cloud와 같은 대규모 고객 기반을 가진 클라우드 공급 업체는 버튼 클릭으로 소프트웨어를 쉽게 추가할 수 있게 하여 고객과 “끈끈한” 관계를 유지하였다. 일부 오픈소스 개발사는 자체 클라우드 서비스를 제공했지만, 소프트웨어를 무료로 사용하는 대형 클라우드 공급 업체와 경쟁하는 건 너무 어렵다는 걸 알게 되었다. 오픈소스 개발사의 서비스가 더 우수한 경우에도, 기존 클라우드 계정에서는 단지 “체크박스를 선택"하여 소프트웨어 제품군을 추가하는 것과는 달리, 새로운 서비스를 사용하기 위한 거래 비용_{transaction cost}이 발생한다는 점이 고객이 등을 돌리게 하였다.

SSPL과 소스 공개 라이선스

2018년 업계는 돌파구를 찾았다. AWS가 오픈소스 플랫폼 소프트웨어를 호스팅하면서 계속 인기를 얻자 오픈소스 개발사들은 행동에 나서기 시작하였다. 라이선스를 변경하였다.

오픈소스 개발사들은 두 가지 다른 경로를 통해 무상 사용 문제에 대응하였다.

1. 매우 강한_ultra-strong 네트워크 카피레프트 라이선스
2. 제한 조건을 갖는 소스 공개 라이선스_{Source Available Licensing}

이 두 범주 모두 이전에는 정의되지 않았던 형태이다. 둘 다 MySQL 및 MongoDB 에서와 같은 듀얼 라이선스 모델을 지원하기 위한 것이다.

SSPL

매우 강한 카피레프트 접근 방식은 2018년 SSPL_{Server Side Public License}을 만든 MongoDB에 의해 시도되었다.

1.  Offering the Program as a Service.

If you make the functionality of the Program or a modified version 
available to third parties as a service, you must make the Service 
Source Code available via network download to everyone at no charge, 
under the terms of this License. Making the functionality of the 
Program or modified version available to third parties as a service 
includes, without limitation, enabling third parties to interact 
with the functionality of the Program or modified version remotely 
through a computer network, offering a service the value of which 
entirely or primarily derives from the value of the Program or 
modified version, or offering a service that accomplishes for users 
the primary purpose of the Program or modified version.

"Service Source Code" means the Corresponding Source for the Program 
or the modified version, and the Corresponding Source for all programs 
that you use to make the Program or modified version available as a 
service, including, without limitation, management software, user 
interfaces, application program interfaces, automation software, 
monitoring software, backup software, storage software and hosting 
software, all such that a user could run an instance of the service 
using the Service Source Code you make available. [emphasis added].

이 라이선스는 무상 사용 문제에 대응하기 위한 오픈소스 솔루션을 만들기 위해 작성되었다. 소스 코드 공유 요구 사항은 AGPL의 요구 사항보다 훨씬 광범위하다. 이러한 요구 사항의 범위는 분산 소프트웨어에 대해서도 GPL 요구 사항과 유사하게 작동하도록 설계되었다. MongoDB는 SSPL 또는 상용 라이선스에 따라 소프트웨어를 사용할 수 있는 듀얼 라이선스 모델을 적용하였다.

MongoDB는 SSPL을 OSI_{Open Source Initiative}에 승인받기 위해 제출하였다. 수개월 간의 논쟁 끝에 승인을 받지는 못하였지만, MongoDB는 듀얼 라이선스 모델의 오픈소스 선택지로 SSPL을 계속 사용하고 있다. 이 라이선스가 오픈소스 정의_{Open Source Definition}에 적합하지 않은 이유에 대한 논의는 복잡했으며, 이 정의를 충족하는 것만이 유일한 기준은 아니었다. 요약하자면, 이렇게 광범위한 소스 공유 요구 사항을 가진 라이선스가 “소프트웨어 자유를 보장“할지가 분명하지 않았다.

제한 조건을 갖는 소스 공개 라이선스

다른 사람들은 또 다른 경로를 따랐다. 일부 회사는 Salil Deshpande가 주도한 Commons Clause를 채택했으며, 어떤 회사는 Elastic이 Elastic License 1.0을 만든 것처럼 Redis, Confluent, CockroachDB와 같은 자체 라이선스를 제작하였다. SSPL과는 달리, 이 라이선스들은 오픈소스 정의를 충족시키기 위한 것이 아니었다. 대신, 이들은 무상 사용을 겨냥한 제한 조건을 갖고 있다.

왜 이렇게 두 가지 경로로 갈렸을까? 이는 Freedom Zero, “어떤 목적으로든 원하는 대로 프로그램을 실행할 수 있는 자유"와 관련이 있다².

오픈소스 또는 자유소프트웨어 라이선스의 주요 특징은 라이선스 제약이나 제한이 없다는 것이다³. 일반적인 상용 소프트웨어 라이선스와 비교해보자. 개인용으로 사용하겠다는 라이선스 조건에 클릭하여 수락하는 형태의 최종 사용자 라이선스_{End User license Agreement}는 소프트웨어를 사용하는 것만 허용하며, 변경하거나 배포할 수 없다. 엔터프라이즈 라이선스는 소프트웨어를 사용할 수 있는 사용자, 서버 또는 물리적 위치의 수에 대한 제한을 설정하고, 기업은 해당 사용을 감시해야 한다. 그러나 오픈소스 라이선스에는 그러한 제한이 없다. 따라서, 소스 코드를 무료로 제공한다고 하더라도 상업적 사용 불가와 같은 제한을 갖고 있다면 정의상 오픈소스가 아니다.

즉, 모든 라이선스 제한은 오픈소스 범주에서 벗어나게 한다.

2018년 이후 발생한 라이선스 변경의 물결 가운데 출시된 모든 라이선스는 거의 비슷한 제한을 갖고 있다. 각각 고유한 조건이 있지만, 이들은 모두 사용자가 소프트웨어를 무료로 사용할 수 있도록 허용하는 동시에 경쟁 호스팅 서비스 제공을 위한 소프트웨어 사용을 금지하는 데 초점을 맞추고 있다.

Elastic License 2.0

2021년 초, Elasticsearch는 이 두 가지 경로를 모두 따르는 하나의 길을 개척하였다. SSPL과 새로운 Elastic License 2.0 (ELv2)이라는 두 가지 무료 선택지를 제공하여 소프트웨어 제품군을 사용할 수 있게 하였다.

새로운 Elastic 2.0 라이선스는 짧고 (한 페이지에 불과) 쉬운 언어로 작성되었으며 오픈소스 라이선스의 거의 모든 자유를 허용한다. 소프트웨어 수신자는 소프트웨어를 자유롭게 사용, 변경 및 재배포 할 수 있다. 전에 소프트웨어 라이선스를 읽어본 적이 없더라도 이 라이선스는 한번 읽어볼 가치가 있다.

여기에는 두 가지 주요 제한이 있다.

You may not provide the software to third parties as a hosted or 
managed service, where the service provides users with access to 
any substantial set of the features or functionality of the software.

You may not move, change, disable, or circumvent the license key 
functionality in the software, and you may not remove or obscure 
any functionality in the software that is protected by the license key.

첫 번째 제한은 무상 사용 문제를 해결하는 데 초점이 맞춰져 있다. 이로써 이 제한을 위반하여 소프트웨어를 사용하면 소프트웨어의 권한을 침해하게 된다.

두 번째 제한은 소프트웨어 라이선스 키의 해킹을 금지하기 위한 것이다. 이러한 제한은 소프트웨어 라이선스에서는 오래전부터 일반적이었으나, 소스 공개 라이선스에서는 이제 막 사용되기 시작하였다. 이 조항을 통해 개발자는 유료 서비스를 ELv2하의 소프트웨어와 상호 작용하게 하거나, 유료 기능을 위한 소프트웨어 구성 요소 일부를 보호할 수 있게 되었다.

이 라이선스의 다른 조항들은 매우 간단하며 오픈소스 라이선스를 읽은 사람이라면 누구나 익숙할 것이다.

왜 듀얼 라이선스를 사용하였는가?

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는 거의 모든 사용자가 소프트웨어를 무료로 사용할 수 있도록 하는 유연성을 강조하였다.

Elastic License 2.0는 오직 클라우드 서비스 공급 업체에서 Elasticsearch를 자기네 클라우드 서비스로 제공하는 것만은 막겠다는 의지인 것 같습니다.

결국 AWS는 Elasticsearch 서비스를 계속하기 위해 Elasticsearch를 Fork했고, 이를 Open Distro for Elasticsearch라고 명명하며 Apache License 2.0을 적용하고, 커뮤니티를 키워가기로 했습니다.

누가 오픈소스의 지속가능성과 발전에 기여하고 있는 것일까요?

Elastic License 2.0과 최신 라이선스 기술

Elasticsearch는 사용자와 개발자 모두에게 공정하고 지속 가능한 비즈니스 모델을 유지하면서 가능한 한 개방성을 유지하기 위해 새로운 라이선스 모델로 전환하였다. 그렇게 함으로써 소스 공개 운동_{source-available movement}에 참여한 다른 참여자들의 목표와 추구하는 바를 라이선스 작성 시 반영하였다.

라이선스 변경에 대한 FAQ에서 요약한 바와 같이 Elastic의 라이선스 변경은 고객이나 커뮤니티 사용자 수에 영향을 미치지 않을 것으로 예상된다. 대부분의 사용자는 Elastic의 소프트웨어를 기반으로 애플리케이션을 구축한다. 이는 “제3자에게 호스팅 또는 관리 서비스_{as a hosted or managed Service}로 제공"하는 비즈니스가 아니기 때문이다.

더 나은 라이선스 만들기

또한, Elastic은 Elastic License 2.0을 작성하는 데 리소스를 투입함으로써 라이선스 작성 기술의 발전을 추구하였다. 어떤 의미에서 소스 공개 라이선스는 소프트웨어만큼 오래되었다. 사실, 바이너리 전용 라이선스는 1980년대 PC / Mac 플랫폼 표준화의 산물이었다. 그 이전에는 거의 모든 소프트웨어가 소스 코드 형식으로 라이선스 되었다. 그러나 시간이 지남에 따라 라이선스의 배포 형식과 방법은 크게 달라졌다.

Elastic License 2.0은 이러한 추세의 정점이다. 형식적으로는 오픈소스 라이선스의 가장 인기 있는 간단하고 직관적인 작성 방식과 템플릿을 채택하였다. 또한 라이선스 키 보존 조항을 통해 공급 업체가 무료 및 유료 기능을 모두 갖춘 소프트웨어에 대한 라이선스를 쉽게 사용할 수 있도록 지원한다.

수십 년 전 유닉스에서 분리된 수많은 호환되지 않은 독점 버전과 마찬가지로 독점 라이선스는 제각각의 조항과 조건으로 덕지덕지 붙여진 누더기이다. 일반 소비자 소프트웨어 제품에 대한 단순한 최종 사용자 라이선스조차도 일반적으로 너무 길고 난해하여 대부분의 사용자는 이해할 수 없다. 아무도 그것을 읽지 않는다는 말도 많다. 그러나 이러한 복잡성은 대부분 불필요하다. 오픈소스 라이선스, 특히 허용_permissive 라이선스는 이를 교훈으로 삼았다. 간단한 일련의 규칙으로도 충분해야 하며 이해하기 쉬울수록 사용자가 이를 존중할 가능성은 높아진다.

Elastic License 2.0은 짧고 간단하며 이해하기 쉬울 뿐만 아니라 사람들이 이를 템플릿으로 사용할 수도 있다. 무상 사용 방지 논쟁이 시작된 후, 마찰이 없는 방식으로, 합리적인 제한을 가지며, 간단하고 이해 가능한 라이선스에 대한 수요가 증가하고 있다. 그러나 대부분의 소규모 소프트웨어 회사는 자체적으로 라이선스를 작성할 리소스가 없다. 많은 소프트웨어 스타트업이 Elastic License 2.0과 Confluent Community License와 같은 라이선스를 그들이 채택할 수 있는 모델로 찾고 있는 것은 놀라운 일이 아니다.

이 분야는 Fair Code가 이에 대한 표준을 만들면서 대중화되었다. Fair Code는 다음과 같이 말한다.

Fair-code is not a software license. 
It describes a software model where software:

* is generally free to use and can be distributed by anybody
* has its source code openly available
* can be extended by anybody in public and private communities
* is commercially restricted by its authors

이 계획은 아직 초기 단계에 있지만, 이로써 사용자와 개발자 모두에게 공정한 패러다임의 필요성을 업계가 인식하기 시작하고 있으며, 오픈소스 상용 기업이 오픈소스 모델보다 더 유연한 방식으로 둘 사이의 균형을 맞출 수 있도록 하고 있음은 분명하다. 한 전문가는 최근의 라이선스 발전을 “오픈소스 이후 시대“라고 부르기까지 하였다. 하지만 실제로는 이러한 소스 공개 라이선스는 비즈니스 및 라이선스 모델이 계속 발전함에 따라 일반적으로 오픈소스 라이선스와 함께 사용된다. 따라서 두 모델은 엄격한 대체품이 아니라 보완품이다.

또 다른 표준화된 라이선스 옵션도 있다. 2020년, 한 변호사 그룹은 PolyForm Project를 시작하여 소스 공개 라이선스 템플릿 모음을 작성하였다. 이러한 라이선스는 오픈소스 라이선스와 독점 라이선스 모두에 경험이 있는 변호사에 의해 상호 리뷰되었다. 개방형 콘텐츠 라이선싱을 위한 Creative Commons와 마찬가지로 비상업적, 평가 전용, 경쟁 방지 라이선스 등의 옵션 메뉴를 제공한다. Elastic License 2.0과 같이 모두 무료로 소스 코드에 대한 접근을 제공하며 필요한 특허 라이선스를 부여한다. PolyForm Perimeter 및 PolyForm Shield는 선조라고 할 수 있는 Confluent Community License와 유사하며, Elastic License 2.0은 이러한 추세에 따라 사용 가능한 옵션을 발전시켰다.

질문이 있거나 더 자세한 내용을 알아가고 싶다면 다음과 같은 몇 가지 자료를 참조하라.

“The rise of open source IPOs” https://coss.media/rise-of-the-open-source-ipo/. This article tracks some of the spectacular business successes of open source companies.

“The After Open Source Era Has Started” https://monetize.substack.com/p/open-source-eras . This article discusses the sea change represented by companies moving to source available licenses.

US House of Representatives Committee on the Judiciary’s report on investigation into competition in digital markets, spearheaded by the Subcommittee on Antitrust, Commercial and Administrative Law. https://www.documentcloud.org/documents/7222836-Investigation-of-Competition-in-Digital-Markets.html. Note the mention of Elasticsearch on page 326.

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

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

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

OSCI (Open Source Contributor Index)

https://solutionshub.epam.com/osci

분석 점수에 따르면 구글이 선두에 위치해 있으며, 마이크로소프트, 레드햇이 각각 다음 순위를 차지했습니다. 한국 기업으로는 삼성이 29위, LG 전자가 71위에 랭크 되어 있습니다.

기업별 라이선스 현황

OSCI를 통해 수집된 데이터로 추출된 오픈소스 라이선스 사용조사 도 주목해 볼만 합니다. Google Big Query 같은 툴을 이용하여 측정은 가능했지만 어뷰징 제거 등 유효한 데이터 필터링 안되어서 신뢰도가 낮은편이었는데, OSCI를 구축하면서 의미있는 Github 저장소들을 대상으로 통계를 낸 거라 유용할 것으로 보입니다.

2018 년 초부터 2020 년 중반까지 GitHub에서 생성 된 새로운 공용 리포지토리의 라이선스 선택을 조사했으며, 인기있는 오픈 소스 호스팅 플랫폼의 패턴을 비교하기 위해 GitLab에서 1 년간의 데이터도 함께 연구했다고 합니다.

GitHub 새로운 Repository의 급격한 증가

GitHub에서 생성 된 리포지토리 수가 지난 2 년 반 동안 급격하게 증가하고 있음을 보여줍니다. 이러한 오픈소스의 증가세는 특히 주목해야 하는 트랜드입니다.

2018 년 이후 라이선스 사용 동향

2018 년 초부터 생성 된 저장소를 살펴보면 몇 가지 추세가 두드러집니다.

• 리포지토리의 34 %가 라이선스 파일을 포함하지 않아 오픈 소스 상태에 문제가 있습니다.
• 리포지토리의 21 %가 GitHub에서 표준 라이선스 유형으로 인식되지 않습니다. 이는 일반적으로 라이선스 파일에 사용자 정의 라이선스 텍스트가 포함되어 있기 때문입니다. 종종 표준 라이선스 텍스트의 사소한 편집 만 포함합니다. 마지막으로, 가장 중요한 것은 Apache 2.0과 MIT가 가장 많이 사용되는 두 가지 라이선스 유형이며 전체 저장소의 총 35 % 이상입니다.

라이선스 파일이없는 리포지토리를 제외하면, 리포지토리의 절반 이상이 Apache 2.0 또는 MIT 라이선스를 사용합니다. 리포지토리의 1/3은 특정 형태의 사용자 지정 라이선스 텍스트를 사용하며 나머지 13 %에는 BSD 및 Gnu Public License의 변형이 가장 일반적인 다양한 라이선스가 포함되어 있습니다.

GitHub의 조언에도 불구하고 라이선스 파일없이 생성 된 리포지토리. 데이터는 많은 개별 기여자들이 오픈 소스 프로젝트에 라이선스 파일을 포함하는 것의 중요성을 이해하지 못하고 있음을 시사합니다.

OSCI 순위 상위 5 개 회사의 라이선스 사용

상업 조직에 대한 그래프는 GitHub에서 분석 한 모든 리포지토리와 비교하여 다른 차트를 보여줍니다. Apache 2.0은 지금까지 가장 많이 사용되는 라이선스이고 그 다음으로 사용자 지정 라이선스 텍스트가 있습니다. MIT 라이선스는 상당한 인기를 얻은 유일한 다른 표준 라이선스입니다. 카피 레프트 라이선스는 거의 사용되지 않습니다. 마지막으로, 라이선스 파일이없는 리포지토리 수가 적지 않습니다. 샘플을 수동으로 연구 한 후에는 대부분 코드가 아닌 저장소 (예제 또는 문서)입니다.

상위 5개 기업을 각각 개별적으로 살펴보면 그 결과가 흥미롭고 기업 선호도가 서로 다릅니다.

Apache는 Google, IBM 및 Red Hat에서 가장 선호하는 라이선스입니다. Microsoft에서 대부분의 라이선스는 사용자 지정 텍스트이며 MIT가 다음으로 선호되는 표준 라이선스 유형입니다. 사용자 지정 라이선스 텍스트 중 일부를 수동으로 검토 한 결과 실제로 MIT (코드 저장 소용) 및 CreativeCommons (문서 용)가 종종 있음을 발견했습니다.

대조적으로 Intel은 훨씬 더 다양한 라이선스 유형을 사용하는 것으로 보이며 Apache가 가장 선호되고 사용자 지정 라이선스 텍스트와 3-Clause BSD가 그 뒤를 따릅니다. Intel 용 리포지토리의 사용자 지정 라이선스 텍스트에 대한 수동 연구는 Apache 2.0, 3-Clause BSD 및 기타 표준 라이선스 유형을 기반으로 한 혼합 텍스트를 보여줍니다.

GitLab 분석

2019 년 2 분기부터 2020 년 1 분기 말까지 12 개월 동안 GitHub 결과와 매우 다른 패턴이 나타 났습니다. 특히 이 기간에 생성 된 공용 저장소의 77.7 %는 라이선스 파일이 없습니다. 이것은 개발자가 오픈 소스 라이선스 선택의 필요성과 가치를 다시 한번 인식하지 못한다는 것을 의미합니다. 또한 GitLab과 GitHub에서 오픈 소스 프로젝트를 만드는 사용자의 일부 차이를 반영 할 수 있으며 기업 사용에 비해 개별 사용이 더 많습니다.

라이선스 파일이없는 리포지토리를 제외하면 아래 이미지는 MIT가 37 %로 가장 인기가 많았고, 사용자 지정 라이선스 텍스트가 21 %, GPL 3.0이 17 %, Apache 2.0이 10 %로 그 뒤를이었습니다. GitLab에서 요약하면 허용 라이선스 유형이 다시 가장 많이 사용되는 유형이지만 MIT가 리더이며 Apache 2.0 사용량은 GitHub보다 훨씬 적습니다. 카피 레프트 라이선스는 GitLab과 GitHub에서 비슷하게 적은 점유율을 가지고 있습니다.

결론

다음과 같은 많은 흥미로운 결과를 보여줍니다.

• Apache 2.0 및 MIT가 확실한 리더로서 허용 라이선스 유형에 대한 추세가 증가하고 있습니다. 카피 레프트 라이선스 유형은 약간 사용됩니다.
• 라이선스 없이 생성되는 저장소가 점점 늘어나고 있으며, 이는 특히 개별 개발자가 오픈 소스의 법적 측면을 이해하지 못할 수 있음을 시사합니다.
• 사용자 지정 라이선스 유형은 특히 상업 조직에서 널리 사용됩니다. 대부분의 경우 표준 라이선스 유형을 기반으로하는 것으로 보입니다.