오픈 소스 라이센스 및 제한
1) iGaming의 OSS 이유와 위험은 어디에 있습니까?
OSS는 플랫폼 개발 (게임 프론트/백, 결제 통합, 사기 방지, 분석) 을 가속화하지만 라이센스 오류로 인해 코드 공개, 릴리스 차단 및 공급자와의 분쟁이 발생합니다. 명확한 정책, 종속성 레지스트리 (SBOM), 감사 프로세스 및 올바른 라이센스 선택.
2) 라이센스 맵: 유형 및 의미
2. 1 허용
MIT, BSD-2/3-Clause, Apache-2. 0
주요 책임은 통지/저작권 Apache-2를 유지하는 것입니다. 0은 또한 특허 보조금 + "방어 종료" 입니다.
적합한: UI 프레임 워크, 유틸리티, SDK 클라이언트, 로깅/해 보기 라이브러리.
2. 2 약한 카피 레프트
MPL-2. 0, LGPL-2. 1/3. 0
라이브러리/모듈 자체 내에서 변경 사항을 열어야하지만 전체 프로젝트는 아닙니다.
조건이 충족되면 (사용자 교체 가능성, 알림) LGPL과의 동적 연결이 일반적으로 허용됩니다.
2. 3 강력한 카피 레프트
GPL-2. 0/3. 0, AGPL-3. 0
코드와 "연결" 할 때 동일한 라이센스 ("tivoization", "SaaS closure" 조건 AGPL 폐쇄) 에 따라 파생 작업을 공개 할 의무가 있습니다.
게임 코어, 사기 방지, 지불 게이트웨이의 폐쇄 모듈에 대한 위험.
3) 연결 및 "파생 제품" (단순화)
GPL과의 정적 연결 → "감염" 의 위험이 높습니다.
LGPL → 와의 동적 연결은 일반적으로 조건 (교체 가능성, 알림) 에 따라 허용됩니다.
IPC/REST/gRPC, 개별 프로세스 → 성능 위험을 줄이지 만 분석을 취소하지는 않습니다 (AGPL은 "네트워크를 통해" 를 "연결" 로 취급합니다).
플러그인/스크립트는 실제 통합 (API 안정성, 주소 공간으로로드) 에 의해 → 평가됩니다.
4) 특허 및 면책 조항
아파치 -2. 0은 저자의 특허 라이센스를 제공합니다 → 특허 청구의 위험을 줄입니다.
GPL-3. 0/AGPL-3. 0은 특허 방지/우회 방지 위치를 가지고 있습니다.
귀하의 모듈이 특허 중요성 (RNG 수학, 사기 방지 알고리즘) 인 경우 특허 보조금없이 라이센스를 피하거나 상업 계약에 별도의 특허 계약을 추가하십시오.
5) OSS 책임: 정확히해야 할 일
알림/NOTICE 저장 (permisisve).
카피 레프트 구성 요소 (MPL/LGPL/GPL) 및 재 조립 방법의 수정을 보여줍니다.
GPL/LGPL (및 AGPL 용 네트워크 액세스) 에 바이너리를 배포 할 때 소스를 제공하십시오.
정보 상자/OSS 크레딧 페이지에 라이센스를 지정하십시오.
선적시 타사 라이센스 (게임 공급 업체/SDK/모바일 빌드) 를 추적하십시오.
6) 플랫폼 OSS 정책 (권장 최소)
1. 라이센스 분류: 녹색 (MIT/BSD/Apache/MPL), 노란색 (조건에 따른 LGPL), 빨간색 (닫힌 부품의 경우 GPL/AGPL/SSPL).
2. 구성 요소 입학 절차: SBOM → 정기 감사에서 요청 → 법률 및 기술 평가 → 기록.
3. 카피 레프트 격리: 별도의 프로세스/마이크로 서비스, gRPC/HTT 테두리, 정적 연결 없음.
4. SBOM 빌드: 각 prod/stage 릴리스마다.
5. 알림 및 소스: NOTICE/THIRD-PARTY의 자동 생성 및 필요한 경우 소스 게시.
6. 기여 (업스트림): CLA/DCO, 비밀/특허 부족, 법률 협력.
7. 보안: 취약점 스캔, 패치 정책, 면제없이 "핀" 취약한 버전 금지.
7) 일반적인 iGaming 영역의 OSS (모범 사례)
게임 수학/RNG: GPL/AGPL을 피하십시오. 자신의 코드 또는 허용 라이브러리를 선호합니다
UI/클라이언트: 반응/Vue/번 들러-허용 → 확인, 라이센스 및 글꼴 모니터링.
결제/CCM: 엄격한 ToS를 가진 공급 업체의 SDK; 카피 레프트와 혼합하지 마십시오.
관찰 가능성/DevOps: Prometheus/Grafana/Elastic-라이센스 (비 OSS 모듈의 일부) 를 고려하십시오. "서버 측" 조건을 읽습니다.
사기 방지/점수: 모델/규칙-독점; 타사 라이브-허용/MIT/Apache.
8) 호환성 매트릭스 (간단히)
9) 위험 매트릭스 (RAG)
10) 점검표
라이브러리를 추가하기
- 녹색/노란색 목록의 라이센스 라이센스.
- 링크 호환성 (정적/동적/IPC) 이 검증되었습니다.
- SBOM + 버전 + 소스.
- 생성 된 알림 (LICENSE/NOTICE).
출시 전에
- 어셈블리 당 SBOM 저장 (prod/stage).
- 취약성 스캔이 통과되었습니다. 중요한-폐쇄 또는 면제.
- 필요한 소스/패치를 발행 할 준비가되었습니다 (필요한 경우).
- "OSS 크레딧 "/정보 페이지가 업데이트되었습니다.
기여를 위해
- CLA/DCO가 서명했습니다.
- 비밀/특허 부족에 대한 검토.
- 저작권/저작권이 정확합니다.
11) OSS 정책 (스 니펫)
11. 1 분류
green: [MIT, BSD-2, BSD-3, Apache-2. 0, MPL-2. 0]
amber: [LGPL-2. 1, LGPL-3. 0] # speaker only/IPC + conditions red: [GPL-2. 0, GPL-3. 0, AGPL-3. 0, SSPL] # disallow for closed modules11. 2 입학 절차
request → legal+tech review → approve/deny → SBOM entry → periodic audit11. 3 카피 레프트 격리
별도의 서비스, 네트워크 인터페이스, 바이너리 조합, 정적 연결 없음.
라이브러리 빌드 및 업그레이드 문서 (LGPL/MPL).
12) 레지스터 (YAML 템플릿)
12. 1 SBOM/타사
yaml component: "rng-core-utils"
version: "1. 8. 2"
license: "Apache-2. 0"
source: "maven:com. example:rng-core:1. 8. 2"
linkage: "dynamic"
notices: ["apache-2. 0. txt"]
security:
cvEs: []
owner: "Engineering"
approved_by: ["Legal","Security"]
approved_at: "2025-11-05"12. 공개를위한 2 개의 OSS 소스
yaml package: "lgpl-math-lib"
our_version: "2. 3. 1-gamblehub"
license: "LGPL-3. 0"
modified_files: ["matrix. c","fft. c"]
public_src_url: "https://example. com/oss/lgpl-math-lib-2. 3. 1-src. zip"
build_instructions: "BUILD. md"12. 3 예금 레지스터 (업스트림)
yaml project: "open-telemetry"
pr: 4521 author: "dev_a"
cla: true dco: true files: ["exporter. go"]
review_legal: "2025-10-28"
status: "merged"13) 안전 및 준수
CI의 SCA/SAST, 새로운 종속성의 오토 스캔.
패치 정책: P1 취약점-
아티팩트 캐시: 원래 LICENSE/NOTICE를 유지하십시오. 무결성을 확인하십시오 (해시).
수출/제재: 금지 된 국가의 구성 요소/거울을 사용하지 마십시오. 로그 확인.
14) 플레이 북 (운영 시나리오)
P-OSS-01: 닫힌 모듈에서 GPL 감지
링크 인벤토리 → 격리/교체 옵션 → 법적 의견 → 릴리스 수정 → 복고풍 프로세스.
P-OSS-02: 출처 요구 사항
의무 범위를 제한합니다 → 보관소 준비 및 NOTICE → 시간별 전송 → 업데이트 문서.
P-OSS-03: 의존성의 중요한 취약성
백 포트/업데이트 → 특별 릴리스 → 관심있는 → 해상 및 고정 규칙에 대한 알림.
15) 미니 -FAQ
LGPL을 사용할 수 있습니까? 예, 동적 연결/IPC 및 조건 준수 (교체 가능성, 알림).
바이너리를 분배하지 않고 서버의 AGPL-안전합니까? 아니오: AGPL은 네트워크를 통해 서비스와 상호 작용하는 사용자에게 소스 코드를 제공해야합니다
특허 보조금이 필요합니까? 알고리즘 혁신을 가진 모듈에는 바람직합니다. 아파치 -2. 0이 바람직합니다.
사이트에 OSS를 지정하기에 충분합니까? 아니요, 알림, 출처, 지침과 같은 모든 요구 사항을 따르십시오.
16) 결론
OSS와의 협력은 입학 표준, 카피 레프트 격리, 자동 알림 및 어셈블리 당 전체 SBOM과 같은 일회성 점검이 아닌 프로세스입니다. 이 기사를 따르면 "네트워크 카피 레프트" 에서 특허 청구에 이르기까지 개발 속도를 유지하고 법적 함정을 피할 수 있습니다.