LICENSE, LIC_FILES_CHKSUM, COMMON_LICENSE_DIR, LICENSE_FLAGS_ACCEPTED

markyang92·2022년 9월 7일
Yoctolicense
1

yocto

목록 보기
45/53
post-thumbnail

GPL 규정 준수

copyleft

  • copyleft는 권리를 최대한 활용하고 자유롭게 표현하기 위해 저작권을 사용하는 합법적 방법이다.
  • 리눅스 배포판을 빌드할 때 최소 두 가지 프로젝트(리눅스 커널, 컴파일러)를 사용한다.
    • 리눅스 커널: GPLv2
    • GNU Compiler: gcc (GNU Compiler Collection) : 프로젝트에 사용되는 것에 의존적임
      • GPLv2, GPLv2.1, GPLv3

copyleft 규약과 상용화 코드의 비교

  • 상용화 코드와 카피레프트 코드가 같은 프로젝트에 동시에 존재할 수 있다.
  • 일부가 라이선스 호환 문제를 갖고 있기 때문에 코드와 함께 링크하는 라이브러리를 주의 깊게 봐야한다.

라이선스 규약의 가이드라인

  • 리눅스 기반 시스템은 각기 다른 라이선스를 갖고 있는 여러 프로젝트의 집합이다.
  • Yocto Project는 개발자들에게 대부분 카피레프트 프로젝트 규약이 다음과 같은 조건을 갖는 것을 이해하는 데 도움을 준다.
    • 프로젝트의 소스코드는 바이너리와 함께 제공되어야 한다.
    • 프로젝트의 라이선스는 바이너리와 함께 제공되어야 한다.
    • 프로젝트에 적용된 모든 수정 사항, 환경설정과 빌드 시 필요한 모든 스크립트도 바이너리와 함께 제공돼야 한다.
  • 이는 카피레프트의 저작권을 가진 프로젝트가 수정되면 그 라이선스 문구, 기반 소스 코드 등 모든 수정 사항이 최종 산출물에 포함돼야 한다는 것을 의미한다.
  • 이 사항들은 카피레프트 라이선스에 의해 보장된 대부분에 권리를 포함한다.

GPL

  • GPL 라이선스는 기본적으로 가져다가 배포하는 순간 내 소스코드도 공개, 어디서 가져왔는지 명시해야한다.
    • 즉, 내가 개인컴에 가져와서 막 사용하는 건 공개하지 않아도 된다.
    • 무료로 배포해도 소스코드 공개해야한다.

LGPL

  • L(lesser)GPL
  • 원래 LGPL인 소스코드 + 내 소스코드 -> 하나의 바이너리 가 나올때 (정적링크) = GPL과 동일(내 코드 모두 공개)
  • 원래 LGPL인 소스코드/바이너리 라이브러리 + 내 소스코드/바이너리가 LGPL로 쓰여진 라이브러리를 동적 링킹할 때,
    • 내 바이너리를 배포 시 LGPL 임을 알리고, 내 바이너리의 소스코드 공개 안해도 됨

AGPL

  • LGPL와 동일한데, 웹서버에서 API로 LGPL꺼 쓸때 결과만 가져가는데, 이걸 배포라 할수있나? 면서 악용하던걸 고쳐서, 그 행위도 LGPL과 동일시하게 하는 것: AGPL

MIT, Apache, BSD

  • 가져다 써도 괜찮고 공헌 안해도 되는데 출처는 공개해라

無라이선스

  • 원작자가 모든 권리를 가짐
  • 마음대로 가져가서 사용 시, 저작권 법 침해
    • 사용을 안하는게 나음
  • 내 SW제품에, 다른 공급자들이 만든 라이브러리가 포함 되는 경우
  • 내 SW제품이 오픈 소스패키지를 사용해 빌드되는 경우
  • 내 SW제품이 임베디드 시스템의 일부분으로 HW와 함께 제공되는 경우

우선 위 3가지 모두 임데디드 디바이스를 위한 리눅스 운영체제 스택인 경우, 해당된다.
제품에 오픈소스 SW가 사용됐음을 인지시켜야한다. 소스 코드 포함 방식에 대한 라이선스 텍스트와 정보를 최종 사용자가 이용할 수 있어야한다.

