【출시】ASF 인큐베이션 프로젝트 공개 FAQ

이 문서는 ASF의 공식 릴리즈 가이드를 기반으로 릴리즈 과정에서 가장 간과/실수하기 쉬운 부분을 중심으로 추출하여 단순화하였습니다. 각 창고/모듈은 완료해야 합니다. 주의 깊게 읽으십시오. 확실하지 않은 경우 제 시간에 통신하십시오.

참고: 이 글은 인큐베이터 에 합류 한 프로젝트, 즉 인큐베이팅 중인 프로젝트를 중심으로 설명하며 , 졸업 프로젝트 및 기타 유형에 대한 추가 설명은 생략합니다. 

*게시 지침:

https://infra.apache.org/release-distribution.html

0. 서문

 ASF를 처음 접하는 모든 인큐베이션 프로젝트는  첫 번째 릴리스에서 작은 문제와 문제가 많을 것이라고 생각하며 특히  대표적인 대표로서 라이센스/고지/저작권  과 관련된 문제가 있습니다.생각해 본 결과 주요 이유는 :

• ASF의 공식 문서는 꽤 흩어져 있고, 커뮤니티의 일반 개발자와 릴리스에 참여하지 않은 학생은 종종 모든 문서를 읽고 주요 문제를 알아차리거나 편차를 이해하는 데 인내심이 없습니다.

• ASF 공식 문서는 일부 설명에 대해 여전히 모호하거나 PMC/Mentor/Mail이 결정을 논의하도록 직접 권장하지만 결론의 이 부분은 일반적으로 업데이트되지 않고 문서에 기록되지 않습니다.

• ASF 관계자는 skywalking-eye (헤더/종속성) 와 유사한 자동 검사 도구를 권장하지 않습니다   . 이러한 도구는 처음으로 게시하는 학생에게 큰 도움이 될 수 있습니다.

• ASF 문서의 일부 규범/규칙은 엄격하게 요구되지는 않지만 게시 및 투표 시 다른 검토자 습관/선호가 다를 수 있으므로 개선을 위한 몇 가지 "제안"을 제시할 것입니다.

• "중국어/영어" 언어/의미 이해 편차로 인해 일부 콘텐츠의 오해가 발생합니다.

Apache HugeGraph  의 첫 번째 릴리스의 기회를 활용하여  PR/이메일에서 발생한 몇 가지 문제와 경험을 요약했습니다.  인큐베이터  프로젝트 의 출시 과정 에서 문제가 반복적으로 나타났습니다 .

*아파치 휴즈그래프:

https://github.com/apache/incubator-hugegraph

0.1 명사

텍스트에 나타나는 몇 가지 일반적인 명사 약어 :

• ASF:  아파치 소프트웨어 재단

• ASL2.0:  Apache 소프트웨어 라이선스 2.0

0.2 ASF 및 아파치

 신입생들은 ASF 메일/문서에서 아파치 프로젝트를 직접 사용하지 않고 ASF 프로젝트 의 사용을 제안/맞춤화한다는  설명을 자주 보는 이유에 대해 혼란스러워할 수 있습니다 . 이는 Apache 프로젝트가 모호하기 쉽기 때문입니다.  Apache 에는 다른 많은 의미가 있기 때문에 Apache 소프트웨어 라이선스를 사용하는 프로젝트를 참조할 수  있지만 ASF (기초) 프로젝트에는 설명에서 구분되는 몇 가지 별도의 요구 사항/제한 사항이 있습니다. 모든 사람이 해당 의미를 오해하는 것을 방지하고 Apache 소프트웨어 라이선스를  사용하는 비 ASF 프로젝트를 도입하는 것과  ASF 이름으로 프로젝트 종속성을 도입하는 것의 차이점을 더 잘 이해할 수 있습니다.     

1 . 특허

LICENSE 는 사소한 문제가 발생할 가능성이 가장 높은 곳이므로 하나씩 확인하고 확인하십시오(확실하지 않은 경우 공식 지침 /이메일/멘토 통신  참조).

1. 모든 소스 및 바이너리 패키지 ( 출시된 jar  패키지 포함)는 LICENSE + NOTICE + DISCLAIMER 파일을 제공해야 합니다 .   

• 소스 패키지는 프로젝트의 루트 디렉터리에 있어야 합니다.

