The practice of handling with FOSS by GPL v2inthe automotive

1. The practice of handling with
FOSS by GPL v2 in the automotive
Copyright 2018 Byungjoo Hwang(mibbeuda@naver.com)

2. 0. Contents
1. What is GPL v2?
2. Major FOSS as GPL v2
3. GPL v2 조항 분석(The analysis of GPL v2’s conditions)
4. Open source compliance process
5. Open source compliance and ASPICE
6. Recent issues.

3. 1. What’s is GPL v2?

4. 1. What is the GPL v2?
• Free software license by FSF. It has started GNU project project by Richard Stallman
• Anyone can use open source that has GPL v2 freely.
• The any software by GPL v2 can be shared and modified freely by anyone.
Reference: https://www.olis.or.kr/license/Detailselect.do?lId=1004

5. 1. What is the GPL v2?
• GPL v2 license can be copied, distributed and modified.
Reference: https://www.olis.or.kr/license/Detailselect.do?lId=1004

6. 1. What is the GPL v2?
• GPL v2 오픈 소스를 사용 하였다면, 해당 코드를 공개 해야 함.
• 그와 함께 GPL v2의 고지문구도 같이 첨부.
• (when using FOSS by GPL v2, author shall disclose own source code with the GPL v2’s notice file of
full text)
Reference: https://www.olis.or.kr/license/Detailselect.do?lId=1004

7. 2. Major FOSS as GPL v2
(FOSS: Free and Open source software)

8. 2.Major FOSS as GPL v2
• FSF에서 제공하는 리눅스 커널은 대표적인 GPL v2라이선스
• Linux Kernel has GPL v2 license provided by FSF.
Reference: https://www.kernel.org/category/faq.html

9. 2.Major FOSS as GPL v2
• Uboot 역시 대표적인 GPL v2 라이선스
• Uboot has GPL v2 license.
Reference: https://www.denx.de/wiki/U-Boot/Licensing

10. 2.Major FOSS as GPL v2
• Bash는 현재 GPL v3이나, 3.2.57 버전까지는 GPL v2
• Bash’s license is now GPL v3 but it was GPL v2 until v3.2.57
Reference: https://www.gnu.org/software/bash/

11. 3. GPL v2 조항 분석(The analysis of
GPL v2’s conditions)

12. GPL 2 no.2 condition
2. You may modify your copy or copies of the program or any potion of it, thus forming a
work based on the Program, and copy and distribute such modifications or workunder the terms
of
Section 1 above, provided that you also meet all of these conditions:
b) You must cause any work that you distribute or publish, that in whole or in part contains or is
derived from the Program or any part thereof, to be licensed as a whole at no charge to all thir
d parties under the terms of this license.
Program Modification
조건: GPL v2라이선스 기
반에서, 비용 없이
Condition: No charge
based on the GPL v2
배포자
(Distributor)
Recipients

13. FSF (Free Software Foundation) FAQ
Q.)Does the GPL have different requirements for statically vs dynamically liked modules
with a covered work?
A) No. Linking a GPL covered work statcally or dynimically with other modules is making
a combined work based on the GPL covered work. Thus, terms and conditions of GNU
GPL cover the whole combination.
Link: https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic
GPL
Library
My
code
Combined work based on the
GPL covered work
배포자
(Distributor)
Recipients
(수신자)
Link
조건: 전체 모두 GPL v2라이선
스, 비용 없이
Condition: all source code with
GPL v2 . No charge

14. GPL v2 no.3 condition
3. You may copy and distribute the Program (or a work based on it, under section 2)
in object code or executable form under the terms of Sections 1 and 2 above provided
that you also do one of the following
A) Accompany it with the complete corresponding machine-readable source code,
For an executable code work, complete source code means all the source code for
modules it contains, plus any associated interface definition files, plus the scripts used to
control compilation and installation of the executable.
GPL
executable
Complete
source
code
배포자
(Distributor)
Conditions
컴파일 후
(after
compileingBuild
script
Recipients
Complete
source
code

15. 3. GPL v2 조항 분석(The analysis of GPL
v2’s conditions)
1) 배포자가 GPL v2를 썼다면, 다른 수신자에게도 GPLv2로서 제
공. 단 비용 없음.
2) 소스 코드만 제공 하는 것이 아닌, 컴파일이 가능한 환경 파일
툴체인 같은 것도 제공.
When The distributor is used by GPL v2, he shall provide own
source code by GPL v2 with no charge to recipients.
Additionally, it shall provide any configuration file or
information with any toolchains for compile by recipients.

16. 4. Open source compliance process