라이선스와 소스 코드 정보는 장치에 포함되거나 다른 방식으로 제공될 수 있다.

  • android를 사용하는 device의 경우, settings 앱의 About Device 메뉴에 있는 Legal Information항목을 통해 라이선스를 확인할 수 있다. 라이선스 정보와 텍스트는 장치에 저장될 수 있다. 특별히 연결되는 장치의 경우, 하이퍼 링크를 통해 라이선스 정보가 보이는 웹사이트로 최종 사용자를 안내할 수도 있다. 최소한의 텍스트 표시가 가능한 사용자 인터페이스를 가진 장치가 편리하며, 이런 인터페이스가 없는 장치를 위해 제조사의 웹사이트 등에 사용자 도큐먼와 함께 라이선스 정보를 제공할 수도 있다.

Yocto는 170개 이상의 일반 라이선스를 가지고 있다. 주요한 라이선스는 오픈소스 라이선스지만, 또한 일부 소프트웨어 패키지들을 위한 상업 라이선스도 있다. 일부 오픈소스 소프트웨어 개발자들은 자신들의 라이선스를 사용하는데, 이 것이 법적으로 적절하지는 않으므로 더 복잡한 문제를 일으 킬 수 도 있다.
오픈소스 이니셔티프(OSI, Open Source Initiative)는 오픈소스 정의를 준수하기 위한 라이선스 검토 과정으로 라이선스들을 검토한다. OSI 웹 사이트에는 조직체의 라이선스 검토 과정을 통과하고 오픈소스 정의에 따라 승인된 약 70개의 오픈소스 라이선스가 목록화 되어 있다.
이를 더 복잡하게 만드는 이슈는 단일 오픈소스 프로젝트가 사실상 여러 라이선스를 사용할 수 있다는 것이ㅏㄷ.

  • 라이브러리 소스코드와 버그 수정 및 개선 같은 작업에 하나의 라이선스가 적용되고, API를 통해 다른 소프트웨어 구성 요소로 인한 라이브러리 사용에 다른 라이선스 스키마가 적용되는 라이브러리. 예를 들면, GnuTLS는 소스를 위해 GPLv3+를 사용하고 다른 구성 요소로 인한 라이브러리 사용을 위해 LGPLv2.1+ 를 이용한다.
  • 서로 다른 라이선스에 의해 개별적으로 부여된 여러 요소로 구성된 패키지. 이 라이선스는 보통 플러그인 방식으로 제공된 패키지에서 찾을 수 있다. 예로 미디어 프레임워크가 있다. 인코더, 디코더를 위한 플러그인이 프레임워크 그 자체, 그리고 FLAC 같은 다른 인코더/디코더와 다르게 라이선스를 할당할 수 있다.

라이선스 지정은 텍스트 문자열이 될 수 있으나 공백을 포함하면 안된다. 표준 라이선스의 경우 meta/files/common-license에 공통 라이선스 파일명을 사용하거나 라이선스 지정으로 meta/conf/licenses.conf에 정의된 SPDX(Software Package Data Exchange) 라이선스 플래그 명을 사용한다. SPDX는 S PDX 작업 그룹에 의해 생성되고 유지되는 라이선스 정보의 표준 형식이다.

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

SPDX-License-Identifier: {$SPDX_license_name}
  • BSD-3-Clause 라이선스로 공개
SPDX-FileCopyrightText: © 2020 Matija Šuklje <matija@suklje.name>

SPDX-License-Identifier: BSD-3-Clause

저작권 표시

  • ©
  • 연도: 처음 소스 코드 파일을 작성한 연도. 한번 작성했으면 더 수정하지 마시오.
  • 저작권 보유자 이름
  • 연락처

poky에 포함된 SW License 관리

  1. 레시피가 어떤 라이선스로 릴리스 되었는가?
  2. 다른 라이선스로 릴리스된 프로젝트가 있는지 아는 것
    즉, 레시피와 프로젝트는 두 개의 다른 개체고, 다른 라이선스를 가진다.
    그리고 그 두 다른 라이선스들은 프로젝트의 일부로 고려돼야한다.

LICENSE

LICENSE : 패키지가 릴리스됐던 라이선스를 기술한다.