• 바이너리 패키지는 일반적으로 루트 디렉토리에도 있습니다(참고: 이 항목은 다른 ASF 프로젝트를 참조하며 ASF는 지금까지 엄격한 요구 사항을 찾지 못했습니다).

LICENSE  파일의 원래 버전은 형식/내용이 완전하고 정확해야 합니다. 공식 버전을 직접 다운로드하여 프로젝트 디렉토리에 넣으십시오(텍스트를 수동으로 복사하여 붙여넣지 마십시오).

LICENSE/NOTICE  파일에는 불필요한 정보를 포함하지 않는 것이 좋습니다 . 제 시간에. 

참조된 제3자 라이선스 의 경우 상세 정보를 당사 LICENSE  파일에 첨부해야 하며, 참조된 LICENSE 가 매우 길 경우 별도의 파일을 저장하여 참조해야 합니다.    

LICENSE- <dependency-name>.txt。 

참조 코드의 소스가 표준(수정되지 않은) APL2.0 계약인 경우 상대방이 표준 버전임을 나타낼 수 있으며 반복 복사 없이 루트 디렉토리에서 APL2.0 LICENSE를 직접 참조할 수 있습니다.   

바이너리 패키지도 특별한 주의가 필요합니다. 일반적으로 포함된  LICENSE + NOTICE  파일의 내용은 소스 패키지와 다릅니다. 동일한 파일을 직접 재사용하지 마십시오.

• 소스 코드 패키지는 일반적으로 바이너리/jar 패키지/그림과 같은 종속성을 수반하지 않으므로  LICENSE 및 NOTICE가  훨씬 간단하고 깔끔하며 주로 소스 코드 참조를 선언합니다.

• 바이너리 패키지는 일반적으로 소스 패키지의 두 파일 참조를 기반으로 하며 참조된 모든 타사 종속성/사진/바이너리 파일 및 해당  LICENSE  파일을 보완해야 합니다.

제3자가 여러 LICENSE 라이선스(예:  ASL2.0 및 GPL )에 의존하는 경우 모두 나열하는 대신 하나 의 라이선스 참조 만 선택하는 것이 좋습니다 (다른 사람이 검토하기에는 편리하지 않음).    

• 일반적으로 다중 선택의 기본 기준 은 B 유형이 고려되지 않는 경우 ASF 문서에 언급된 A 유형 느슨한 라이선스를 선택하는 것입니다. 

• 종속  라이선스  파일이 독립적으로 존재하는 경우 선택한 콘텐츠만 선택해야 합니다(예: GPL  또는  기타 중복 선언 참조 제거).

• 실제로 일부 ASF 프로젝트는 LICENSE  파일 의 모든 LICENSE 항목에 대한 종속성을 도입했지만 권장되는 작성 방법이 아닐 수 있습니다(복사 참조는 피해야 함). 

*공식 설명:

https://infra.apache.org/licensing-howto.html

* LICENSE 파일의 공식 버전:

https://www.apache.org/licenses/LICENSE-2.0.txt

* 클래스 A 허용 라이선스:

https://www.apache.org/legal/resolved.html#category-a

문서를 읽는 것 외에도 가장 좋은 방법 중 하나는 공식 예제 /기타 인큐베이터 프로젝트를 참조한 다음 멘토/커뮤니티에 제 시간에 질문하는 것입니다.

• httpd-소스

  • https://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE

• 좌석 터널 - 소스

  • https://github.com/apache/incubator-seatunnel/blob/dev/LICENSE

• 좌석 터널 - 바이너리

  • https://github.com/apache/incubator-seatunnel/blob/dev/seatunnel-dist/release-docs/LICENSE

• linkis-소스

  • https://github.com/apache/linkis/blob/master/LICENSE

• 연결된 - 바이너리

  • https://github.com/apache/linkis/blob/master/linkis-dist/release-docs/LICENSE

참고:  Linkis는  이제 졸업했습니다. 최신 문서를 주의 깊게 참조하십시오. 졸업하기 전에 스냅샷으로 이동할 수 있습니다.

2. 라이선스 헤더

위의 프로젝트 전체에 대한 LICENSE 참조를 마치면 많은 학생들이 혼동할 수 있는  라이선스 헤더에 대해 이야기해 보겠습니다(예를 들어 전역적으로 선언되는 이유와 각 파일을 개별적으로 선언해야 하는 이유).  

