소스 코드 내 저작권 표시 방법

최근 소스 코드 내 저작권 표시가 필요한 이유와 올바르게 작성하는 방법을 소개한다.

By Haksung Jang (@haksungjang) | 2020년 8일 12월

안녕하세요.
오픈소스 분야의 저명한 변호사인 Matija Šuklje는 최근 소스 코드 내 저작권 표시가 필요한 이유와 올바르게 작성하는 방법을 소개하였습니다.
아래 글은 위의 원글을 기반으로 작성하였습니다. 대부분 원글을 그대로 번역하여 저자의 의도가 충실히 전달되도록 하였습니다.

개발자를 위한 간단한 저작권 표시 가이드로 생각하고 시작하였으나, 저작권 정보 표시에 대한 통일된 가이드가 없었기 때문에 가이드 작성이 쉽지 않았다. 결국 새로 하나 작성하기로 하였다.

다음 사항을 고려하며 균형을 맞춰서 작성하려고 하였다.

무엇을 하면 되는지만 간단히 알고 싶어하는 개발자를 위해
단지 모범 사례 뿐만 아니라 그 이면에 있는 이유에 대해서도 이해하고자 하는 FOSS 컴플라이언스 담당자와 법률가를 위해

시간이 극단적으로 없다면, TL;DR에서 최소한의 가이드를 확인하라. 2분 정도의 시간이 있다면 아래의 actual HowTo a bit lower below를 읽어라.

물론, 20분 정도의 시간이 있다면, 처음부터 끝까지 한번 읽어보는 것이 제일 좋다.

TL;DR

아래 포맷의 저작권 및 라이선스 표시 당신이 작성한 모든 소스 코드 파일에 추가하라.

SPDX-FileCopyrightText: © {$year_of_file_creation} {$name_of_copyright_holder} <{$contact}>

SPDX-License-Identifier: {$SPDX_license_name}

예를 들어, 내가 오늘 소스 코드 파일을 하나 작성하였고, 이를 [BSD-3-Clause license][bsd-3-clause] 라이선스로 공개하였다면, 다음과 같은 내용을 파일 상단 주석 부분에 추가한다.

SPDX-FileCopyrightText: © 2020 Matija Šuklje <matija@suklje.name>

SPDX-License-Identifier: BSD-3-Clause

참고로 [REUSE.software][reuse] 프로젝트의 가이드를 따르면 모든 파일에 적절한 표시가 되었는지 확인할 수 있다.

저작권이란?

저작권은 ([베른 협약][berne] 이후) 저작자가 저작물 만들 때 자동으로 생성된다. 모든 저작물은 저작권에 의해 보호되며, 저작권 보유자에게 저작물에 대한 독점적인 권한이 부여된다. 따라서 당신의 저작물(소스 코드, 텍스트, 이미지, 기타 미디어 등)을 다른 사용자가 사용할 수 있게 하려면 그들에게 라이선스를 부여해야 한다. 라이선스의 사전적 정의는 “특정 권리를 실행하기 위해 자격이 있는 기관으로부터 받은 허가"이며, 이러한 허가 없이 특정 권리를 실행하는 것은 저작권 침해와 같은 불법 행위가 된다.

마찬가지로 당신이 다른 사람의 소스 코드를 복사, 수정 등의 작업을 하려면 필요한 권한을 부여 받아야 한다. 즉, 라이선스를 받아야 한다. 만약, 그 라이선스가 권리 실행 허가 조건으로 특정 의무를 요구한다면, 당신은 권리 실행을 위해 그 의무사항도 따라야만 한다.

어쨌든, 저작권법의 기본 요건을 준수해야 하며, 이를 위해서는 최소한 다음 두 가지가 필요한다.

저작자 표시 (attribution) : 저작권 보유자 및/또는 저자를 명시한다. (특히 도덕적 권리를 인정하는 관할권에서)
라이선스 (license) : 라이선스는 저작권 보유자 이외의 다른 사람에게 코드를 사용할 권한을 부여하는 유일한 방법이기 때문에 라이선스를 고지하고 전체 라이선스 텍스트를 제공하는 것이 좋다. 이는 당신이 내보내는 Outbound 라이선스나 (복사된 코드나 라이브러리 같은 3rd party 저작물을 사용하면서) 다른 이로부터 받는 Inbound 라이선스 모두에 해당한다.