LIC_FILES_CHKSUM

  • LIC_FILES_CHKSUM : 패키지를 위한 라이선스 파일과 체크섬을 기술한다.
    프로젝트 마다 라이선스를 다양하게 기술하고 있는 것을 발견할 것이다.
  • 가장 많이 사용되는 라이선스 파일은 meta/files/common-licenses/에 있다.
    ${COMMON_LICENSE_DIR} 변수에 match되어 있다.
  • 자체 Source에서, COPYING, LICENSE와 같은 파일을 가지고 있는 경우
    LIC_FILES_CHKSUM 변수에는 프로젝트의 라이선스 문구의 체크섬을 갖고 있다. 어떤 글자가 변하면 체크섬도 변한다. 이것은 어떤 변화가 일어났는지를 언급하는 데 사용되고 개발자는 수락한다. 라이선스 변화는 문구 수정이 될 수도 있다. 하지만 이로인해 법적 의무가 변할 수도 있다. 그래서 개발자는 이런 변화를 검토하고 이해하는 것이 중요하다.
    다른 라이선스 체크섬이 감지될 때 비트베이크는 빌드 에러를 내고 그 라이선스가 변화된 프로젝트를 가리킨다. 이 소프트웨어를 사용할 때 영향을 미치는 라이선스 변화가 발생할 때 주의 해야한다. 다시 빌드 할 수 있게 하기 위해선, LIC_FILES_CHKSUM값을 변경하고 LICENSE 부분을 라이선스 변화에 맞게 수정해야 한다. 라이선스 용어가 변경됐다면 법률 부서에 의뢰하는 것이 좋다.

상업 라이선스

  • 기본적으로 포키는 상업 라이선스의 제한이 있는 어떤 패키지도 설치하지 않는다.
  • gstreamer1.0-plugin-ugly 패키지를 살펴보자.

  • 이 경우, Source에서 자체적으로 2개의 라이선스 파일을 갖고 있다.
    • COPYING ;md5='md5sum값'
    • tests/check/elements/xingmux.c ;beginline=1;endline=21;md5='md5sum값'
    • 따라서, LIC_FILES_CHKSUM에 기술한다. (둘다 내용은 LGPL-2.1-or-later 같음)
      LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
					file://tests/check/elements/xingmux.c;beginline=1;endline=21;md5=4c771b8af188724855cb99cadd390068"
  • LICENSE에 따로 전반적으로 사용하는 라이선스를 기술한다.
    • LICENSE = "LGPL-2.1-or-later & GPL-2.0-or-later"
  • 위에서 기술된 라이선스용 파일들은
    • LIC_FILES_CHKSUM + LICENSE -> ${DEPLOY_DIR}/licenses/${PN} 에 copy 되어, 체크섬을 수행한다.
  • LICENSE_FLAGS: 라이선스 제한 설정하는 변수다.
    gstreamer1.0-plugin-ugly의 경우 LICENSE_FLAGS += "commercial"로 한다
    • 어떤 레시피는 LICENSE_FLAGS += "＜license＞_${PN}_${PV}"로 설정하기도 한다.
    • commercial은 상업용 라이선스이며, Yocto는 기본적으로 라이선스 에러를 낸다.
    • 상업용 라이선스 레시피를 설치하기 위해선 local.conf에 필요한 특별한 라이선스의 화이트리스트를 적어야한다.
    • 이때 LICENSE_FLAGS_WHITELIST(deprecated) -> LICENSE_FLAGS_ACCEPTED 를 사용한다.
      gstreamer ugly plugin에서 이 패키지만 설치되길 원한다면
      LICENSE_FLAGS_WHITELIST_pn-gstreamer1.0-plugins-ugly = "commercial"
      다른 레시피의 commercial 배제하지만 gstreamer1.0-plugins-ugly는 허용한다.
    • 그러나 bitbake로 이미지에 commercial 패키지를 설치하려면 build/conf/local.conf에
      # LICENSE_FLAGS_WHITELIST = "commercial" (deprecated)
LICENSE_FLAGS_ACCEPTED = "commercial"
      를 명시하자.

카피레프트 규약을 지키기 위한 포키의 사용
다른 라이선스를 가진 패키지를 사용해 리눅스 기반 시스템 제품을 생산 시, 필요한 법적 측면을 이해할 시간

  • 카피레프트 규약 사용 절차의 일부로 공유돼야 하는 결과물을 생성하기 위해 포키에 환경설정을 할 수 있다.