• 우선, 대부분의 오픈 소스 조직은 프로젝트의 각 소스 파일 에 명확한 라이센스  설명이 있어야 합니다. 따라서 다른 사람들이 파일만 참조할 때 설명을 유지하는 것이 가장 쉽고/또한 가장 직관적이고 명확합니다. 

• 둘째, 원본 LICENSE 파일은 일반적으로 매우 긴 것을 고려하여 간결함을 위해 파일 헤더에 약식 버전을 인용하여 라이선스 헤더 라고 하며 정식 버전은 루트( LICESEN ) 아래에 배치하도록 규정합니다. 파일 ), 참조 관계 형성;   

• 따라서 동일한 프로토콜이 ASL2.0 이더라도 서로 다른 프로젝트의  라이센스 헤더가  정확히 동일하지 않을 수 있으며 일부 콘텐츠가 추가/삭제되는 것이 정상임을 알 수 있습니다(직접 "통합"하지 않음). . 

*원본 라이선스:

https://www.apache.org/licenses/LICENSE-2.0.txt

2.1 핵심

1.  ASF는 이름 아래 프로젝트의 라이선스 헤더  (파일 헤더)에 저작권 문구를 포함  할 수 없도록 규정하고 있으며 이 부분을 고려해야 합니다. 

   1. 기증 전 저작권을 자발적으로 포기하는 등 불필요한 경우에는 직접 제거하십시오 .

   2.  필요한 경우 NOTICE  파일의 헤드 에 별도로 선언합니다 .

2. 제3자 코드를 인용하는 경우 다른 당사자의 헤더  와 여기에 포함된 저작권  문구를 삭제/수정하지 말고 추가  ASL2.0  헤더를 추가하지 마십시오 .  

• 누구나 일반적으로 플러그인/스크립트를 통한 일괄 형식화 에 익숙합니다 .이 때 타사 코드가 추가 ASL2.0 선언을 추가하지 않는지 확인해야 합니다.

• 또 다른 일반적인 문제는 코드 의 일부만 참조된다는 것입니다 . 어떻게 처리해야 할까요?

1. 1. 약간의 수정/추가(제3자 코드의 경우) , 일반적으로 원본 파일의 라이선스를 사용해야 하며  원본 라이선스/작성 내용을 수정해서는 안 됩니다.

   2. 주요 개정의 경우 ASF는 PMC가 구체적으로 논의하고 처리할 것을 권장합니다("크고 작은" 개정에 대한 엄격한 정의가 없으므로 필요하지 않은 경우 마이너 개정으로 취급합니다).

   3. 내부 구조/클래스(수십 줄)가 큰 파일(수천 줄)에서 참조되는 경우 , 이때 라이선스 헤더 참조를 유지하는 방법은 무엇입니까?(가능한 한 피해야 합니다. 자세한 내용은 기사 끝)

타사 코드의  헤더  형식/문법/구두점에 문제가 있거나 불완전한 경우 (간단한 버전)에도 원본 라이선스 헤더를 수정하지 마십시오 . 

위와 같이 소프트웨어/코드 전체에 여러 선택적 라이선스가 포함되어 있는 경우 다음 옵션 중 하나를 고려하십시오.

• 불필요한 문제를 피하기 위해 Apache의 가장 적합한 클래스 A 느슨한 라이선스를  라이선스 헤더 로 우선 순위를 지정합니다.

• 원본 코드의 라이선스 헤더 에 여러 선택적 라이선스가 언급된 경우 수정할 필요가 없습니다(일반적으로 원본 코드의 작성자가 수정할 권한이 있기 때문입니다).  

*클래스 A 허용 라이선스:

https://www.apache.org/legal/resolved.html#category-a

2.2 특별한 경우

ASF는 일부 파일은 라이선스 헤더를 추가할 필요가 없다고 규정하고 있습니다 .원칙은 "내용/구조에 창의성이 없다"입니다.확실하지 않은 경우 기본적으로 추가해야 합니다  .필요한 예 추가:

1. 짧은 텍스트 정보(일반적인 README, CONTRIBUTING, *.txt, *.md, *.log 및 다양한 린트 파일)    

2. 오류를 보고할 수 있는 헤더 주석을 추가했습니다(일반적인  json  파일).

3. .github  , .git 또는 유사한 파일 아래의 전용 작업 파일 과 같이 소스 코드를 패키징할 때 제외될 수 있는 파일입니다 . 