Inbound vs. Outbound 라이선스
당신이 사용자(downstream)에게 부여한 라이선스를 Outbound 라이선스라고 부른다. 이는 당신으로부터 흘러나오는(out) 코드의 권한을 다루기 때문이다. 반대로, (동일한 코드의) 사용자 입장에서는 그들에게 흘러들어오는 (In) 코드의 권한을 다루기 때문에 Inbound 라이선스로 간주한다. 간단히 말해, 유입되는 권한을 설명하는 라이선스를 Inbound 라이선스라고 하고, 유출되는 권한을 설명하는 라이선스를 Outbound 라이선스라고 한다. 다행인 점은 저작자 표시는 저자의 권리이지 의무는 아니다. 또한 사용자는 저자가 저작자 표시 권리를 사용한 경우에만 이를 유지해야 하는 의무가 있다. 즉, 저자가 저작자 표시를 하지 않았을 때에는 사용자가 이를 직 표시하려고 수고하지 않아도 된다.

왜 저작권 표시를 해야 하는가?

1989년 베른 협약에 가입하기 전까지 미국 저작권법은 저작물을 보호하려면 명시적인 저작권 표시를 요구하였다. 그러나 베른 협약으로 저작권 표시를 하지 않아도 저작권은 자동으로 생성된다. 그럼에도 저작권 표시는 유용한다.

저작권 표시가 법에 따라 요구되는 것은 아니지만, 실제로는 해당 저작물의 저작권이 누구에게 있는지에 대한 증거로서 매우 유용한다. 또한, 이는 컴플라이언스 측면이나 코드 추적을 위해서도 큰 도움이 된다.

저작권 표시는 실질적으로 다음과 같은 이유로 필요한다.

대부분의 라이선스가 저작권 표시를 요구한다.
라이선스에서 요구하지 않더라도 대부분의 관할권의 저작권 법률에서 요구한다.
(이러한 요구가 없더라도) 사용자는 법적 또는 기술적인 이유로 원저작자에게 연락하기를 원할 수도 있다.

따라서, 저작물에 저작자의 이름과 연락처 정보를 포함하는 것은 의미가 있다.

저작권 표시 및 라이선스 고지의 올바른 방법

저작권 표시

좋은 저작권 표시는 다음 정보로 구성되어야 한다.

© 기호
연도 : 처음 소스 코드 파일을 작성한 연도이다. 한번 작성했으면 더 수정하지 마라.
저작권 보유자 이름 : 일반적으로 저자이지만, 저자의 고용주일 수 있다. 또한, CLA에 따라 다른 법인이나 개인이 될 수도 있다.
유효한 연락처 : 저작권 보유자에게 연락할 수 있는 정보

예를 들어, 오늘 소스 코드 파일을 작성하였다면 다음과 같이 저작권 표시를 파일 상단 헤더 부분에 추가한다.

© 2020 Matija Šuklje <matija@suklje.name>

라이선스 고지

또한, 코드를 공개하면서 라이선스가 무엇인지 알리는 것도 매우 중요한다. SPDX ID를 사용하면 코드의 라이선스를 명확하게 알릴 수 있다. 라이선스 고지가 명확하지 않으면 이를 보는 사용자에게 혼란을 야기시킬 수 있다.

REUSE.software

REUSE.software 프로젝트는 SPDX tag를 사용해서 저작권 표시와 라이선스 고지를 작성하는 Best Practice를 제공한다.

저작권 표시 tag : SPDX-FileCopyrightText
라이선스 고지 tag : SPDX-License-Identifier

아래의 예는 위의 모든 사항을 고려하고 SPDX 및 REUSE.software 요구사항을 모두 준수하는 저작권 표시 및 라이선스 고지이다.

SPDX-FileCopyrightText: © 2020 Matija Šuklje <matija@suklje.name>

SPDX-License-Identifier: BSD-3-Clause

이제 당신이 작성한 모든 소스 코드 파일에 이러한 주석이 포함되었는지 확인하라!

FAQ

왜 연도를 표시해야 하는가?

어떤 사람들은 연도를 생략하고 단순하게 작성하는 게 오히려 저작권 표시를 유지하기 쉬울 것이라고 주장한다. 실제로 이는 Microsoft와 GitHub의 정책이기도 한다.

연도를 표시하지 않는 게 작업을 크게 단순화한다는 데에는 동의하지만, 이를 유지한다면 코드 베이스에서의 모호한 타임라인을 확인하는 데 도움이 된다. 또한, 발명이 처음으로 일반인에게 언제 공개되었는지를 알아내는데 유용할 수 있다. 특히 특허 방어에 유용하게 사용될 수 있다.

이런 사항들을 고려하여 Liferay의 새로운 정책에서는 파일 생성 연도를 작성하고, 연도를 더 변경하지 않다.

왜 연도 표시를 변경하지 말아야 하는가?

다음과 같은 저작권 표시를 보았을 거다.

