타사 코드를 수정 한 후 저자로 본인을 포함시켜야합니까?

타사 코드를 수정하거나 수정하는 것이 일반적입니다 (간단한 요지 또는 전체 라이브러리). 그러나 이러한 코드 중 상당수에는 자체 라이센스 규칙이 있으며 결국 저작권 정보가있는 모든 파일에 헤더가있는 것이 일반적입니다.

수정 한 후 다음에해야 할 일이 무엇입니까? 라이센스 정보를 건드릴 수없는 상태로 유지하거나 자신을 포함하여 @author또는 @revision태그 와 같은 정보로 업데이트하려고 합니까?

또 다른 일반적인 문제는 타사 네임 스페이스 / 패키지를 프로젝트 규칙에 맞게 변경하는 것입니다. 일부 라이센스 유형에는 이러한 종류의 정보가 라이센스 블록에 포함되어 있습니다. 자유롭게 변경할 수 있습니까?

이 질문에 대한 답변은 각 라이센스 유형에 따라 다르므로 질문을 더 구체적으로 만들려면 ...

일반적인 라이센스 규칙을 고려할 때 (보통 작은 측면에서 다릅니다.), 수정에 대한 정보 를 라이센스 블록에 자유롭게 추가 하고 코드에서 참조하는 방법 을 수정하는 윤리적이거나 최소한 허용 됩니다. (예를 들어, 사용 YACorp.YALib으로 Utils.YALib)?

수정 한 후 다음에해야 할 일이 무엇입니까? 라이센스 정보를 건드리지 말고 @author 또는 @revision 태그와 같이 자신을 포함하여 업데이트하려고하십니까?

소프트웨어 라이센스와 소프트웨어의 일부인 프롤로그를 혼동하고 있다고 생각합니다.

라이센스는 프로그램에 대한 저작권 소유자가 다른 사람의 사용 조건 (라이센스)을 지정하는 곳입니다. 일부 라이센스는 매우 허용적이고 다른 라이센스는 훨씬 제한적입니다.

프롤로그는 작성자 가 소스 코드의 변경 사항을 추적하는 방법을 제공하기 위해 삽입 @author및 @revision태그를 삽입하는 위치 입니다. 경우에 따라 코드에 사소한 내용을 추가하지 않아도 코드의 해당 부분에 대한 저작권을 주장 할 수 있습니다. 저작권 문제를 다루기 어려울 수 있으며 변호사가 처리하는 것이 가장 좋습니다. 그러나 당신은 구체적으로 당신이 그 측면에 관심이 없다고 말했기 때문에 계속하겠습니다.

또 다른 일반적인 문제는 타사 네임 스페이스 / 패키지를 프로젝트 규칙에 맞게 변경하는 것입니다. 일부 라이센스 유형에는 이러한 종류의 정보가 라이센스 블록에 포함되어 있습니다. 자유롭게 변경할 수 있습니까?

이것은 실제로 프로젝트의 규칙에 달려 있습니다.

프로젝트를 포크하면 원하는대로 할 수 있습니다.

변경 사항을 프로젝트에 다시 제공하려는 경우 확립 된 규칙을 준수해야합니다. 네임 스페이스를 변경해야 할 강력한 이유가 있다면이를 애플리케이션 커뮤니티에 제시해야합니다.

일반적인 라이센스 규칙을 고려할 때 (보통 작은 측면에서는 다릅니다.)

라이센스 블록에 수정 사항에 대한 정보를 자유롭게 추가하고 코드에서 정보를 참조하는 방법을 수정하는 것이 윤리적입니까 (적어도 허용됩니다) (예 : YACorp.YALib을 Utils.YALib로 사용)?

라이센스를 변경하지 마십시오!

우선, 라이센스를 변경할 법적 권리가 없을 것입니다. 둘째, 변경하면 라이센스가 엉망이 될 수 있습니다. 변호사에게 면허 변경을 남겨 두십시오.

프롤로그를 업데이트하는 한 프로젝트 규범에 따라 다릅니다. 일부 프로젝트는 소스 제어를 사용하여이를 추적하기 때문에 프롤로그를 원하지 않습니다. 다른 프로젝트들도 마찬가지입니다. 프로젝트 규칙을 따르십시오.

사실 제 관심사는 법적 측면보다는 "커뮤니티에 대한 존중"에 관한 것입니다. 프로젝트가 사적이거나 개인적인 것으로 간주 될 수 있다면 윤리적으로 남아있을 수있는 정도에 대해 더 많이 묻습니다.

자신의 변화를 지키고 있다면 왜 다른 사람들의 생각에 관심이 있습니까? 자신 만 사용하고 다른 사람에게 배포하지 않는 것은 원래 프로젝트에 영향을 미치지 않습니다. 그래서 그들은 당신이하는 일에 신경 쓰지 않습니다.

변경 사항을 배포하거나 프로젝트에 다시 제공하려는 경우 해당 프로젝트의 규칙을 평가해야합니다. 일부 프로젝트는 포크를 원하지 않으며이를 방지하는 라이센스가 있습니다. 다른 사람들은 "당신이 원하는 것을하라"고 말하면서 당신이 원하는대로 할 수있는 일을 할 수 있습니다. 궁극적으로 여기에 대한 답변은보고있는 특정 프로젝트에 따라 다릅니다.

파일이 "vanilla"가 아니라는 것을 독자에게 알리기 위해 관련 문서 나 문제 추적 시스템에 대한 링크와 함께 주석을 추가합니다.

편집 : 따라서이 상황은 라이브러리와 같은 Linux 배포 패키지가 언제인지 상기시킵니다. 데비안은 패키지를 빌드하고 이름을 지정하는 방법에 대한 지침과 표준을 가지고 있으며, 이는 라이브러리가 일반적으로 사전 빌드되는 방법과 다를 수 있습니다.

더 넓은 세상에 결과를 배포하지 않을 것이라고 생각하기 때문에 라이브러리 이름 지정 / 빌드 / 수정에 대해 부끄러워해야한다고 생각하지 않습니까? 이 경우 변경 내용과 이유를 설명하는 소스와 함께 README를 포함하겠습니다. 예 : README. $ {companyName} .changes

코드의 라이센스 규칙을 참조해야합니다.

일반적으로 많은 오픈 소스 프론트 엔드 애플리케이션 (예 : Firefox, OpenOffice)은 애플리케이션 이름과 로고를 상표로 간주합니다. 따라서 수정 된 버전의 앱을 출시 할 경우 원래 상표 / 무역 드레스를 사용할 수 없습니다 (따라서 IceWeasel, Torbrowser, LibreOffice).

그러나 대부분의 프로그래밍 라이브러리는 누가 무엇을하는지가 명확하다면 (보통 버전 관리 메타 데이터에서 찾을 수있는 경우) 상표에 대해 덜 걱정합니다.

저자 정보는 두 가지 목적으로 사용됩니다.

1. 기한이 지난 곳에 크레딧 제공
2. 가치가있는 곳에서 비난을 받다

변경 사항이 커질수록 후자가 더 중요해집니다. 실제 저작권 정보는 일반적으로 버전 관리에서 찾을 수 있지만 일부 프로젝트는 공식적으로 별도의 파일에 일련의 작성자를 제공합니다. 사람들이 공식적으로 크레딧을받는 컷오프 지점은 각 프로젝트마다 다르므로 의심이가는 경우 원래 작성자에게 문의하십시오.