다음은 권장되는(필수는 아님) 추가의 일반적인 예입니다.

1.  Makefile/pom.xml 등과 같은 패키지 관리/의존성 구성 파일.  ASF는 분쟁을 피하기 위해 필요하지 않은 경우 추가할 것을 권장합니다 ( 이메일 토론 참조) .

2. 프로그램에서 생성한 템플릿/ 사용자가 사용하는 *.conf 및 *.properties 파일은 특정 상황에 따라 PMC에서 논의할 수 있으며, Uncertainty 또는 단위 테스트에 사용되는 구성 파일은 기본적으로 가져오도록 제안 (또는 상담);  

3.  압축된 css/js  및 기타 파일이 있는 경우 자체 프로젝트 개발에서 생성한 경우 원래 헤더 버전 대신 선언의 짧은 버전을 사용하는 것이 좋습니다 .

즉, ASF는 명확하게 사용되지 않거나 추가하기 어려운 경우를 제외하고 권한을 나타내는  라이센스 헤더를  추가할 것을 권장합니다 .

*라이선스 헤더를 추가할 필요가 없는 일부 파일:

https://www.apache.org/legal/src-headers.html#faq-exceptions

*패키지 관리/종속성 구성 파일에 라이선스 헤더를 추가할지 여부에 대한 메일 토론:

https://lists.apache.org/thread/l6w0ytfodywfsb6ky0gd41qfzb148r50

*자체 개발 프로젝트에서 생성된 압축 css/js 및 기타 파일의 짧은 버전 선언:

https://www.apache.org/legal/src-headers.html#is-a-short-form-of-the-source-header-available

3. 공지사항

LICENSE/Header가  자체 + 타사 라이센스를 저장한다는 것을 이해하기가 더 쉽습니다. NOTICE  파일의 기능 은 무엇입니까  ? 간단히 말해서 저작권 + (법적) 필수 라이센스 요구 사항을 저장할 수 있습니다.

1. NOTICE 파일은 ASF 표준 사양을 따라야 하며 형식을 임의로 수정할 수 없습니다  . 

2. NOTICE 파일의 저작권  연도 는 가능한 한 일관성이 있어야 하며(예: 여러 리포지토리가 있음) 최종 연도는 릴리스와 함께 업데이트되어야 합니다(예:  2017-20xx, 릴리스는 xx 연도를 확인해야 함). 

