소스 파일의 저작권 고지 / 면책 조항


60

오픈 소스 프로젝트의 각 소스 파일에 저작권 고지, 다양한 법적 고지 사항 및 때로는 전체 라이센스 계약을 게시하는 것이 일반적입니다. 이것은 (1) 오픈 소스 프로젝트와 (2) 비공개 소스 프로젝트에 실제로 필요합니까? 이러한 통지를 소스 파일에 넣어서 달성하거나 방지하려는 것은 무엇입니까?

나는 이것이 법적 질문이라는 것을 이해하고 프로그래머가 여기에서 완전한 유능한 답변을 얻을 수 있을지 의심합니다. , "모든 사람이"또는 법적 조언을 받았기 때문입니까? 추론은 무엇입니까?

답변:


41

이것이 정말로 필요한가요?

아닙니다. 법적으로 요구되지는 않습니다. (저는 변호사가 아니지만,이 변호사의 진술을 보았습니다.)


개별 파일이 문맥 취할 수있는 프로젝트를 가지고 있다면, 그것은 분별있을 수 있습니다 -하지만 그것은 단지 필요로 같은 말을, 라인의 몇 :

이 파일은 <license> 아래에 릴리스 된 <project>의 일부입니다.
전체 라이센스 세부 사항은 <filename> 파일을 참조하거나 <url>으로 이동하십시오.


무엇이든 프로젝트 루트에 LICENSE 텍스트 파일을 넣고 README 파일에 관련 세부 정보 / 신용 / 등을 넣을 수 있습니다. 읽어보기 파일.


1
전체 라이센스 보일러 플레이트를 넣지 않은 경우 +1 난 그냥 한 줄을 사용합니다 :Copyright YYYY First Last. Subject to the XYZ license.
mk12

1
많은 회사는 "라이센스 관리"를 원하기 때문에 저작권을 갖고 싶어합니다. 다시 말해, 인터넷에서 복사 된 GPL'ish를 확인하십시오. 기본적으로 소스 코드에서 저작권을 찾습니다. 실제로 "Copyright"/ "(c)"를 포함하는 첫 번째 줄입니다. 따라서 해당 라인에는 저작권 보유자 (저자 또는 회사)와 자유 소프트웨어인지 여부에 대한 힌트가 포함되어야합니다. 따라서 @ mk12는 최소한의 모습에 관한 것입니다. 진실은-> 두 번째 또는 세 번째 줄은 소스 코드 이외의 다른 곳에서는 절대 알 수 없기 때문입니다.
Guido U. Draheim

12
Google "IANAL"을하고 싶지만 조금 두려워합니다.
Pieter De Bie

1
@PieterDeBie "나는 변호사가 아니다"의 약어
Adam Lindberg

<license>의 경우 버전 번호를 포함시키는 것이 좋습니다. LGPL 2.1은 오픈 소스 개발자에게 훌륭한 보호막이었습니다. GPL 3.0은 모두를 소비하는 바이러스입니다.
user922020

22

LICENSE 파일을 언급하는 저작권 표시를 간단하게 넣을 수 있지만 일단 릴리스 된 후에는 코드가 원자 적으로 유지된다는 보장이 없습니다. 사실,이다 확실히 그것의 비트와 조각이 적어도 몇 가지 다른 프로젝트에서 리믹스 될 가능성이 높습니다.

그렇기 때문에 모든 소스 파일에 최소한 다음이 있어야합니다.

/* Copyright (C) 1883 Thomas Edison - All Rights Reserved
 * You may use, distribute and modify this code under the
 * terms of the XYZ license, which unfortunately won't be
 * written for another century.
 *
 * You should have received a copy of the XYZ license with
 * this file. If not, please write to: , or visit :
 */

이를 수행하여 두 가지를 수행하십시오.

  • 향후 코드가 어떻게 흩어지고 흩어 지든 상관없이 귀하의 저작권은 주장됩니다.
  • 누군가가 작성한 라이브러리의 일부만받는 경우에도 사용, 배포 및 수정이라는 용어를 명확하게 정의합니다.

많은 사람들이 또한 저작권에 전자 메일 주소를 포함시켜 향후 패치를받는 데 도움이됩니다. 지난달 5 년 전에 작성한 코드에 대한 패치를 받았으며 오랫동안 잊어 버렸습니다. 물론, 그것은 전자 메일 주소를 유지하고 약간의 스팸을 참는 것을 의미합니다.