17. 4. Open source compliance process
4.1 개발 초기 단계( At the beginning phase)
1) 프로젝트 내 오픈 소스 담당자는 아래 사항을 확인 (The person in charge of FOSS in
your project should check these items below.)
a. 고객 요구 사항에 FOSS조항 또는 요구 사항이 있는가 확인
Check if it has FOSS terms and conditions in the customer requirements.
유럽 OEM의 경우 특별 조항이 있음. 또한 Tier2같은 third party에게 오픈 소스 사용 할 수
있다는 요구 사항이 있음.
Europe OEM have special conditions about FOSS. For example, Tier 1 shall allow third
parties as Tier 2 to permit FOSS.
b. 사용 가능한 라이선스, 금지된 라이선스를 파악 (OEM서 보통 GPL v3나, LGPL v3를 사용
금지 하는 곳이 있음.
Check if it has accepted or prohibited FOSS licenses ( OEM don’t sometimes allow Tier1
to use GPL v3 or LGPL v3.)

18. 4. Open source compliance process
4.1 개발 초기 단계( At the beginning phase)
c. 내부 프로세스에 따를 때, 제품 정의 단계 같은 경우, 어떠한 오픈 소스를 사용 할지 미리
조사가 필요.
c. Dev team should investigate for open source licenses to be used at the beginning of
dev phase.
d. 오픈 소스 고지 문구 제공 횟수와 탬플릿은 OEM의 양식에 맞추어 제공 해야 하는지 고
객사와 협의 필요.
Dev team should negotiate that how many times provide FOSS report to OEM .
When providing FOSS report, Tier1 should check if it would comply OEM’s templates.
OEM에게 어떤 분석 도구를 사용하는지 반드시 협의가 필요.
Dev team should make a decision about which tools use to OEM.

19. 4. Open source compliance process
4.1 개발 초기 단계 At the beginning phase
f. 프로젝트 내 3rd parties가 참여 하였다면, 개발 초기 단계에서 3rd parties에 오픈 소스 계약
관련 내용을 소개 하고, 자사의 FOSS 리포트에 맞게 제출 해야 함.
f. In your project, if 3rd parties has joined, Tier 1 should introduce the policies of Tier1’s FOSS
to them. 3rd parties shall submit FOSS report with Tier1’s FOSS template to Tier1 when using
FOSS.
g. 소스 코드와 바이너리 파일을 공개 하는 경우, Tier1의 웹사이트에서 공개 할지 또는, OEM사
에 코드와 바이너리 파일, Tier 1 고지 문구만 제공 할지는 협의가 필요.
When disclosing source code and binary files, Check if Tier1’s web site or OEM’s website use
for posting FOSS to the public.
h. Automotive의 경우, 고지 방법에 대해 반드시 OEM과 협의 하여야 함. 스크린이 있는 경우면,
반드시 해당 고지 문구가 스크린 내 메뉴에 보여야 하는 경우가 있음.
In the automotive field, Tier1 shall negotiate the way of how to notice FOSS license full text
with OEM. If any products has the display, There is any case that the license full text for FOSS
shall displayed in the menu.

20. 4. Open source compliance process
4.2 개발 중간 단계 (4.2 At the middle phase of SW development)
1) 프로젝트 진행 중, 일부 모듈에 대해 3rd parties가 개발 하고 있다면, 반드시 오픈 소스 사용
유무와 함께 리포트를 받아야 함. ( In case 3rd parties are developing any modules in your
project, Tier1 shall get FOSS reports from third parties)
2) 중요 릴리즈 ex. Official release 중에서 오픈 소스 보고서를 제공 하는 경우는, 각 릴리즈 상
code fix후 오픈 소스를 분석 하여 오픈 소스 리포트를 제공.
At the major SW release, in case Tier 1 should provide FOSS report to OEM, After code
fix at the each release, dev team analyze FOSS and then provide FOSS reports to OEM.
3) 고객 요구 사항에 오픈 소스 관련 조항이 있는 경우, 시스템 요구 사항과 소프트웨어 요구 사
항에 해당 내용을 추가. 요구 사항의 추적성을 위해 나누는 것이 바람직. 또한 주요 회사의 gate
시 오픈 소스 확인 섹션이 있을 시 해당 내용을 비기능 요구 사항으로 처리 하는 것이 바람직.
If there is FOSS’s terms or conditions in the customer requirements, Tier1 should add any
requirements about FOSS to system requirements and SRS. Also at the Tier1’s major phase, if
it has FOSS’s section for Pass or fail, dev team would include its requirements as non-
functional requirements in the SRS.