라이선스 검사
카피레프트 규약을 지키는 데 도움을 주기 위해 포키는 이미지가 빌드되는 동안 build/tmp/deploy/license/<image_name-machine_name_datestamp>/ 디렉토리에 라이선스 목록을 만든다.

  • image_license.manifest: 레시피 이름, 버전, 라이선스, build/tmp/deploy/image/<machine>에서 사용할 수 잇는 패키지의 파일을 열거하지만 rootfs에 설치되지는 않는다. 가장 많이 사용되는 예제는 부트로더, 리눅스 커널 이미지, dtb 파일이다.
  • package.manifest: 이미지의 모든 패키지들 목록이 있다.
  • license.manifest: 모든 패키지의 이름, 버전, 레시피 이름, 라이선스의 목록. 이 파일은 카피레프트 규약을 검사하는 데 사용된다.
  • 소스코드 제공
  • 가장 확실한 방법은 포키가 DL_DIR 내용을 공유함으로써 이미지를 사용하는 모든 프로젝트의 소스코드를 제공하는 데 도움을 주는 것이다. 그러나 이 접근 방법은 한가지 위험성이 있다. 내용물을 그대로 공유하는 경우 상용화 코드가 DL_DIR안에 있다면 이것도 함께 공유된다. 추가적으로 이런 접근 방식은 카피레프트 규정에 의해 요구하지 않은 것을 포함한 소스코드도 공유한다.

또다른 방식은 포키가 소스코드의 집합을 생성하고 결과로 나오는 것을 결정하게 설정하는 것이다. 이때 archiver 클래스를 사용한다. 이 클래스는 아키텍처(allarch-poky-linux, arm-poky-linux-gnueabi, x86_64-linux)와 라이선스에 의해 분리돼 build/tmp/deploy 디렉토리에 잇는 각 패키지의 소스코드를 카피한다.

  • arm-poky-linux-gnueabi의 패키지는 build/tmp/deploy/sources/arm-poky-linux-gnueabi/GPLv3/package-name 디렉토리에 있는 GPLv3로 릴리스 한다.

포키는 마지막 이미지를 만들기 전에 소스코드를 묶는 환경설정을 해야한다. 이 것을 하기 위해 local.conf에 다음과 같이 설정한다.

INHERIT += "archiver"
ARCHIVER_MODE[src] = "original"
  • 라이선스 기반의 소스를 공유하게 선택해야 하지만, 이런 접근 방식 조차 build/tmp/deploy/sources를 공유하면 불필요한 상용화 코드가 공유된다는 점을 명심해야 한다. 공유 가능한 곳 또는 어떤 다른 라이선스 조합에서 필요한 공유 전략에 따라, GPLv3 또는 MIT의 라이선스를 가진 패키지만 복사할 수 있다.

GPL 라이선스를 가진 모든 패키지를 복사하기 위해 사용되는 복사 명령어의 예는 다음과 같다.
(http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html)