3. 다른 ASF 프로젝트를 참조하는 경우 여기( https://infra.apache.org/licensing-howto.html#bundle-asf-product, 일반 Apache2.0 프로토콜을 참조하는 프로젝트와 동일하지 않음)를 참조하세요. ;

4.  NOTICE를 가능한 한 간결하게 유지하십시오  . 불확실한 참조에 대해서는 커뮤니티/멘토에게 문의하십시오. 사용자(다운스트림)에게 추가 부담(전이적)을 가져오므로 여기에서 필요하다고 가정해서는 안 됩니다.

5. BSD/MIT  라이선스에 포함된 저작권 표시는 암송이 필요하지 않습니다(LEGAL-59).

6. 제3자가 의존하는 NOTICE  파일이 LICENSE 또는 기타 정보를 잘못 인용한  경우 어떻게 선택해야 합니까?  

• 일반적으로 잘못된 부분 을 복사할 필요 없이 필수/컴플라이언스 부분을 선택하기만 하면 됩니다 .

• 확실하지 않은 경우 튜터에게 문의하거나  인큐베이터  커뮤니티에 이메일을 보낼 수 있습니다.

*법률-59：

https://issues.apache.org/jira/browse/LEGAL-59

3.1 공식 + 인큐베이터 예시:

• 공식 최소 템플릿  (권장)

  • https://www.apache.org/licenses/NOTICE-2.0.txt

• 좌석 터널  (권장)

  • https://github.com/apache/incubator-seatunnel/blob/dev/NOTICE

• HTTP 서버(권장하지 않음)

  • https://www.apache.org/licenses/example-NOTICE.txt

4. 면책조항

인큐베이션 중인 프로젝트의 모든 배포 패키지(웹 사이트 포함)는 DISCLAIMER  (면책 조항) 파일을 포함해야 합니다  . 합법적으로 들리는 이 파일에는 두 가지 옵션이 있습니다: (자세한 내용은 공식 설명 참조)

1. 표준 버전:   DISCLAIMER 파일 이라는 ASF의 모든 릴리스 정책을 따를 수 있는 인큐베이팅 프로젝트  (조건이 허용되는 경우 우선 순위가 부여되어야 함);

2. WIP(Work In Progress) 버전 : *GPL/CC 와 같이 "미충족" 조건이 더 느슨한 DISCLAIMER-WIP 라는 릴리스 프로세스 중에 ASF의 요구 사항을 충족할 수 없는 일부 릴리스 정책이 있음을 의미합니다.  -BY  등 X 클래스 호환되지 않는 라이선스는 허용될 수 있습니다(더 특별한 경우 강사/이메일에 문의하는 것이 가장 좋습니다). 

두 설명에 대한 템플릿의 내용이 다르며 특히  WIP  버전은 "알려진 문제 목록"을 구체적 으로 나열해야 합니다 . 졸업 전에 인큐베이션 프로젝트를 업데이트해야 함 표준 면책  조항으로 변환(즉,  WIP  버전에서 관련 릴리스 문제가 해결되었음을 언급함) 

*공식 설명:

https://incubator.apache.org/policy/incubation.html#disclaimers

5. 저작권

저작권 표시는 소프트웨어 보조금의 일부로 ASF에 기부된 경우에만 재배치됩니다.

저작권에 대한 별도 참고 사항:

ASF 프로젝트는  라이선스 헤더 대신 NOTICE 파일에 저작권이  있어야 합니다. 이는 ASF 단독으로 요구되는 사항이며, 저작권을 자유롭게 사용하고 추가하는 다른 프로젝트와는 아무런 관련  이 없습니다. 아파치 라이선스 ( 수화2.0). 오해를 피하기 위해 서두에서 언급한 ASF 프로젝트와 Apache 프로젝트의 중요한 차이점 중 하나이기도 합니다.    

6. GPL

기본적으로 *GPL 라이선스 로 표현되는 코드/바이너리 참조는 ASF 프로젝트에 포함될 수 없습니다. 간단히 말해서: 배포/상업화를 엄격히 제한하는 라이선스/기본적으로 도입할 수 없습니다(자세한 목록은 공식 금지 참조 목록 참조). )  

여기에 포함될 수 없는 것은 소스 코드가 포함되지 않을 뿐만 아니라 컴파일로 생성된 바이너리 패키지가 이론적으로 포함될 수 없기 때문에 유사한 종속성/플러그인을 사용하는 일부 코드는 제거/리팩토링해야 합니다. 그렇지 않으면 매우 까다로울 것입니다. . 다음을 사용할 수 있습니다. 참조를 위한 일반 관행:

1. Oracle의 ojdbc.jar  패키지와 같이 ASF가 허용하지 않는 이러한 종류의 참조를 옵션으로 만드십시오.  필요한 사용자에게 직접 다운로드하고 연결/활성화하도록 알리는 문서를 작성할 수 있습니다.

2.  프로젝트 계약에서 여러 라이선스를 허용하는 경우 ASL2.0  호환 라이선스가 포함되어 있고 선택한 라이선스가 프로젝트 LICENSE 파일에 지정되어 있는 한 사용할 수 있습니다 .