이제까지 당신이 실제로 필요한 경우 시행 라이센스를, 그 것이다 중요한 상대방이 용어가 모두 제쳐 놓고 농담, 모호한 또는 누락 된 있다고 말할 수있다.

또한 코드의 비트와 조각이 시간이 지남에 따라 다른 비트와 코드 조각으로 어떻게 들어가는 지 보는 것도 재미 있습니다. 대부분의 사람들은 공정하고 저작권 및 라이센스 조건을 존중합니다.


2
"불행히도 XYZ 라이센스의 조항은 다른 세기 동안 쓰여지지 않을 것입니다." 130 년이 지났고 세고 있습니다. : P
Joe Z.

많은 회사는 "라이센스 관리"를 원하기 때문에 저작권을 갖고 싶어합니다. 다시 말해, 인터넷에서 복사 된 GPL'ish를 확인하십시오. 기본적으로 소스 코드에서 저작권을 찾습니다. 실제로 "Copyright"/ "(c)"를 포함하는 첫 번째 줄입니다. 이 예는 "모든 권리 보유"이기 때문에 자유 소프트웨어가 아니라고 말합니다. 즉, 세 번째 장소에 라이센스 시트가 있어야 함을 의미합니다. LICENSE.TXT 파일 또는 실제 용지 일 수 있습니다. 그 의미 때문에 상용구 라이센스 텍스트가 필요 하지 않습니다 .
Guido U. Draheim

4

Open Source! = No Copyright에 주목하고 싶었습니다.

오픈 소스는 저작권을 주장한 다음 특정 법률 문서 (GPL처럼)를 채택하여 다른 사람에게 해당 코드에 대한 권한을 부여합니다.

따라서 결정한 사항은 비공개 소스 코드에 적합하며 공개 소스 코드에도 적합합니다.


1
알토 (Altho)는 오픈 소스 프로젝트에서 다른 소스로 단일 파일을 가져올 가능성이 더 높기 때문에 오픈 소스 프로젝트에서 파일 헤드의 저작권 표시가 더 합리적 일 수 있습니다.
James

1
라이센스는 "저작권을 포기하지 않습니다". 사용 및 / 또는 수정 및 / 또는 재배포 권한을 부여합니다.
글렌 랜더스-피어슨

@ GlennRanders-Pehrson 좋은 지적, 편집했습니다.
James

2

모든 오픈 소스 프로젝트

코드를 사용하고 재배포 할 조건을 정의하고 있습니다 (또는 조건에 따라 다름).

최소한 라이센스는 다음과 같은 질문에 대답 할 수 있습니다.

  • 타당성 : 누군가가 코드를 가져 와서 다른 프로젝트로 발전시킬 수 있습니까? 이러한 현상의 좋은 예는 오픈 소스 Chromium 프로젝트를 기반으로하는 Chrome입니다.
    • 그들은 당신에게 신용을주고, 허가를 구해야합니까?
  • 상업적 사용 : Photoshop에서 타사 DLL로 코드를 상업적으로 사용할 수 있습니까? 그렇다면 다른 조건이 적용됩니까?
  • 재배포 : 코드를 비슷한 용도로 사용하는 소프트웨어에 사용해야합니까? 이것을 요구하는 GPL과 같은 라이센스를 바이러스 라이센스 라고 합니다.

등 그것은 결코 포괄적 인 목록이 아니며, 단지 라이센스가 명확하게 진술 할 질문에 대한 아이디어를 제공하는 것입니다.


1
나는 그것을 이해한다고 생각하지만 왜 각 소스 파일에 법적 통지를해야합니까? 아니면 왜 안된다면 사람들이 그렇게합니까?
mojuba

라이센스가 소스 코드와 분리되어 있어도 라이센스가 손실되지 않도록하는 안전한 방법 인 것 같습니다.
doppelgreener

-1

코드에 저작권을 부여해야하는 또 다른 이유는 다른 사람이 코드를 작성한 사람에게 알리기 때문입니다. 코드의 출처와 사용 시간을보고 싶습니다. 다른 프로젝트에서 코드가 어떻게 사용되었는지 확인하는 것은 흥미롭고 유용합니다. 따라서 법적으로 귀하의 저작물을 저작물에 게시 할 필요는 없지만 정보를 제공하기 위해 추가하십시오. -가시


1
이것은 질문에 대답하지 않습니다. 문제는 저작권 고지 여부가 아니라 전체 라이센스 텍스트를 모든 소스 파일에 넣을지 여부였습니다.
Brandin
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.