# Script to archive a subset of packages matching specific license(s)
# Source and license files are copied into sub folders of package foler
# Must be run from build folder
#!/bin/bash
src_release_dir="source-release"
mkdir -p $src_release_dir
for a in tmp/deploy/sources/*; do
	for d in $a/*; do
    	Get package name from path
        p=`basename $d`
        p=${p%-*}
        p=${p%-*}
        # Only archive GPL packages (update *GPL* regex for your license check)
        numfiles=`ls tmp/deploy/licenses/$p/*GPL* 2> /dev/null | wc -l`
        if [ $numfiles -gt 1 ]; then
        	echo Archiving $p
            mkdir -p $src_release_dir/$p/$source
            cp $d/* $src_release_dir/$p/source 2> /dev/null
            mkdir -p $src_release_dir/$p/$license
            cp tmp/deploy/licenses/$p/* $src_release_dir/$p/license 2> /dev/null
        fi
    done
done

라이선스에서 주의를 해야하는 사항에 대해 포키의 도움을 받고 싶다면 ARCHIVER_MODE[filter] ?= "yes" 코드를 local.conf에 추가한다.
기본 환경 설정은 모든 프로젝트마다 소스코드를 갖고 있는 것이다. 즉, 필터가 없는 것이다.
그러나 COPYLEFT_LICENSE_INCLUDE 프로젝트의 소스코드만 갖고 있는 것을 선호한다면 필터를 사용할 수 있다.
COPYLEFT_LICENSE_INCLUDE 변수는 현재 GPL 또는 LGPL 로 시작되는 모든 라이선스를 포함한다. 또 다른 라이선스 또는 변화를 포함하기 결정하길 원한다면 이 변수를 local.conf에 덮어 쓰면 된다.

컴파일 스크립트와 수정된 소스코드 제공

  • 앞 절에서 제공된 환경설정과 함께 포키는 각 프로젝트의 원본 소스코드를 패키징 할 수 있다. 패치된 소스코드를 포함하기 원하는 경우 ARCHIVER_MODE[src] = "patched"만 추가하면 된다. 이 방법으로 포키는 do_patch 작업 후 프로젝트 소스코드를 묶을 수 있다. 레시피 또는 bbappend 파일의 수정을 포함한다.
  • 이런 방식으로 소스코드와 수정 사항은 쉽게 공유될 수 있다. 하지만 여전히 지금까지 만들어지지 않는 정보의 유형이 있다. 그 절차는 프로젝트를 설정하고 빌드하기 위해 사용됐다.
  • 빌드 환경을 재구성하기 위해서 do_configure 작업 후 설정된 프로젝트를 공유해야한다.
    이를 위해 local.conf에 다음을 추가할 수 있다.
ARCHIVER_MODE[src] = "configured"
  • 카피레프트 규약에 관해 Yocto 프로젝트를 사용하지 않는 사람도 고려해야 한다.
  • Yocto 프로젝트를 이용하지 않으면 소스코드에 적용된 패치와 환경설정 과정은 적용 불가능하다.
    이러한 이유로 환경설정이 완료된 소스코드를 공유해야한다. 이를 통해 누구든 빌드 환경을 다시 재현할 수 있다.
  • 소스코드의 모든 것을 공유하기 위한 결과 파일은 압축 파일이다. 다른 대안은 ARCHIVER_MODE[srpm] = "1"을 local.conf에 추가하는 것이다. 결과 파일은 SRPM 패키지가 될 것이다.
  • 라이선스 문구 제공
  • 소스 코드를 제공할 때 라이선스 문구는 그 내부에 공유된다. 최종 이미지에 라이선스 문구가 들어가는 것을 원하면 local.conf에 다음을 추가한다.
COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"

이렇게 하면 라이선스 파일은 루트 파일 시스템에서 /usr/share/common-licenses/에 위치할 것이다.

LICENSE

LICENSES 를 가지는 보통의 오픈소스

  1. 보통의 오픈소스는, Licenses 디렉토리가 있어서, 거기서 라이선스를 관리한다.
    1.1. 예시는 https://github.com/OE4T/u-boot-tegra 이다.

    1.2. Licenses/README가 있다.
    1.3. Licenses/＜license＞.txt 로 각종 라이선스 파일들이 있다.
    1.4 이 라이선스 파일들은 (당연히) 예전에 만들어지고 고유의 md5가 있다.
    1.5 yocto에선, 컴포넌트마다 '라이선스'의 체크섬을 체크한다.

레시피에서의 LICENSE, LIC_FILES_CHKSUM(라이선스1개 사용 시)

  • 레시피 'libubootenv_0.3.2.bb'를 가지고 테스트해본다.
  • 실제로 clone 받아서 있는지, 그리고 md5sum 값이 맞는지 체크해본다.
    • 명시된 레시피의 md5 값과 같다.

레시피에서의 LICENSE, LIC_FILES_CHKSUM(라이선스 README 사용 시)

  • 위의 libubootenv_0.3.2.bb의 경우, 1개의 레시피 파일을 지정해서 md5sum을 체크하는데, 오픈소스에서 자체 Licenses디렉토리를 두고, 많은 license를 사용하며, Licenses/README를 가지는 경우.
  • 이 예제에서는 u-boot-common.inc 레시피(설정) 파일을 예제로 설명한다.

LICENSE를 자체적으로 가지고 있지 않을 경우

  • 오래된 오픈소스 중에는 자체적으로 License 파일을 가지고 있지 않을 때도 있다.
    이경우 yocto에서 제공하는 ${COMMON_LICENSE_DIR}에 있는 것을 사용한다.
    • ${COMMON_LLICENNSE_DIR} 연결
  • LICENSE = "라이선스 지정"
  • LIC_FILES_CHKSUM = "file://위 LICENSE에서 지정한 라이선스 파일;md5=....."
    • OpenEmbedded build system은 라이선스가 변경되지 않게 하기 위해 이 변수를 사용
    • 위 컴포넌트의 라이선스인 ${LICENSE}의 파일 지정 및 체크섬
    • 만약 사용 중인 라이선스가 MIT라면,
      LIC_FILES_CHKSUM="file://${COMMON_LICENSE_DIR}/MIT;md5=......."
  • ${COMMON_LICENSE_DIR}

  • md5는 md5sum의 값
profile
markyang92
pllpokko@alumni.kaist.ac.kr
이전 포스트

clang-sys

다음 포스트

core-image-sato, SDK, TOOLCHAIN_HOST_TASK, populate_sdk, gdb, gdbserver, dev 패키지, debug tools 설치, PACKAGE_DEBUG_SPLIT_STYLE

0개의 댓글