3. 또한 CC(Creative Commons) 라이선스에 주의하세요.ASF가 단독으로 나타나면 허용되지 않습니다 (https://www.apache.org/legal/resolved.html#cc-by) (이는 쉽게 간과될 수 있습니다. 누구나 플러그인 스캐닝을 사용하는 것이 좋습니다).

*ASF는 제3자 오픈 소스 라이선스 계약 소프트웨어 목록 인용을 공식적으로 금지합니다.

https://www.apache.org/legal/resolved.html#category-x

7. 바이너리/아카이브

바이너리 파일 + 별도의 jar 패키지(  아카이브  파일로 간주됨)도 특별한 주의가 필요합니다. 이렇게 하면 게시할 때 많은 불필요한 문제를 피할 수 있습니다.

1. 바이너리 파일은 소스코드 패키지에 가급적 등장하지 않아야 하며, 컴파일/테스트 시 다운로드나 임시 생성으로 인해 기존 파일이 대체될 것으로 판단되는 경우(신규 PR은 재도입을 피해야 함);

2. 상대적으로 크기가 크고 검토하기 어려운 압축 파일(예:  swagger-ui는  Apache에서 라이선스를 부여한 프런트 엔드 패키지)의 경우 소스 코드로 직접 가져오지 말고 컴파일 중에 다운로드하여 압축을 푸십시오.

3. 대부분의 그림도 바이너리 파일로 간주되며 이 부분이 소스코드에 필요하지 않은 경우 패키징 시 제외된 것으로 볼 수 있습니다.

4. 필요한 사진/바이너리인 경우 LICENSE  파일 에 별도의 참조 설명이 있어야 합니다 (추가할 예제). 

8. Git/GitHub/공식 홈페이지 관련

다음은 주로 오해하기 쉬운 몇 가지 기타 세부 정보이지만 실수로 인해 릴리스가 되돌릴 수도 있습니다.

1. 릴리스 브랜치는 개별적으로 업데이트할 수 있지만 릴리스 VOTE  이메일이 전송되면 후속 업데이트 제출을 확정/중지해야 합니다(그렇지 않으면 규정을 준수하지 않는 것으로 간주됨). 

2. 버전을 출시할 때 여러 라운드 가 있을 가능성이 있으므로 태그에 rc 접미사를 사용하는 것이 좋습니다  .  반환됨(필수는 아니지만 권장됨)

3. 분기(branch)는 ASF 메일 (https://lists.apache.org/thread/k08vq5r4nfos2ptn69w2fbm2mvmkb91n) 에서 언급한 것처럼 필요하지 않으므로 재사용을 위해  release-1.0.0을  유지하십시오.

4. 쉽게 확인할 수 있도록 게시 이메일에 태그의 최신  Commit-ID (약어)를 포함할 수 있습니다. 

5. 릴리스가 완료되기 전에는 공식 웹사이트의 다운로드 페이지에 임시 다운로드 주소를 포함할 수 없습니다(마찬가지로 Github의 릴리스 페이지는 최신 릴리스 대신 사전 릴리스를 사용해야 합니다.  

6. 공식 웹 사이트 다운로드 페이지 또는 프로젝트 README  (필수는 아니지만 권장) 에 기본적인 "무결성 검사" + "소스 코드를 컴파일하는 방법" 문서가 있는 것이 가장 좋습니다 . 

8.1 자동 확인(강력 권장)

수동/수동 조작 부주의로 인해 발생하는 수많은 불필요한 작은 문제와 숨겨진 위험을 방지하기 위해 검사를 지원하는 자동  CI/Action을 추가하는 것이 좋습니다. 

1. maven RAT 검사 바이너리/헤더/아카이브(maven 플러그인, Java 전용 - 필수);  

2. skywalking-license-header 확인  (PR에서 댓글 알림을 제공할 수도 있음, 우수 - 필요)

3. skywalking-dependencies 생성 및 확인(적어도 확인 부분을 활성화하는 것이 좋습니다. 문서는 위와 동일합니다. 선택 사항).

4.  릴리스 패키지 확인(HugeGraph에서 작성한 자동 확인 작업 참조 , GPG/SHA/바이너리 파일/빈 파일 (폴더) 사전 확인 등 - 권장)

5. dependency-review-action  (GitHub는 공식적으로 라이선스를 확인/제외할 수 있는 Action을 제공합니다 - 선택 사항).

   ‍

그런 다음 주요 수동 검사는 "라이선스 + 통지 + 타사 종속 헤더 선언"과 같은 문제에 중점을 두어 스크립트로 덮을 수 없는 일부 위치에 집중하여 많은 노력을 줄일 수 있습니다.

*스카이워킹-라이선스-헤더 확인：

https://github.com/apache/skywalking-eyes

*HugeGraph에서 작성한 자동 확인 작업:

https://github.com/apache/incubator-hugegraph-doc/blob/master/.github/workflows/validate-release.yml

*의존성-검토-조치：

https://github.com/actions/dependency-review-action

9. 문제 해결

다음은 ASF 관계자가 직접 설명하지 않거나 명확한 정의가 부족하지만 실제로 발생할 수 있는 몇 가지 골치 아픈 문제/제안입니다.참고할 몇 가지 결론이 있으며 복잡한 제안은 멘토/커뮤니티와 논의됩니다  . 

1. 타사 코드(소스 코드)를 인용한 후, 소스 및 바이너리 릴리스의 서로 다른 LICENSE 파일에 동시에 인용을 추가해야 하나요?

   A: 예, 둘 다 필요합니다(문제 참조).

2.  라이선스 헤더  에 대한 몇 가지 사항 :

• (원칙) 제3자의 코드를 단편적으로 사용하는 것을 권장하지 않으며, 직접 분리하거나 다시 작성하는 것을 우선시하며, 인용해야 할 경우 원본 코드의 라이선스 헤더를 유지해야 합니다. 

• (원칙) 한 프로그래밍 언어에서 다른 프로그래밍 언어로 타사 코드를 변환하는 것은 대대적인 수정이 아니며 원래  라이선스 헤더를 유지해야 합니다  (일부 알고리즘 관련 코드에서 일반적임).

• (특수 사례) 가져온 타사 코드가 코드 파일의 작은 부분에 불과한 경우 라이선스 헤더를 전체 파일의 헤더로 사용해야 합니까?  

1. 1. 인터페이스 정의/하위 클래스/구조를 가져오는 경우 코드 조각의 이 부분에서 라이선스 헤더를 직접 가져올 수 있습니까? 

   2. 라이센스 헤더를 코드 중간에 삽입할 수 없는 경우 헤더 에 두 개의 라이센스 헤더를 유지할 수 있습니까(하나는 ASF이고 다른 하나는 가져옴). 

   3. 라이선스 헤더가 하나만 예약되어 있는 경우 LICENSE 파일 에 가져온 코드 줄의 범위를 지정 해야 하나요 ?  

A: 위와 같은 상황은 최대한 헤더 파일/독립 클래스를 통해 별도로 도입해야 하며, 적은 양의 코드/함수를 참조해야 하는 경우 재작성에 우선순위를 두는 것이 좋습니다. 위의 문제에 빠지다).

‍‍‍‍‍‍‍‍‍‍

위로 스와이프하여 이 기사의 참조를 확인하세요.

• https://incubator.apache.org/guides/releasemanagement.html (인큐베이터 프로젝트 출시 안내①)

• https://www.apache.org/foundation/preFAQ.html (일반적인 ASL2.0 프로토콜 사용 질문)

• https://www.apache.org/legal/src-headers.html(타사 참조를 포함한 일반 라이선스 헤더 참조 문제)

• https://infra.apache.org/licensing-howto.html (라이센스/고지 사항 파일 작성 방법)

• https://www.apache.org/legal/resolved.html#category-x(CC-BY를 포함한 금지된 참조의 공식 목록)

• https://lists.apache.org/[email protected] (ASF 인큐베이터 메일링 리스트)

• …

丨ALC 베이징에서 복각

저자丨imbajin

편집丨Luo Ruiyan

관련 읽기 | 관련 읽기

Kaiyuanshe 자문위원회의 2023 년 1 분기 회의가 성공적으로 개최되었습니다!

ChatGPT와 같은 오픈 소스 소프트웨어, 개발자가 사용할 수 있습니까?

Kaiyuanshe 소개

2014년에 설립된 Kaiyuan Society는 오픈 소스 사업에 자발적으로 기여하는 개별 회원으로 구성되며 "기여, 합의 및 공동 관리"의 원칙에 따라 구성되며 항상 벤더 중립의 특성을 유지해 왔으며, 국제 통합, 커뮤니티 개발, 프로젝트 인큐베이션"은 사명을 가진 오픈 소스 커뮤니티 연맹입니다. Kaiyuanshe는 오픈 소스를 지원하는 커뮤니티, 기업 및 정부 관련 단위와 긴밀히 협력하고 "중국에 기반을 두고 세계에 기여"라는 비전을 가지고 건강하고 지속 가능한 오픈 소스 생태계를 만들고 중국의 오픈 소스 커뮤니티를 촉진하는 것을 목표로 합니다. 글로벌 오픈소스 시스템의 주역이 되기 위한 참여 및 기여자.

2017년 Kaiyuanshe는 ASF와 같은 최고의 국제 오픈 소스 재단의 거버넌스 모델을 참조하여 운영되는 개인 구성원으로만 구성된 조직으로 변모했습니다. 지난 9년 동안 수만 명의 오픈 소스 사람들을 연결하고 수천 명의 커뮤니티 구성원과 자원봉사자, 수백 명의 국내외 강사를 모았으며 수백 명의 후원자, 미디어 및 커뮤니티 파트너와 협력했습니다.