Copyright (C) 1992, 1995, 2000, 2001, 2003 CompanyX Inc.

이렇게 계속해서 연도를 추가하는 건 이렇게 하면 저작권 보호 기간을 연장할 수 있다는 생각이 있기 때문이며, 실제 널리 행해 지고 있다. 하지만, 불행하게도 이런 작업은 쓸모가 없고, 오히려 해가 될 도 있다.

게다가 새로운 변경이나 기여를 받을 때마다 이렇게 그 연도를 추가하는 행위를 법적으로 본다면 논란의 여지가 있다. 문제는 모든 기여가 저작권을 주장할 수 있을 정도로 독창적이거나 규모가 있지 않다. 따라서, 문제 소지를 없애려면 모든 기여에 대해 법률에 따라 저작권 보호를 받을 수 있을 만큼 독창적인지 여부를 먼저 판단하고, 그에 따라 저작권 표시에 연도를 추가해야할 것이다.아

게다가, 일반적으로 하나의 소스 코드 파일은 소프트웨어를 구성하는 수많은 파일 중 하나일 뿐이다. 소프트웨어가 성장해가면서 새롭게 파일이 추가될 텐데, 그때 새로운 파일에 새로운 작성 연도를 추가해간다면 전체 저작물로서의 소프트웨어에는 최신 연도의 저작권 표시가 이미 포함되고 있는 거다.

Git/VCS 히스토리를 더럽히지 마라
만약 매년 모든 파일에 연도 표시를 새롭게 추가한다면 이로 인해 Git/VCS 히스토리가 불필요하게 길어지게 되고, 저장소 공간을 소비하며, 정작 중요한 정보를 찾을 때 방해가 될 수 있다.

연도를 범위로 표시하는 건 어떤가요?

연도를 범위로 표시하는 것(예: 1999-2020)도 매년 연도 표시를 변경해줘야 하기 때문에 위의 질문에서 언급한 모든 사항이 동일하게 적용된다.

어떤 경우는 ‘{$year}-present’와 같은 형태로 범위를 지정하기도 한다. 이 또한 위에서 언급한 사항들이 대부분 적용되며, 추가로 또 다른 혼란을 줄 수 있다. ‘present’가 의미하는 것은 추상적이다. ‘present’는 어떤 것을 의미하는 걸까요?

파일이 마지막으로 수정 시간?
패키지가 릴리즈된 시간?
처음 다운로드 한 시간?
마지막으로 실행한 시간?
아니면 바로 지금?

이처럼 ‘present’는 전혀 도움이 되지 않는 표시이다.

항상 그렇지는 않다. Git (및 다른 VCS)은 메타데이터 관리에 뛰어나지만, 항상 이 의존하는 것은 주의해야 한다.

더 중요하게는, 파일이 저장소에서 옮기게 되면 메타데이터는 사라진다. 소스 코드만 압축해서 배포한다거나, 저장소를 fork 혹은 rebase하는 방식으로 각 파일을 새로운 코드 베이스로 복사하면 이전까지의 추적 데이터는 더 이상 확인할 수 없다.

왜 © 기호를 사용하는가?

EU에서의 한 예로, 슬로베니아의 ZASP §175. (1)은 독점적 저작권 보유자가 자신의 저작물을 표시하기 위해 “(c)” 또는 “©"로 표시할 수 있다고 명시하고 있다. 반면에 미국에서는 17 U.S. Code § 401. (b)(1) 에서는 다음과 같이 저작물 표시 방법을 지정하고 있다. “the symbol © (the letter C in a circle), or the word “Copyright”, or the abbreviation “Copr.””

왜 연락처를 남겨야 하는가? 두 명 이상의 저자가 있을 때는 어떻게 하는가?

Public Domain은 무엇인가?

일부 관할권 (예: 미국, 영국)에서는 저작권 보유자가 자신의 저작권을 포기하고 저작물을 Public Domain으로 기부할 수 있지만, 대부분의 관할권(예: 대부분의 EU 회원국)에서는 이런 행위가 불가능한다. 이는 관할권에 따라 저자가 자신의 저작물을 Public Domain으로 제공한다고 표시하였다고 하더라도 이것이 실제로 유효하게 하기 위한 법적 기준을 충족할 수 없고, 결국 여전히 저작물에 대한 저작권을 저작권자만 보유하고 있음을 의미한다.

소스 코드를 다른 언어나 컴파일러 및 다른 형태로 변환하더라도 모두 저작권 보유자에게 독점적 권리가 있다. 따라서, minify 한 코드를 사용할 때에도 유효한 라이선스가 필요하다.

← Previous