21. 4. Open source compliance process
4.2 개발 중간 단계(4.2 At the middle phase of SW development)
1) 고객 요구 사항 예시(Customer requirements’ Example)
“Tier 1은 오픈 소스를 사용시에 반드시 오픈 소스에 대한 사용 리포트를 OEM에서 제공하는 리포트를 사용 하여
야 한다.” In case Tier 1 use FOSS, Tier 1 shall use OEM’s template when making FOSS reports
“Tier 1은 3rd party가 오픈 소스를 사용시, 이를 허락해주어야 한다.”
If 3rd parties use FOSS, Tier 1 shall be permitted.
2) 시스템 요구 사항 예시(System requirements’ examples)
다음과 같이 오픈 소스가 GPL v2의 라이선스를 사용 한 경우 XXX사의 오픈 소스 홈페이지에 코드 공개 대상은
아래와 같다.
“리눅스 커널 내의 드라이버를 수정한 경우“
“GPL v2인 오픈 소스를 원본 그대로 사용 하였거나, 수정한 경우
When using FOSS by GPL v2, XXX company shall disclose own source code and related binary files with Tool
chain below.
- In case modifying driver’s code in the Linux Kernel
- In case using original source code by GPL v2 or modifing them.

22. 4. Open source compliance process
4.2 개발 중간 단계 (At the middle phase of SW development)
3) 소프트웨어 요구 사항 의 예시 중( The examples in the SRS)
XXX에서 제공한 리눅스 커널의 ver. XX를 사용 한 경우 이 라이선스가 GPL v2이면, 해당 코
드와 바이너리 파일은 XXX의 오픈 소스 사이트에 공개 하여야 한다.” 공개는 SW PPAP종료
시점 XX이벤트 시점까지 오픈 소스 사이트에 업로드 되어야 한다.
In case Tier1 use Linux Kernel ver.XX provided by XXX(Third parties) and it is GPL v2, dev
team shall disclose Linux Kernel’s source code with Tool chain and how to build by
anyone to the XXX company’s open source distribution site by internal SW PPAP phase.
Verification method: Manual review after analyzing FOSS by Blackduck Protex
Verification criteria: They shall be protected by GPL v2.

23. 4. Open source compliance process
4.2 개발 종료 단계(at the end of development)
1) 개발 종료 시점은 보통 OEM이 요구한 SW PPAP전 시점. ( The finish period of
development is at the point before SW PPAP from OEM.
2) 리눅스 커널 공개시, 반드시 소스 코드와 함께 툴체인 및 빌드 방법을 제공 해야 함.
In case of disclosing Linux Kernel by GPL v2 to the public, it shall provide own source
code and toolchain with the way of how to compile.
3) OEM과의 결정에 따라, 고지 문구는 Tier1 배포 사이트에 업로드.
The notice files for FOSS shall post to Tier1’s website according to OEM’s decision.
4) OEM에서 SW PPAP진행시, OEM이 소스 코드와 바이너리 파일 요구시 제공 하여야 하
고 준수 해야 함.
On the progress of SW PPAP by OEM, In case OEM requests Tier 1 to provide open
source code and binary files, Tier 1 shall be complied.

24. 5. Open source compliance and
ASPICE

25. 5. Open source compliance and ASPICE
1) 프로젝트에서 오픈 소스 사용시, 반드시 프로젝트 계획서에 오픈 소스 사용에 대한 정
책 명시. ( In case it uses FOSS in your project, you shall address FOSS’s policies in
your project plan.)
2) 시스템 요구 사항, 소프트웨어 요구 사항에 반드시 명시. You shall include FOSS’s
requirements in the your system requirements and SW requirements specification.
3) 형상 관리 측면에서는, 고지 문구와 FOSS 분석 reports는 형상 아이템으로 식별 하여야
함.
Configuration manager should identify the configuration items as Notice files of license
full texts and FOSS analysis reports.
4) 필요시 오픈 소스는 단위 검증이나 정적 분석에서 제외. (If needed, open source code
would be excluded in the SW unit verification and static analysis.
5) 각 오픈 소스 정보에는, 다운로드 사이트, 버전 정보, copyright 정보가 포함 되어야 함.
Each open source’s information should include downloaded site, version info and
copyrights.

26. 6. Recent issues

27. 6. Recent issues
1) Simulink 로 MBD로 개발시, 시뮬링크 내의 기능 중 S-function을 사용하여 외부 코드를
import하여 개발할 때, 해당 코드가 GPL v2인 경우면,
2) 시뮬링크의 auto gen되서 나온 코드는 GPL v2의 파생 저작물로 봄. 따라서 공개 해야함.
1) When you develop MBD(Model based design) by Mathworks’ Simulink, you used S-
function that can import external source code in the Simulink. And then external source code
was GPL v2.
2) The auto code by Simulink is any derivative work by GPL v2. So you shall be disclosed to
the public.
3) 유럽 OEM의 경우, FOSS report의 탬플릿이 대다수 영문임. 퀘백의 경우, 고지문구가 불어로
제공 되어야 하는 경우가 있어. Tier1은 OEM과 반드시 협의 해야 함.
4) When providing FOSS reports by Europe OEM to Tier1, their templates for FOSS are in
English. But, Quebec’s official language in Canada is French. Tier1 would make notice
files of each license full text as French version. So Tier1 shall discuss with OEM regarding
how to handle this issue.