├── README.md ├── assets ├── cover.jpg ├── image1.jpg ├── part1 │ └── 02 │ │ ├── 01 │ │ ├── image2.jpg │ │ └── image3.jpg │ │ ├── 02 │ │ └── image4.jpg │ │ ├── 03 │ │ ├── image5.jpg │ │ ├── image6.jpg │ │ └── image7.jpg │ │ ├── 04 │ │ ├── image10.jpg │ │ ├── image8.jpg │ │ └── image9.jpg │ │ └── 05 │ │ ├── image11.jpg │ │ ├── image12.jpg │ │ ├── image13.jpg │ │ ├── image14.jpg │ │ └── image15.jpg └── part2 │ ├── 01 │ └── 03 │ │ └── image2.jpg │ ├── 02 │ ├── 01 │ │ └── image3.jpg │ ├── 02 │ │ ├── image4.jpg │ │ ├── image5.jpg │ │ ├── image6.jpg │ │ └── image7.jpg │ ├── 03 │ │ ├── cb_img_1.jpg │ │ ├── cb_img_2.jpg │ │ ├── image8.jpg │ │ ├── tb_img_1.jpg │ │ └── tb_img_2.jpg │ ├── 04 │ │ ├── cb_img_10.jpg │ │ ├── cb_img_11.jpg │ │ ├── cb_img_12.jpg │ │ ├── cb_img_13.jpg │ │ ├── cb_img_3.jpg │ │ ├── cb_img_4.jpg │ │ ├── cb_img_5.jpg │ │ ├── cb_img_6.jpg │ │ ├── cb_img_7.jpg │ │ ├── cb_img_8.jpg │ │ ├── cb_img_9.jpg │ │ ├── git_img_1.jpg │ │ ├── git_img_2.jpg │ │ ├── git_img_3.jpg │ │ ├── git_img_4.jpg │ │ ├── image10.jpg │ │ ├── image11.jpg │ │ ├── image12.jpg │ │ ├── image13.jpg │ │ ├── image14.jpg │ │ ├── image15.jpg │ │ ├── image16.jpg │ │ ├── image17.jpg │ │ ├── image18.jpg │ │ └── image9.jpg │ ├── 05 │ │ ├── cb_img_14.jpg │ │ ├── image19.jpg │ │ ├── image20.jpg │ │ ├── image21.jpg │ │ ├── image22.jpg │ │ ├── image23.jpg │ │ ├── image24.jpg │ │ ├── image25.jpg │ │ ├── tb_img_1.jpg │ │ ├── tb_img_2.jpg │ │ ├── tb_img_3.jpg │ │ ├── tb_img_4.jpg │ │ ├── tb_img_5.jpg │ │ ├── tb_img_6.jpg │ │ ├── tb_img_7.jpg │ │ ├── tb_img_8.jpg │ │ └── tb_img_9.jpg │ └── 06 │ │ ├── image26.jpg │ │ ├── noname_1.jpg │ │ ├── noname_10.jpg │ │ ├── noname_11.jpg │ │ ├── noname_12.jpg │ │ ├── noname_13.jpg │ │ ├── noname_2.jpg │ │ ├── noname_3.jpg │ │ ├── noname_4.jpg │ │ ├── noname_5.jpg │ │ ├── noname_6.jpg │ │ ├── noname_7.jpg │ │ ├── noname_8.jpg │ │ └── noname_9.jpg │ ├── 03 │ └── image27.png │ └── image1.jpg ├── docs ├── IITP_OSS-Guideline_V1.0.1 (file size).pdf └── files ├── part1 ├── 01 │ ├── 01.md │ └── 02.md ├── 02 │ ├── 01.md │ ├── 02.md │ ├── 03.md │ ├── 04.md │ └── 05.md ├── 03 │ ├── annex1.md │ ├── annex2.md │ ├── faq.md │ └── refList.md ├── target-configuration.md └── terms-definition.md ├── part2 ├── 01 │ ├── 01.md │ ├── 02.md │ ├── 03.md │ ├── 04.md │ └── 05.md ├── 02 │ ├── 01.md │ ├── 02.md │ ├── 03.md │ ├── 04.md │ ├── 05.md │ └── 06.md ├── 03 │ ├── annex1.md │ ├── annex2.md │ ├── annex3.md │ ├── faq.md │ └── refList.md ├── target-configuration2.md └── terms-definition2.md └── publish.md /README.md: -------------------------------------------------------------------------------- 1 | # 공개SW R&D 실무수행 가이드라인 1.0 2 | 3 | Open Source Software R&D Projects의 수행에 참고하는 IITP 공개SW R&D 실무수행 가이드라인 1.0 입니다.
4 | + [가이드라인 목차 바로가기](#content) 5 | + [IITP_OSS-Guideline_V1.0 화일 폴더 열기 (다운로드)](https://github.com/iitp-rnd/oss-guideline/blob/main/docs/) 6 | + [정보통신기획평가원(IITP 홈페이지 공개자료실)에서 화일 다운로드](https://www.iitp.kr/kr/1/knowledge/openReference.it) 7 | * 에러 발생시, IITP 홈페이지(https://www.iitp.kr) 메인-공개자료실로 이동후 다운로드 8 | 9 |

공개SW R&D 실무수행 가이드라인 1.0


10 | 11 |
12 |
13 | 14 | ## <보도자료 주요내용> 15 | 16 | - 정부는 정보통신기술 연구개발 전담기관인 정보통신기획평가원(IITP)과 함께 연구개발 현장의 의견을 청취하고 공개 소프트웨어 방식의 연구개발을 수행 중인 연구원의 노하우 등을 반영, 실제 연구 수행 과정에서 참고할 수 있는 가이드라인을 개발하였다. 17 | 18 | + 이번 가이드라인은 공개 소프트웨어 연구개발을 수행 전(前)과 수행 중 단계로 구분하고, 단계별로 연구자가 검토해야 하는 항목들을 순서대로 설명함으로써, 가이드라인 순서대로 따라가면 연구개발을 수행할 수 있도록 제작되었다. 19 | + 또한, 접근성을 높이기 위해 현장에서 빈번하게 발생하는 질의사항들을 질의응답으로 정리하고, 수행 단계에서는 이해하기 쉽도록 공개 소프트웨어 방식의 연구개발이 진행 중인 실제 사례를 제시하였다. 20 | 21 | - 수행 전 단계에서는 공개 소프트웨어 연구개발의 목적, 영리 목적의 연구개발 시 적용 가능한 사업 모델, 라이선스 정책 및 외부 공개 소프트웨어 활용 시 리스크 관리 등 연구개발을 수행하기 전 단계에서 미리 검토되어야 하는 사항들을 해설하였다 22 | + 수행 단계에서는 준비→분석→검증→확산에 이르기까지 공개 소프트웨어 연구개발의 모든 단계에서 실무자가 검토해야 할 사항들을 해설하였다. 23 |
24 |
25 | 26 | 본 가이드라인의 목차 구성은 다음과 같습니다.
27 | 28 | 가이드라인은 공개SW R&D를 계획하고 수행하는 기업 및 연구소, 대학의 연구책임자 및 연구원들에게 도움을 주고자 크게 2개 파트로 구성하고 있습니다.
29 | 30 | - 첫 번째 파트는 연구를 수행하기 전에 사전 연구계획 준비과정에서의 정책 수립시 검토할 사항을 제시하고,
31 | - 두 번째 파트에서는 연구 수행 중에 발생하는 실무자의 궁금한 점을 모아서 연구개발 단계별로 따라할 수 있도록 구성하고 있습니다.
32 | - 또한, 파트별로 자주 묻는 질문을 FAQ로 구성하여 설명하고 있습니다.
33 | 34 |
35 | 36 | - [책자 안내] 37 | + 공개SW R&D 과제를 준비하는 과정에서 어떤 항목을 검토해야 하는지 궁금한 사항은 [“[파트 1] 2장 1. 공개SW R&D 계획수립의 단계별 검토사항 개요”](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/02/01.md)를 참고하세요.
38 | + 프로젝트에 적합한 오픈소스 라이선스를 어떻게 결정해야 하는지 궁금한 사항은 [“[파트 1] 2장 3. 2단계 공개SW R&D 라이선스 정책수립 단계”](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/02/03.md)를 살펴보세요.
39 | + 공개SW R&D과제의 기술이전을 준비하는 과정에서 어떤 유형을 검토해야하는지 궁금한 사항은 [“[파트 1] 2장 5. 공개SW R&D 기술이전시의 검토사항”](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/02/05.md)을 참고하세요.
40 | + 프로젝트의 소스코드를 어떻게 관리해야 하는지 궁금한 사항은 [“[파트 2] 2장 4. 공개SW R&D 과제 구현”](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/02/04.md)을 통해 프로젝트의 개발방법론, 형상 관리, 커밋, 이슈, 릴리즈 등의 과정을 알아보세요. 이 내용에는 공개SW 프로젝트의 업스트림 개발과정 및 소프트웨어 소스 코드 형상 관리와 지속적 통합 환경을 구축하고 프로젝트를 관리하는 방법을 설명하고 있습니다. 41 | + 공개SW R&D는 어떤 항목을 성과지표로 관리해야 하는지 궁금한 시항은 [“[파트 2] 2장 5. 공개SW R&D 과제 검증”](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/02/05.md)을 살펴보세요.
42 | 43 | 44 |
45 |
46 | 47 | ## 목차 48 | + ### [파트1] 사전 준비단계 49 | + [가이드의 대상 및 구성](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/target-configuration.md) 50 | + [용어 설명](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/terms-definition.md) 51 | + 1장. 공개SW R&D의 개요
52 | - [1. 일반SW R&D와 공개SW R&D의 차이점](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/01/01.md) 53 | - [2. 공개SW R&D 개요 및 기대효과](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/01/02.md)
54 |      가. 공개SW R&D의 개요
55 |      나. 공개SW R&D의 기대효과
56 | + 2장. 공개SW R&D 계획수립의 단계별 검토사항 57 | - [1. 공개SW R&D 계획수립의 단계별 검토사항 개요](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/02/01.md)
58 |      가. 공개SW R&D 계획수립의 검토 단계
59 |      나. 공개SW R&D 계획수립의 검토 절차
60 | - [2. 공개SW R&D 추진전략 및 사업모델 수립단계](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/02/02.md)
61 |      가. 공개SW R&D 추진전략 수립
62 |      나. 공개SW R&D 사업모델
63 | - [3. 공개SW R&D 라이선스 정책수립 단계](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/02/03.md)
64 |      가. 공개SW R&D에 적용할 공개SW 라이선스 분류기준
65 |      나. 사업화를 위한 공개SW R&D의 사업모델에 따른 라이선스 정책검토
66 |      다. 비영리 목적의 공개SW R&D의 라이선스 정책검토
67 |      라. 공개SW R&D 대표 라이선스 및 호환 라이선스 정책 검토
68 | - [4. 공개SW 사용정책 및 절차 수립단계](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/02/04.md) 69 | - [5. 공개SW R&D 기술이전 검토사항](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/02/05.md)
70 |      가. 공개 R&D 결과물의 기술이전 유형
71 |      나. 공개 SW R&D 결과물의 기술이전 유형별 검토사항
72 | + [3장. 자주 묻는 질문과 답변(FAQ)](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/03/faq.md)
73 | + [별첨 1. 공개SW 라이선스 의무사항](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/03/annex1.md)
74 | + [별첨 2. 사용·결합·통신 방식에 따른 라이선스 의무사항](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/03/annex2.md)
75 | + [참고문헌](https://github.com/iitp-rnd/oss-guideline/blob/main/part1/03/refList.md) 76 | 77 |
78 | 79 | + ### [파트2] 연구수행 실무단계
80 | + [가이드의 대상 및 구성](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/target-configuration2.md) 81 | + [용어 설명](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/terms-definition2.md) 82 | + 1장. 공개SW R&D의 개요 83 | - [1. 공개SW R&D 과제란](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/01/01.md) 84 | - [2. 일반SW R&D와 공개SW R&D의 차이점](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/01/02.md) 85 | - [3. 공개SW R&D 과제의 성장 단계](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/01/03.md) 86 | - [4. 공개SW R&D 과제 점검표](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/01/04.md) 87 | - [5. 공개SW R&D의 기대효과](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/01/05.md) 88 | + 2장. 공개SW R&D 수행 가이드 89 | - [１. 공개SW R&D 과제 수행 준비](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/02/01.md)
90 |      가. 관리 정책 수립
91 |      나. 수행 조직 구성
92 |      다. 개발환경 구축
93 |      라. 참여연구원 교육 94 | - [２. 공개SW R&D 과제 분석](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/02/02.md)
95 |      가. 요구분석 및 조사
96 |      나. 공개SW 분석 및 평가 97 | - [３. 공개SW R&D 과제 설계](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/02/03.md)
98 |      가. 공개SW 연구개발과제의 소프트웨어 설계 방식
99 |      나. 공개SW 연구개발과제의 소프트웨어 재사용에 대한 접근
100 | - [４. 공개SW R&D 과제 구현](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/02/04.md)
101 |      가. 공개SW R&D 과제의 개발 방법론
102 |      나. 공개SW R&D 과제의 소프트웨어 형상 관리
103 |      다. 공개SW R&D 과제의 이슈 관리
104 |      라. 공개SW R&D 과제의 릴리즈 관리
105 | - [５. 공개SW R&D 과제 검증](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/02/05.md)
106 |      가. 공개SW R&D 과제의 테스트
107 |      나. 공개SW R&D 과제의 성과지표 관리
108 |      다. 공개SW R&D 과제의 라이선스 검증
109 |      라. 공개SW R&D 과제의 보안 취약점 검사
110 | - [６. 공개SW R&D 과제의 커뮤니티 관리](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/02/06.md)
111 |      가. 공개SW 커뮤니티의 이해
112 |      나. 커뮤니티 거버넌스
113 |      다. 커뮤니티 구성원의 고려사항
114 |      라. 웹사이트 및 포럼
115 |      마. 기여자 가이드라인
116 |      바. 마일스톤 및 로드맵 공유
117 |      사. 협력기업 관리
118 |      아. 지식 재산권 관리
119 |      자. 모니터링
120 |      차. 홍보
121 |      카. 문서화 122 | + [3장. 자주 묻는 질문과 답변(FAQ)](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/03/faq.md) 123 | + [부록 1. 기여자 행동 강령 규약의 예](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/03/annex1.md) 124 | + [부록 2. 기여자 라이선스 동의서 예](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/03/annex2.md) 125 | + [부록 3. 기여자 가이드라인 문서 예](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/03/annex3.md) 126 | + [참고문헌](https://github.com/iitp-rnd/oss-guideline/blob/main/part2/03/refList.md) 127 | 128 |
129 | 130 | ## *CONTRIBUTING* 131 | 132 | 본 가이드라인의 작성 내용은 오픈소스 개발 방법을 적용하여 여러분의 기여를 통해 개선해 나갑니다.
133 | 134 | - 일반적인 GitHub Flow에 따라 수정 사항 Commit을 만들어서 Pull Request해 주세요.
135 | - 또는, 이슈를 생성하여 의견을 남겨주세요. 간단한 의견이라도 가이드라인 1.0 개선에 도움이 됩니다.
136 | 137 |
138 |
139 | 140 | ## *이 문서의 저작권* 141 | 142 | 본 저작물은 '정보통신기획평가원(IITP)'에서 2022년 작성하여 ["공공누리 제4유형(출처표시 + 상업적 이용금지 + 변경금지) 저작권"](https://www.kogl.or.kr/info/license.do#04-tab) 으로 개방하였습니다.
143 | 144 |
145 |
146 | -------------------------------------------------------------------------------- /assets/cover.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/cover.jpg -------------------------------------------------------------------------------- /assets/image1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/image1.jpg -------------------------------------------------------------------------------- /assets/part1/02/01/image2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/01/image2.jpg -------------------------------------------------------------------------------- /assets/part1/02/01/image3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/01/image3.jpg -------------------------------------------------------------------------------- /assets/part1/02/02/image4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/02/image4.jpg -------------------------------------------------------------------------------- /assets/part1/02/03/image5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/03/image5.jpg -------------------------------------------------------------------------------- /assets/part1/02/03/image6.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/03/image6.jpg -------------------------------------------------------------------------------- /assets/part1/02/03/image7.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/03/image7.jpg -------------------------------------------------------------------------------- /assets/part1/02/04/image10.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/04/image10.jpg -------------------------------------------------------------------------------- /assets/part1/02/04/image8.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/04/image8.jpg -------------------------------------------------------------------------------- /assets/part1/02/04/image9.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/04/image9.jpg -------------------------------------------------------------------------------- /assets/part1/02/05/image11.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/05/image11.jpg -------------------------------------------------------------------------------- /assets/part1/02/05/image12.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/05/image12.jpg -------------------------------------------------------------------------------- /assets/part1/02/05/image13.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/05/image13.jpg -------------------------------------------------------------------------------- /assets/part1/02/05/image14.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/05/image14.jpg -------------------------------------------------------------------------------- /assets/part1/02/05/image15.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part1/02/05/image15.jpg -------------------------------------------------------------------------------- /assets/part2/01/03/image2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/01/03/image2.jpg -------------------------------------------------------------------------------- /assets/part2/02/01/image3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/01/image3.jpg -------------------------------------------------------------------------------- /assets/part2/02/02/image4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/02/image4.jpg -------------------------------------------------------------------------------- /assets/part2/02/02/image5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/02/image5.jpg -------------------------------------------------------------------------------- /assets/part2/02/02/image6.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/02/image6.jpg -------------------------------------------------------------------------------- /assets/part2/02/02/image7.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/02/image7.jpg -------------------------------------------------------------------------------- /assets/part2/02/03/cb_img_1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/03/cb_img_1.jpg -------------------------------------------------------------------------------- /assets/part2/02/03/cb_img_2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/03/cb_img_2.jpg -------------------------------------------------------------------------------- /assets/part2/02/03/image8.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/03/image8.jpg -------------------------------------------------------------------------------- /assets/part2/02/03/tb_img_1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/03/tb_img_1.jpg -------------------------------------------------------------------------------- /assets/part2/02/03/tb_img_2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/03/tb_img_2.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/cb_img_10.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/cb_img_10.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/cb_img_11.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/cb_img_11.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/cb_img_12.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/cb_img_12.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/cb_img_13.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/cb_img_13.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/cb_img_3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/cb_img_3.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/cb_img_4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/cb_img_4.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/cb_img_5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/cb_img_5.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/cb_img_6.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/cb_img_6.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/cb_img_7.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/cb_img_7.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/cb_img_8.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/cb_img_8.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/cb_img_9.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/cb_img_9.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/git_img_1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/git_img_1.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/git_img_2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/git_img_2.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/git_img_3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/git_img_3.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/git_img_4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/git_img_4.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/image10.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/image10.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/image11.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/image11.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/image12.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/image12.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/image13.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/image13.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/image14.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/image14.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/image15.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/image15.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/image16.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/image16.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/image17.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/image17.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/image18.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/image18.jpg -------------------------------------------------------------------------------- /assets/part2/02/04/image9.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/04/image9.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/cb_img_14.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/cb_img_14.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/image19.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/image19.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/image20.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/image20.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/image21.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/image21.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/image22.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/image22.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/image23.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/image23.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/image24.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/image24.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/image25.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/image25.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/tb_img_1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/tb_img_1.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/tb_img_2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/tb_img_2.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/tb_img_3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/tb_img_3.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/tb_img_4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/tb_img_4.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/tb_img_5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/tb_img_5.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/tb_img_6.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/tb_img_6.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/tb_img_7.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/tb_img_7.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/tb_img_8.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/tb_img_8.jpg -------------------------------------------------------------------------------- /assets/part2/02/05/tb_img_9.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/05/tb_img_9.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/image26.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/image26.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/noname_1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/noname_1.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/noname_10.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/noname_10.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/noname_11.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/noname_11.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/noname_12.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/noname_12.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/noname_13.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/noname_13.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/noname_2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/noname_2.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/noname_3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/noname_3.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/noname_4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/noname_4.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/noname_5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/noname_5.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/noname_6.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/noname_6.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/noname_7.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/noname_7.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/noname_8.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/noname_8.jpg -------------------------------------------------------------------------------- /assets/part2/02/06/noname_9.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/02/06/noname_9.jpg -------------------------------------------------------------------------------- /assets/part2/03/image27.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/03/image27.png -------------------------------------------------------------------------------- /assets/part2/image1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/assets/part2/image1.jpg -------------------------------------------------------------------------------- /docs/IITP_OSS-Guideline_V1.0.1 (file size).pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iitp-rnd/oss-guideline/7188503ffc62e1fa06a1d58fbf90936bb88b13f5/docs/IITP_OSS-Guideline_V1.0.1 (file size).pdf -------------------------------------------------------------------------------- /docs/files: -------------------------------------------------------------------------------- 1 | list up and download the IITP_OSS-Guideline file 2 | -------------------------------------------------------------------------------- /part1/01/01.md: -------------------------------------------------------------------------------- 1 | 2 | # 1장. 공개SW R&D의 개요 3 | 4 | # 1. 일반SW R&D와 공개SW R&D의 차이점 5 | 6 | 공개SW는 저작권이 존재하지만 저작권자가 소스 코드를 공개하여 누구나 자유롭게 설치, 복제, 수정, 재배포 등을 할 수 있는 소프트웨어를 의미한다. 따라서, 일반SW R&D와 공개SW R&D의 가장 큰 차이점은 공개SW R&D의 경우 R&D 구현 결과물의 전체 혹은 일부를 누구나 사용할 수 있도록 공개하는 데 있다. 7 | 8 | 그 밖에도 일반SW R&D와 공개SW R&D의 차이점은 기획, 개발조직, 분석설계, 구현/리뷰/내부시험, 릴리즈, 평가, 지원절차에 따라 [표 1]과 같이 정리할 수 있다. 공개SW R&D에 있어 중요한 사항은 프로토타입 공개 시점을 기준으로 개발조직이 주관 및 참여기관에서 커뮤니티 개발 조직으로 확대된다는 것이고 R&D 구현 결과물(소스코드, 문서 등)에 대한 릴리즈에 있어 결과물의 전체 혹은 일부분을 공개SW 라이선스를 적용하여 공개해야 한다는 것이다. 또한, 공개 이후 커뮤니티에 의한 유지관리와 지원이 이루어져야 한다. 9 |
10 | 11 | > 표 1. 일반SW R&D와 공개SW R&D의 차이점 12 | 13 | | 구분 | 일반SW R&D | 공개SW R&D | 14 | | :---: | --- | --- | 15 | | 기획 | • 정책, 민간, 산업 수요에 따라 전문가들에의한 공청회를 통해 기획 | • 정책, 민간, 산업 수요에 따라 전문가들에 의한 공청회를 통해 기획

• R&D 과정에서 산출된 SW결과물에 대해 저작권자가 해당 소스코드를 일반에 공개하여 이를 사용, 복제, 수정, 배포 할 수 있는 권한을 부여하는 공개SW 방식을 적용 | 16 | | 개발
조직 | • 주관기관 및 참여기관 개발조직으로 구성 | • 주관기관 및 참여기관 개발조직(코어 개발자), 프로토타입 공개 이후에는 자생적 코어 개발자 그룹과 커뮤니티로 조직 구성 | 17 | | 분석
설계 | • 과제의 규모에 따라 다르며, 주관기관의 개발 프로세스에 따른 분석 및 설계 과정 | • 과제의 규모에 따라 다르며, 주관기관의 개발 프로세스에 따른 분석 및 설계 과정

• 프로토타입 공개 이후에는 공식적인 분석 설계 과정이 없으며, 코어 개발자 사이의 커뮤니케이션, 초기 소스의 스냅샷 릴리즈와 커뮤니티의 리뷰를 통한 간접적인 분석 설계 | 18 | | 구현
리뷰
시험 | • 선정된 개발팀에 의한 독자적인 개발 혹은 부족한 부분에 대한 위탁 개발. 주관기관의 개발 프로세스에서 정한 방식에 따라 조직 내부에서의 리뷰 및 시험, 과제의 요구에 따라 시범 사업에 의한 실환경 시험 | • 코어 개발자 주도의 개발 및 내부 리뷰, 시험이 진행되며, 분석, 설계 단계와 마찬가지로 프로토타입 공개 이후의 모든 구현 결과 또한 공개되고 커뮤니티의 리뷰, 시험 | 19 | | 릴리즈 | • 과제 성격에 따라 매우 다양하나, 거의 소스를 공개하지 않음 | • 일부 혹은 모든 소스코드와 문서가 해당 프로젝트가 채택 하고 있는 라이선스에 따라 공개 | 20 | | 평가 | • 독립적인 평가위원회에 의해 기획 단계와 주관기관 선정 당시에 정의된 과제 목표와 성과를 비교하는 방식으로 평가 | • 오픈소스 라이선스를 포함한 특허 적용 전략, 공개 계획, 커뮤니티 운영 등 SW 결과물의 공개 계획 및 확산 전략 등에 대한 평가 지표를 추가하여 평가 | 21 | |                
커뮤니티
활성화
                | • R&D과제 수행자를 중심으로 운영 가능 | • R&D과제 수행자뿐만 아니라 외부 개발자, 사용자들이 포함된 공개SW 커뮤니티를 구성, 연구개발 산출물을 외부에 공개하고, 외부 참여자들이 개발에 참여하도록 하는 커뮤니티를 통해 개발결과물의 품질을 향상시킴 | 22 | -------------------------------------------------------------------------------- /part1/01/02.md: -------------------------------------------------------------------------------- 1 | 2 | # 2. 공개SW R&D 개요 및 기대효과 3 | 4 | ## 가. 공개SW R&D의 개요 5 | 공개SW는 운영체제, 데이터베이스, 웹서버 등 SW기반 기술에서 인공지능, 빅데이터, 클라우드, 블록체인 등 신기술 분야까지 두루 사용되고 있으며, 글로벌 기술 동향에 의하면 90% 이상의 SW에서 공개SW가 활용될 정도로 기업의 신시장 창출, 사업 경쟁력 강화, 성장 동력 확보에 중요한 수단이 되었다. 6 | 7 | 지난 2020년 5월에 통과된 소프트웨어진흥법의 제 25조 2항은 소프트웨어의 소스 코드를 공개하여 외부의 기여자가 참여하도록 하는 공개SW 개발방식의 활용을 채택하도록 개정되었으며, 이에 따라 향후 국가연구개발사업에서 공개SW 연구개발 방식을 통한 개방형 혁신 연구개발과제 계획 및 수행에 필요한 역량 강화가 필요하며 이를 위한 가이드 제공 등의 R&D 수행에 필요한 다각적인 지원이 필요한 시점이다. 8 | 9 |
10 | 11 | > 표 2. 2020년 5월 소프트웨어 진흥법 개정 12 | 13 | |
소프트웨어진흥법 제 2조
| 14 | | ----------------- | 15 | | 제25조(소프트웨어 연구 및 기술개발 촉진 등) ① 정부는 소프트웨어 기술경쟁력 강화를 위하여 소프트웨어 분야의 기초연구를 진흥하여야 한다.
② 정부는 소프트웨어 분야의 국가연구개발사업을 하는 경우 다음 각 호의 방법으로 소프트웨어 연구개발이 활성화되도록 노력하여야 한다.
1. 소프트웨어의 원시코드(source code)를 공개하여 소프트웨어의 개발ㆍ유지 및 관리 과정에 해당 소프트웨어 개발자 외의 자도 참여하도록 하는 개발 방식의 활용
2. 국가연구개발사업의 결과물을 공개소프트웨어(저작권자가 원시코드를 공개하여 활용ㆍ복제ㆍ수정 및 재배포가 자유로운 소프트웨어를 말한다)로 배포
③ 정부는 소프트웨어와 관련된 기술의 개발을 촉진하기 위하여 기술개발사업을 하는 소프트웨어사업자에게 필요한 자금의 전부 또는 일부를 출연하거나 보조할 수 있다. | 16 | 17 |
18 | 19 | ## 나. 공개SW R&D의 기대효과 20 | 공개SW R&D는 수행하는 동안 내부 개발 인력만으로 수행될 수도 있지만 외부의 참여자가 참여하여 협력 개발이 진행될 때 개방형 혁신 R&D의 경험을 습득하게 되고 글로벌 시장에서 경쟁할 수 있는 R&D 역량이 강화될 수 있다. 또한, R&D의 결과물을 공개SW 프로젝트로 공개하여 누구나 사용할 수 있게 함으로써 모든 SW를 자체 개발할 여력이 없는 중소기업들도 핵심기술을 기반으로 다양한 사업모델을 발굴할 수 있고 개인 개발자들도 스타트업 기업을 보다 쉽게 창업할 수 있는 기반을 조성할 수 있다. 그 밖에도 공개SW R&D는 여러 관점에서 다음과 같이 다양한 기대효과를 제공한다. 21 | 22 | 23 | - ### 경제적 이점 24 | 공개SW R&D를 통해 신규 시장 개척 및 신제품 개발을 위한 R&D 비용, 인프라 SW 비용 등의 투자비를 절감할 수 있게 함으로써 원가 우위를 기반으로 경쟁시장 진입에 대한 진입장벽을 완화할 수 있다. 25 |

26 | - ### 제품, 서비스 및 이미지 차별화 27 | 커뮤니티를 기반으로 성장하는 사업전략을 통해 해당 기업 제품 및 서비스를 차별화하여 시장의 독점 기업 경쟁자에 대해 경쟁력을 확보할 수 있고, 공개SW 기반의 사업을 통한 기술 주도적 기업, 혁신적 기업, 개방적인 사회적 기업 등의 긍정적 이미지를 형성할 수 있다. 28 |

29 | - ### 제품 품질 향상 30 | 개발된 제품의 품질을 공개SW 커뮤니티를 통해 검증하게 되며, 발견된 버그에 대한 코드의 수정도 기업 내부의 개발자와 외부 공개SW 프로젝트 커뮤니티의 자원을 통해 이루어지게 되므로 이 과정에서 최종 제품의 품질이 향상될 수 있다.1) 또한, 국내 산업계에 공개된 기술을 전파, 활용하게 함으로써 국내 산업 기술 경쟁력에 이바지할 수 있다. 31 |

32 | - ### 기업의 SW기술 수준 향상 도모 33 | 공개SW 활동의 활성화를 통해 기업의 내부 개발자들이 자연스럽게 외부 개발자들과 협력을 유도하고 다양한 전문성을 보유한 개발자의 참여와 최신 SW기술 활용을 유도함으로서 개발 SW의 수준과 개발 역량을 모두 향상시킬 수 있다. 특히 기업에게는 SW 개발 시간을 단축시키고 전문개발 인력 양성을 위한 비용을 절감하며 적기에 시장 진출을 할 수 있다. 34 |

35 | - ### 창의성 증대 및 유능한 개발자 확보 36 | 기업은 내부 제품 및 서비스를 공개SW로 전환하거나 공개SW로 공개함으로써 폐쇄적인 기업 문화가 아닌 개방된 창의적인 기업문화를 조성하게 되고 창의적인 역량 확보와 명성을 중요하게 생각하는 최근의 유능한 SW개발자들에게 일하고 싶은 기업으로서의 동기부여를 제공할 수 있다. 또한, 특정 분야의 공개SW 전문 기업으로서의 명성을 통해 유능한 글로벌 커미터들을 확보할 수 있다. 37 |
38 |
39 | 40 | ## 다. 공개SW R&D 수행 시 주요 검토사항 41 | - ### 추진전략 및 사업모델 수립 42 | 공개SW R&D를 수행함에 있어 가장 먼저 검토해야 할 사항은 해당 공개SW R&D의 목적이다. 공개SW R&D의 목적이 비영리적으로 많은 사용자들이 자유롭게 무료로 해당 결과물을 사용할 수 있도록 공유하기 위해 소스코드를 공개하기 위함이라면 소스코드 공개에 충실하면 되지만, 해당 공개SW R&D를 통한 사업화 즉, 영리적 목적에 있다면 명확한 사업전략과 사업모델에 대한 검토가 선행되어야 한다. 해당 R&D 결과물이 공개되면 사용자들이 자유롭게 해당 SW의 소스코드와 관련 문서 및 기술에 대한 접근이 가능하고 시장 내 잠재적 경쟁자의 양산과 시장진입을 용이하게 할 수 있다. 그 결과 공개SW R&D를 통해 기대했던 매출 증대, 시장점유율 증대, 핵심 기반 기술 선점 등의 다양한 사업목표 달성이 어려워지고 그 결과 R&D 수행기관의 지식재산만 공개되는 결과를 초래하기 때문에 공개SW R&D 수행 목적에 부합한 명확한 공개SW 사업전략과 사업모델 수립이 필요하다. 43 |

44 | - ### 공개SW 라이선스 및 보안 취약점 관리와 공개를 위한 정책과 절차 수립 45 | 공개SW 추진전략 및 사업모델 수립 이후에는 추진전략 및 사업모델에 부합된 공개SW 라이선스 정책을 수립하고 공개SW 라이선스 및 보안취약점 관리를 위한 정책과 절차를 수립해야 한다. 공개SW R&D 결과물 전체를 직접 개발하는 경우에는 공개SW 사용 여부에 대한 검증과 공개를 위한 절차가 필요하며 외부 공개SW를 사용하는 경우에는 공개SW 사용정책과 절차를 통해 사용된 공개SW 라이선스 의무사항을 식별 및 이행하고 보안취약점에 문제가 없도록 관리하여야 한다. 또한 사용된 공개SW의 경우 보안취약점 식별은 물론 지속적인 모니터링을 통한 패치 노력이 지속되어야 한다. 이를 위하여 현업 담당 부서와 지원부서는 각각 별도의 프로세스와 자원을 배정하고 공개SW R&D 개발의 전 단계에서 라이선스 준수 및 보안취약점 패치에 대한 통제 및 관리가 반드시 이루어져야 한다. 46 |

47 | - ### 공개SW 커뮤니티의 관리자원 확보 48 | 공개SW R&D의 장점을 극대화하기 위해서는 외부 개발자들이 자유롭게 참여하여 협업할 수 있도록 커뮤니티 생태계 조성을 위해 노력해야만 한다. 공개SW R&D 결과물(소스코드, 문서 등)을 공개한다고 공개SW의 이점을 바로 획득할 수 있는 것이 아니며, 외부 개발자들의 참여와 협업을 위해서는 투명하고 공정한 바른 생태계 조성을 위한 다양한 노력이 필요하다. 49 | 50 | -------------------------------------------------------------------------------- /part1/02/01.md: -------------------------------------------------------------------------------- 1 | # 2장 공개SW R&D 계획수립의 단계별 검토사항 2 | 3 | # 1. 공개SW R&D 계획수립의 단계별 검토사항 개요 4 | 5 | ## 가. 공개SW R&D 계획수립의 검토 단계 6 | 7 | 공개SW R&D 계획의 단계별 검토사항은 [그림 2]를 참고하면 다음과 같다. 첫째, 추진하고자 하는 공개SW R&D의 목적이 사업화를 위한 영리 목적인지 또는 공개SW의 부가 기대효과를 위한 비영리 목적인지를 명확히 하여 이에 적합한 추진전략 및 사업모델을 수립하여야 한다. 이 경우에 공개방식 (라이선스/저장소/커뮤니티 등)에 대한 계획수립이 먼저 고려되어야 한다. 둘째, 추진전략 및 사업모델에 부합한 공개SW 라이선스 정책을 수립하여야 한다. 셋째, 추진전략 및 라이선스 정책을 기반으로 개발 시 외부 공개SW 사용 여부를 검토하여 적절한 공개SW 사용정책 및 절차를 수립하여야 한다. 공개SW R&D의 목적이 사업화를 위한 영리 목적일 경우는 기술이전 검토사항을 참조할 수 있다.
8 |
9 | 10 | > 공개SW R&D 계획수립의 검토단계는 [그림 2]와 같이 정리될 수 있다. 11 | 12 |

그림 2. 공개SW R&D 계획의 단계별 검토사항


13 | 14 | ## 나. 공개SW R&D 계획수립의 검토 절차 15 | 공개SW R&D 계획에 있어서 가장 먼저 검토해야 할 사항은 공개SW R&D의 목적이 사업화를 위한 영리 목적인지 16 | 공개SW 부가 기대효과를 위한 비영리 목적인지를 검토하는 것이다. 17 | 18 | 본 가이드에서는 공개SW R&D 계획의 단계별 검토사항을 사업화를 위한 영리적 목적인 경우와 비영리 목적의 경우로 구분하였으며 수행에 있어서도 외부 공개SW를 사용할 경우와 직접 개발할 경우로 구분하여 검토항목을 제시하였다. 19 | 20 | 본 가이드에서 제공하고 있는 공개SW R&D 계획에 있어서의 전반적인 개요와 절차를 쉽게 이해할 수 있도록 [그림 3]에서 사업화 여부와 외부 공개SW 사용 여부에 따른 검토절차와 항목을 제시하였다. 21 | 22 |

그림 3. 공개SW R&D 계획시 검토절차


23 | 24 | 25 | |
:heavy_exclamation_mark: 주의사항
| 26 | | --------------- | 27 | | 공개SW R&D 계획의 단계별 검토사항 중, 최초 공개SW 사용정책 및 절차수립 단계에서 외부 공개SW에 대한 사용계획 없이 R&D를 수행하는 과정에서 추후 필요에 의해 외부 공개SW를 사용하는 경우가 발생할 수도 있다. 이 경우 추가적으로 공개SW 사용정책 및 절차를 수립하여 사용된 외부 공개SW의 라이선스에 따라 소스코드 공개 및 고지 의무사항 등을 준수할 수 있도록 검토해야 한다. | 28 | 29 | -------------------------------------------------------------------------------- /part1/02/02.md: -------------------------------------------------------------------------------- 1 | # 2. 1단계 : 공개SW R&D 추진전략 및 사업모델 수립단계 2 | 3 | 공개SW R&D 계획에 있어 가장 먼저 검토해야 할 사항은 해당 공개SW R&D의 목적이다. 공개SW R&D의 목적은 크게 공개SW R&D를 통한 사업화와 R&D 결과물 공개를 통한 공개SW로서의 부가 기대효과 (특정 SW 제품 대체, 브랜드 가치 및 명성 등)로 구분될 수 있다. 4 | 5 |

그림 4. 공개SW R&D 추진전략 및 모델 수립단계


6 | 7 |
8 | 9 | ## 가. 공개SW R&D 추진전략 수립 10 | 공개SW R&D의 추진전략은 다음과 같이 사업화를 영리목적의 공개SW R&D 추진과 공개SW의 부가 기대효과를 위한 비영리 목적의 공개SW R&D 추진전략으로 구분될 수 있다. 11 | 12 | ### (1) 사업화를 위한 영리목적의 공개SW R&D 추진전략 13 | 사업화를 위한 공개SW R&D를 추진함에 있어서는 다음과 같은 공개SW 추진전략을 검토할 수 있다. 14 | 15 | * **① 공개SW를 통한 시장점유 전략**
16 | 기존 상용SW를 고도화 혹은 대체할 수 있는 신제품 및 솔루션을 공개SW로 개발하여 시장 점유율을 높이는 전략이다. 무료로 공개SW를 제공하여 시장 점유율을 높이고 좀 더 부가가치 있는 상용 기능 및 모듈 제공을 통해 수익을 창출할 수 있다. 공개SW 솔루션 Qt의 경우 공개SW 엔진, 도구 및 라이브러리들을 제공하면서 상용SW 모듈을 판매하고 있다. 17 |
18 | 19 | * **② 공개SW를 통한 서비스 창출 전략**
20 | 공개SW로 신규 제품 및 솔루션을 개발하여 기존 상용 제품 시장을 공략하는 전략이다. 통합지원 서비스 모델보다는 다양한 요구사항을 기반으로 교육 및 커스텀 개발, 컨설팅 등이 필요한 BPM(Business Process Management), BI(Business Intelligence) 등 제품 및 솔루션 시장에 적합한 공개SW R&D 전략이다. 저렴한 SW 라이선스 비용으로 도입을 용이하게 하고 조직의 다양한 요구사항을 반영하여 교육 및 커스텀 개발, 컨설팅 서비스를 통해 수익을 창출할 수 있다. 21 |
22 | 23 | * **③ 공개SW를 통한 시장 확대 전략**
24 | 공개SW를 통한 새로운 시장 확대 전략이다. 예를 들어 아파치재단에 기부한 클라우드 스택(CloudStack)의 경우는 공개SW를 통한 클라우드 시장을 확대한 사례이다. 공개SW로 전환 후 클라우드 스택은 아파치 웹서버, 하둡, 톰캣 등 셀 수 없이 많은 유명한 공개SW를 운영, 기여하고 있는 아파치 재단의 세력에 힘입어 지속적으로 발전하고 있다. 25 |
26 | 27 | * **④ 공개SW를 통한 시장 및 제품 다각화 전략**
28 | 공개SW로 신규 제품 및 솔루션을 개발하여 새로운 시장을 창출하는 전략이다. 클립소프트의 경우는 기존 JasperReports, BIRT와 같은 리포팅툴 시장에서 HTML5를 지원하는 공개SW 리포팅툴을 제공하여 새로운 시장을 창출한 사례이다 29 |

30 | 31 | ### (2) 공개SW의 부가 기대효과를 위한 비영리 목적의 추진전략 32 | 다양한 부가 기대효과를 목적으로 공개SW R&D를 추진할 수 있다. 비영리 목적의 공개SW R&D 추진시 검토할 수 있는 추진전략은 다음과 같다. 33 | * **① 공개SW를 통한 특정제품 대체 전략**
34 | 기존 상용SW 기능을 대체할 수 있는 공개SW를 제공함으로써 많은 사용자에게 비용 절감을 가능하게 할 수 있다. 35 |
36 | 37 | * **② 공개SW를 통한 원천기술 및 신기술 기반 시장 확대 전략**
38 | 기존에 없는 원천기술이나 신기술이 적용된 공개SW를 제공함으로써 많은 산업 및 사용자들을 통한 사용 및 기타 융합기술 적용을 통해 시장 및 신기술 적용 범위를 확대시킬 수 있다. 39 |
40 | 41 | * **③ 브랜드 가치 및 명성**
42 | 유용한 공개SW를 지속적으로 제공함으로써 브랜드 및 명성을 증대시킬 수 있다. 43 |
44 | 45 | * **④ 인재육성 전략**
46 | 대학 및 연구소 개발자들을 공개SW 개발에 적극 참여시키고 글로벌 커뮤니티 및 커미터들과의 협업을 통해 보다 유능한 인력으로 성장하고 유능한 인력을 유인할 수 있다. 47 |
48 |
49 | 50 | ## 나. 공개SW R&D 사업모델 51 | 사업화를 목적으로 추진되는 공개SW R&D는 추진전략 수립 이후 다양한 공개SW 사업모델을 검토할 수 있으며 다양한 공개SW 사업모델 중에서 추진하고자 하는 공개SW R&D에 적합한 사업모델을 수립하여야 한다. 52 | 53 | ### (1) 공개SW 사업 모델 54 | 본 가이드에서는 공개SW　R&D를 통해 적용 가능한 사업모델로서 Anthony I. Wasserman이 정의한 11가지 공개SW 사업 모델[2](#footnote2)을 제시하고 있으며 [표 3]과 같다. 55 | 56 | > 표 3. 공개SW 사업 모델 57 | 58 | | 비지니스 모델 | 설 명 | 59 | | :------------------------------------------------------------------------: | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 60 | | 구독 모델
(Subscription Model) | • 사용자가 공개SW를 무료로 다운로드받고 제한없이 사용할 수 있는 모델
• 사용자가 수동으로 소프트웨어 업데이트를 확인해서 설치하고 기술적인 문제들에 대해 포럼을 통해 질문하고 답변을 받는 방식으로 해결할 수 있음
• 기술지원 업체는 년간 계약을 통해 사용자에게 가입모델에 따른 수준별 서비스를 제공하며 수익을 창출하는 모델 | 61 | | 상용 및 공개SW 제품 모델
(Offering Commercial and Open SourceProducts) | • 기업의 제품이 상용 라이선스에 기반하여 지원을 받는 상용SW와 완전히 무료로 제공되는 공개SW 제품으로 제공되는 유형(상용SW와 공개SW는 기능 및 기술지원 등에 차이가 있을 수 있음) | 62 | | 지원 및 교육 모델
(Support and Training Model) | • 공급업체가 특정 공개SW에 대한 기술지원 및 교육을 제공할 수도 있고 공급업체가 아닌 해당 제품에 대해 기술지원이나 교육이 가능한 기업 혹은 개인 개발자가 제공할 수도 있는 모델
• 공급업체는 하나 이상의 공개SW 프로젝트에 대한 기술지원 서비스, 교육 또는 출판물을 제공하는 유형 | 63 | | 컨설팅 모델
(Consulting and Integration Strategy | • 공급업체가 직접 어떤 공개SW 소프트웨어를 제공하지 않지만 고객이 공개SW와 관련된 전략적 의사 결정과 설계 및 투자를 하는 데 도움을 주고 컨설팅 비용을 청구하는 모델 | 64 | | 듀얼 라이선스 모델
(Dual License Model) | • 공급업체는 GPL 또는 아파치와 같은 공개SW 라이선스가 적용된 공개SW를 제공하면서, 동일한 SW를 상용 라이선스로 판매하는 모델 | 65 | | 호스팅 서비스 모델
(Hosted Service) | • 기업이 공개SW를 사용하여 고객에게 특정 서비스를 제공하는 모델 | 66 | | 광고 모델
(Advertising Model) | • 공급업체가 공개SW를 개발하여 서비스(클라우드)로 제공하며, 해당 서비스의 사용자에게 광고를 노출시키는 모델 | 67 | | 강화된 상용SW 모델
(Commercial Enhancement) | • 공급업체는 공개SW를 사용하여 상업적으로 제공할 수 있는 새로운 SW를 개발하여 판매하는 모델 | 68 | | 시스템 모델
(Embedding Model) | • 벤더 하드웨어 제품에 공개SW를 사용하여 제품을 판매해서 수익을 창출하는 모델 | 69 | | 후원 모델
(Patronage Model) | • 수익을 직접적으로 기대하지 않고 공개SW, 자금, 장비 또는 커뮤니티를 위한 시간 등을 제공하며 기업을 홍보하는 모델 | 70 | | 통합지원 서비스 모델
(Packaging Model) | • 공급업체는 자사의 전문기술을 활용하여 한 개 이상의 공개SW를 통합하여 스택을 구성하고 기술지원, 교육, 컨설팅을 스택과 함께 제공하는 모델 | 71 | 72 |
73 |
74 | 75 | ### (2) 공개SW 사업모델 중 공개SW R&D 적용 가능 사업모델 76 | 이상의 11가지 공개SW 사업모델 중 공개SW R&D를 통해 사업화가 가능한 사업모델은 [표 4]와 같이 정의될 수 있음을 참고한다. 77 | 78 | > 표 4. 공개SW R&D를 통해 사업화가 가능한 사업모델 79 | 80 | | 사업 모델 | 사업모델 상세 | 81 | | :------------------------------------------------------------------------: | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 82 | | 구독 모델
(Subscription Model) | • 공개SW R&D 결과물 중 전체 소스코드를 공개하여 사용자가 소프트웨어를 무료로 다운로드받고 제한 없이 사용할 수 있는 모델
• 사용자가 수동으로 소프트웨어 업데이트를 확인해서 설치하고 기술적인 문제들에 대해 포럼을 통해 질문하고 답변을 받는 방식으로 해결할 수 있음
• 사용자들이 해당 공개SW를 도입 및 사용할 경우 패치 업데이트 등 보다 전문적인 기술지원과 문제해결 등에 대한 지원을 받고 싶을 경우 지원 수준 기준으로 책정된 서비스 가격으로 년간 계약을 통해 서비스료를 과금하는 사업 모델 | 83 | | 상용 및 공개SW 제품 모델
(Offering Commercial and Open Source Products) | • 공개SW R&D 결과물 중 일부 기능을 구현하는 소스코드를 공개SW 라이선스가 적용된 공개SW로 공개하고 기능이나 성능, 활용범위 등이 보다 향상된 SW사용을 원하는 사용자들을 위해 공개하지 않은 소스코드를 상용 라이선스가 적용된 상용SW로 판매하는 사업모델 | 84 | | 듀얼 라이선스 모델
(Dual License Model) | • R&D결과물을 공개SW 라이선스가 적용된 공개SW로 공개하고 동일한 SW를 상용 라이선스가 적용된 상용SW로 판매하는 사업 모델
• 가장 일반적으로 많은 기업들이 적용하고 있는 모델로서 기업은 적절한 라이선스를 선정하여 공개소프트웨어를 사용하고 상업적으로 제공할 수 있는 새로운 제품을 개발하여 판매하는 방식
• 공개SW를 사용하는 사용자들은 무료로 사용할 수 있지만 해당 공개SW에 적용된 라이선스 의무사항을 준수해야 하고 상용SW를 구매하는 사용자들은 일반 상용SW와 동일하게 독점적으로 사용할 수 있음 | 85 | 86 | 87 | --- 88 | 89 | 2) Building a Business on Open Source Software Anthony I. Wasserman Carnegie Mellon Silicon Valley Mountain View, CA 94035 USA/Anthony I. (Tony) Wasserman is a Professor of Software Management Practice and the Executive Director of the Center for Open Source Investigation at CMU-SV. He also serves as a Director of the Open Source Initiative (opensource.org) [return](#part1_2_02)
-------------------------------------------------------------------------------- /part1/02/03.md: -------------------------------------------------------------------------------- 1 | # 3. 2단계 : 공개SW R&D 라이선스 정책수립 단계 2 | 공개SW R&D 추진전략 및 사업모델 수립 후에는 영리 또는 비영리 목적에 맞게 공개SW 라이선스 정책을 수립해야 한다. 사업화를 위한 영리 목적의 공개SW R&D의 경우에는 시장 창출 등의 목적에 부합되도록 공개SW 라이선스 정책을 수립하여야 하며, 비영리 목적의 경우에는 추진전략에 부합된 기대효과를 얻을 수 있도록 자유로운 사용 장려, 특정 영리기업의 상용독점 사용금지 등의 목적에 부합된 공개SW 라이선스 정책을 수립하여야 한다. 3 | 4 |

그림 5. 공개SW R&D 라이선스 정책수립 단계


5 | 6 | ## 가. 공개SW R&D에 적용할 공개SW 라이선스 분류기준 7 | 전 세계에는 약 2,000여 종 이상의 공개SW 라이선스가 공표되어 있다. 본 가이드라인에서는 이들 공개SW 라이선스를 적용함에 있어 해당 공개SW 라이선스가 사용자들에게 요구하는 의무사항 중 소스코드 공개 범위를 기준으로 다음과 같이 세 가지 분류체계를 적용하였다. 8 | + 허용적 라이선스(Permissive License) 계열: 소스코드 공개 의무 없음 9 | + 약한 카피레프트 라이선스(Weak Copyleft License) 계열: 한정된 범위에서의 소스코드 공개 의무 발생 10 | + 강한 카피레프트 라이선스(Strong Copyleft License) 계열: 전체 소스코드 공개 의무 발생 11 | - 카피레프트(Copyleft)는 일반적인 상용/독점 저작권을 의미하는 카피라이트(Copyright)의 반대개념을 내포하는 용어로서 공유와 협업을 목적으로 제정된 라이선스들에 적용됨 12 |
13 | 14 | ### (1) 허용적 라이선스 계열 15 | 허용적 라이선스 계열은 해당 공개SW를 사용하여 배포 및 서비스를 제공할 경우 사용한 공개SW를 개발한 저작권자, 공개SW 명, 라이선스 명, 라이선스 사본을 누구나 알 수 있도록 고지해야 할 의무가 발생되는 라이선스 계열이다. 소스코드 공개를 요구하지 않으며 라이선스에 따라 부가적인 의무사항(무상 특허 허용, 광고 및 홍보 사용 금지, 상업적 용도 사용금지 등)을 요구하는 라이선스가 있다. BSD, MIT 등이 대표적인 허용적 라이선스이다. 소스코드 공개를 요구하고 있지 않기 때문에 많은 상용SW 및 서비스에 광범위하게 사용되고 있다. 16 | 17 | 18 | ### (2) 약한 카피레프트 라이선스 계열 19 | 약한 카피레프트 라이선스 계열은 허용적 라이선스 의무사항에 추가하여 제한적인 소스코드 공개 의무가 발생된다. 해당 공개SW와 개발 소스코드와의 결합형태에 따라 단순 고지의무와 일부 소스코드 공개의무 또는 전체 소스코드 공개의무가 발생된다. MPL, EPL, LGPL 등이 대표적인 약한 카피레프트 라이선스이다. 제한된 범위에서의 소스코드 공개를 요구하고 있기 때문에 많은 상용SW 및 서비스에 광범위하게 사용되고 있다. 20 | 21 | ### (3) 강한 카피레프트 라이선스 계열 22 | 강한 카피레프트 라이선스 계열은 허용적 라이선스 의무사항과 약한 카피레프트 라이선스 의무사항에 추가하여 전체 소스코드 공개 의무가 발생된다. GPL, AGPL 등이 대표적인 강한 카피레프트 라이선스이다. 광범위한 소스코드 공개를 요구하고 있기 때문에 공개SW들 중에서 가장 많이 채택하고 있는 라이선스 계열이며, 일반적으로 상용 SW 및 서비스에 사용되기 어렵지만, 일부 상용SW 및 임베디드 SW에서 자체 개발한 소스코드와 완벽히 분리된 결합형태 [별첨2. 사용·결합·통신 방식에 따른 라이선스 의무사항 참조]로 사용되고 있다. 23 | 24 | > 공개SW 라이선스 분류별 해당 공개SW 라이선스 종류는 [그림 6]과 같다 [3](#footnote3) 25 | 26 |

그림 6. 공개SW 라이선스 분류


27 | 28 | 29 | |
:heavy_exclamation_mark: 주의사항
| 30 | | --------------- | 31 | | 허용적 라이선스 계열인 BSD, MIT 라이선스가 적용된 공개SW를 사용 및 수정하여 개발된 SW를 유상 또는 무상으로 배포한 경우에는 해당 SW를 수령하는 사용자들에게 누구나 알 수 있는 방식으로 BSD, MIT 라이선스가 사용되고 있음을 알리고, 해당 공개SW를 개발한 저작권자, 라이선스 사본을 고지할 의무가 있다. 반면에, 약한 카피레프트 라이선스 계열인 MPL 계열 라이선스가 적용된 공개SW를 사용 및 수정하여 개발한 경우에는 해당 파일을 구성하는 소스코드를 공개해야 하며 강한 카피레프트 라이선스 계열인 GPL 계열의 라이선스가 적용된 공개SW를 사용 및 수정하여 개발한 경우에는 전체 소스코드를 공개해야 한다. | 32 | 33 |
34 | 35 | ## 나. 사업화를 위한 공개SW R&D의 사업모델에 따른 라이선스 정책검토 36 | 공개SW 사업모델 중 공개SW R&D에 적용 가능한 사업모델은 구독모델, 상용 및 공개SW 제품 공급, 듀얼 라이선스 모델, 강화된 상용SW 모델이다. 각 공개SW R&D 사업모델에 있어 검토할 필요있는 라이선스 정책은 [표 5]와 같다. 37 | 38 | > 표 5. 공개SW R&D 사업모델 및 라이선스 정책
39 | 40 | | 공개SW 라이선스 정책 | 공개SW 라이선스 정책 | 41 | | :-------------------------------------------------------------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 42 | | 구독 모델
(Subscription Model) | • 공개SW R&D 결과물 중 전체 소스코드를 공개하여 사용자가 소프트웨어를 무료로 다운로드 받고 제한 없이 사용할 수 있는 모델
`• 공개된 소스코드를 가지고 특정 기업이나 개발자들이 유사한 SW를 개발하여 독점/상용 라이선스로 판매하는 것을 제한하기 위해서 모든 소스코드를 반드시 공개해야만 하는 강한 카피레프트 라이선스 정책이 권장됨`
• 강한 카피레프트 라이선스를 적용함에 있어 라이선스 양립성에 대한 검토가 필요함 | 43 | | 상용 및 공개SW 제품
(Offering Commercial and Open Source Products) | • 공개SW R&D 결과물 중 일부 기능을 구현하는 소스코드를 공개SW로 공개하고 기능이나 성능, 활용범위 등이 보다 향상된 상용 SW를 판매하는 사업모델
• 전체 공개SW R&D 결과물 중 공개된 소스코드에 적용된 공개SW 라이선스와 공개하지 않은 소스코드에 적용된 상용 라이선스가 상호 충돌이 발생 되지 않도록 검토 필요
`• 특정 기업 혹은 개발자들이 공개된 소스코드를 수정하여 독점/상용 라이선스로 판매하는 것을 제한하기 위해서 공개된 소스코드에는 해당 소스코드에만 라이선스가 적용되는 약한 카피레프트 라이선스 사용이 권장됨`
• 만약 R&D결과물에 보다 강력한 강한 카피레프트 라이선스를 적용하기 위해서는 공개된 코드와 공개하지 않은 코드가 분리된 저작물 형태로 결합되어야 함( 별첨 2. “사용·결합· 통신 방식에 따른 라이선스 의무사항” 참조) | 44 | | 듀얼 라이선스 모델
(Dual License Model) | • 공개SW R&D결과물을 공개SW로 공개하고 동일한 SW를 상용 라이선스가 적용된 상용SW로 판매하는 사업모델
• 공개SW를 사용하는 사용자들은 무료로 사용할 수 있지만 해당 공개SW에 적용된 라이선스 의무사항을 준수해야 하고 상용SW를 구매하는 사용자들은 일반 상용SW와 동일하게 독점적으로 사용할 수 있음
`• 특정 기업 혹은 개발자들이 공개SW로 공개된 소스코드 전체 혹은 일부를 가지고 유사한 상용 독점 SW를 개발하여 판매하는 것을 제한하기 위해 공개된 소스코드에는 강한 카피레프트 라이선스 적용이 권장됨`
• 강한 카피레프트 라이선스는 해당 소스코드 전체 혹은 일부를 복제, 수정 사용할 경우 해당 코드와 연결된 모든 소스코드를 동일한 라이선스를 적용하여 누구나 사용할 수 있도록 공개해야 함에 따라 유사 경쟁SW 개발 및 판매를 예방할 수 있음
• 다만 동일한 소스코드에 대해 공개SW 라이선스와 상용 라이선스를 동시에 적용하기 | 45 | 위해서는 해당 소스코드에 대한 저작권리를 100% 확보하고 있어야 함 | 46 |
47 |
48 | 49 | ## 다. 비영리 목적의 공개SW R&D의 라이선스 정책검토 50 | 사업화가 아닌 비영리 목적의 공개SW R&D 추진시 공개SW 라이선스 정책은 다음과 같이 추진전략별 특성에 맞게 검토될 수 있다. 51 | 52 | > 표 6. 비영리 목적의 공개SW R&D 추진전략에 따른 공개SW 라이선스 정책
53 | 54 | | R&D 추진전략 | 공개SW 라이선스 정책 | 55 | | :-----------------------------------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 56 | | 특정 SW 제품 대체 전략 | • 기존 상용SW 기능을 대체할 수 있는 공개SW를 무료로 제공함으로써 많은 사용자에게 비용 절감을 가능하게 하기 위해서는 특정 기업 및 개발자들이 해당 공개SW를 활용하여 상용/독점 판매하는 것을 제한하는 것이 바람직함
`• 해당 공개SW를 일부 혹은 전체를 복제, 수정하여 2차 저작물을 개발 및 배포할 경우 모든 소스코드를 공개해야 하는 강한 카피레프트 계열의 라이선스 적용이 권장됨` | 57 | | 원천기술 및 신기술 기반 시장 확대전략 | • 기존에 없는 원천기술이나 신기술이 적용된 공개SW를 제공함으로써 많은 사용자들을 통한 사용 및 기타 융합기술 적용을 통해 시장을 확대시키기 위해서는 누구나 자유롭게 별다른 제약조건 없이 사용할 수 있도록 허용하는 것이 바람직함
`• 개인 및 기업들이 자유롭게 사용하고 해당 공개SW를 다양한 기술 및 제품에 적용하여 부가가치를 얻게 하기 위해서는 사용 및 저작권 고지의무만을 요구하고 있는 허용적 라이선스 계열의 라이선스 적용이 권장됨` | 58 | | 브랜드 가치 및 명성 | • 유용한 공개SW를 지속적으로 제공함으로써 브랜드 및 명성을 증대시킬 수 있게 하기 위해서는 누구나 자유롭게 별다른 제약조건 없이 사용할 수 있도록 허용하는 것이 바람직함
`• 개인 및 기업들이 자유롭게 사용하고 해당 공개SW를 통해 다양한 부가가치를 얻게 하기 위해서는 사용 및 저작권 고지의무만을 요구하고 있는 허용적 라이선스 계열의 라이선스 적용이 권장됨` | 59 | | 인재 육성 전략 | • 대학 및 연구소 개발자들을 공개SW 개발에 적극 참여시키고 글로벌 커뮤니티 및 커미터들과의 협업을 통해 보다 유능한 인력으로 성장하고 유능한 인력을 유인할 수 있게 하기 위해서는 누구나 자유롭게 별다른 제약조건 없이 사용할 수 있도록 허용하는 것이 바람직함
`• 개인 및 기업들이 자유롭게 사용하고 해당 공개SW를 통해 다양한 부가가치를 얻게 하기 위해서는 사용 및 저작권 고지의무만을 요구하고 있는 허용적 라이선스 계열의 라이선스적용이 권장됨` | 60 |
61 |
62 | 63 | ## 라. 공개SW R&D 대표 라이선스 및 호환 라이선스 정책 검토 64 | 65 | ### (1) 공개SW R&D 대표 라이선스 정책 검토 사항 66 | 67 | 공개SW R&D 결과물 공개 시에는 대표 공개SW 라이선스를 선정하여 적용해야 하며 향후 커뮤니티를 통한 외부 개발자들이 코드를 기여할 때 대표 공개SW 라이선스 정책과 의무사항을 준수할 수 있도록 대표 라이선스와 호환되는 공개SW 라이선스 조건을 명시한 라이선스 정책을 제공해야 한다. 68 | 69 | > 표 7. 공개SW R&D 대표 라이선스와 호환되는 라이선스
70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 |
대표 라이선스호환 라이선스결합형태
허용적 라이선스 계열
(Apache, MIT, BSD 등)		허용적 라이선스 계열사용에 별도의 제한 없음
약한 카피레프트 라이선스 계열• LGPL : 라이브러리 링크로 복제 및 수정 사용
• EPL : 모듈로 복제 및 수정 사용
• MPL : 파일 복제 및 수정 사용
강한 카피레프트 라이선스 계열분리된 저작물(Separate Work)
약한 카피레프트 라이선스 계열
(MPL, EPL, LGPL 등)		허용적 라이선스 계열사용에 별도의 제한 없음
약한 카피레프트 라이선스 계열• LGPL : 라이브러리 링크로 복제 및 수정 사용
• EPL : 모듈로 복제 및 수정 사용
• MPL : 파일 복제 및 수정 사용
강한 카피레프트 라이선스 계열분리된 저작물(Separate Work)
강한 카피레프트 라이선스 계열
(GPL, AGPL 등)		허용적 라이선스 계열사용에 별도의 제한 없음
약한 카피레프트 라이선스 계열분리된 저작물(Separate Work)
강한 카피레프트 라이선스 계열사용에 별도의 제한 없음(다만, GPL 3.0, AGPL 3.0의 경우 설치정보 제공, 기술적 보호 금지에 대한 검토가 필요함)
122 |
123 | 124 | 참고로, 라이선스 의무사항과 관련해서는 라이선스의 적용범위도 함께 이해하는 것이 좋다. 오픈소스와 관련한 주요 법적 권리는 오픈소스 라이선스에 주로 명시되어 있다. 오픈소스 라이선스에 기술되는 의무사항으로는 125 | 소스코드 공개의무, 저작권 고지의무, 특허 포기의무, 사용권 고지의무 등이 있는데, 특히 오픈소스 공개의무의 범위와 특허보복조항의 적용 범위에 대해서는 제대로 이해할 필요가 있다[4](#footnote4).
126 |
127 | 먼저, 소스코드 공개 의무를 가지는 라이선스에는 GPL, LGPL, AGPL, MPL 등 카피레프트 계열이 해당되는데, 라이선스별로 소스코드 공개의 범위와 조건이 다르므로 오픈소스를 가져다 쓸 때 확인이 필요하다. 이 중 GPL 2.0 을 예로 살펴보면, GPL은 라이선스에는 무조건 공개하는 것으로 나와 있지만 실제 공개 범위는 GPL FAQ에서 적용범위에 대한 단서를 찾아 다음과 같이 정리할 수 있다[5](#footnote5). 128 | 129 | > 표 8. GPL 2.0 라이선스 적용 범위
130 | 131 | | 단서 부분 | GPL FAQ | 132 | | :-----------------: | ------- | 133 | | GPL 2.0의 적용 범위 | • Static linking, dynamic linking인 경우는 GPL 2.0의 적용을 받음
• shared memory로 연결된 경우도 GPL 2.0의 영향을 받음
• socket, pipe, exec, rpc, CLI 등 독립적인 프로세스로 운영되는 경우만 GPL 2.0의 적용을 받지 않음. 그러나 통신 의미에 따라 다르게 적용. 모듈이 동일한 실행 파일에 포함되면 GPL 적용받음 | 134 | 135 |
136 | 137 | 특허보복조항(patent retaliation)은 특허SW 사용 시 특허권을 주장할 수 없도록 라이선스에 명문화된 조항을 의미한다. 오픈소스를 특허에 대한 제약 없이 활용할 수 있도록 하는 목적이다. 특허보복조항을 가지는 라이선스는 대표적으로는 Apache 2.0이 있고 그 외에도 GPL 3 0, MPL 2.0, EPL 2.0 등이 있다. 최근 많이 사용하는 Apache 2.0 라이선스도 라이선스 적용 범위에 따라서 특허 보호 범위가 정해지므로 이에 대해 이해할 필요가 있다. Apache 2.0의 라이선스 적용 범위는 Apache 2.0 라이선스 원문 제1조에서 찾을 수 있다[6](#footnote6). 138 | 139 | > 표 9. Apache 2.0 라이선스 적용 범위
140 | 141 | | 단서 부분 | Apache 2.0 라이선스 제1조 정의 부분 | 142 | | :--------------------: | ----------------------------------- | 143 | | Apache 2.0의 적용 범위 | • 개발 코드가 Apache 2.0 모듈과 별개의 모듈이면 같은 프로세스여도 라이선스 적용 안 받음
• Socket, pipe, CLI 외에도 static linking, dynamic linking으로 연동되는 경우도 Apache 2.0 라이선스의 적용 안 받음 | 144 | 145 |
146 |
147 | 148 | ### (2) 공개SW 프로젝트 라이선스 정책 사례 149 | 글로벌 차량 플랫폼 공개SW 프로젝트인 GENIVI Alliance에서는 [그림 7]과 같이 Public Policy for GENIVI Licensing and Copyright Version 2.07)을 통해 대표 라이선스(Default License)를 MPL 2.0[7](#footnote7)으로 선언하고 호환 공개SW 라이선스들을 Green-light, Red-light, Orange-light로 분류하고 있다.
150 | 151 |
152 | Green-light로 분류된 공개SW 라이선스들은 제약없이 사용 가능하고, Red-light로 분류된 공개SW 라이선스들은 사용 금지, Orange-light로 분류된 공개SW 라이선스들은 결합형태에 따라 사용가능 혹은 금지를 의미한다. 153 | 154 |

그림 7. GENIVI 프로젝트 대표 라이선스 및 호환 라이선스 정책


155 | 156 | 157 | --- 158 | 159 | 3) SSPL(Server Side Public License)은 오픈소스인 MongoDB가 2018년 기존에 적용하던 AGPL 라이선스를 대신해 적용하기 시작한 라이선스 [return](#part1_3_03)
160 | 4) 박정숙 외, “오픈소스의 지식재산권 분쟁 대응 방안: 오라클과 구글의 Java API 소송 사례 중심”, 주간기술동향, 제2127호, 2021년 12월 15일. [return](#part1_3_04)
161 | 5) GPL FAQ, https://www.gnu.org/licenses/gpl-faq.en.html [return](#part1_3_05)
162 | 6) Apache 2.0 라이선스, https://www.apache.org/licenses/LICENS-2.0 [return](#part1_3_06)
163 | 7) https://at.projects.genivi.org/wiki/download/attachments/ [return](#part1_3_07)
164 | -------------------------------------------------------------------------------- /part1/02/04.md: -------------------------------------------------------------------------------- 1 | # 4. 공개SW 사용정책 및 절차 수립단계 2 | 공개SW R&D 결과물에 적용한 공개SW 라이선스 정책을 수립하였으면 해당 공개SW 라이선스 정책을 준수하기 위한 공개SW 사용정책 및 절차를 수립하여야 한다. 3 | 4 |

그림 8. 공개SW 사용정책 및 절차 수립단계


5 | 6 | ## (1) 공개SW R&D 관리 요구사항 7 | 공개SW R&D 수행을 위해 공개SW를 사용하지 않는 SW결과물에 대한 라이선스 정의, 저장소 및 커뮤니티 운영 등에 대한 정책을 수립하여 라이선스 및 보안취약점 위험을 예방한다. 8 | 9 | ## (2) 공개SW 관리 10 | * **책임과 권한**
11 | 공개SW R&D 프로세스별로 사업책임자, 개발자 및 지원 조직원의 역할은 다양하게 정의할 수 있으나 공개SW R&D 관련한 중요한 책임과 권한을 정리하면 [표 10]과 같다. 12 | 13 | > 표 10. 공개SW R&D 수행조직의 책임과 권한 예시
14 | 15 | | 담당 | 책임/권한 | 16 | | :--------: | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 17 | | 사업책임자 | • 공개SW R&D 추진전략 및 사업모델 수립
• 공개SW R&D 사업 일정, 이슈 및 위험 관리
• 공개SW R&D 사업 의사소통 관리
• 공개SW R&D 공개 정책 수립
• 공개SW R&D 결과물의 라이선스 및 보안취약점 검증 관리
• 공개SW R&D 결과물의 공개 및 기술이전 계획 수립
• 공개SW 커뮤니티 운영 및 관리 계획 수립 | 18 | | 개발자 | • 공개SW 요구사항 정의 및 관리
• 공개SW 개발 및 시험
• 공개SW 라이선스 및 보안취약점 검증 활동 (공개SW 사용 여부)
• 공개SW 결과물 공개 및 저장소 운영 : 소스코드 및 관련 문서(LICENSE, README, NOTICE, CONTRIBUTION GUIDE 등) | 19 | | 지원조직 | • 공개SW R&D 제도 및 정책 지원
• 공개SW R&D 수행을 위한 가이드 및 플랫폼(검증/저장소/공개/커뮤니티) 지원
• 공개SW 배포 및 공급망 관리 지원
• 공개SW 라이선스 및 보안취약점 검증 지원
• 오픈소스 관련 법률 지원 | 20 | 21 |
22 | 23 | * **공개SW R&D 단계별 주요 업무** 24 | R&D 단계별 주요 업무는 [표 11]와 같다. 25 | 26 | > 표 11. 공개SW R&D 단계별 주요 업무 예시
27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 |
단계주요 업무주관
1. 과제 계획(설계)• 공개SW R&D 관리절차 수립사업책임자
2. 구현• 소스코드 내 저작권 및 라이선스 문구 유지개발자
3. 위험관리• 주관기관 및 참여기관 공개SW 라이선스 및 보안취약점 검증개발자, 지원조직
• 검증결과 검토사업책임자
4. 공개• 공개SW 라이선스 정의 및 저장소 지정
• 공개SW R&D 결과물 공개 : 소스코드 및 관련 문서(LICENSE, README, NOTICE, CONTRIBUTION GUIDE 등)		개발자, 지원조직
• 공개범위 검토사업책임자
5. 기술이전• 공개SW 라이선스/보안취약점 검증
• 라이선스, 고지문 작성 및 제공 		개발자, 지원조직
• 검증결과 검토 및 기술이전 결과물 적절성 검토사업책임자
6. 과제 계획/ 개발 완료/ 공개/기술이전• 라이선스 자문 지원
• 공개SW 라이선스 검증 지원
• 기타 공개 및 기술지원 관련 자문 지원		지원조직
82 | 83 |
84 | 85 | ## (3) 공개SW 저장소 및 커뮤니티 운영 정책 86 | 공개SW는 공개 정책에 따라 저장소를 선정하여 저장소 운영 및 관리 정책을 수립한다. 또한 공개SW의 지속적인 기능 개발 및 공유를 위해 공개SW 커뮤니티 운영 정책을 수립하고, 커뮤니티 운영 정보를 공개하여 커뮤니티 활성화를 추진한다. 87 |
88 | 89 | ## (4) 공개SW 관리 범위 90 | * **공개SW 사용 범위에 따른 라이선스 의무사항**
91 | 공개SW 라이선스는 공개SW 사용 범위에 의해 의무사항이 적용되는데 [그림 9]와 같이 개발자들이 수취 및 실행을 목적으로만 사용할 경우에는 라이선스 준수 의무가 없고 배포 및 서비스의 경우 라이선스 의무사항이 적용된다. 또한 적용 라이선스의 성격에 따라 단순히 사용 및 변경사항을 고지할 수도 있고 소스코드 전체를 공개할 수도 있다. 다만, 공개SW R&D 수행 중 사용된 공개SW 컴파일러 등의 경우는 단지 실행만을 목적으로 사용됨에 따라 라이선스 의무사항이 발생되지 않는다. 92 |
93 | 94 |

그림 9. 공개SW 사용범위 별 라이선스 의무사항


95 | 96 | 97 | * **배포 및 서비스 유형**
98 | 유상이든 무상이든 관계없이 공개SW R&D결과물을 외부에 배포 및 서비스 시에는 어떠한 공개SW를 사용 하더라도 해당 공개SW 라이선스에 따라 [그림 10]와 같이 공개SW 라이선스 의무사항이 발생된다. 허용적(permissive) 라이선스 계열의 공개SW를 사용했을 경우 사용 및 변경사항에 대한 고지의무와 특정 라이선스의 경우 특허권리를 주장할 수 없게 된다. 약한(weak) 카피레프트 라이선스 계열의 공개SW를 사용했을 경우 추가적으로 제한된 범위에서의 소스코드 공개의무가 발생되고, 강한(strong) 카피레프트 라이선스 계열의 공개SW를 사용했을 경우 모든 소스코드 공개의무가 발생된다. 사용된 공개SW 중에 AGPL-3.0, SSPL-1.0 라이선스가 사용되었다면 오프라인을 통한 배포 뿐 아니라 네트워크를 통한 서비스를 제공할 경우에도 라이선스 의무사항이 발생된다. 99 |

100 | 따라서, 외부 공개SW를 사용할 경우 해당 공개SW 라이선스 계열에 따라 의무사항이 달라 짐에 따라 공개SW R&D 결과물 공개를 위해 계획한 대표 라이선스 및 호환 라이선스 정책에 부합되게 공개SW가 사용될 수 있도록 관리하여야 한다. 101 | 102 |
103 | 104 | ## (5) 공개SW R&D 수행에 있어서 공개SW 사용정책 105 | 공개SW R&D 수행에 있어 외부 공개SW를 사용할 경우에는 공개SW R&D 라이선스 정책 수립단계에서 검토한 공개SW 라이선스 분류기준을 활용할 수 있다. [표 12]과 같이 사용되는 공개SW 라이선스 분류별로 발생되는 의무사항을 검토하여 해당 공개SW R&D 라이선스 정책에 부합되게 사용정책을 수립할 수 있다. 106 | 107 | > 표 12. 공개SW 라이선스 분류별 사용정책
108 | 109 | | 공개SW 라이선스 분류 | R&D 결과물 공개 시 발생 의무사항 | 소스코드 공개 범위 | 사용정책 | 110 | | :----------------------------------------------------------: | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------: | :-----------------: | 111 | | 허용적 라이선스 계열
(MIT, BSD 등) | • 사용 공개SW명, 저작권 명, 라이선스 명, 라이선스 사본, 출처에 대한 고지
• 경우에 따라, Apache 등과 같이 무상 특허 허용 의무사항을 가진 라이선스 검토 필요 | 없음 | 사용 | 112 | | 약한 카피레프트 라이선스 계열
(LGPL, EPL, MPL 등) | • 사용 공개SW명, 저작권 명, 라이선스 명, 라이선스 사본, 출처에 대한 고지
• 공개SW를 수정 사용할 경우 수정 사용 소스코드 공개 의무 (예외 조항 있음)
• 경우에 따라, EPL, MPL 등과 같이 무상 특허 허용 의무사항을 가진 라이선스 검토 필요 | 라이브러리, 모듈, 파일 등 | 사용 or
사용금지 | 113 | | 강한 카피레프트 라이선스 계열 (I)
(GPL 2.0, AGPL 2.0 등) | • 사용 공개SW명, 저작권 명, 라이선스 명, 라이선스 사본, 출처에 대한 고지
• 사용한 공개SW 라이선스와 동일한 조건으로 전체 소스코드 공개 의무 | 전체 소스코드.
단, 결합형태에 따라 예외조항 있음 | 사용 or
사용금지 | 114 | | 강한 카피레프트 라이선스 계열 (II)
(GPL 3.0, AGPL 3.0 등) | • 사용 공개SW명, 저작권 명, 라이선스 명, 라이선스 사본, 출처에 대한 고지
• 사용한 공개SW 라이선스와 동일한 조건으로 전체 소스코드 공개 의무
• 해당 R&D 결과물이 특허등록 대상일 경우, GPL3.0, AGPL 3.0 등과 같이 무상 특허 허용 의무사항을 가진 라이선스 검토 필요
• 특허 검토에 추가해서 R&D 결과물에 제3자의 무단 접근 혹은 복제 등을 통제하는 기술적 보호조치가 필요할 경우 GPL 3.0, AGPL 3.0과 같이 기술적 보호조치 금지 및 설치정보 제공 의무사항을 가진 라이선스 검토 필요 | 전체 소스코드
단, 결합 형태에 따라 예외조항 있음 | 사용 or
사용금지 | 115 | 116 |
117 | 118 | |
:heavy_exclamation_mark: 주의사항
| 119 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | 120 | | 해당 공개SW R&D 결과물 중 일부 소스코드만을 공개하기 위해 LGPL이나 MPL과 같은 약한 카피레프트 라이선스 정책 적용을 계획할 경우, 개발 중 강한 카피레프트 라이선스 계열의 공개SW가 사용된다면 계획 시 검토하지 않았던 전체 소스코드 공개가 발생되기 때문에 개발 중 강한 카피레프트 라이선스 계열의 공개SW 사용은 금지하는 정책(라이선스 충돌 및 기존 특허출원 회피 전략을 포함)을 수립하는 것이 바람직하다. | 121 | 122 |
123 | 124 | [표 12]에서 제시한 사용 공개SW 라이선스 분류별 사용정책 수립과 관련하여 보다 구체적으로 직접개발 코드와 결합 사용된 공개SW의 라이선스 계열, 허용적(permissive) 카피레프트 라이선스 계열, 약한(weak) 카피레프트 라이선스 계열, 강한(strong) 카피레프트 라이선스 계열)과의 결합 형태에 따라 [그림 11] [8](#footnote8)과 같이 R&D 결과물에 적용되는 라이선스 조건이 달라질 수 있다. 125 |
126 | 127 | - ①과 같이 직접개발 코드와 강한 카피레프트 라이선스 계열의 공개SW를 강하게 분리된 저작물(GPL 2.0의 경우 PIPE, 소켓, CLI, 시스템 콜 등)의 형태로 결합 사용할 경우 그 결과물은 직접개발 코드에 적용한 특정 라이선스와 강한 카피레프트 라이선스를 각각 적용하여 배포할 수 있다.
128 | 129 | - ②와 같이 직접개발 코드와 강한 카피레프트 라이선스 계열의 공개SW를 파생 저작물(GPL 2.0의 경우 모듈, 라이브러리 링크도 포함) 형태로 결합 사용할 경우 그 결과물 전체는 사용된 강한 카피레프트 라이선스를 적용하여 배포해야 한다.
130 | - ③과 같이 직접개발 코드와 약한 카피레프트 라이선스 계열의 공개SW를 파생 저작물 형태로 결합 사용할 경우 공개SW R&D 결과물 전체는 사용된 약한 카피레프트 라이선스를 적용하여 배포해야 한다.
131 | - ④와 같이 직접개발 코드와 약한 카피레프트 라이선스 계열의 공개SW를 분리된 저작물(LGPL 2.1의 경우 동적 링킹 등)의 형태로 결합 사용할 경우 그 결과물은 직접개발 코드에 적용한 특정 라이선스와 약한 카피레프트 라이선스를 각각 적용하여 배포할 수 있다.
132 | - ⑤와 같이 직접개발 코드와 허용적 라이선스 계열의 공개SW를 파생 저작물 형태로 결합 사용할 경우 그 결과물 전체는 사용된 허용적 라이선스 또는 직접개발 코드에 적용한 라이선스로 배포할 수 있다.
133 | - ⑥과 같이 직접개발 코드와 허용적 라이선스 계열의 공개SW를 결합 저작물 형태로 결합 사용할 경우(Apache 2.0의 경우 모듈) 그 결과물은 직접개발 코드에 적용한 특정 라이선스와 허용적 라이선스를 각각 적용하여 배포할 수 있다. 134 |

135 | 136 |

그림 10. 직접개발 코드와 공개SW 사용에 따른 R&D 결과물의 라이선스 적용 조건

137 | (※ License Compatibility 그림 수정, 출처: https://en.wikipedia.org/wiki/License_compatibility) 138 | 139 |
140 | 141 | ## (6) 공개SW R&D 공급망 관리 가이드 라인 142 | 주관기관은 참여기관 혹은 외부 개발자로부터 공개SW R&D 결과물에 포함되는 소프트웨어를 공급받을 경우 혹은 위탁 용역과제의 경우 해당 공개SW R&D를 위해 수립된 공개SW 사용 정책이 준수될 수 있도록 계약 시에 공개 SW 사용 정책을 분명히 고지하고 SW 공급시에 정책준수 여부를 확인하기 위한 조항이 필요하다. 해당 공개SW R&D 라이선스 정책준수 여부를 확인하기 위해서는 [표 13]과 같이 사용된 공개SW 내역을 확인할 수 있도록 신뢰할 만한 검증도구를 통해 분석된 공개SW검증 보고서를 수신하는 것이 권장된다. 검증보고서 검토 항목을 간단히 설명하면 다음과 같다. 143 | 144 | > 표 13. 공개SW 검증보고서 검토 항목 예시
145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 |
① 컴포넌트명② 라이선스③ 라이선스④ 버전⑤ 수정⑥ 결합 형태⑦ 공개⑧ 고지⑨ 특허⑩ 기준
LGPL 2.11.11○Dynamic Link○○X준수
⑪ 보안 취약점⑫ 데이터베이스⑬ ID⑭ 릴리즈 날짜⑮ Base Score⑯ 등급⑰ 기준
NVDCVE-2017-35862017-04-245.5Medium준수
199 | 200 | 1. 컴포넌트명 : 사용된 공개SW 프로젝트 명. ex) TensorFlow, Apache Cassandra 등
201 | 2. 라이선스 : 사용된 공개SW에 적용된 라이선스에 관련된 정보 및 의무사항.
202 | 3. 라이선스 명 : 사용된 공개SW에 적용된 라이선스 명. ex) GPL 2.0, LGPL 2.1, EPL 1.0 등
203 | 4. 버전 : 사용된 공개SW 프로젝트 버전.
204 | 5. 수정 : 공개SW를 수정하여 사용했을 경우 ○, 수정하지 않고 복제하여 사용했을 경우 X
205 | 6. 결합형태 : 사용자 코드와 공개SW의 결합형태. ex)공개SW를 동적 연결하여 사용할 경우 Dynamic Link, 정적 연결하여 사용할 경우 Static Link. (별첨 2. 사용·결합·통신 방식에 따른 라이선스 의무사항 참조)
206 | 7. 공개 : 사용된 공개SW 라이선스 의무사항으로 인해 해당 소스코드 공개가 발생할 경우 ○, 발생하지 않을 경우 X.
207 | 8. 고지 : 사용된 공개SW 라이선스 의무사항으로 인해 해당 공개SW 라이선스 사본 및 저작권 고지의무가 발생할 경우 ○, 발생하지 않을 경우 X.
208 | 9. 특허 : 사용된 공개SW 라이선스 의무사항으로 인해 무상특허 허용이 발생할 경우 ○, 발생하지 않을 경우 X.
209 | 10. 기준 : 해당 공개SW 라이선스 사용정책을 준수한 경우 준수, 준수하지 못한 경우 미준수
210 | 11. 보안 취약점 : 상용된 공개SW 및 버전에 포함되어 있는 보안취약점에 관련된 정보
211 | 12. 데이터베이스 : 보안취약점이 등록된 데이터베이스, 일반적으로 미국 국가 취약점 데이터베이스인 NVD(National Vulnerability Database)가 광범위하게 사용됨
212 | 13. ID : 해당 보안취약점 고유식별자로서 CVE (Common Vulnerabilities and Exposures)가 많이 사용되며 CVE는 시간대 별로 발생된 보안취약점 또는 위험 노출을 정리한 목록을 제공. MITRE를 주축으로 각종 소프 트웨어 회사나 CERT 같은 기관에서 감지되는 보안취약점을 보고하면 CVE 조정위원회에서 목록을 관리. CVE 의 형식은 CVE-[해당년도]-[일련번호]로 표현되며, 시간에 따라 감지된 보안 취약점 또는 위험 노출을 정리해 둔 목록. CVE는 미국 국토안보부 산하의 사이버 보안 및 인프라 보안국(Cybersecurity and Infrastructure Security Agency)의 재정 지원을 받아 MITRE Corporation에서 감독.
213 | 14. 릴리즈 날짜 : 해당 보안취약점이 공개된 날짜.
214 | 15. Base Score : NVD 주관으로 보안취약점에 대한 악용가능성과 영향도에 대한 점수로서 0-10까지 있으며 높은 점수일수록 악용가능성과 영향성에 대한 위험도가 높음.
215 | 16. 등급 : NVD 주관으로 보안취약점에 대한 악용가능성과 영향도에 대한 등급으로서 None, Low Risk, Medium Risk, High Risk로 구분됨
216 | 17. 기준 : 해당 공개SW 보안취약점 사용정책을 준수한 경우 준수, 준수하지 못한 경우 미준수 217 | 218 |
219 | 220 | ## (7) 공개SW 양립성 검토 221 | 공개SW 양립성은 호환성이라고도 하며, 기본적으로 공개SW를 사용함에 있어서 하나 이상의 공개SW 라이선스를 사용할 경우에 검토해야 될 사항이다.

222 | 공개SW R&D에서 A 공개SW와 B 공개SW를 결합하여 사용할 때 A에 적용된 공개SW 라이선스 조건과 B에 적용된 공개SW 라이선스 조건이 양립해서 공개SW R&D 결과물에 사용될 수 있는 조건일 경우 두 공개SW는 양립 또는 호환된다고 할 수 있다. 223 |
224 | 225 | |
:heavy_exclamation_mark: 주의사항
| 226 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | 227 | | 예를 들어, GPL 2.0이 적용된 공개SW 라이브러리를 사용했고 라이브러리 내에 MPL 2.0이 적용된 공개 SW 파일을 수정하여 사용했을 경우 사용된 공개SW 라이선스 의무사항에 따라 전체 소스코드는 GPL 2.0과 동일한 조건으로 공개를 해야 하지만 MPL 2.0 또한 공개 시에 MPL 2.0과 동일한 조건으로만 공개를 허용하고 있어서 양립되지 않는 조건에 해당된다. | 228 | 229 |
230 | 231 | ## (8) 공개SW R&D 특허와 공개SW 사용 검토 232 | * **공개SW와 특허**
233 | 특허란 신규성 및 진보성이 인정되는 발명에 대하여 사적 독점을 보장함으로써 발명을 보호, 장려하고 그를 통하여 기술을 발전시키고자 하는 제도이다. 이에 따라 특허를 취득하는 경우 해당 기술에 대하여 특허권자가 특허 발명을 실시할 기술을 독점하게 된다. 이러한 독점적인 사용권이 특허권자에게 부여되는 이상, 특허가 부여된 소프트웨어의 구성요소(예, 소스코드)는 자유로운 배포가 불가능하여 자유로운 기여 및 배포에 기반하는 공개SW의 취지와 양립하기 어렵다. 특히 특허가 부여된 경우 그 특허의 진보성 및 신규성을 구성하는 핵심적 기술 사상이 동일하면 코드가 달라져도 특허의 범위에 포함되어 보호되기 때문에, 특허와 공개SW는 충돌하기 쉽다. 공개SW 커뮤니티에서도 이러한 사실을 인식함에 따라, 공개SW의 자유로운 배포 및 확산이 특허에 의하여 제약되는 것을 방지하기 위하여 라이선스 조항에 특허를 제한하거나 무력화할 수 있는 조항을 포함하는 경우가 생겼는데, 이에 관하여 대표적인 것이 특허 보복 조항과 무상 특허 허용 조항이다. 234 | 235 | * **특허 보복 조항**
236 | 특허 보복 조항은 공개SW의 사용자가 해당 공개SW에 관련된 특허소송을 제기하는 경우 그 공개SW에 대한 라이선스를 자동으로 종료시키는 조항이다. 이러한 특허 보복 조항이 특허 자체를 무효화하는 것은 아니다. 그러나 이러한 조항은 공개SW의 배포, 기여 및 확산 과정에서 특허가 포함되었더라도 그 특허권자가 적극적으로 권리를 행사할 수 있는 수단인 특허소송을 제기하는 경우 해당 특허권자의 공개SW 라이선스를 자동으로 종료시킴으로써 간접적으로 공개SW에 이미 포함된 특허권의 행사를 저지하는 효과가 있다. 이러한 특허 보복 조항이 포함된 대표적인 라이선스로는 LGPL 3.0, AGPL 3.0, Apache 2.0, MPL, EPL, CPL 라이선스 등이 있다. 237 | 238 | * **무상 특허 허용 조항** [9](#footnote9)
239 | 무상 특허 허용 조항은 해당 공개SW에 대하여는 특허권자가 공개SW 사용자들에게 무료로 특허를 사용할 수 있도록 허용하는 규정을 의미한다. 이러한 조항이 있는 경우 해당 공개SW에 포함된 특허는 그 공개SW에 관하여서는 사실상 특허권 행사를 포기한 것과 같은 효력이 발생하게 된다. 이러한 무상 특허 허용 조항이 포함된 대표적인 라이선스로는 GPL 3.0, LGPL 3.0, MPL 2.0, EPL 1.0, Apache 2.0, CDDL 등이 있다.
240 | 241 | ① GPL 3.0 : 무상 특허 허용, 차별적 특허 라이선스 계약 체결 금지 조항이 있다. (10조)
242 | ② LGPL 3.0 : 차별적인 특허 라이선스 계약체결의 금지 조항이 있다. (11조)
243 | ③ MPL 2.0 : 무상 특허 허용, 특허소송 제기 시 60일 이내에 관련 소송을 철회하거나 원 개발자 등에게 라이선스 사용에 따른 정당한 로열티를 지급하지 않는 경우에 해당 라이선스에서 부여한 무상 특허권 및 저작권리가 종료된다. (5조 2항)
244 | ④ EPL 1.0 : 무상 특허 허용, 특허소송 제기 시 해당 소송이 제기된 날에 사용자에게 주어진 무상 특허권리가 종료된다. (라이선스 사용 권리는 유지) (2조)
245 | ⑤ Apache 2.0 : 무상 특허 허용, 특허소송(교차청구나 반소 포함)을 하는 경우 해당 라이선스에서 부여한 무상 특허 라이선스 권리가 소송 접수일에 종료되는 것으로 규정하고 있다. (3조)
246 | ⑥ CDDL(Common Development & Distribution License) : 특허 침해 소송을 제기하는 경우, 공개소프트웨어 저작권자로부터 통보를 받은 지 60일 이내에 소송을 취하하거나 철회하지 않으면, 공개소프트웨어 저작권자가 본 라이선스의 제2조1항과 제2조2항에 준하여 부여한 모든 권한은 통보한 날로부터 60일 이후에 종료된다.(6조 2항)
247 | 248 | * **특허 사용 기준 및 정책**
249 | 특허 보복 조항 혹은 무상 특허 허용 조항이 포함된 공개SW 라이선스를 이용하여 개발되는 경우, 그 과정에서 R&D 연구기관의 특허가 포함되는 경우 그 특허가 무력화되거나 해당 공개SW 라이선스를 이용할 수 없게 되어 프로젝트 250 | 전체에 문제를 발생시킬 수 있다. 따라서 다음과 같은 지침의 준수가 요구된다.
251 | 252 | ① 가능한 특허의 취득 : 모든 공개SW 라이선스에 특허 보복 조항 혹은 무상 특허 허용 조항 등이 존재하는 것이 아니며, 또 그러한 조항이 있더라도 특허권 자체를 박탈하는 것은 아니기 때문에, 공개SW를 이용한 개발 과정에서 특허권을 취득할 수 있는 기술이 개발된 경우 해당 기술에 대하여는 공개SW와 무관하게 특허 출원절차를 진행한다.
253 | ② 특허의 보호 조치 : 앞서 언급된 LGPL 3.0, AGPL 3.0, Apache 2.0, MPL, EPL, CPL 라이선스 등 특허 보복조항 및/또는 무상 특허 허용 조항이 있는 공개SW를 사용한 개발 과정에서 자사 및 관계사의 특허가 사용되는 경우 해당 특허권의 행사에 이슈가 발생하거나 향후 해당 공개SW의 지속 사용에 문제가 발생할 수 있으므로, 원칙적으로 해당 라이선스를 사용한 개발에는 R&D 연구기관의 특허권 포함 여부와 관련 이슈에 대한 검토가 필요하며 공개SW 사용절차에 특허 검토 절차를 추가하여 수행하는 것을 권장한다.
254 | 255 |
256 | 257 | |
:heavy_exclamation_mark: 주의사항
| 258 | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 259 | | A대학에서 공개SW R&D를 수행함에 있어 XX특허를 등록하고 향후 소스코드는 공개하여 자유롭게 사용하도록 허용할 계획이지만 해당 소스코드를 기반으로 특정 기술 및 서비스를 제공하는 기업들에게 특허 로열티를 청구할 목적인 경우 다음 두 가지 사항을 주의하여야 한다.

① R&D 개발 시에 무상 특허 허용 규정을 가지고 있는 GPL 3.0, AGPL 3.0, Apache 2.0, MPL, EPL, CPL 등의 라이선스가 적용된 공개SW 사용하지 않음
② R&D 결과물을 공개 시에 무상 특허 허용 규정을 가지고 있는 GPL 3.0, AGPL 3.0, Apache 2.0, MPL, EPL, CPL 등의 라이선스를 적용하지 않음
③ R&D 개발 및 공개 시에 무상 특허 허용 규정을 가지고 있지 않은 MIT, BSD계열, GPL 2.0, LGPL 2.0 등의 라이선스가 적용된 공개SW 사용 가능 | 260 | 261 | 262 | 263 | --- 264 | 265 | 8) https://en.wikipedia.org/wiki/License_compatibility, License compatibility : “License compatibility for derived works and combined works of a developer's own code and externally developed open-sourcelicensed code (adapted from Välimäki 2005)“ [return](#part1_2_08)
266 | 9) 정보통신산업진흥원, 공개소프트웨어 라이선스 가이드, 2021 [return](#part1_2_09)
267 | -------------------------------------------------------------------------------- /part1/02/05.md: -------------------------------------------------------------------------------- 1 | # 5. 공개SW R&D 기술이전시의 검토사항 2 | 공개SW R&D결과물의 사업화를 위한 기술이전을 위해서는 1) 기술이전 유형과 유형별 고려사항을 분석하고, 2) 추진전략과 사업모델의 수립, 그리고 3) 공개SW의 라이선스 정책 수립 및 공개SW 사용 정책 수립에 반영하여야 한다 3 | 4 |

그림 11. 공개SW R&D 기술이전 검토사항


5 | 6 | ## 가. 공개 R&D 결과물의 기술이전 유형 [10](#footnote10) 7 | 공개SW R&D 결과물을 기술이전하는 것은 상용화하는 부분과 어떻게 결합되어 있는가에 따라 다음과 같은 여러 유형들을 고려할 수 있다. 8 | 9 | > 표 14. 공개SW R&D 결과물의 기술이전 유형
10 | 11 | | No. | 유 형 | 예 제 | 12 | | :-: | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | 13 | | 1 | 일부 소스코드는 공개하고 일부 소스코드는 기술이전 | 소스코드 A와 B가 결합되는 공개SW R&D 결과물 중 A 소스코드를 Apache/BSD/MIT/GPL(허용적 라이선스와 강한 카피레프트 라이선스) 등으로 공개하고 B를 기술이전하는 경우 | 14 | | 2 | 일부 소스코드와 실행파일을 공개하고, 실행파일의 소스 코드를 기술이전 | 소스코드 A와 B가 결합되는 공개SW R&D 결과물 중 A 소스코드를 공개하고 B 실행파일을 공개한 후, B 실행파일에 대한 소스코드를 기술이전하는 경우 | 15 | | 3 | 듀얼 라이선스 적용 (강한 카피레프트 라이선스, 상용) | 소스코드 A로 구성되는 공개SW R&D 결과물을 GPL과 같은 강한 카피레프트 라이선스로 공개하고 상용 라이선스를 듀얼 라이선스로 적용하여 전체 코드를 기술이전하는 경우 | 16 | | 4 | 듀얼 라이선스 적용 (허용적 라이선스, 상용) | 소스코드 A로 구성되는 공개SW R&D 결과물을 MIT와 같은 허용적 라이선스로 공개하고 상용 라이선스를 듀얼 라이선스로 적용하여 전체 소스코드를 기술이전하는 경우 | 17 | 18 |
19 | 20 | ## 나. 공개 SW R&D 결과물의 기술이전 유형별 검토사항 21 | ### (1) 일부 소스코드를 공개하고 일부 소스코드를 기술이전하는 경우 22 | 이 유형을 그림으로 표현하면 다음과 같다. R&D 결과물을 구성하는 소스코드 A와 B는 서로 중복되지 않는 기능 모듈들로 구성된다. 이 경우, 공개 라이선스나 결과물 개발 시 사용한 오픈소스의 라이선스를 모두 고려해야 한다. 23 |
24 | 25 |

그림 12. 일부 소스코드 공개, 일부 소스코드 기술이전


26 | 27 | 이 유형에 대해 검토해야 할 사항들을 구체적으로 나열해 보면 표와 같다. 28 | 29 | > 표 15. 공개 SW R&D 결과물의 기술이전 유형별 검토사항 (일부 소스코드만 공개)
30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 |
공개SW R&D 결과물소스코드 공개 적용
라이선스 및 기술이전		자체개발 or
사용 가능한 공개SW		결합형태
AApache/BSD/MIT 등 허용적 라이선스 계열로 공개• 자체개발 or 허용적 라이선스 계열만 사용 가능A와 B는 분리된 저작물로 결합되어야 함
(별첨 1. 사용·결합·통신 방식에 따른 라이선스 의무사항 참조)
GPL 등 강한 카피레 프트 라이선스 계열로 공개• 자체개발 or 허용적 라이선스 계열 사용 가능
• 강한 카피레프트 라이선스로 공개할 경우에는 동일한 의무사항을 가진 강한 카피레프트 라이선스 사용 가능
• MPL, EPL 등 동일 조건 배포만 요구하는 약한 카피레프트 라이선스는 사용할 수 없음
B기술이전• 자체개발 or 허용적 라이선스 계열만 사용 가능
• Apache와 같은 무상 특허 허용 라이선스에 대한 추가 검토 필요
60 | 61 |
62 | 63 | ### (2) 일부 소스코드 공개 + 실행파일 제공 64 | 이 경우를 그림으로 표현하면 다음과 같다. R&D 결과물을 구성하는 소스코드 A와 B는 서로 중복되지 않는 기능 모듈들로 구성된다. 다만, 모듈 B에 대해서는 실행파일만 공개하고 소스코드를 기술이전하는 경우이다 65 |
66 | 67 |

그림 13. 공개SW R&D 기술이전 검토사항(1)


68 | 69 | 이 유형에 대해 검토해야 할 사항들을 구체적으로 나열해 보면 표와 같다. 70 | 71 | > 표 16. 공개 SW R&D 결과물의 기술이전 유형별 검토사항 (일부 소스코드 공개 + 실행파일 제공)
72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 |
공개SW R&D 결과물소스코드 공개 적용
라이선스 및 기술이전		자체개발 or
사용 가능한 공개SW		결합형태
AApache/BSD/MIT 등 허용적 라이선스 계열로 공개• 자체개발 or 허용적 라이선스 계열만 사용 가능A와 B는 분리된 저작물로 결합되어야 함
(별첨 1. 사용·결합·통신 방식에 따른 라이선스 의무사항 참조)
GPL 등 강한 카피레프트 라이선스 계열로 공개• 자체개발 or 허용적 라이선스 계열 사용 가능
• 강한 카피레프트 라이선스로 공개할 경우에는 동일한 의무사항을 가진 강한 카피레프트 라이선스 사용 가능
• MPL, EPL 등 동일 조건 배포만 요구하는 약한 카피레프트 라이선스는 사용할 수 없음
B기술이전 • 자체개발 or 허용적 라이선스 계열만 사용 가능
• Apache와 같은 무상 특허 허용 라이선스에 대한 추가 검토 필요
102 | 103 |
104 | 105 | ### (3) 듀얼 라이선스(강한 카피레프트 라이선스, 상용 라이선스) 106 | 이 경우를 그림으로 표현하면 다음과 같다. R&D 결과물을 구성하는 소스코드 A에 듀얼 라이선스를 적용하여 공개와 기술이전을 동시에 진행하는 경우이다. 특히 공개할 때 카피레프트 라이선스를 기반으로 소스코드를 공개하는 경우이다. 107 |
108 | 109 |

그림 14. 공개SW R&D 기술이전 검토사항(2)


110 | 111 | 이 유형에 대해 검토해야 할 사항들을 구체적으로 나열해 보면 표와 같다. 112 | 113 | > 표 17. 듀얼 라이선스 결과물(강한 카피레프트 라이선스, 상용 라이선스)의 검토사항
114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 |
공개SW R&D 결과물소스코드 공개 적용
라이선스 및 기술이전		자체개발 or
사용 가능한 공개SW		결합형태
AGPL로 소스코드 공개• 자체개발 or 허용적 라이선스 계열 사용 가능
• 강한 카피레프트 라이선스로 공개할 경우에는 동일한 의무사항을 가진 강한 카피레프트 라이선스 사용 가능
• MPL, EPL 등 동일 조건 배포만 요구하는 약한 카피레프트 라이선스는 사용할 수 없음		결합 형태 유형 에 따른 검토사항 없음
B기술이전
(GPL 의무사항 이행이 어려운 사용자 대상)		• Apache와 같은 무상 특허 허용 라이선스에 대한 추가 검토 필요
140 | 141 | |
:heavy_exclamation_mark: 주의사항
| 142 | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 143 | | 듀얼 라이선스 (dual license) : 공개SW R&D를 수행함에 있어 1개 이상의 공개SW 라이선스가 적용된 공개 SW를 사용하는 경우이다. 이 경우 R&D 결과물의 배포 시에 함께 사용된 공개SW 라이선스 의무사항이 모두 준수될 수 있어야 한다. | 144 | 145 |
146 | 147 | ### (4) 듀얼 라이선스(허용적 라이선스, 상용 라이선스) 148 | 이 경우를 그림으로 표현하면 다음과 같다. R&D 결과물을 구성하는 소스코드 A에 듀얼 라이선스를 적용하여 공개와 기술이전을 동시에 진행하는 경우로, 허용적 라이선스를 기반으로 소스코드를 공개하는 경우이다. 149 |
150 | 151 |

그림 15. 공개SW R&D 기술이전 검토사항(3)


152 | 153 | 154 | 이 유형에 대해 검토해야 할 사항들을 구체적으로 나열해 보면 표와 같다. 155 | 156 | > 표 18. 듀얼 라이선스 결과물(허용적 라이선스, 상용 라이선스)의 검토사항
157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 |
공개SW R&D 결과물소스코드 공개 라이선스 및 기술이전자체개발 or
사용 가능한 공개SW		결합형태
A허용적 라이선스(MIT, BSD, Apache 동)로 소스코드 공개• 자체개발 or 허용적 라이선스 계열만 사용 가능
• MPL, EPL 등 동일 조건 배포만 요구하는 약한 카피레프트 라이선스는 사용할 수 없음
• MIT 의무사항은 고지의무만 존재하므로 별다른 제약조건 없이 무료 사용이 가능한 소스코드에 대해 상용 라이선스 구매(기술이전 계약)가 필요하지 않음
• A소스코드에 허용적 라이선스 계열을 적용하여 일반 사용자들에게는 자유로운 사용을 허용하면서 상용 라이선스(기술이전 계약) 정책을 적용하기 위해서는 제한적인 허용적 라이선스의 적용 및 개발이 필요함
• 예) 비영리 목적에는 자유롭게 사용하지만 영리 목적의 사용인 경우 상용 라이선스가 적용되는 라이선스 개발 적용 or 상용 사용이 금지된 라이선스 (CC-BY-NC-4.0, CC-BY-NC-SA-4.0, CC-BY-NC-ND-4.0 등) 적용		결합 형태 유형에 따른 검토사항 없음
B기술이전
(비영리 목적으로만 사용이 어려운 경우)		• Apache와 같은 무상 특허 허용 라이선스에 대한 추가 검토 필요
183 | 184 | 185 | --- 186 | 187 | 10) ETRI, 오픈소스 기술이전 및 공개를 위한 라이선스 모델연구, 2020 [return](#part1_2_10)
188 | -------------------------------------------------------------------------------- /part1/03/annex1.md: -------------------------------------------------------------------------------- 1 | ## :page_facing_up: 별첨 1 공개SW 라이선스 의무사항 2 | 3 | > 주요 공개SW 라이선스 조건에 대한 주요 의무사항을 비교하여 표로 정리하면 다음과 같다
4 | 5 | | NO | License Name (SPDX idenrifier) | 배포(바이너리 파일 배포에 의해서만 부여되는 의무사항) | 소스코드 공개/강제적 공유 의무사항 | 복제 및 수정 권한 허용 | 역설계 권한 허용 | 차별적 제한조건 제한 | 특허 무상 실시권 부여, 특허 보복 | DRM 보호금지, 설치정보 제공 | 고지 (라이선스 사본 포함) | 변경사항 고지 (라이선스 사본 포함) | 보증의 부인 및 책임의 제한 | 광고/ 홍보시 배포자, 저작자, 특정상 표사용 금지 | 원코드와 동일조건 허가 | 라이선스 적용 범위 | 6 | | :-: | :----------------------------: | :---------------------------------------------------: | :--------------------------------: | :--------------------: | :--------------: | :------------------: | :------------------------------: | :-------------------------: | :-----------------------: | :--------------------------------: | :------------------------: | :---------------------------------------------: | :--------------------: | :----------------: | 7 | | 1 | GPL-2.0 | O | O | O | △ | △ | X | X | O | O | O | X | O | GPL | 8 | |2| GPL-3.0 |O| O| O| △ |O |O |O |O |O |O |X |O| GPL| 9 | |3| AGPL-3.0 |O |O |O |△ |O |O |O |O |O |O |X |O| GPL| 10 | |4 |Apache-2.0| X| X| O| △| X |O |X |O |O |O |O |X |X| 11 | |5 |APSL-2.0 |O |O |O |△ |X |O |X |O |O |O |O |O |MPL| 12 | |6 |BSD-3-Clause |O |X |O |△ |△ |X |X |O |X |O |O |X |X| 13 | |7 |BSD-2-Clause |O |X |O |△ |△ |X |X |O |X |O |X |X |X| 14 | |8 |BSD-4-Clause |O |X |O |△ |△ |X |X |O |X |O |X |X |X| 15 | |9 |CC-BYSA-4.0 |O |O |O |△ |O |X |O |O |O |O |O |O |GPL| 16 | |10 |MPL-2.0 |O |O |O |△ |X |O |X |O |O |O |X |O |MPL| 17 | |11 |CDDL-1.0 |X |O |O |△ |X |O |X |O |O |O |X |O |MPL| 18 | |12 |CPL-1.0 |O |O |O |△ |X |O |X |O |O |O |X |O |EPL_CPL| 19 | |13 |EPL-2.0 |O |O |O |△ |△ |O |X |O |O |O |X |O |MPL| 20 | |14 |IPL-1.0 |X |O |O |△ |X |O |X |O |O |O |X |X |MPL| 21 | |15| IJG |X |X |O |△ |△ |X |X |O |O |O |O |X |X| 22 | |16 |ISC |O |X |O |△ |△ |X |X |O |X |O |X |X |X| 23 | |17 |LGPL-2.1 |O |O| O |O |X |X |X |O |O |O |X |O |LGPL| 24 | |18 |LGPL-3.0 |O |O |O |O |O |X |X |O |O |O |O |O |LGPL| 25 | |19 |MS-PL |X |X |O |△ |X |O |X |O |X |O| O |X |X| 26 | |20 |MIT |O |X |O |△ |△ |X |X |O |X |O |X |X |X| 27 | |21 |OSL-3.0 |X |O |O |△ |△ |O |X |O |O |O |O |O |MPL| 28 | |22 |OpenSSL |X |X |O |△ |X |X |X |O |O |O |O |X |X| 29 | |23 |Ruby |O |X |O |△ |△ |X |X |O |X |O |X |X |LGPL| 30 | |24 |OFL-1.1| X| X| O| △| X| X| X| O| X| O| O| X| X| 31 | |25| ZPL-2.0 |X |X |O |△ |△ |X |X |O |X |O |O |X |X| 32 |
33 | 34 | △ 강제 의무사항이 없고 자율적으로 결정 35 | X 해당 의무사항/권리/책임을 부여해서는 안됨 36 | O 해당 의무사항을 준수해야 함 -------------------------------------------------------------------------------- /part1/03/annex2.md: -------------------------------------------------------------------------------- 1 | ## :page_facing_up: 별첨 2 사용·결합·통신 방식에 따른 라이선스 의무사항 2 | 3 | | 결합형태 구분 | 적용 경우 | 4 | | :--------------------------------------------: | --------- | 5 | | 동일매체 단순집합 저작물
(Merely Aggregate) | • 공개SW가 직접개발한 코드와 분리되어 상호 링크 및 연결되어 작동하지 않지만 단지 동일매체로 배포되는 경우로서 동일매체로 배포되는 공개SW 라이선스는 직접개발 코드에 적용되지 않음
• 예) GPL-2.0이 동일매체로 배포되는 경우 GPL2.0 고지의무만 이행, 해당 GPL-2.0코드를 수정할 경우 GPL 2.0 모든 코드 공개 | 6 | |분리된 저작물
(Separate Work) | • 공개SW사용 사례로서 공개SW가 직접개발 코드와 파이프(pipes), 소켓(sockets), command-line arguments 형태로 통신하는 경우, 공개SW가 플러그인(plug-ins)의 경우 fork와 exec를 이용하는 경우, 공개SW가 정상적인 시스템 콜에 의해 커널 서비스를 이용하는 사용자 프로그램(user programs)일 경우 공개SW 라이선스는 직접개발 코드에 적용되지 않음
• 예) GPL 2.0이 상기 방식으로 직접개발 코드와 결합되어 있을 경우 GPL 2.0 고지의무만 이행, 해당 GPL 2.0코드를 수정할 경우 수정코드를 포함하는 모든 소스코드 공개 | 7 | |동적/정적 라이브러리 링크
(Dynamic Library/ Static Library) | • 공개SW가 직접개발 코드와 동적/정적 라이브러리로 링크되어 있는 경우로서 LGPL의 경우 해당 라이선스가 직접개발 라이브러리에는 적용되지 않음
• 예) LGPL 2.1이 수정되지 않고 상기 방식으로 직접개발 코드와 결합되어 있을 경우 LGPL 2.1 고지의무만 이행, 해당 LGPL 2.1코드를 수정할 경우 수정코드를 포함하는 해당 라이브러리 소스코드 공개 | 8 | | 모듈
(Module) | • 공개SW가 직접개발 코드와 파일복제 형태로 연결되어 있는 경우로서 EPL, CPL의 경우 해당 라이선스가 모듈 범위 내로 적용되는 경우
• 예) EPL, CPL이 수정되지 않고 상기 방식으로 직접개발 코드와 결합되어 있을 경우 고지의무만 이행, 해당 EPL, CPL 코드를 수정할 경우 수정코드를 포함하는 해당 모듈 소스코드 공개 | 9 | | 파일
(File) | • 공개SW가 직접개발 코드와 파일복제 형태로 연결되어 있는 경우로서 MPL의 경우 해당 라이선스가 파일 범위 내로 적용되는 경우
• 예) MPL이 수정되지 않고 상기 방식으로 직접개발 코드와 결합되어 있을 경우 고지의무만 이행, 해당 MPL 코드를 수정할 경우 수정코드를 포함하는 해당 파일 소스코드 공개 | 10 | 11 | ※ 구체적 사항은 ‘공개소프트웨어 라이선스 가이드’(정보통신산업진흥원) 자료 (https://www.oss.kr/oss_guide) 참조(2021. 11월) 12 | -------------------------------------------------------------------------------- /part1/03/faq.md: -------------------------------------------------------------------------------- 1 | # 3장 자주 묻는 질문과 답변(FAQ) 2 | 3 | 4 | + ### Q1 공개SW R&D 사업화를 위해 가장 중요한 검토사항은 무엇인지요? 5 | 공개SW R&D 사업화를 위해서는 가장 먼저 사업화를 위한 시장분석을 통한 추진전략 수립과 사업모델을 구체화하는 것이 중요합니다. 예를 들어 특정 상용SW 벤더가 시장을 독점하고 있는 상황이라면 동일한 기능을 제공하는 상용SW를 개발하여 경쟁하기에는 진입장벽이 높을 수 있습니다. 이런 경우 공개SW R&D를 통해 경쟁하는 상용SW 대체를 위한 공개SW 신제품 개발전략을 검토할 수 있고 사업모델도 고가의 상용 라이선스 정책 대신 년간 구독모델을 통해 가격경쟁력을 가져갈 수 있습니다. 6 | 7 |
8 | 9 | + ### Q2 공개SW R&D를 계획할 때 가장 먼저 검토해야 할 검토 단계는 어떻게 되는지요? 10 | 공개SW R&D를 계획함에 있어서는 공개SW R&D를 통한 사업화가 목적인지 공개SW로서의 부가기대효과를 위한 비영리 목적인지를 명확히 하여야 합니다. 공개SW R&D의 목적에 따라 라이선스 정책 및 공개SW 사용정책 등에 대한 검토사항이 달라지기 때문입니다. 11 | 12 |
13 | 14 | + ### Q3 공개SW R&D를 수행하게 되면 반드시 전체 소스코드를 공개해야 하는지요? 15 | 그렇지 않습니다. 기존 공개SW 프로젝트들도 전체 소스코드를 공개하는 경우도 있고 특정 라이브러리, 모듈 등을 공개하는 경우도 있습니다. 또한 동일한 SW 중 일부 기능을 제공하는 소스코드는 공개해서 자유롭게 사용하도록 허용하면서도 일부 기능은 상용SW로 판매하는 경우도 있습니다. 따라서, 공개SW R&D의 추진전략에 따라 소스코드 공개 범위를 검토할 수 있습니다. 16 | 17 |
18 | 19 | + ### Q4 공개SW R&D 결과물에 적용할 공개SW 라이선스 선택의 기준은 무엇인가요? 20 | 공개SW R&D 결과물에 적용할 라이선스 선택기준은 추진전략과 사업모델입니다. 추진전략이 다양한 산업과 사용자들의 상용/독점 사용을 포함하여 자유로운 사용을 장려하기 위함이면 가급적 제약조건이 없는 퍼미시브(허용적) 라이선스 계열을 적용하는 것이 권장되고, 공개SW R&D 결과물을 공개 후 특정 기업이나 개발자들의 상용/독점 사용을 제한하기 위해서는 강한(strong) 카피레프트 라이선스 계열을 적용하는 것이 권장됩니다. 21 | 22 |
23 | 24 | + ### Q5 공개SW R&D 결과물에 대해 특허 등록을 계획하고 있습니다. R&D 결과물에 공개SW 라이선스를 적용하여 공개 하더라도 특허권리 주장에 문제는 없는지요? 특허권리 주장을 위해 주의해야 할 사항은 무엇인지요? 25 | 공개SW R&D 결과물을 특허출원 및 등록을 하는 목적은 특허권리를 주장하기 위함입니다. 따라서, 공개 SW R&D 결과물을 공개하면서도 특허권리를 주장하기 위해서는 두 가지 사항을 검토해야 합니다. 첫째, 무상 특허 사용을 허용해야 하는 GPL 3.0, LGPL 3.0, Apache 2.0, EPL/CPL/MPL 계열의 공개SW 라이선스를 개발하는 과정에서 선택해서는 안 됩니다. 다만, 특허청구 조항이 소스코드 저작권과 관련이 없는 알고리즘 등이면 사용할 수 있습니다. 둘째, 공개SW R&D 결과물을 공개할 때 무상 특허 사용을 허용해야 하는 공개SW 라이선스를 선택해서는 안 됩니다. 만약 해당 공개SW 라이선스를 적용하여 공개할 경우 모든 사용자들에게 무상 특허 사용을 허용해야 합니다. 26 | 27 |
28 | 29 | + ### Q6 외부 공개SW를 활용하여 공개SW R&D를 수행하는 것과 직접개발 할 경우의 가장 큰 차이점은 무엇인가요? 30 | 공개SW R&D 수행 시에 외부 공개SW를 활용하게 될 경우에는 활용된 공개SW에 적용된 라이선스 의무사항을 준수해야 하기 때문에 공개SW R&D 결과물의 공개에 있어 제약을 받게 됩니다. 반면, 공개SW R&D 수행 시에 연구개발 수행기관이 직접 개발할 경우에는 공개SW R&D 결과물에 대한 모든 저작권을 연구개발 수행기관이 확보함에 따라 연구기관의 정책과 조건에 따라 공개SW R&D 결과물을 공개 및 사용할 수 있습니다. 31 | 32 |
33 | 34 | + ### Q7 공개SW R&D 결과물을 모두 공개 시에 개발 연구기관의 저작권은 어떻게 되는지요? 35 | 저작권은 창작물을 창작함과 동시에 창작자에게 부여되는 권리입니다. 따라서, 공개SW에도 모두 저작권이 존재하고 저작권리를 행사할 수 있습니다. 다만, 공개SW의 경우 저작권자가 저작권리를 행사함에 있어서 소스코드를 공개해서 누구나 자유롭게 사용할 수 있도록 허용하면서도 명문화된 라이선스를 적용하여 사용자들에게 라이선스 의무사항을 준수하도록 요구하는 것이 일반 상용SW와의 차이점이라고 할 수 있습니다. 공개SW R&D 결과물을 모두 공개하게 될 경우 연구기관이 직접 개발한 코드의 저작권은 연구기관에게 있습니다. 다만, 함께 사용된 공개SW 라이선스 조건에 따라 저작권리를 행사함에 있어 해당 공개SW 라이선스 조건에 따라 저작권리 행사가 제한될 수는 있습니다. 36 | 37 |
38 | 39 | + ### Q8 외부 공개SW를 활용하여 수행한 공개SW R&D의 사업화에 가장 주의해야 할 사항은 무엇인가요? 40 | 공개SW R&D의 사업화에 있어서는 사업화를 위한 추진전략과 사업모델을 면밀히 검토하여 외부 공개SW 사용 정책과 절차를 수립하는 것이 중요합니다. 예를 들어, 공개SW R&D 결과물 중 특정 기능을 제공하는 소스코드를 공개SW로 공개하여 산업과 사용자들이 별다른 제약조건 없이 자유롭게 활용하게 함으로써 시장을 점유하고 시장 점유를 기반으로 공개SW R&D 결과물 중 공개하지 않은 일부 부가 기능을 판매하기 위한 사업화 전략일 경우 다음 두 가지에 대한 주의가 필요합니다. 첫째, 공개SW R&D 결과물을 사용자들이 자유롭게 활용 및 사용할 수 있도록 허용적(permissive) 라이선스 계열로 공개하는 것이 권장됩니다. 둘째, 공개SW R&D 결과물을 허용적(permissive) 라이선스 계열로 공개하기 위해서는 공개SW R&D 수행 시에 강한(strong) 카피레프트 라이선스 계열의 공개SW를 사용해서는 안 됩니다. 41 | 42 |
43 | 44 | + ### Q9 공개SW R&D 결과물을 공개하여 누구나 자유롭게 사용하도록 하고 싶습니다. 어떤 라이선스를 적용해야 하는지요? 45 | 공개SW R&D 결과물을 공개하여 누구나 별다른 제약조건 없이 자유롭게 사용하게 하기 위해서는 사용된 공개SW 및 저작권 고지, 공개SW 라이선스 사본 제공만을 요구하고 있는 MIT, BSD 등과 같은 퍼미시브(허용적) 라이선스 계열을 적용하는 것이 권장됩니다. 46 | 47 |
48 | 49 | + ### Q10 공개SW R&D 결과물을 공개하더라도 개발 연구기관의 조건에 맞게 사용하도록 하고 싶습니다. 어떤 방법이 있을까요? 50 | 공개SW R&D 결과물 공개 시에 사용자들에게 특정 사용조건을 요구하고 싶을 경우 공개SW 수행방법에 있어 다음 두 가지 방법을 검토할 수 있습니다. 첫째 모든 결과물을 연구기관이 직접 개발 할 경우입니다. 이 경우 공개SW R&D 결과물에 대한 모든 저작권리가 연구기관에 있기 때문에 연구기관의 조건에 맞는 라이선스를 창작하여 적용할 수도 있고 기존 공개SW 라이선스를 일부 수정하여 적용할 수도 있고 조건에 부합되는 기존 공개SW 라이선스가 있다면 그대로 적용하여 공개할 수도 있습니다. 두 번째로, 외부 공개SW를 활용하여 개발할 경우입니다. 이 경우 공개SW R&D 결과물에 대한 저작권리가 연구기관과 해당 공개SW 저작권자들과 결합되어 있기 때문에 개발 연구기관의 저작권을 가지고 특정 사용조건을 요구하기 어려울 수 있습니다. 51 | 52 |
53 | 54 | + ### Q11 초보자들이 실제 상황에 따라 적용할 수 있도록 라이선스 정책 중 일반적으로 많이 활용되는 것이 무엇인지에 대해 궁금합니다. 55 | 공개SW 활용시에 라이선스를 선택·적용한 사례를 아래와 같이 참고로 제시합니다. 다만, 다양한 오픈소스 라이선스가 존재하고 있으며 각 라이선스는 세부 항목에 있어 차이가 있음에 주의하시기 바라며, 주어진 상황에 적절한 오픈소스 라이선스를 선택하는 것이 중요합니다. 공개소프트웨어 사용에 있어서의 라이선스별로 요구하고 있는 고지 의무, 저작권 및 특허 이슈 등의 보다 자세한 사항은 공개소프트웨어 라이선스 가이드 (https://www.oss.kr 에서 다운로드)를 추가 참고하기 바랍니다. 56 | 57 | 58 | 59 |
60 | 61 | --- 62 | 63 |
64 | 65 | ### :notebook: <사례> 클라우드바리스타에 적용한 오픈소스 라이선스 66 | + **Q : 클라우드바리스타 개발에 있어서 타 공개SW와 라이선스 간의 충돌 회피 등을 고려하고 수요기업 측면에서 사업화를 위해 채택한 라이선스는 어떤 것인가요?** 67 | - A : 라이선스의 선정은 산출된 결과물의 활용 측면, 연계, 활용 가능성이 높은 타 공개SW와의 연계성, 특허권리의 실시 및 개발 기술 분야의 특성 등을 고려하여, 결과물의 공개 시점보다는 공개SW의 설계단계에서 결정하는 것이 바람직합니다.

68 | 라이선스 선정에 고려하였던 주요 사항으로 먼저, 결과물의 활용, 확산 측면에서는 개발된 공개SW를 기술 수요자인 기업이 사업화를 추진하는 경우에 수요기업이 추가 개발한 소스코드에 대한 공개 의무 등의 제약이 적은 Apache-2.0 및 MIT, BSD 등의 라이선스가 생태계 파급효과가 클것으로 판단하여 선정의 후보 라이선스들로 우선 고려하였습니다.

69 | 다음으로, 개발 측면에서는 개발하고자 하는 SW(Cloud-Barista 플랫폼)의 설계 단계에서 개발을 진행하며 주요 공개SW의 라이선스를 분석하여 대부분 Apache-2.0을 채택하고 있음을 확인하였습니다. 또한 개발한 공개SW와 연계 또는 활용하는 공개SW와의 라이선스 간의 충돌 회피를 고려하였습니다. 70 | 71 | > < 주요 공개SW의 라이선스를 분석 >
72 | 73 | 74 | | 연계, 활용가능성이 높은 공개SW | 주요 기능 | 라이선스 정책 | 75 | | :----------------------------: | ---------------------------------------- | ------------- | 76 | | ContainerLinux(구 CoreOS) | 컨테이너 전용 리눅스배포판 | Apache-2.0 | 77 | | Docker | 컨테이너 런타임(OS 수준 가상화) | Apache-2.0 | 78 | | Kubernetes | 클러스터 관리 및 컨테이너 오케스트레이션 | Apache-2.0 | 79 | | Mesos | 클러스터 관리 | Apache-2.0 | 80 | | OpenStack | 클러스터 관리 및 VM오케스트레이션 | Apache-2.0 | 81 | | Crossplane | 멀티 클라우드기반 서비스 오케스트레이션 | Apache-2.0 | 82 | 83 | 끝으로, 특허권 확보 측면에서는 Apache 2.0의 경우는 특허권을 주장할 수 없도록 되어 있어서 확보된 특허권 실시를 통한 권리 주장 측면에서는 MIT 라이선스가 더 적정하였습니다. 하지만, 클라우드바리스타의 특허 확보의 목적은 권리 주장이 아니라, 국내 생태계의 다양한 기술 수요자들이 클라우드바리스타를 사용할 경우에 타 기관, 타 국가로부터 특허 소송 등에 휘말리는 상황을 사전에 예방하는 방어적 특허를 확보하는 것이 중요한 목적이기에 MIT, Apache-2.0 등의 라이선스를 동등한 측면에서 고려하였습니다.

84 | 이에, 상기와 같은 고려사항 및 분석을 통하여, 클라우드바리스타는 결과물의 활용에 있어 수요 기업의 사업화가 용이한 라이선스(Apache-2.0, MIT, BSD 등) 중에서, 개발 단계에서 연계, 활용 되는 공개SW와 라이선스 충돌이 적고, 특허권 확보의 목적성을 만족하는 Apache 2.0을 채택하여 설계 단계부터 공개를 추진하여 커뮤니티를 운영하고 있습니다. 85 | 86 |
87 | 88 | --- 89 | 90 |
91 | 92 | ### :notebook: <사례> Linux Kernel의 라이선스 93 | + **Q : 연구를 위해 고안해낸 새로운 아이디어를 기존 리눅스 커널 위에 새로 구현하여 논문으로 제출했습니다. 이를 바탕으로 특허 권리권을 행사(로얄티)할 의향이 없는데, 이런 경우에도 공개를 해야 하나요?** 94 | - A : GPL-2.0 라이선스는 공개를 의무화하지는 않습니다*. GPL-2.0 라이선스는 공개할 경우에 대한 제약사항을 명시할 뿐이고, GPL-2.0 라이선스로 공개된 코드에 대한 수정을 한 경우에도 GPL-2.0 95 | 라이선스를 강제할 뿐입니다. 소스코드에 대한 비공개는 GPL-2.0 라이선스에서도 허용하는 사항입니다.
* 근거 https://www.oss.kr/oss_guide/show/044d96fd-413d-4ab3-ad72-4776d2b7e002
하지만 학회지나 학회에 논문 출판을 위하여 GPL-2.0 라이선스 코드를 사용하였다면, 많은 경우에 논문 검증을 위하여 소스코드를 공개해야 하는 경우도 있습니다. 이러한 경우에는 GPL-2.0 라이선스로 배포하여야 하고, 요구사항을 준수하여야 합니다.
가장 중요한 사항은 기존 GPL-2.0 라이선스 오픈소스 코드에 대하여 추가/수정을 하여 공개 할 때에는 추가/수정한 부분에 GPL-2.0 라이선스를 적용하여야 하고, 수정 사항에 대한 고지를 포함하여야 합니다. 소스코드를 컴파일하여 바이너리 형태로 제공할 때에는 반드시 컴파일 전 소스코드도 GPL-2.0 라이선스로 적용하여 공개하여야 합니다.
마지막으로 주의해야 할 점은 서로 다른 요구사항을 가진 오픈소스 라이선스가 한 프로그램에 존재해서는 안됩니다. 따라서 Linux Kernel에 GPL-2.0과 충돌하는 라이선스(예: Apache-2.0, BSD-4-Clause 등)를 가지는 다른 소스코드를 합쳐서 배포해서는 안됩니다.
※ Apache-2.0은 특허보복조항, BSD-4-Clause는 광고조항 때문에 GPL-2.0과 호환되지 않음 -------------------------------------------------------------------------------- /part1/03/refList.md: -------------------------------------------------------------------------------- 1 | # 참고문헌 2 | 3 | 1. 정보통신산업진흥원, 공개소프트웨어 라이선스 가이드, 2021. 4 | 2. 한국전자통신연구원, “오픈소스 기술이전 및 공개를 위한 라이선스 모델 연구”, 2020. 5 | 3. 이민석, “공개 소스 소프트웨어 프로젝트의 생명 주기와 품질 유지 방안”, 정보과학회지 26(7), pp.11-21, 2008년 7년. 6 | 4. 박정숙 외, “오픈소스의 지식재산권 분쟁 대응 방안: 오라클과 구글의 Java API 소송 사례 중심”, 주간기술동향, 제2127호, 2021년 12월 15일. 7 | 5. GPL FAQ, https://www.gnu.org/licenses/gpl-faq.en.html. 8 | 6. Apache 2.0 라이선스, https://www.apache.org/licenses/LICENS-2.0. 9 | 7. Anthony I. Wasserman, “Building a Business on Open Source Software”, 2009, https://www.researchgate.net/publication/228850181_Building_a_Business_on_Open_Source_Software 10 | 8. GENIVI, “Pubblic Policy for GENIVI Licensing and Copyright Version 2.0”, 2014, https://fdocuments.in/document/public-policy-for-genivi-licensing-and-copyright-version-2-2216-flora-license.html. 11 | 9. “License Compatibility”, https://en.wikipedia.org/wiki/License_compatibility. 12 | -------------------------------------------------------------------------------- /part1/target-configuration.md: -------------------------------------------------------------------------------- 1 | # 가이드의 대상 및 구성 2 | 3 |
공개SW R&D 수행 가이드 라인의 목적은 공개SW R&D를 계획하고 수행하는 기업 및 연구소, 대학의 연구책임자 및 연구원들을 대상으로 [파트1](https://github.com/iitp-rnd/oss-guideline/tree/main/part1)에서는 공개SW R&D 수행 전 연구계획 단계에서의 정책수립 시 검토해야 하는 사항을 제공하고, [파트2](https://github.com/iitp-rnd/oss-guideline/tree/main/part2)에서는 실제 공개SW R&D를 수행 단계에서의 실무 검토사항을 제공하는 목적을 가진다. 4 | 5 | 공개SW R&D 수행 가이드 라인은 [그림1]과 같이 공개SW R&D 연구계획 수립단계와 공개SW R&D 수행 단계로 구성되어 있으며 본 가이드라인은 이 중 공개SW R&D를 수행하기에 앞서 반드시 검토해야 할 단계별 정책검토 사항을 제시함에 있다. 6 | 7 | 공개SW R&D 연구계획 수립단계에서 검토해야 할 정책 검토사항은 공개SW R&D 사업전략 및 모델 수립, 공개SW R&D 라이선스 정책수립, 공개SW 사용정책 및 절차 수립, 공개SW R&D 기술이전 검토사항이다. 8 | 9 | 공개SW R&D 수행에 관련된 내용은 [파트2]의 내용을 참조할 수 있다. 10 |
11 | >라이선스, 특허, 보안취약점 관리 12 | 13 |

그림 1. 공개SW R&D 수행 가이드라인의 구성


-------------------------------------------------------------------------------- /part1/terms-definition.md: -------------------------------------------------------------------------------- 1 | # 용어정리 2 | 3 | - ### 저작권 (Copyright) 4 | 저작자가 자신이 저작한 저작물을 독점적으로 이용하거나 이를 남에게 허락할 수 있는 인격적· 재산적 권리. 저작물의 복제·번역·상연·상영·전시·방송·대여 등을 내용으로 한다. 5 |

6 | - ### 공개SW (Open Source Software) 7 | 저작권이 있으면서 저작권자가 소스 코드를 공개해 누구나 특별한 제한 없이 8 | 해당 코드를 복제, 사용, 배포, 수정, 활용할 수 있는 소프트웨어를 말한다. 9 | 적용된 라이선스에 따라 자유 소프트웨어 (Free Software), 오픈소스 소프트웨어로 구분되지만 본 가이드에서는 오픈소스 (Open Source Software, 오픈소스 소프트웨어)로 통일하여 지칭한다. 10 |

11 | - ### 라이선스 (License) 12 | 저작권을 가진 저작자가 타인에게 특정한 조건 하에 저작물을 사용할 수 있도록 허용하는 13 | 계약을 말한다. 14 |

15 | - ### 라이선스 양립성 (License Compatibility) 16 | 호환성이라고도 하며 복수의 저작물에 적용된 상이한 라이선스가 17 | 새로운 저작물을 만들기 위하여 해당 저작물들의 소스 코드나 내용물을 결합시키는 것을 불가능하게 만드는 조건을 18 | 포함할 때 발생하는 문제이다. “적어도 두 패키지 중 한 저작자의 직접적인 허가가 없이는 두 패키지의 결합을 합법적 19 | 으로 배포할 수 없는 경우＂두 개의 라이선스는 호환되지 않는다 또는 양립할 수 없다고 말한다. 20 |

21 | - ### 듀얼 라이선스 22 | 다중 라이선스 (영어: multi-licensing)는 컴퓨터 소프트웨어를 둘 이상의 각기 다른 조항과 조건으로 23 | 배포하는 행위이다. 이는 여러 개의 각기 다른 사용권이나 사용권 집합을 의미할 수 있다. 듀얼 라이선스(dual license)는 소프트웨어가 두 개의 각기 다른 사용권에서 배포되는 것을 의미한다. 24 |

25 | - ### 배포 (Distribute) 26 | 오픈소스가 포함된 소프트웨어를 단지 실행 및 사용하지 않고 유상이든 무상이든 제3자에게 전달하는 행위를 말한다. 27 |

28 | - ### 서비스 (Service) 29 | 오픈소스가 포함된 소프트웨어를 단지 실행 및 사용하지 않고 서버 기반으로 네트워크를 이용해 30 | 제3자에게 서비스를 제공하는 행위를 말한다. 31 | 소스코드 (Source Code) : 원시코드라고도 하며, 컴퓨터 프로그램을 사람이 읽을 수 있는 프로그래밍 언어로 기술한 텍스트 파일이다. 32 |

33 | - ### 소스코드 (Source Code) 34 | 원시코드라고도 하며, 컴퓨터 프로그램을 사람이 읽을 수 있는 프로그래밍 언어로 기술한 35 | 텍스트 파일이다. 36 |

37 | - ### 고지 (Notification) 38 | 오픈소스가 포함된 소프트웨어를 배포 및 서비스 시에 사용된 오픈소스 저작권, 라이선스, 39 | 컴포넌트, 출처를 누구나 알 수 있도록 알리는 행위이다. 40 | 결합형태 (Usage Pattern) : 소프트웨어개발 시에 오픈소스와 사용자 코드 간의 결합형태를 말한다. 파일 복제, 파일 41 | 수정, 라이브러리 링크 등이 있다. 42 |

43 | - ### 무상 특허 허용 (Royalty Free Patent) 44 | 오픈소스 라이선스 조항 중 사용자가 해당 오픈소스가 포함된 소프트웨어를 45 | 배포 및 서비스 시에 사용자의 특허권을 무상으로 제3자에게 허용해야 한다는 규정이다. 46 | 라이선스 충돌(License Conflict) : 라이선스 위반이라고도 하며 오픈소스가 포함된 소프트웨어를 배포 및 서비스 47 | 시에 해당 소프트웨어의 배포 및 서비스 라이선스 의무사항과 포함된 오픈소스 라이선스 의무사항 혹은 사용된 오픈소스 48 | 간의 라이선스 의무사항이 상호 준수에 있어 호환되지 않는 상태를 말한다. 49 |

50 | - ### 공급망 관리 (Supply Chain Management) 51 | 최종 사용자에게 배포 및 서비스되는 소프트웨어 개발에 참여하는 52 | 모든 소프트웨어개발 기업(발주, 외주, 협력 등)이 준수해야 하는 정책 및 절차 등을 말한다. 53 |

54 | - ### 리버스 엔지니어링 (Reverse Engineering) 55 | 역설계 또는 역공학 이라고도 하며 장치 또는 시스템의 기술적인 56 | 원리를 그 구조분석을 통해 발견하는 과정이다. 이것은 종종 대상(기계 장치, 전자 부품, 소프트웨어 프로그램 등)을 57 | 조각내서 분석하는 것을 포함한다. 그리고 유지 보수를 위해, 또는 같은 기능을 하는 새 장치를 원본의 일부를 이용하지 58 | 않고 만들기 위해 대상의 세부적인 작동을 분석하는 것을 포함한다. 59 |

60 | - ### 파생저작물 (Derivative Work) 61 | 오픈소스를 수정 및 결합하여 만들어진 2차적 저작물을 말한다. 62 | -------------------------------------------------------------------------------- /part2/01/01.md: -------------------------------------------------------------------------------- 1 | # 1장 공개SW R&D의 개요 2 | 3 | # 1. 공개SW R&D 과제란? 4 | 5 | 공개SW는 운영체제, 데이터베이스, 웹서버 등 SW기반 기술에서 인공지능, 빅데이터, 클라우드, 블록체인 등 신기술 분야까지 두루 사용되고 있으며, 글로벌 기술 동향에 의하면 90% 이상의 SW에서 공개SW가 활용될 정도로 기업의 신시장 창출, 사업 경쟁력 강화, 성장 동력 확보에 중요한 수단이 되었다.
6 |
7 | 지난 2020년 5월에 통과된 소프트웨어진흥법의 제 25조 2항은 소프트웨어의 소스 코드를 공개하여 외부의 기여자가 참여하도록 하는 공개SW 개발방식의 활용을 채택하도록 개정되었으며, 이에 따라서 향후 국가연구개발사업에서 공개SW 연구개발 방식을 통한 개방형 혁신 연구개발과제 수행에 필요한 역량이 필요하나 현재 대부분의 과제 8 | 수행자는 공개SW 연구개발과제 수행의 어려움을 호소하고 있다. 9 | 10 | |
소프트웨어진흥법 제 25조
| 11 | | ---| 12 | |제25조(소프트웨어 연구 및 기술개발 촉진 등) ① 정부는 소프트웨어 기술경쟁력 강화를 위하여 소프트웨어 분야의 기초연구를 진흥하여야 한다.

② 정부는 소프트웨어 분야의 국가연구개발사업을 하는 경우 다음 각 호의 방법으로 소프트웨어 연구개발이 활성화되도록 노력하여야 한다.

1. 소프트웨어의 원시코드(source code)를 공개하여 소프트웨어의 개발ㆍ유지 및 관리 과정에 해당 소프트웨어 개발자 외의 자도 참여하도록 하는 개발 방식의 활용

2. 국가연구개발사업의 결과물을 공개소프트웨어(저작권자가 원시코드를 공개하여 활용ㆍ복제ㆍ수정 및 재배포가 자유로운 소프트웨어를 말한다)로 배포

③ 정부는 소프트웨어와 관련된 기술의 개발을 촉진하기 위하여 기술개발사업을 하는 소프트웨어사업자에게 필요한 자금의 전부 또는 일부를 출연하거나 보조할 수 있다.|
13 | 14 | 본 가이드라인은 공개SW 연구개발과제 수행자가 공개SW 개발방식의 효율성 제고를 위해서 어떠한 활동이 필요한지 실무적 지침을 제시하여 국가 공개SW 연구개발과제 행자의 과제 수행을 지원하여 결과물의 효율성과 효과성을 확보할 수 있기를 기대한다. -------------------------------------------------------------------------------- /part2/01/02.md: -------------------------------------------------------------------------------- 1 | # 2. 일반SW R&D와 공개SW R&D의 차이점 2 | 3 | 공개SW는 저작권이 있으나 저작권자가 소스 코드를 공개하여 누구나 자유롭게 설치, 복제, 수정, 재배포 등을 할 수 있는 소프트웨어를 의미한다. 따라서, 일반SW R&D와 공개SW R&D의 가장 큰 차이점은 공개SW R&D의 경우 R&D 구현 결과물의 전체 혹은 일부를 누구나 사용할 수 있도록 공개하는 데 있다.
4 |
5 | 공개SW R&D에 있어 중요한 사항은 프로토타입 공개 시점을 기준으로 개발을 주도하던 조직이 주관기관 및 참여기관으로 구성된 개발조직에서 커뮤니티 기반의 개발조직으로 확대된다는 점이며 연구개발 결과물(소스 코드, 문서 등)에 대한 릴리즈에 있어 전체 혹은 부분적인 결과물에 공개SW 라이선스를 적용하여 공개되며 공개 이후 커뮤니티에 의한 지속적인 유지관리와 지원이 이루어져야 한다는 점이다.
6 |
7 | 일반SW R&D와 공개SW R&D의 차이점은 개발조직, 분석설계, 구현/리뷰/내부시험, 릴리즈, 평가, 지원절차에 따라 [표 1]과 같이 정리할 수 있다. 8 | 9 | > 표 1. 일반SW R&D와 공개SW R&D의 차이점
10 | 11 | | 구 분 | 일반SW R&D | 공개SW R&D | 12 | | :---: | ----------| --------- | 13 | | 기획 | • 정책, 민간, 산업 수요에 따라 전문가들에 의한 공청회를 통해 기획 | • 정책, 민간, 산업 수요에 따라 전문가들에 의한 공청회를 통해 기획
• R&D 과정에서 산출된 SW결과물에 대해 저작권자가 해당 소스코드를 일반에 공개하여 이를 사용,복제, 수정, 배포 할 수 있는 권한을 부여하는 공개SW 방식을 적용 | 14 | | 개발
조직 | • 주관기관 및 참여기관 개발조직으로 구성 |• 주관기관 및 참여기관 개발조직(코어 개발자), 프로토타입 공개 이후에는 자생적 코어 개발자 그룹과 커뮤니티로 조직 구성 | 15 | |분석
설계 | • 과제의 규모에 따라 다르며, 주관기관의 개발 프로세스에 따른 분석 및 설계 과정 | • 과제의 규모에 따라 다르며, 주관기관의 개발 프로세스에 따른 분석 및 설계 과정
• 프로토타입 공개 이후에는 공식적인 분석 설계 과정이 없으며, 코어 개발자 사이의 커뮤니케이션, 초기 소스의 스냅샷 릴리즈와 커뮤니티의 리뷰를 통한 간접적인 분석 설계 | 16 | | 구현
리뷰
시험 |• 선정된 개발팀에 의한 독자적인 개발 혹은 부족한 부분에 대한 위탁 개발. 주관기관의 개발 프로세스에서 정한 방식에 따라 조직 내부에서의 리뷰 및 시험, 과제의 요구에 따라 시범 사업에 의한 실환경 시험 | • 코어 개발자 주도의 개발 및 내부 리뷰, 시험이 진행되며, 분석, 설계 단계와 마찬가지로 프로토타입 공개 이후의 모든 구현 결과 또한 공개되고 커뮤니티의 리뷰, 시험 | 17 | | 릴리즈 | • 과제 성격에 따라 매우 다양하나, 거의 소스를 공개하지 않음 | • 일부 혹은 모든 소스코드와 문서가 해당 프로젝트가 채택하고 있는 라이선스에 따라 공개 | 18 | | 평가 | • 독립적인 평가위원회에 의해 기획 단계와 주관 기관 선정 당시에 정의된 과제 목표와 성과를 비교하는 방식으로 평가 |• 오픈소스 라이선스를 포함한 특허 적용 전략, 공개 계획, 커뮤니티 운영 등 SW 결과물의 공개 계획 및확산 전략 등에 대한 평가 지표를 추가하여 평가 | 19 | | 커뮤
니티
활성화
| • R&D과제 수행자를 중심으로 운영 가능 | • R&D과제 수행자뿐만 아니라 외부 개발자, 사용자 들이 포함된 공개SW 커뮤니티를 구성, 연구개발 산출물을 외부에 공개하고, 외부 참여자들이 개발에 참여하도록 하는 커뮤니티를 통해 개발결과물의 품질을 향상시킴 | -------------------------------------------------------------------------------- /part2/01/03.md: -------------------------------------------------------------------------------- 1 | # 3. 공개SW R&D 과제의 성장 단계 2 | 3 | 공개SW 연구개발과제는 결과물의 기술이전을 통해 사업화로 이어지던 기존의 연구개발 과제와 다르게 연구개발 결과물 공개단계와 연구개발 결과물 활용 확산을 위한 관리 및 지원 체계구축 단계로 발전하게 되는 특징을 가지고 있다. 4 | 5 |

그림 2. 공개SW 연구개발과제 성장 단계


6 | 7 | 연구개발 결과물 공개단계는 공개SW 개발방식을 채택하여 연구개발을 수행하고 외부 기여자의 활용을 돕는 환경을 조성하여 개방형 혁신 연구개발 방식의 효율성을 극대화하는 과정이다. 이 과정에서는 공개SW 연구개발 결과물의 공개에 필요한 소스 코드 저장소 관리, 소프트웨어 형상 관리, 소프트웨어 배포 관리, 소프트웨어 품질관리 등 다양한 활동을 수행하게 되며 공개SW 라이선스 및 보안 취약점의 검토 및 보완이 주로 수행된다.
8 |
9 | 연구개발 결과물 활용 확산을 위한 관리 및 지원 체계구축 단계는 공개한 연구개발 결과물이 커뮤니티를 기반으로 산업 전반에 걸쳐 폭넓게 활용될 수 있도록 지원 체계를 구축하여 관리하는 과정이다. 이 과정에서는 과제의 결과물을 공개한 후 커뮤니티를 중심으로 공개한 프로젝트가 활용될 수 있도록 커뮤니티 거버넌스 구축, 웹사이트 및 포럼 제공, 파트너 발굴 및 온·오프라인 프로젝트 홍보 등이 주로 수행된다.
10 |
11 | 공개SW R&D 과제는 연구개발 결과물이 잘 활용될 수 있는 환경을 조성하고 지속적인 지원 체계를 마련하는 것이 이상적인 결과지만 과제 수행 기간이 1년 이내의 과제의 경우 커뮤니티를 기반으로 결과물이 활용될 수 있는 체계를 구축하는 것은 대부분 어려운 상황이다.
12 |
13 | 따라서 공개SW 연구개발과제 수행자는 무조건 결과물 활용 확산을 위한 관리 및 지원 체계를 구축하는 것으로 목표를 설정하는 것보다 과제 수행의 기간이나 환경에 적합한 수준의 목표를 설정하는 것이 중요하다.
14 |
15 | 연구개발 결과물 활용 확산을 위한 관리 및 지원 체계구축을 포함하는 중장기 과제에서도 과제의 사용 가능한 결과물이 없는 상태인 과제의 시작 시점부터 커뮤니티를 구축하고 외부 참여자를 중심으로 개발하는 방식을 계획하는 것은 피하는 것이 좋다.
16 |
17 | 수행자는 과제의 시작 시점부터 커뮤니티를 만들고 외부 기여자가 등장하는 것을 기대하지만, 커뮤니티가 형성되기 위해서는 먼저 사용자가 있어야 하며, 이 사용자 커뮤니티 그룹에서 소프트웨어 개발에 소스 코드 개선이 가능한 개발자가 생기면서 이 참여자들이 외부 기여자가 되기 때문에, 본 가이드에서 제시하는 첫 번째 단계의 연구개발 결과물을 공개하는 목표를 수행하여 좋은 소프트웨어를 공개SW 프로젝트로 공개하는 것을 우선으로 수행하고, 이 공개한 프로젝트를 기반으로 커뮤니티 환경 조성하고 유지관리하는 단계로 성장하는 것이 좋은 공개SW 프로젝트로 발전하는 방식이다. -------------------------------------------------------------------------------- /part2/01/04.md: -------------------------------------------------------------------------------- 1 | # 4. 공개SW R&D 과제 점검표 2 | 3 | 공개SW 연구개발 과제의 수행자는 다음과 같이 연구개발 결과물 공개단계와 결과물 활용 확산을 위한 관리 및 지원 체계구축 단계에서 필요한 항목을 사전에 점검하여 공개SW 연구개발 과제에 적합한 수행 계획이 준비되었는지 검토하고 부족한 부분에 대하여 보완해야 한다. 4 | 5 | > 표 2. 공개SW 연구개발과제 수행 점검 항목
6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 |
단계검토 항목
결과물 공개과제 관리 정책을 확인, 이해하였는가?
참여연구원 역할과 책임은 정의되었는가?
공개SW에 적합한 소프트웨어 개발방법을 사용하는가?
적절한 소스 코드 형상 관리 방안은 준비되었는가?
이슈 및 버그 관리 방안이 존재하는가?
지속적 릴리즈 관리 방안이 존재하는가?
라이선스 고지문은 포함되었는가?
공개SW 보안 취약점 점검 방안은 존재하는가?
참여형 문서 협업 환경이 준비되었는가?
프로젝트의 로드맵은 공개되었는가?
외부 기여자를 위한 가이드라인은 존재하는가?
기여자 라이선스 동의문은 포함되었는가?
프로그램 사용 가이드는 제공되는가?
결과물 활용 확산을 위한
관리 및 지원 체계 구축		웹사이트 및 포럼을 통한 커뮤니티 채널은 존재하는가?
커뮤니티에 적합한 거버넌스 정책이 존재하는가?
협력기업 관리 방안은 준비되었는가?
지식 재산권 관리를 위한 대응책은 존재하는가?
커뮤니티 현황을 분석할 수 있는 도구는 존재하는가?
프로젝트를 위한 홍보 도구나 방안이 존재하는가?
커뮤니티 지원을 담당할 담당자는 배정되었는가?
43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | -------------------------------------------------------------------------------- /part2/01/05.md: -------------------------------------------------------------------------------- 1 | # 5. 공개SW R&D의 기대효과 2 | 3 | 공개SW R&D는 수행하는 동안 내부 개발 인력만으로 수행될 수 도 있지만, 외부의 참여자가 참여하여 협력 개발이 진행될 때 개방형 혁신 R&D의 경험을 습득하게 되고 세계 시장에서 경쟁할 수 있는 R&D 역량이 강화될 수 있다. 또한, R&D의 결과물을 공개SW 프로젝트로 공개하여 누구나 사용할 수 있게 함으로써 모든 SW를 자체 개발 여력이 없는 중소기업들도 핵심기술을 기반으로 다양한 사업모델을 발굴할 수 있고 개인 개발자들도 스타트업 기업을 더욱 쉽게 창업할 수 있는 기반을 조성할 수 있다. 그 밖에도 공개SW R&D는 여러 관점에서 다음과 같이다양한 기대효과를 제공한다. 4 | 5 | * **경제적 이점**
6 | 공개SW R&D를 통해 신규 시장 개척 및 신제품 개발을 위한 R&D 비용, 인프라 SW 비용 등의 투자비를 절감할수 있게 함으로써 원가 우위를 기반으로 경쟁 시장진입에 대한 진입장벽을 완화할 수 있다.
7 |
8 | * **제품, 서비스 및 이미지 차별화**
9 | 커뮤니티를 기반으로 성장하는 사업전략을 통해 해당 기업 제품 및 서비스를 차별화하여 시장의 독점 기업 경쟁자에 대해 경쟁력을 확보할 수 있고, 공개SW 기반의 사업을 통한 기술 주도적 기업, 혁신적 기업, 개방적인 사회적 기업 등의 긍정적 이미지를 형성할 수 있다.
10 |
11 | * **제품 품질 향상**
12 | 개발된 제품의 품질을 공개SW 커뮤니티를 통해 검증하게 되며, 발견된 버그에 대한 코드의 수정도 기업 내부의 개발자와 외부 공개SW 프로젝트 커뮤니티의 자원을 통해 이루어지게 되므로 이 과정에서 최종 제품의 품질이 향상될 수 있다.[1](#footnote1) 또한, 국내 산업계에 공개된 기술을 전파, 활용하게 함으로써 국내 산업 기술경쟁력 제고에 이바지할 수 있다.
13 |
14 | * **기업의 SW 기술 수준 향상**
15 | 공개SW 활동이 시작되게 되면, 내부 개발자들이 자연스럽게 외부 개발자들과 협력하게 되고 더욱 역량 있는 개발자들과 교류하게 됨으로서 개발역량 향상이 이루어질 수 있다. 막대한 교육훈련비와 시간 및 동기부여의 수단이 투입되지 않더라도 기업 및 조직의 입장에서는 자연스레 역량 있는 SW 개발자들을 육성할 수 있는 계기가 된다.
16 |
17 | * **창의성 증대 및 유능한 개발자 확보**
18 | 기업은 내부 제품 및 서비스를 공개SW로 전환하거나 공개SW로 공개함으로써 폐쇄적인 기업 문화가 아닌 개방된 창의적인 기업문화를 조성하게 되고 창의적인 역량 확보와 명성을 중요하게 생각하는 최근의 유능한 SW 개발자들에게 일하고 싶은 기업으로서의 동기부여를 제공할 수 있다. 또한, 특정 분야의 공개SW 전문기업으로서의 명성을 통해 유능한 글로벌 커미터들을 확보할 수 있다. 19 |
20 | 21 | --- 22 | 1) 공개 소스 소프트웨어 프로젝트의 생명 주기와 품질 유지 방안 - 정보과학회지 제26권 제712호 (2008.7) 이민석 [return](#part2_1_01)
-------------------------------------------------------------------------------- /part2/02/01.md: -------------------------------------------------------------------------------- 1 | # 2장 공개SW R&D 수행 가이드 2 | 3 | # 1. 공개SW R&D 과제 수행 준비 4 | 5 | ## 가. 관리 정책 수립 6 | 공개SW 연구개발 과제의 수행자는 과제를 공개SW 방식으로 진행하는데 필요한 관리 정책을 수립하고 참여연구원 전원과 공유해야 수행과정에서 이슈가 있는 경우 참여연구원이 명확하게 대응할 수 있다.
7 |
8 | 과제 관리를 위한 정책이 조직 내부의 전사 정책으로 있는 경우는 전사 공개SW 관리 정책을 준수하면 되지만, 국내 대부분의 공개SW 연구개발 과제 수행자의 경우 공개SW 관리 정책이 제대로 갖춰져 있지 않은 상황이므로 이 경우에는 다음과 같은 항목을 위주로 과제 수행에 적합한 정책을 수립하고 참여연구원 모두 수시로 확인할 수 있도록 공유되어야 한다.
9 | 10 | > 표 3. 공개SW 연구개발과제 수행을 위한 관리 정책의 주요 내용
11 | 12 | | 정책 | 예시 설명 | 13 | | :---: | -------- | 14 | |공개SW 사용| 소프트웨어에서의 공개SW 사용 범위 | 15 | | 소스 코드 공개 | 소스 코드 공개 범위, 자체 개발 커널 모듈, 자체 개발 펌웨어, 소스 코드 공개 방법 등 | 16 | |라이선스 검증 | 검증 방법, 라이선스 별 조치 대상, 외부 공개SW 라이선스 충돌의 해결 | 17 | |커미터 역할 | 프로젝트 구성원의 공개SW 프로젝트의 커미터로 참여할 수행 범위와 책임을 규정 | 18 | | 외부 커뮤니티 활동 | 공개SW 관련 외부 커뮤니티 활동을 지원하기 위한 사용 절차 및 주체 | 19 | |커뮤니티 생성 및 운영 | 공개SW를 위한 커뮤니티 수립 방안 및 이를 관리하기 위한 정책 | 20 | | 공개SW 생명 주기
또는 프로세스 | 공개SW 도입에서 운영, 유지보수에서 폐기에 이르는 전체 생명 주기를 관리하기 위한 절차 | 21 | | 전사 R & R | 공개SW 생명 주기에서의 각 조직의 역할 및 책임 정립 | 22 | | 공개SW 평가 | 유사 항목에서의 우수 공개SW를 선택하기 위한 평가 모델 | 23 | | 공개SW 교육 | 공개SW를 도입, 사용하기 위한 교육 | 24 | | 주요 라이선스별 적용 방안 | 공개SW 라이선스별로 안전하게 사용 및 적용하기 위한 정책 | 25 | | 조직별 공개SW 활용 | 방안 조직의 특성에 따라 공개SW를 도입, 개발 또는 유지보수 하기 위한 정책 | 26 | | 공급업체의 공개SW 라이선스
의무 수행 |공개SW를 공급받을 시 공급업체로부터 받아야 하는 라이선스 준수 정책| 27 | 28 |
29 | 30 | ### :notebook: 클라우드바리스타 커뮤니티 사례 31 | 32 | - 클라우드바리스타 커뮤니티(https://github.com/cloud-barista)에서는 공개SW 수행 관리 정책중, 커뮤니티에서 수용가능한 항목들을 선별하고 수행 R&D에 최적화하여 적용 33 | 34 | |정책 예시 | 설명 | 35 | |:----:|------| 36 | |공개SW 사용 |- R&D의 핵심이 되는 주요 소스코드는 설계를 통한 신규 개발
- 타 공개SW의 활용시는 동일 기능의 타 공개SW로 대체 가능하도록 프레임워크 구조로 수용
- 활용 공개SW가 개발소스코드의 라이센스인 Apache2와의 충돌여부 확인 후 적용| 37 | |소스 코드 공개 |- 과제에 포함된 모든 소스코드는 공개를 기본 원칙
- 소스코드는 깃헙 기반의 개발, 저장, 공유
- R&D를 추진하며 추가 개발한 유틸리티 및 사업화 지원 SW 등은 일부 비공개로 유지
- 소스코드는 6개월마다(연2회) 깃헙을 통하여 정식 릴리스를 수행하며, 커뮤니티 컨퍼런스를 통하여 신규 기술 및 노하우 공유 | 38 | | 라이선스 검증 | - R&D를 수행하고 있는 기관에서 지원하는 라이센스 검증도구를 활용하여, 라이센스 충돌 등을 주기적으로 검증
- 충돌되는 공개SW가 있는 경우, 유사 기능을 제공하는 타 공개SW를 분석, 적용 커뮤니티 생성 및 운영
- R&D의 시작 시점에 깃헙을 통한 프로젝트 생성
- 설계단계부터 깃헙에 내용을 공유하고 외부와 소통을 추진
- SW 모듈들을 독립적으로 구동가능한 주요 형상으로 구분하여 각각의 저장소 (Repository)를 생성
- 주요 SW모듈의 개발자는 해당 저장소의 메인테이너로 개발 및 외부 소통 활동을 수행 39 | 40 |
41 | 42 | ## 나. 수행 조직 구성 43 | 공개SW 연구개발과제의 수행에 필요한 조직은 다음과 같이 각 부문의 전문성을 제공할 수 있는 전담 조직으로 구성되어야 한다. 마이크로소프트, Salesforce 같은 기업은 전사적으로 공개SW 전략을 일관되게 구현할 수 있도록 잘 정의된 정책 및 프로세스를 개발하는 조직으로 OSPO(Open Source Program Office) 조직을 구성하고 있으며, 국내 대표적인 연구기관인 한국전자통신연구원(ETRI), LG전자, 삼성전자 등의 기업들도 전사적으로 공개 SW 전략을 명확하게 전달하고 전략 실행을 감독하여 효과적인 공개SW 사용 촉진을 목적으로 하는 전담 조직을 구성하고 있다.
44 |
45 | 만약 대학 등 조직의 규모에 따라 전담 조직의 구성이 어려운 경우에는 해당 업무를 겸임할 수 있는 자원으로 구성하고, 공개한 소스 코드의 라이선스 의무사항 위반의 경우 향후 사업화에 큰 위험을 초래할 수 있으므로 만약 별도의 법무 조직이 없는 경우는 외부 컨설팅 또는 오픈업 지원센터(https://www.oss.kr/)를 통해 라이선스 검증을 지원받을 수 있도록 준비하는 것이 좋다. 46 |
47 | 48 | > 표 4. 공개SW 연구개발과제 수행 조직의 예
49 | 50 | |조직| 설명| 51 | |:----:|------| 52 | |공개SW 검토위원회 | 공개소프트웨어 정책 수행을 위한 핵심 기구 | 53 | |법무| 라이선스와 계약 준수를 포함하여 법적 요구사항들을 준수해야 하는 조직의 제품과 솔루션에 대한 궁극적인 책임 | 54 | |개발| 개발부서는 실제로 공개소프트웨어를 사용하고 공개소프트웨어와 결합한 제품 및 솔루션을 창출하는 조직| 55 | |운영| 조직의 개발시스템 운영 환경을 담당 | 56 | |마케팅| 공개소프트웨어 컴포넌트들과 결합한 제품 및 솔루션을 위한 사업계획뿐만 아니라 해당 공개소프트웨어 라이선스 의무사항을 준수하기 위한 모든 필요 속성들을 확인하는 기구 | 57 | |재무/감사| 조직의 특정 상태에 따라 준법성이 적절히 준수되고 있음을 증명해야 하는 책임 | 58 | 59 |
60 | 61 | ## 다. 개발환경 구축 62 | 공개SW 연구개발과제는 수행 컨소시엄 간의 협업뿐만 아니라 외부 기여자들의 과제 참여가 가능하도록 다음과 같은 개발환경을 구축해야 한다. 63 | 64 | - 공개SW 연구개발과제 워크플로우(브랜치 전략) 65 | - 소프트웨어 소스 코드 저장소(Github, Gitlab, Bitbucket 등) 66 | - 소프트웨어 형상 관리 도구(Mantis, Jira, Github 등) 67 | - 소프트웨어 테스트 자동화 도구(Catch, Junit, unittest 등) 68 | - 소프트웨어 보안 취약점 점검 도구(Veracode Greenlight, Synopsys Code Sight 등) 69 | - 소프트웨어 릴리즈 관리 도구(Travis, Hudson, Bamboo 등) 70 | - 공개SW 라이선스 검증 도구(올리브, FOSSology, CodeEye, Clarity 등) 71 | - 공개SW 라이선스 컴플라이언스 도구(Fosslight, Fossa, SW360, Black Duck, SPDX 등) [2](#footnote2) 72 | - 공개SW 연구개발과제 이슈 및 버그 관리 도구(Github, Gitlab, Jira 등) 73 | - 참여형 문서 협업 도구(Wiki, Confluence 등) 74 | 75 |

그림 3. 공개SW 연구개발과제 개발환경


76 | 77 | 78 | ## 라. 참여연구원 교육 79 | 공개SW 연구개발과제의 수행에 참여하는 연구원들은 기본적인 공개SW의 이해와 공개SW 개발방식의 전문성이 요구된다. 이를 위해서는 조직 내 별도의 내부 교육프로그램을 통해 지속적인 공개SW 개발역량 강화가 필요하며, 만약 별도의 내부 교육프로그램이 없는 경우에는 공개SW 소프트웨어 통합지원센터에서 제공하는 다음과 같은 다양한 교육과정을 통해 필요한 역량을 강화할 수 있다.(교육과정 등 세부사항은 아래 URL 참조) 80 | 81 | - URL : https://www.oss.kr/pro_ability 82 | - 공개SW 소개 및 협업툴 사용, 분야별 공개SW 트렌드 및 프로젝트 소개 등 교육 제공 83 | 84 | > 표 5. 공개SW 특강 예시
85 | 86 | |분 야 | 과정명 | 87 | |:----:|-----| 88 | |개론| · 공개SW의 이해 | 89 | |협업| · Github를 활용한 개인 포트폴리오 제작하기
· 공개SW 기여를 위한 개발환경 이해 | 90 | |인공지능| · 인공지능 딥러닝 개론
· 인공지능 딥러닝 | 91 | |빅데이터|· 데이터 로그 저장 및 수집
· Spark로 시작하는 머신러닝 입문 | 92 | |클라우드| · 도커 컨테이너 기술
· 공개SW와 클라우드| 93 | 94 |
95 | 96 | - 공개SW 프로젝트 기본구조 · 활용 등 프로젝트에 대한 이해도 강화 및 개발방법에 대한 실습교육 제공 97 | 98 | > 표 6. 공개SW 전문교육 예시
99 | 100 | |분야 | 프로젝트명 | 과정명 | 101 | |:----:|:-----:|-------| 102 | |협업 | GitHub | · 글로벌 공개SW 프로젝트 개발 참여 | 103 | |AI | TensorFlow | · 데이터 분석과 이미지 처리에 딥러닝 활용| 104 | | AI-Bigdata | Numpy/Pandas | · 파이썬을 활용한 공공데이터 분석(기본) | 105 | 106 |
107 | 108 | - URL : https://www.oss.kr/notice/show/ac01c651-2c77-442e-8873-83dd2d82970a 109 | - 공개SW 매니지먼트 아카데미 : 공개SW 활용과 관리를 위한 전문가 양성과정을 제공 110 | - 접수처 : Open UP(license@oss.kr) 111 | > 표 7. 공개SW 활용과 관리를 위한 전문가 양성과정 예시 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 |
구분개요운영
공개소프트웨어
매니지먼트 전문과정		공개소프트웨어 매니저 전문가 양성을 위한 선발제
집중 교육과정 운영		선발제
10주 교육
공개소프트웨어
일반 교육과정		신청자(기업/기관/개인)의 수준에 따라 맞춤형 단기
교육과정 운영		신청시
수시 교육
공개소프트웨어
기타 교육 지원		공공 SW사업 수·발주자 및 공개SW 개발자대회
참가자 대상 라이선스 교육 지원		지정 일정
11회 교육
144 | 145 | 146 | --- 147 | 2) https://github.com/NIPA-OpenUP/oss-governance-guide/blob/main/oss-governance-guide.md [return](#part2_2_02)
-------------------------------------------------------------------------------- /part2/02/02.md: -------------------------------------------------------------------------------- 1 | # 2. 공개SW R&D 과제 분석 2 | 3 | ## 가. 요구분석 및 조사 4 | 공개SW 연구개발과제의 결과물이 모든 소프트웨어를 자체 개발하는 경우에는 소프트웨어 개발 프로세스의 첫번째 단계인 요구분석은 일반적인 소프트웨어 개발과정(요구사항 도출, 요구사항 분석, 요구사항 명세)과 다르지 않다.
5 |
6 | 하지만 많은 연구개발과제는 외부의 라이브러리 또는 컴포넌트를 활용하는 경우를 포함하고 있으며, 만약 외부의 공개SW를 포함해서 개발하거나 외부의 공개SW를 개작하여 공개하는 유형의 과제의 경우라면 공개SW 조사, 분석, 평가, 계약의 활동이 추가로 필요하다. 7 | 8 |

그림 4. 공개SW 사용범위 분석의 예


9 | 10 | 공개SW 연구개발과제의 수행자는 과제에 적합한 공개SW의 조사를 위해서 다음과 같은 웹사이트를 이용하여 원하는 공개SW를 조사할 수 있다. 아래의 웹사이트들은 기술분류, 트렌드, 개발자 수, 인기도 등 다양한 지표를 기반으로 공개SW 프로젝트에 대한 안내를 제공하고 있으므로 수행자는 과제에 활용할 수 있는 외부 공개SW를 쉽게 조사할 수 있다.
11 | 12 | - https://sourceforge.net/ 13 | - https://www.openhub.net/ 14 | - https://github.com/ 15 | - https://opensourcesoftwaredirectory.com/ 16 | 17 |
18 | 19 | 그 중 오픈허브 서비스(https://www.openhub.net/)의 경우 다음과 같이 다수의 프로젝트를 비교할 수 있는 기능을 제공하므로 자체 평가방법을 준비하지 않은 경우에도 유용하게 활용할 수 있다. 20 | 21 |

그림 5. TensorFlow 와 Pytorch 공개SW 프로젝트 비교(Openhub.net)


22 | 23 | ## 나. 공개SW 분석 및 평가 24 | 25 | 이처럼 외부의 공개SW를 포함해서 개발하거나 외부의 공개SW를 개작하여 공개하는 유형의 경우라면 수행자는 조사한 다수의 공개SW 프로젝트의 속성과 커뮤니티 정보를 취합하여 해당 프로젝트의 성숙도와 적용성을 평가하는 과정을 통해 과제에 적합한 공개SW 프로젝트를 선정하고 활용할 수 있다.
26 |
27 | 공개SW 프로젝트를 선정하는 경우에는 단순히 소프트웨어의 기능이나 성능 같은 항목으로 평가하기보다 일반적인 소프트웨어의 품질속성과 공개SW의 특성을 반영한 품질속성과 함께 과제의 이해관계자 요구사항을 반영하여 복합적으로 고려하여 평가하는 것이 필요하다. 28 | 29 |

그림 6. 외부 공개SW 활용을 위한 프로젝트 평가 예


30 | 31 | 공개SW 성숙도 및 적용성 평가 표준(한국정보통신기술협회)은 공개SW의 평가를 위해서 필요한 속성과 척도를 정의하고 평가항목을 정량화시켜 기능성, 이식성, 신뢰성, 사용성, 유지 보수성, 커뮤니티 영속성 등 공개SW 의 수준과 가치를 평가하는 방법을 제공하므로 공개SW 연구개발과제의 수행자가 외부의 공개SW 성숙도를 평가하거나 자신이 공개할 과제에 대한 객관적 평가의 지표로 참고할 수 있다. 32 | 33 |

그림 7. 공개SW 성숙도 및 적용성 평가 표준(한국정보통신기술협회)


34 | 35 | 공개SW 성숙도 및 적용성 평가 지침(TTA.KO-11.0133)은 ISO 9126의 일반적인 소프트웨어 품질요소와 공개 SW 특성을 반영한 품질요소가 추가된 구성으로 국내에서 널리 사용되고 있는 전자정부 표준프레임워크의 공개 SW 프로젝트 선정에도 사용된 지침이므로 신뢰할 수 있는 자료이다.
36 |
37 | 조직에서 공개SW의 활용이 상시 존재하는 경우에는 공개SW의 라이선스 준수를 위한 효과적인 프로세스 관리 표준으로 ISO/IEC 5230:2020 국제표준(OpenChain 2.1)의 활용도 고려할 수 있다. '오픈체인 프로젝트'는 2016 년 미국의 비영리단체인 리눅스 재단(Linux Foundation)의 주도로 시작됐으며, 효과적이고 일관성 있는 공개SW 컴플라이언스 체계를 갖추고 있는 기업을 대상으로 인증을 부여하는 방식으로 운영되는데 최근 국내의 삼성전자, LG전자, 엔씨 등 기업들도 소프트웨어 공급망에 유입되는 전사적 공개SW 관리를 위해 오픈체인을 도입하고 있으며 아래 웹사이트를 방문하여 자세한 내용을 확인할 수 있다. 38 | - URL : https://openchain-project.github.io/OpenChain-KWG/guide/nipa_openchain/i-openchainproject/ 39 | -------------------------------------------------------------------------------- /part2/02/03.md: -------------------------------------------------------------------------------- 1 | # 3. 공개SW R&D 과제 설계 2 | 3 | ## 가. 공개SW 연구개발과제의 소프트웨어 설계 방식 4 | 5 | 외부 기여자가 참여하여 소프트웨어의 개발이 이루어지는 공개SW 연구개발과제의 설계는 개발 영역을 나누어 개발자가 의사소통이 쉽게 이루어질 수 있도록, 소프트웨어 소스 코드의 결합도가 낮게 모듈화하는 설계를 고려해야한다. 이런 설계는 각 기능 모듈이 다른 모듈에 영향을 주지 않고 개발을 할 수 있게 하며, 실험적인 코드들이 안전하게 수용될 수 있는 특징이 있다.
6 |
7 | 직접 개발한 소프트웨어 유형뿐만 아니라, 외부의 공개SW를 활용하거나 개작하는 경우의 과제 유형에서도 공개 SW 활용의 효용성을 위해서 직접 관리하는 핵심영역과 공개SW 활용영역이 쉽게 통합될 수 있도록 정의된 API를 통해서 통신하는 소규모의 독립적인 서비스로 구성되는 마이크로서비스 아키텍처(MSA)로 구성하는 것이 좋다. 8 | 9 |

그림 8. 모노리틱 아키텍처와 마이크로서비스 아키텍처의 비교


10 | 11 | 마이크로서비스는 분산형 개발을 통해 같은 애플리케이션 개발에 더 많은 개발자가 동시 참여할 수 있으므로 개발에 드는 시간을 단축할 수 있으며 여러 가지 프로그램 언어로 개발되고 서로 API를 사용하기 때문에 개발자들은 필요한 기능에 맞는 최적의 언어와 기술을 자유롭게 선택할 수 있는 장점이 있다. 12 | 13 |
14 | 15 | ## 나. 공개SW 연구개발과제의 소프트웨어 재사용에 대한 접근 16 | 수행자는 공개SW 연구개발과제의 설계 단계에서 공개한 소프트웨어가 재사용 될 수 있도록 모듈라 방식, 플러그인 아키텍처, 마이크로서비스 아키텍처 등 소프트웨어를 쉽게 확장할 수 있도록 설계하는 것이 중요하며, 일반적으로 소프트웨어 재사용을 위한 작업은 추상화(abstraction), 저장(storage), 재구성(recontextualization)의 세 단계를 통해 수행한다. [3](#footnote3)
17 |
18 | 추상화(abstraction)는 기존의 소프트웨어 자산이나 소프트웨어 개발 첫 단계로부터 재사용이 가능한 소프트웨어 부분들을 정하는 것을 의미하며, 이 과정에서 공개SW 연구개발과제 수행자는 모든 소프트웨어를 직접 개발할지 또는 외부에서 획득한 공개SW를 활용할지를 결정하게 된다.
19 |
20 | 저장(storage) 단계는 사용자가 공개한 프로젝트에서 원하는 소프트웨어 기능들을 쉽게 찾을 수 있도록 결과물을 구성하는 소프트웨어 코어 부문, 확장 가능한 플러그인 부문 등으로 구분하고 각 부문의 주요 기능에 대하여 상세히 기술하는 과정이다.
21 |
22 | 마지막으로 공개한 프로젝트의 기능을 재사용하고자 하는 개발자가 이해할 수 있는 형태로 만드는 재구성(recontextualization) 작업을 통해 결과물의 재사용성은 개선될 수 있다. 플러그인 개발을 따라 할 수 있는 플러그인 개발 가이드라인 또는 API 활용을 돕는 API 활용 가이드라인 등의 문서를 추가로 준비하여 공개하고, 소프트웨어 데모나 플러그인을 쉽게 활용할 수 있는 플러그인 저장소 등을 구축하여 결과물의 활용을 적극적으로 지원할 수도 있다.
23 | 24 | > 마이크로서비스 아키텍처와 매크로서비스 아키텍처 비교
25 | 26 |
27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 |
마이크로서비스 아키텍처매크로서비스 아키텍처
주요 목적• 지속적배포(Continuous Delivery)• 접근 가용성(Enable Access)
주요 특징• 기능단위의 독립적 실행, 운용
• 각 실행 단위 별 데이터 관리
• 개별 실행 단위의 API 제공		• 전체 서비스 단위로 실행 운용
• 데이터의 전체 공유
• 전체 서비스에 대한 API 제공
서비스 구현 모델
API• 다수의 독립 배포가 가능한 마이크로 서비스 들에 의하여 개별 기능들의 API를 제공• 모놀리틱 응용안에 기능들을 엮어서 전체 서비스 차원의 API를 제공
58 | 59 |
60 | 61 | ### :notebook: 클라우드바리스타[*](#footnoteCB1) 커뮤니티 사례 62 | 63 | - 클라우드바리스타 커뮤니티에서는 공개SW R&D 설계 방법을 수립 및 추진, 개방형 API 기반의 매크로서비스아키텍처[*](#footnoteCB2)로 개발 중 64 | 65 | > 공개SW R&D 설계 방식
66 | 67 |

클라우드바리스타 공개SW R&D 설계 및 개발 방식


68 | 69 | - 초기 워터폴 모델에서 점차 에자일 방식으로 혼합하여 설계 추진 70 | - 공개SW 개발(에자일)의 특성 반영으로 설계-개발 단계가 혼재된 방식으로 추진 71 | - 다양한 채널을 통하여 상시 외부 의견을 수렴하고 소스코드에 반영 72 | 73 |
74 | 75 | > 설계시, 미니 서비스 구조(Mini Service Architecture)의 수용
76 | 77 |

클라우드바리스타 미니서비스아키텍처 형상


78 | 79 | - 개별 SW모듈(프레임워크)들은 개방형 API를 제공하며, 모듈별 독립 실행이 가능한 미니 서비스 구조를 수용 80 | - 설계 초기, 자체 개발 SW부분과 공개SW 활용 부분에 대한 정책을 수립
81 |
82 | 83 | ※ 미니서비스아키텍처: 기능 단위(Fine-grained)의 개별 배포 및 실행이 가능한 마이크로서비스 보다는 크고, 관련 84 | 기능의 그룹인 모듈 단위(Coarse-grained)의 개별 배포 및 실행이 가능한 서비스 아키텍처 (micro-mini-macro) 85 | 86 | 87 | --- 88 | 3) Essentials of Systems Analysis and Design, Joseph S Valacich, University of Arizona, Joey F. George, Iowa State University, 2015 [return](#part2_3_03)
89 | 90 | *) 클라우드바리스타는 출연연, 기업, 개발자 모두가 참여하여 개발의 전과정을 공개SW 개발방법론에 따라 수행하는 공개SW 대표 프로젝트로 다양한 멀티 클라우드 활용·확산을 극대화하는 멀티 클라우드 서비스 공통 프레임워크 기술 및 커뮤니티 고도화 도모 [return](#part2_3_100)
91 | 92 | *) 미니서비스아키텍처: 기능 단위(Fine-grained)의 개별 배포 및 실행이 가능한 마이크로서비스 보다는 크고, 관련 기능의 그룹인 모듈 단위(Coarse-grained)의 개별 배포 및 실행이 가능한 서비스 아키텍처 (micro-mini-macro) [return](#part2_3_101)
93 | 94 | -------------------------------------------------------------------------------- /part2/02/04.md: -------------------------------------------------------------------------------- 1 | # 4. 공개SW R&D 과제 구현 2 | ## 가. 공개SW R&D 과제의 개발 방법론 3 | 공개SW 연구개발과제의 초기 단계는 외부 기여자와 협업이 없으므로 일반적인 소프트웨어 개발 방법론을적용하면서 진행할 수 있지만, 결과물을 공식적으로 공개한 이후에는 다음과 같은 방식으로 개발이 진행된다.
4 |
5 | 공개SW 연구개발과제는 이처럼 외부 기여자의 이슈나 소스 코드 개선 요청을 상시 수용하면서 릴리즈를 관리해야 하므로, 점진적 개선이 가능한 XP, 스크럼, 칸반 등의 애자일 개발방법론을 적용하는 것이 좋다. 6 | 7 |

그림 9. 공개SW 연구개발과제의 개발과정

8 | 9 |
10 | 11 | 대부분의 공개SW 프로젝트는 조기 출시, 잦은 출시의 특징을 가지고 있으며 전통적인 소프트웨어 개발환경에 익숙해진 개발자들에게 가장 큰 차이점은 빠른 속도로 진행되는 개발과정이다. 공개SW 연구개발과제의 수행자는 소프트웨어 개발과정에서 다음과 같은 사항을 고려해야 한다. 12 | 13 | - 처음부터 완벽한 코드를 제출하려고 하지 말고 목표를 달성하기에 충분할 때 제출한다. 14 | - 가능한 최소의 합리적인 크기로 구현해서 작은 변경을 테스트 및 통합하도록 제출한다. 15 | - 개발한 소스 코드를 다시 사용할 수 있도록 준비하자.
16 |
17 | 18 | 만약 외부의 공개SW 프로젝트를 활용하여 과제에 사용한 경우에는 업스트림(가지고 온 원래 프로젝트)에 기여하는 절차를 개발과정에 포함하는 것이 필요하다. 그냥 발견한 공개SW를 다운로드 후 과제에 사용하기가 더 쉬워 보일 19 | 수 있지만, 다음과 같은 이유로 업스트림에 기여하는 것이 더 유리하다. [4](#footnote1) 20 | 21 | - 변경사항을 업스트림 프로젝트에 통합하여 완제품을 제작하는 데 드는 노력의 양을 줄일 수 있다. 22 | - 제출한 변경사항에 대해 업스트림 프로젝트에서 기여자의 자원 활용(리뷰 또는 개선)이 가능하다. 23 | - 업스트림 프로젝트에 기여는 향후 프로젝트 방향에 영향을 줄 기회를 제공한다. 24 | - 자신의 코드가 우발적으로 파손될 위험이 줄어든다. 25 | 26 |

그림 10. 공개SW 프로젝트의 업스트림 개발 과정


27 | 28 | ## 나. 공개SW R&D 과제의 소프트웨어 형상 관리 29 | 공개SW 연구개발과제의 수행자는 소프트웨어 소스 코드의 형상을 관리하기 위한 도구를 준비하고 어떤 브랜치 전략으로 과제를 수행할지, 커밋 메시지를 작성하는 표준은 어떻게 할지 등을 결정하고 참여하는 모든 연구원이 이 절차를 준수하도록 관리해야 한다.
30 |
31 | 최근의 대부분 공개SW 프로젝트는 형상 관리 도구로 git을 사용하며 소스 코드 저장소는 github을 사용하며 gitlab이나 bitbucket을 사용하여 과제를 위한 환경을 직접 내부에 구축하여 운영하기도 한다. 32 | 33 | - 브랜치 모델 34 | 35 | 형상 관리 도구를 준비한 이후에는 다수의 개발자가 하나의 소스 코드 저장소를 사용할 때 저장소를 효율적으로 관리하기 위한 워크플로우가 필요하며, git-flow, github-flow, branch-per-issue 등의 조직의 규모, 서비스의 특징, 프로젝트에 참여하고 있는 구성원들이 제각기 달라서 자신의 상황에 맞는 다양한 브랜치 모델을 사용해야 한다. 36 | 37 | git-flow는 5가지의 브랜치를 이용해서 저장소를 운영하는 브랜치 모델이다. 5가지 중 항시 유지되는 메인 브랜치(master, develop) 2가지와 소스 코드가 병합되면 사라지는 보조 브랜치(feature, release, hotfix) 3가지로 구성된다. 38 | 39 | 40 |

그림 11. git-flow


41 | 42 | - master : 라이브 서버에 제품으로 출시되는 브랜치. 43 | - develop : 다음 출시 버전을 대비하여 개발하는 브랜치. 44 | - feature : 기능 개발 브랜치. develop 브랜치에 들어간다. 45 | - release : 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 master 브랜치로 합친다. 46 | - hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치. 47 | 48 | 주기적으로 배포, QA 및 테스트, hotfix 등 수행할 수 있는 여력이 있는 팀이라면 git-flow로 각각의 브랜치를 체계적으로 관리할 수도 있지만, 릴리즈 주기가 짧고 서비스를 지속적으로 테스트하고 배포하는 조직의 경우는 git-flow보다 간단한 github-flow 모델을 사용할 수 있다.
49 |
50 | github-flow는 git-flow가 Github에서 사용하기에는 복잡하다고 나온 브랜치 모델이다. 이 브랜치 모델은 메인 브랜치(일반적으로 master 또는 main 브랜치를 의미)에 대한 역할만 잘 관리하는 방식으로 hotfix 브랜치나 feature 브랜치를 구분하지 않고, 새로운 기능 추가 또는 이슈 해결이 필요한 시점에 작업 브랜치를 생성하여 관리하고 작업이 끝난 소스 코드의 병합은 깃허브에서 제공하는 pull request 기능을 사용하도록 권장하는 방식이다.[5](#footnote1) 51 | 52 |

그림 12. github-flow


53 | 54 | ### :mortar_board: github-flow 사용법 55 | 1. **main 브랜치는 어느 시점이든 소프트웨어의 배포가 가능해야 한다.** 56 | - 먼저 과제 수행 컨소시엄 구성원들에게 분산되어 보관되는 소스 코드가 있는 경우, 모든 소스 코드를 main 브랜치에서 관리하도록 구성한다. 57 | - main 브랜치는 항상 최신 상태며, 안정적인 상태로 유지되어야 하며 소프트웨어 배포에 사용되는 브랜치. 따라서 이 브랜치에 대해서는 소스 코드를 병합하기 전에 충분한 테스트가 필요하며 엄격한 규칙으로 관리되어야 한다. 58 | - 테스트는 브랜치를 최신으로 병합하고 릴리즈 관리 도구(Jenkins, Travis CI 등)를 통해 테스트할 수 있도록 59 | 구성한다. 60 | 2. **기능 추가나 이슈 해결을 위해 소스 코드의 수정을 할 때 브랜치의 생성은 항상 main 브랜치에서 만들고, main 브랜치에서 새로운 일을 시작하기 위해 브랜치를 만들 때는 브랜치의 이름을 명확히 작성한다.** 61 | - 새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름은 자세하게 어떤 일을 하고 있는지에 대해서 62 | 작성한다. 63 | - 커밋 메시지는 여러 사람과 같이 개발할 때 서로 간의 코드 리뷰에 도움이 되므로 표준을 정의하고 준수한다. 64 | 3. **개발자는 작업 중인 원격 저장소 브랜치로 자주 병합해야 한다.** 65 | - 항상 원격 저장소에 자신이 하는 작업을 반영하여 다른 사람들도 확인할 수 있도록 해야 한다. 66 | - 개발환경에 문제가 발생해 작업하던 부분이 없어지더라도, 원격 저장소에 있는 소스를 받아서 작업할 수 67 | 있도록 관리해야 한다. 68 | 4. **피드백이나 도움이 필요할 때, 그리고 병합할 준비가 완료되었을 때는 풀리퀘스트(pull request)를 생성한다.** 69 | - 풀리퀘스트(pull request)는 소프트웨어의 형상 관리를 책임지는 책임자에게 소스 코드의 병합을 위해 리뷰를 요청하는 행동이다. 70 | - 풀리퀘스트(pull request)를 이용해 자신의 코드를 공유하고 리뷰를 요청한 후 리뷰어의 검토 사항에 따라 발견한 리뷰 내용을 수정한다. 71 | - 리뷰어의 검토사항을 모두 수정하고 병합을 할 준비가 완료되었다면 main 브랜치로 반영을 요구하도록 한다. 72 | 5. **소스 코드의 기능에 대한 리뷰가 끝난 후 main 브랜치로 병합한다.** 73 | - 병합을 반영하면 바로 릴리즈로 반영이 될 기능이므로, 이해관계자들과 충분한 논의 이후 반영하도록 한다. 74 | - main 브랜치에 병합이 완료되면 작업한 브랜치는 삭제한다. 75 | 6. **소스 코드가 main 브랜치로 병합되어 적용되면 소프트웨어의 새 릴리즈가 즉시 배포된다.** 76 | - 이 부분이 GitHub-flow의 핵심으로 워크플로우 자동화도구인 깃헙액션 또는 자신이 사용중인 릴리즈 관리 도구의 트리거를 이용하여 main 브랜치의 변경이 일어나면 자동으로 배포가 되도록 설정해 놓는다 77 | - 병합한 이후에는 릴리즈 자동화 도구의 결과를 확인하여 오류가 없는지 점검한다. 78 |
79 | 80 | - 커밋 메시지 작성하기 81 | 82 | 공개된 프로젝트에 참여하고 싶은 외부 기여자는 커밋 메시지를 통해 공개된 소프트웨어의 변경 이력을 분석할 때 도움이 되기 때문에 누구나 쉽게 이해할 수 있도록 작성하는 것이 필요하다.
83 |
84 | 공개SW 연구개발 과제의 수행자는 소프트웨어 소스 코드 저장소에 새로운 소스 코드가 반영될 때 입력하는 커밋 메시지의 표준을 정의하고 참여연구원 전원이 준수할 수 있도록 관리하여 소프트웨어 소스 코드의 무의미한 커밋을 방지하고 외부 기여자의 쉬운 프로젝트 참여 환경을 구축할 수 있다.
85 |
86 | 87 | 별도의 커밋 메시지 표준이 없는 경우에는 다음과 같은 커밋 메시지 규칙(Udacity Git Commit Message Style 88 | Guide)을 참고할 수 있다. [6](#footnote3) 89 | 90 | - 커밋 메시지는 크게 제목, 본문, 꼬리말 세 가지 부분으로 나누고, 각 부분은 빈 줄을 두어 구분하여 작성하자. 91 | - type : 어떤 의도로 커밋을 했는지 알 수 있도록 type에 명시. 92 | - subject : 최대 50글자가 넘지 않도록 하고 마침표는 찍지 않는다. 영문으로 표기하는 경우 동사(원형)를 가장 앞에 두고 첫 글자는 대문자로 표기. 93 | - body : 긴 설명이 필요한 경우에 작성. 어떻게 했는지가 아니라, 무엇을 왜 했는지를 최대 75자를 이내로 작성. 94 | - footer : issue tracker ID를 명시하고 싶은 경우에 작성. 95 | 96 |
97 | 98 |

그림 13. 커밋 메시지 구조

99 | 100 |
101 | 102 | 이런 규칙을 적용하여 커밋 메시지를 작성하면 다음과 같이 작성할 수 있다.
103 | 104 |

그림 14. 커밋 메시지 작성 예

105 | 106 |
107 | 108 | ### :notebook: 클라우드바리스타 커뮤니티 사례 109 | - 신규 컨트리뷰터를 위해 “GitHub를 통한 Cloud-Barista 컨트리뷰션 절차 가이드” 제공: https://github.com/cloud-barista/docs/blob/master/contributing/how_to_open_a_pull_request-ko.md 110 | - 클라우드바리스타 커뮤니티의 공개SW 기여 방법 111 | 112 | 113 |

[클라우드바리스타 커뮤니티 협업/기여 방법 절차]

114 | 115 | 1. Propose an issue: 이슈 오픈/생성/제안하는 작업 116 | 2. Discuss the issue: 이슈와 관련된 사람들간 논의 작업 117 | 3. Assign/self-assign the issue to contributors: 논의를 바탕으로 이슈 담당자 자원/배정 작업 118 | 4. Fork/Sync (Fetch and merge) upstream: 처음이면 업스트림을 포크 / 처음이 아니면 업스트림의 최신 변경사항을 동기화 119 | 5. Create branch: 이슈 해결을 위한 브랜치 생성 작업 (로컬 저장소에서 수행해도 무방) 120 | 6. Fetch/pull: 121 | - Fetch는 원격 저장소의 내용을 가져오는 작업 122 | - Pull은 원격 저장소의 내용을 가져와 자동으로 병합 작업까지 수행 123 | 7. Checkout: 작업을 위한 브랜치로 변경 124 | 8. Improve/develop: 이슈 해결/개선 작업 125 | 9. Build test: 이슈 해결/개선 사항의 빌드 성공 여부 테스트 수행 126 | 10. Commit: 이슈 해결/개선 사항을 기록 127 | 11. Fetch upstream (e.g., upstream/main): 업스트림의 최신 변경사항을 가져옴 128 | 12. Rebase (if needed): 업스트림에 변경된 내용이 있다면 작업 브랜치의 Base를 최신 업스트림으로 변경하는 작업 129 | 13. Push: 로컬 저장소의 변경 이력을 원격 저장소에 공유/업로드하는 작업 130 | 14. Perform tests in the guided test environment (An issue occurs, do step 8-14): 기여자/개발자/사용자에게 안내된 테스트 환경 및 방법이 있다면 이에 대한 테스트 수행 (테스트 수행 중, 이슈 발생 시 8-14 수행) 131 | 15. Pull request (PR): 작업한 브랜치의 내용(이슈 해결/개선 사항)을 upstream에 반영해 달라고 요청하는 작업 및 다른 기여자에게 변경사항이 있음을 알리는 작업 132 | 16. Review and make comments: 이슈 해결/개선사항 반영 요청에 대한 검토 수행 및 검토의견을 바탕으로 상호 논의 수행 133 | 17. Handle comments (do step 8-14, and squash/amend if needed): 검토의견 및 논의 내용을 반영 또는 개선 작업 수행 (필요에 따라 Squash/amend 수반) 134 | 18. Approve: 앞선 과정을 통해 이슈가 해결되었음을 승인하는 작업 135 | 19. Merge: 승인된 이슈 해결/개선 사항을 main 브랜치에 병합하는 작업
136 | 137 | > 클라우드바리스타의 커밋(Commit)을 참고로 추가하며, 추가로 How to Write a Git Commit Message(Chris 138 | Beams) 내용을 번역, 편집하고 도움이 될만한 내용을 추가한 블로그((https://meetup.toast.com/posts/106) 139 | 를 참고하면 좋습니다.
140 | 141 |
142 | 143 | ### :notebook: CB-Spider 프레임워크 사례 144 | - #### **사례1)** 제목만으로 충분한 설명이 된 Commit 메시지 145 | https://github.com/cloud-barista/cb-spider/commit/0f6adc89ba0ead2929cc346088caf99b725ad233 146 | 147 |

사례1) 제목만으로 충분한 설명이 된 Commit 메시지


148 | 149 | - #### **사례2)** 제목이 몇 가지 내용을 포괄하고 있어 상세 설명을 작성한 Commit 메시지 150 | 151 |

사례2) 제목이 몇 가지 내용을 포괄하고 있어 상세 설명을 작성한 Commit 메시지


152 | 153 | 154 | ### :notebook: CB-Tumblebug 프레임워크 사례 155 | https://github.com/cloud-barista/cb-tumblebug/commit/4493e962ed19a52eba0ea1ac2968b448ff317ea4 156 | 157 |

CB-Tumblebug 프레임워크 사례


158 | 159 | ## 다. 공개SW R&D 과제의 이슈 관리 160 | 공개SW 연구개발과제의 이슈 관리는 일반적인 소프트웨어 개발의 이슈 관리와 같이 다양한 이슈 관리 도구 (Bugzilla, redmine, Jira, github, Gitlab 등)를 이용해서 진행된다. 일반적인 소프트웨어 개발과 차이점은 이슈를 등록하는 역할이 내부 개발팀의 연구원이 아니라 공개된 프로젝트를 사용하는 외부 사용자일 수 있으므로 이슈 관리를 통해 연구개발과제의 진행 과정이 투명하게 남는다는 점이다.
161 |
162 | 공개SW 연구개발과제의 수행자는 등록되는 이슈에 대하여 다음과 같은 절차를 준비하고 각 절차의 담당자를 배정하여 수행해야 한다.
163 | 164 | - 이슈 등록 : 사용자 혹은 품질관리팀이 발견한 버그 혹은 신규 기능을 추가한다. 담당자가 명확한 경우 지정하기도 165 | 하나 공란으로 남겨두는 일도 흔하다. 166 | - 이슈 검토/분류 : 등록된 이슈는 개발팀이 검토한다. 중복, 재현 불가, 해결 불가능한 이슈의 경우 이 단계에서 167 | 이슈를 닫는다. 개발팀에서 해결할 이슈의 경우 담당자, 우선순위, 마감일 등을 지정한다. 168 | - 이슈 해결 : 이슈가 해결되면 이슈를 닫는다. 담당자와 별개로 검증 담당자(Verifier)를 따로 두어 진짜로 이슈가 169 | 해결되었는지 검증하는 때도 있다. 170 | 171 | 이슈 관리 시스템은 사전에 정의된 이슈 템플릿을 생성하는 기능, 이슈의 유형을 식별하는 레이블 자동생성, 이슈의 담당자 지정 등 다양한 기능을 제공하고 있으므로 공개SW 연구개발과제의 수행자는 참여연구원 전체가 사용하는 이슈 관리 도구의 사용법을 미리 숙지할 수 있도록 교육하고 효율적으로 운영하는 것이 필요하다.
172 | 173 |

그림 15. 이슈 템플릿 기능의 예


174 | 175 | ### :notebook: 클라우드바리스타 커뮤니티 사례 176 | - 클라우드바리스타 커뮤니티에서는 자료 조사 후 몇 차례 검토 회의를 통해 이슈 템플릿을 적용하였고, 아래는 CB-Tumeblebug의 이슈 템플릿에 대한 사례를 나타낸다. 177 | 178 |

[이슈 템플릿 마크다운 경로 및 파일]


179 | 180 |

[이슈 템플릿 마크다운 내용]


181 | 182 |

[이슈 생성 화면]


183 | 184 |

[이슈 생성 화면]


185 | 186 | ### 라. 공개SW R&D 과제의 릴리즈 관리 187 | 공개SW 연구개발과제의 결과물을 배포하기 위해서는 개발된 프로그램 소스 코드와 배포용 바이너리 파일을 함께 포함하여 배포하는 것이 일반적인 배포방법이다. 깃허브의 경우 소스 코드와 빌드된 바이너리 파일을 함께 포함하여 온라인에서 쉽게 릴리즈 할 수 있는 도구를 제공하고 있으며 다음과 같이 사용할 수 있다.
188 |
189 | 190 | ### 깃허브에서 소프트웨어 릴리즈 하는 법 191 | 1. 릴리즈를 위해 저장소의 Releases 페이지 이동한다. 192 |


193 | 194 | 2. 페이지에서 Create a new release 버튼 선택 195 | 릴리즈된 버전이 없는 경우 아래와 같이 출력되며, Create a new release를 누르면 릴리즈할 항목을 선택할 196 | 수 있다. 197 |


198 | 199 | 3. 릴리즈 항목 입력 200 | 다음 그림과 같은 화면에서 릴리즈에 필요한 태그, 릴리즈 버전명, 릴리즈 내용, 추가할 바이너리 또는 기타 파일을 함께 업로드한다. 201 |


202 | 203 | 입력을 모두 마친 후, Publish release 버튼을 눌러보자!
204 | 205 | 4. 패키지 배포 결과 206 | 207 |


208 | 209 | 직접 추가한 바이너리 파일들과 릴리즈 시점의 소프트웨어 소스 코드가 자동으로 첨부되어 릴리즈 페이지에 210 | 제공된다.
211 |
212 | 이때 소프트웨어 릴리즈에 사용하는 버전 태그는 버전 이름 앞에 문자 v를 붙이는 것이 일반적이다. 태그가 프로덕션용으로 사용되지 않는 경우 버전 이름 뒤에 v0.2.0-alpha 또는 v5.9-beta처럼 이 릴리스 전 버전을 추가하는 방식으로 작성한다. 공개SW 연구개발과제의 수행자는 소프트웨어 출시 전 버전 번호를 어떻게 정할지 규칙을 결정하기 위해 사전에 다음과 같은 규칙을 정의하는 것이 필요하다.
213 |
214 | 215 | ### Semantic Versioning 2.0.0 216 | 버전을 주.부.수 숫자로 하고 : 217 | 218 | 기존 버전과 호환되지 않게 API가 바뀌면 “주(主) 버전”을 올리고,
219 | 기존 버전과 호환되면서 새로운 기능을 추가할 때는 “부(部) 버전”을 올리고,
220 | 기존 버전과 호환되면서 버그를 수정한 것이라면 “수(修) 버전”을 올린다.
221 | 주.부.수 형식에 정식배포 전 버전이나 빌드 메타데이터를 위한 라벨을 덧붙이는 방법도 있다.[7](#footnote4) 222 | 223 |
224 | 225 | 소프트웨어의 배포가 자주 이루어지지 않는 경우는 이처럼 수동으로 릴리즈 하는 핀포인트 릴리즈 방식을 사용해도 되지만, github-flow 같은 브랜치 모델을 사용하는 경우에는 항상 릴리즈를 최신으로 유지하는 것이 필요하며 Travis, Jenkins 등의 릴리즈 관리 도구의 기능을 이용하여 자동으로 소프트웨어가 배포되도록 지속적 통합 (Continuous Integration) 환경을 구성하는 DevOPS 방식을 구성하는 것이 좋다. [8](#footnote5) 226 |
227 | 228 | 지속적 통합(Continuous Integration) 환경이란 소프트웨어의 배포를 특정 시점에 계획하여 배포하는 핀포인트 릴리즈 방식이 아니라 작은 코드 변경이 이루어지는 시점에서 병합하여 배포를 수행하는 방식이다. 지속적 통합 (Continuous Integration) 환경은 소프트웨어 배포 전 통합테스트를 통해 검증하는 기존의 개발방식이 아니라 개발자의 프로그램 소스 코드 변경내용이 저장소에 반영되는 시점에 빌드, 테스트, 배포를 자동으로 수행하도록 구성하여 개발 종료 시 변화가 많은 상태로 병합하는 것보다 더 작은 규모로 개발하고 자주 테스트함으로써 건강한 소프트웨어를 만드는 방식으로, 성숙도가 높은 대부분의 공개SW 프로젝트는 지속적 통합 환경을 구축하여 프로젝트를 관리하고 있다. 229 |
230 | 231 |

[그림 16. 지속적 통합(Continuous Integration) 워크플로우]


232 | 233 | 좋은 지속적 통합 프로세스의 필수 요소[9](#footnote6)는 다음과 같다. 234 | 235 | - 소스 코드 관리 시스템 사용 – 소스 코드 관리 시스템을 사용하지 않거나 소스 코드의 일부만 저장소에 있는 경우 첫 단계는 모든 소스 코드를 저장소에 가져오고 모든 팀원이 사용하도록 요청해야 한다. 236 | - 자주 커밋하기 – 소스 관리 시스템을 사용하는 경우 참여연구원 모두가 자주 커밋하는 습관을 기르는 것이 중요하다. 커밋 시에는 작업 크기가 지나치게 크면 변경을 파악하기 어려우므로 각각의 작업을 더 작은 부분으로 나누어 쉽게 로컬에서 변경을 완료하고 테스트할 수 있도록 작업하고 자주 커밋해야 한다. 237 | - 모든 커밋 이벤트 발생 시 빌드 – 프로젝트의 모든 구성원과 코드의 변경사항을 정기적으로 공유하도록 구성 후 최신 변경사항이 생기면 결과물의 빌드가 가능한지 확인할 수 있도록 구성한다. 이 작업을 수동으로 수행할 수 있지만 빌드를 자동으로 수행하도록 구성하면 훨씬 쉽고 효율적이며 이를 위하여 지속적 통합(Continuous Integration) 환경이 필요하다. 238 | - 테스트 자동화 – 성공적인 빌드 결과는 좋은 신호이지만 소프트웨어의 품질을 더욱 확실히 관리하려면 테스트를 자동으로 실행하도록 구성하는 것이 좋다. 수동으로 테스트하기보다는 자동 테스트를 구성하면 보다 효율적이다. 239 | - 피드백 경청 – 지속적 통합 환경에서 피드백 받은 정보를 기반으로 소프트웨어의 개선을 잘 수행하는 것이 중요하다. 이런 피드백의 편의성을 위해서 대부분의 지속적 통합(Continuous Integration) 도구들은 빌드가 실패하는 경우 이메일, 메신저 등의 알림을 연동하여 즉각적인 대응이 가능하도록 제공하고 있다. 240 | - DevOps 문화 구축 – 지속적인 통합의 이점을 적절히 활용하려면 모든 팀원이 작동하지 않는 빌드를 수정하거나 테스트 실패에 책임감을 느끼는 팀 문화를 조성해야 한다. 마지막으로 커밋한 팀원만을 탓하기보다는 변경사항을 조기에, 자주 커밋하는 편이 프로젝트 수행팀 모두의 이익에 부합된다는 것을 이해하는 문화가 필요하다. 241 | 242 | 과제 수행자는 이런 지속적 통합 환경을 구축하기 위해서 Jenkins, Travis, Bamboo, TeamCity 등의 소프트웨어나 클라우드 서비스를 이용할 수 있으며, 깃허브에서는 Travis CI 서비스와 깃허브 소스 코드 저장소의 쉬운 연동을 지원하고 있으므로 다음과 같은 지속적 통합 배포 환경을 쉽게 구성할 수 있다. 이런 환경은 소프트웨어 품질 관리 프로세스를 상시 수행하고 있는 신뢰할 수 있는 프로젝트임을 의미하며 향후 외부 기여자들이 소스 코드의 개선에 적극적으로 참여할 수 있는 중요한 요소이다. 243 | 244 |

[그림 17. Travix CI 서비스를 이용한 지속적 통합 배포 환경의 구성 예]


245 | 246 | 또 다른 방법으로 깃허브의 경우 소스 코드 저장소의 변경을 감지하여 필요한 조치를 추가로 수행하는 Github Action[10](#footnote7)이라는 워크플로우 자동화 기능을 제공하고 있으며, 이를 이용하면 메인테이너의 리뷰가 끝난 소스 코드를 저장소에 커밋하는 동시에 최신의 소프트웨어를 릴리즈하는 과정을 자동으로 수행되도록 다음과 같이 구성할 수도 있다. 247 | 248 |

[그림 18. Github Action을 이용한 지속적 통합 배포 환경의 구성 예]


249 | 250 | 251 | ### :notebook: 클라우드바리스타 커뮤니티 사례 252 | - 클라우드바리스타 커뮤니티는 2019년도 v0.1.0-americano 첫 공개(Release)를 시작으로 매년 공개 행사를 통해 개발 소스 코드 및 산출 문서를 공개하고 있다. 253 | 254 |

[클라우드바리스타 커뮤니티 오픈 세미나 및 릴리스 마일스톤]


255 | 256 | - 클라우드바리스타 커뮤니티 컨퍼런스를 통한 주요기술 현황 공유 소스코드 릴리스 계획 예시
257 | https://github.com/cloud-barista/docs/wiki/Cloud-Barista-v0.5.0-(Affogato)-release-plan

258 | - 향후 개발 및 기여되는 수많은 신규 소스코트 통합으로 인해 발생하게 될 업무 부하(소위: Integration hell)에 대비하기 위하여 CI/CD 자동화를 도입하였으며, 도입된 CI 자동화 범위는 아래와 같다. 259 | 260 |

[클라우드바리스타 커뮤니티의 CI/CD 자동화 도입 범위]


261 | 262 | - GitHub에서 제공하는 워크플로 자동화 도구인 GitHub Actions를 활용하여 클라우드바리스타 CI/CD 자동화 파이프라인을 구현하였으며 아래 그림은 CI 워크플로 중 Build test 적용 사례를 나타낸다. 263 | 264 |

[클라우드바리스타 CI 워크플로 중 Build test 사례]


265 | 266 |
267 | 268 | --- 269 | 270 | 4) https://github.com/todogroup/ospo101 [return](#part2_2_04)
271 | 5) https://hellowoori.tistory.com/56 [return](#part2_2_05)
272 | 6) https://udacity.github.io/git-styleguide/ [return](#part2_2_06)
273 | 7) https://semver.org/lang/ko/ [return](#part2_2_07)
274 | 8) https://nimbella.com/blog/ci/cd-pipeline-with-github-actions [return](#part2_2_08)
275 | 9) https://www.jetbrains.com/ko-kr/teamcity/ci-cd-guide/continuous-integration-vs-delivery-vs-deployment/ [return](#part2_2_09)
276 | 10) https://docs.github.com/en/actions/quickstart [return](#part2_2_10)
277 | 278 | 279 | -------------------------------------------------------------------------------- /part2/02/05.md: -------------------------------------------------------------------------------- 1 | # 5. 공개SW R&D 과제 검증 2 | 3 | ## 가. 공개SW R&D 과제의 테스트 4 | 5 | 지속적 통합 환경을 구축하면 개발자가 Git 같은 버전 관리 제어 시스템을 사용하여 공유된 소스 코드 저장소에 빈번하게 변경내용을 병합하게 된다. 각 커밋에 앞서, 개발자는 통합 전에 검증을 위해 소스 코드에 단위테스트를 수행할 수 있다.
6 |
7 | 이렇게 테스트 된 결과를 코드 커버리지(Code Coverage)로 표현하게 되는데 코드 커버리지는 소프트웨어의 품질을 논할 때 얼마나 테스트가 충분한가를 나타내는 지표 중 하나로 소프트웨어 테스트를 진행했을 때 코드 자체가 얼마나 실행되었냐를 의미하는 것이다.

8 | 과제 수행자는 공개SW 연구개발과제의 결과물을 공개한 후 사용자에게 소프트웨어의 신뢰성을 제공하는 방법으로, 프로그램 언어별로 적합한 테스트 도구(unittest, pytest, mocha, junit 등)를 이용하여 테스트 코드를 작성하고, 테스트 자동화 기능을 지원하는 속적 통합 환경을 이용하여 테스트 결과를 코드 커버리지 보고서를 통해 제공할 수 있다.
9 |
10 | 자동화된 테스트 작성에 더 많은 노동력이 필요한 듯 보이지만, 빠른 피드백을 얻기 위해 모든 빌드 시점에서 테스트를 실행할 경우 시간을 훨씬 단축할 수 있으며, 지속적 통합 서비스는 새로운 코드 변화에 대한 테스트를 자동으로 실행하여 즉시 모든 오류를 가시화할 수 있는 좋은 도구로서, 프로젝트를 구성할 때 활용하는 것을 권장한다.
11 | 12 | 깃허브를 사용하는 경우에는 작성한 테스트 코드와 테스트 도구를 지속적 통합 도구 Travis CI와 연동하여 다음과 같이 테스트 결과를 함께 제공할 수도 있다.[11](#footnote11) 13 | 14 |

[그림 19. 코드 커버리지(Code Coverage) 보고서 예]


15 | 16 |
17 | 18 | ## 나. 공개SW R&D 과제의 성과지표 관리 19 | 20 | 과제 수행자는 공개SW 연구개발과제를 제대로 평가하기 위해 공개SW 특성을 반영한 성과지표를 선정하고 관리하는 과정이 요구된다. 공개SW 연구개발과제의 성과지표를 구성하는 과제 수행자는 일반적인 연구개발과제에서 사용하던 소프트웨어의 성능 및 기능의 목표와 함께 공개할 과제 결과물의 공개SW 프로젝트 성숙도를 표현할 수 있는 다양한 지표를 추가하여 관리하는 것이 필요하다.
21 | 22 | 과제 수행자가 일반적으로 사용할 수 있는 공개SW 연구개발과제의 성과지표는 다음과 같은 예를 들 수 있다. 23 | - 공개한 소스 코드 저장소의 활성화 정도를 표시하는 스타, 커밋(commit), 포크(fork), 이슈(Issue), 풀리퀘스트(Pull Request) 등의 지표 24 | - 커뮤니티의 활동성을 대변하는 기여자 수, 커뮤니티 사용자, 홍보 채널, 기술 문서 등의 지표 25 | - 결과물의 활용성을 의미하는 기술이전, 적용사례, 파트너 참여기업 수 등의 지표 26 | 27 | 과제 수행자는 아래에 제시한 [표 8]의 공개SW R&D 과제의 성과지표 예시를 참고하여, 연구개발 과제의 수행 기간 전반에 걸쳐 체계적으로 관리하는 것이 중요하다. 성과지표의 각 항목은 과제의 수행 기간이나 커뮤니티 신규 구축 여부 등 자신이 수행하는 과제의 수행 환경에 적합한 목표치를 설정하고, 성과지표를 관리할 때에는 과도하게 설정한 커밋 수를 올리기 위해서 의미 없는 커밋 메시지를 반복하여 기록하는 행위나 외부 인원을 동원하여 스타 수를 올리기 위해서 경품 이벤트를 하는 깃허브 스타 어뷰징[12](#footnote12)같은 행위 등 공개SW 프로젝트의 사용자들을 기만하는 행위로 지표를 달성하는 것은 하지 말아야 한다. 28 | 29 | > 표 8. 공개SW 연구개발과제의 공개SW 성과지표 예시
30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 |
구분(지표)목표실적
(누적)		설정근거내용
당해 목표치
저장소10개 이상3연간 3개 이상 확보 및 유지연구 개발과 관련된 프로젝트의 공개 저장소를 10개 이상 지속해서 운영
　
스타(Star)100개 이상20저장소당 10개 이상10개 이상의 저장소에 대해 100개 이상의 스타 확보
　
커밋(Commit)200개 이상200과제 수행연도 및 개발내용 고려/자체 설정Github 등 저장소 커밋 횟수
(커밋 규칙을 준수하는 유의미한 내용으로 작성)
　
포크(Fork)30개 이상20과제 수행연도 및 개발내용 고려/자체 설정Github 등 저장소 fork 수
　
이슈(Issue closed)50회 이상20과제 수행연도 및 개발내용 고려/자체 설정프로젝트의 이슈 관리 시스템에 등록된 이슈 중 해결된 이슈 수
　
풀리퀘스트(Pull Request closed)50회 이상20과제 수행연도 및 개발내용 고려/자체 설정Github 등 저장소에 요청한 내용 중 해결된 요청 수(PR)
　
기여자(명)15명 이상5과제 참여 인력의 50% 이상실제 프로젝트 커밋에 참여하는 기여자를 15명 이상 확보
　
커뮤니티 사용자100명 이상50과제 수행연도 및 개발내용 고려/자체 설정커뮤니티 서비스에서 확인되는 공개SW 커뮤니티의 사용자 수
　
기술이전3건 이상1기술이전 계약서 공개SW 커뮤니티를 통한 기술이전 건수
　
활동성4점 이상2과제 수행연도 및 개발내용 고려/자체 설정커뮤니티 버전 번호 평균과 월단위의 커뮤니티 유지기간을 곱하여 산출
*점수 = 최종 버전 # * 커뮤니티 유지 개월 수
　
홍보1건/년2과제 수행연도 및개발내용 고려/자체 설정 SCI 논문 게재 등을 통한 커뮤니티 홍보 건수
157 |
158 | 159 | 과제 수행자는 이렇게 선정된 지표를 관리하는 방법으로 다음 이미지와 같이 소스 코드 저장소의 README 파일에 배지 이미지 형식으로 가시화하여 공개할 수 있다. 이런 프로젝트는 외부의 사용자가 해당 프로젝트를 처음 사용하려고 할 때 일반적인 공개SW 프로젝트 보다 더욱 신뢰할 수 있는 프로젝트로 보이게 되므로 적극적으로 활용하는 것이 좋다. 160 | 161 |

그림 20. 공개SW 프로젝트 메타데이터의 가시화 예


162 | 163 | 이 때 과제 수행자는 직접 공개SW 성과지표를 수집하고 분석하는 과정을 수행하지 말고 공개SW 프로젝트의 품질에 대한 다양한 항목의 메타데이터를 이미지 형태로 제공하는 서비스를 이용하는 것을 권장한다.
164 |
165 | 이처럼 공개SW 프로젝트의 메타데이터를 쉽게 가시화할 수 있는 대표적인 서비스는 Shields.io, badgen.net 등이 있으며, 이를 활용하면 다음과 같이 주요한 과제에서 선정한 공개SW 성과지표를 쉽게 가시화하여 보여줄 수 있으므로 과제 결과물을 공개할 시 활용하는 것이 좋다. 166 | 167 | > 표 9. 공개SW 프로젝트 성과지표 가시화 방법의 예시 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 |
성과지표배지 이미지 생성 URL보기
Stars/github/stars/:org
Commit/github/commit-activity/:interval/:user/:repo
Fork/github/forks/:user/:repo?label=Fork
Pull Request/github/issues-pr/:user/:repo
해결된 이슈/github/issues-closed-raw/:user/:repo
해결된 PR/github/issues-pr-closed/:user/:repo
컨트리뷰터/github/all-contributors/:user/:repo/:branch*
다운로드 수/github/downloads/:user/:repo/tota
221 | 222 | 이 서비스는 예시로 제시한 항목 이외에도 빌드 결과, 코드 커버리지, 다운로드 수, 이슈 관리 상태, 라이선스 정보, 커밋 활동 등 프로젝트의 품질에 대한 다양한 항목의 메타데이터를 가시화하는 방법을 제공하고 있으므로 과제 수행자는 과제에 적합한 항목을 공개SW 성과지표로 선정하고 관리하는데 활용할 수 있다. 223 | - URL : https://shields.io 224 | - URL : https://badgen.net 225 | 226 | 예를 들어 과제 수행 조직의 이름으로 등록한 저장소의 전체 스타 수를 보여주기 위해서는 다음과 같은 경로를 소스 코드 저장소의 README 파일에 추가할 수 있다. 227 | 228 | 229 | 230 | 231 | 233 | 234 | 235 | 237 |
URLhttps://img.shields.io/github/stars/hamonikr?style=social 232 |
배지 이미지 236 |
238 | 239 | 그 외에도 공개SW 프로젝트의 성숙도와 적용성을 평가하는 항목을 제시하고 있는 공개SW 성숙도 및 적용성 평가 표준(TTAK.KO-11.0133)에서는 다음과 같은 항목을 공개SW 프로젝트의 평가요소로 제안하고 있으므로, 수행자는 공개SW 연구개발과제의 상황에 적합하게 지표를 선정하여 관리할 수 있다. 240 | 241 |
242 | 243 | ### :notebook: 클라우드바리스타 커뮤니티 사례 244 | 245 | - GitHub 고도화의 일환으로 각 저장소에 Badge를 추가하여 유용한 정보를 제공. 글로벌 공개SW의 커뮤니티, 저장소, Badge에 대한 분석을 통하여 커뮤니티에서 수용할 Badge를 선정하였으며 “클라우드바리스타 저장소를 위한 공통 Badge”에 대한 정보는 아래와 같다.
246 | https://github.com/cloud-barista/docs/wiki/Common-badges-for-readme-for-Cloud-Barista-repos 247 | 248 | - 클라우드바리스타 저장소들의 Badge 적용 249 | 250 | 251 |


252 | 253 |

그림 21. 공개SW 성숙도 및 적용성 평가 표준(TTAK.KO-11.0133)의 구성


254 | 255 | 이 표준은 공개SW 프로젝트를 평가하기 위해 일반적인 소프트웨어의 품질 속성과 시장성, 기술지원, 커뮤니티 성숙도, 성장성 등의 공개SW 고유의 품질 속성, 그리고 특정 분야의 기술을 공개SW로 대체할 때의 확장 속성을 평가에 함께 적용할 수 있는 내용으로 구성되어 있다. 그중 커뮤니티의 평가항목으로 제시하고 있는 속성은 나이 및 규모, 주체, 접근성, 성숙성 등의 요소가 있으며 이 속성들은 다음과 같이 계량화할 수 있게 제시하고 있으므로 공개 SW 프로젝트의 커뮤니티 활성화 정도를 성과지표로 관리할 때 적절히 활용할 수 있다. 256 | 257 | > 표 10. 공개SW 성숙도 및 적용성 평가 표준의 커뮤니티 평가 방법
258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 |
속성변환 공식적용 방법
나이 및 규모변수 = {버전 번호, 연령}
지표 = 최종 버전 번호 x 나이
1 점: 0 <= 지표 < 12
2 점: 12 <= 지표 < 24
3 점; 24 <= 지표 < 72
4 점: 72 <= 지표 < 180
5 점: 180 <= 지표		지표는 최종 버전 번호와 월 단위의 커뮤니티 나이를 곱해서 산출함
버전 번호가 1.0 이상이고 커뮤니티 나이도 12개월 이상이 되어야 자생력이 있는 커뮤니티로 인정함
버전이 3.0 이상이고 연수가 5이상이면 최상위 수준으로 인정함
주체변수 = { 후원 단체 유무}
1 점: 지원 없음
2 점: 하나의 중소기업 지원
3 점: 복수의 중소기업 지원
4 점: 하나의 대기업의 지원
5 점: 복수의 대기업의 지원		인력 및 자금에 대한 후원 단체의 유무로 측정함
접근성변수 = {게시판, 포럼, 위키, 검색성, 인터넷}
지표 = 제공하는 접근방법의 종류 / 전체
접근방법의 종류 개수
1 점: 0.0 <= 지표 < 0.2
2 점: 0.2 <= 지표 < 0.4
3 점: 0.4 <= 지표 < 0.6
4 점: 0.6 <= 지표 < 0.8
5 점: 0.8 <= 지표 <= 1.0		전체 접근 방법의 종류 개수 = 5
1. 게시판 운영
2. 포럼 운영
3. 위키 운영
4. 인터넷 검색 시 첫 페이지 출력
5. 인터넷 사이트에서 정보 제공
외부에서 커뮤니티로 연락하거나 관련 정보를 얻을 수 있는 용이성
공개SW 커뮤니티에 대해 전문 정보를 제공하는 인터넷 사이트로는 ohloh.net, wikipedia.org 등이 있음
성숙성변수 = {기간, 버전 출시, 관리 체제,
평가방법, 위원회 운영}
지표 = 충족하는 성숙지표의 종류 /
전체 성숙 지표의 종류 개수
1 점: 0.0 <= 지표 < 0.2
2 점: 0.2 <= 지표 < 0.4
3 점: 0.4 <= 지표 < 0.6
4 점: 0.6 <= 지표 < 0.8
5 점: 0.8 <= 지표 <= 1.0		전체 성숙 지표의 종류 개수 = 5
1. 최초 버전 출시 이후 3년 이상 지속적으로 신규 버전 출시
2. 최근 배포한 안정된 버전의 넘버가 1.0 이상
3. 관리 운영자(maintenance operator), 커미터(심의자), 개발자 등의 운영 체제 확립
4. 기여도 및 참여도에 따른 개발자의 등급 체제 확립
5. 이사회 운영 - 개인의 독단적 판단이 아닌 위원회에 의한 의사결정 방식

291 | 292 | ## 다. 공개SW R&D 과제의 라이선스 검증 293 | 공개한 수행자는 공개SW 연구개발과제의 라이선스 의무사항을 제대로 준수하고 있는지 검증하고 보완하기 위하여 소프트웨어 출시 전 반드시 검증 절차를 거쳐야 한다. 특히 과제 결과물에 위탁/용역 등 외부공급을 통해 포함된 소프트웨어가 존재하는 경우에는 해당 부문의 소프트웨어 결과물에 대한 공개SW 라이선스 검증을 필수로 수행하여 라이선스 의무사항의 위반이 없는지 확인하는 것이 중요하다.
294 | 295 | 296 | 수행기관 내부에서 검증기능을 제공하는 조직이 존재하는 경우는 전사 공개SW 관리 정책에서 제시하는 절차에 따라 라이선스 검증이 필요하며, 수행기관 내부에 별도의 검증기능을 제공하는 조직이 존재하지 않는 경우는 카카오 올리브, Fossa, FOSSology, SW360, FOSSID, Black Duck 등의 서비스를 이용하여 개발한 소프트웨어의 라이선스를 직접 검증해 볼 수도 있다. 297 | - URL : https://olive.kakao.com/ 298 | - URL : https://fossa.com/ 299 | - URL : https://fossid.com/ 300 | - URL : https://olive.kakao.com/ 301 | 302 |
303 | 304 | `참고. 관련 서비스 예시` 305 | ### 카카오 올리브 서비스 이용 절차 (https://olive.kakao.com/) 306 | 1. Project 추가
307 | Github 계정의 public repository 혹은 private repository를 추가합니다. 308 | 2. Scan 시작하기
309 | Project 를 분석하여 Dependency 를 식별하고 확인된 Component 를 자동 Mapping 합니다. 310 | 3. Component 확인
311 | 분석된 Dependency 와 Component 를 확인하고 Mapping 합니다. 312 | 4. License 확인
313 | Component 의 License 의무사항을 확인하고 이슈를 해결합니다. 314 | 5. Report 확인
315 | 검증 내역, 체크리스트, 고지문 미리보기가 제공됩니다. 316 | 6. 검증 완료(Complete)
317 | 'Complete' 버튼을 눌러 검증을 완료하고 (참고용)고지문을 다운로드할 수 있습니다. 318 | 319 |

그림 22. 카카오 올리브 라이선스 검증 서비스


320 | 321 | 만약 자체 라이선스 검증이 아니라 외부 기관을 통해서 검증받고 싶은 경우에는 정보통신산업진흥원(NIPA)에서 제공하는 라이선스 검증서비스를 이용하여 공개SW 연구개발과제의 라이선스 준수를 사전에 점검하고 조치할 수 있으니 이를 활용하는 것이 좋다.
322 |
323 | 정보통신산업진흥원(NIPA)에서 제공하는 라이선스 검증서비스의 신청 정보는 다음과 같다. 324 | - 오픈업(OpenUP) 센터 (오픈소스SW 통합지원센터, https://www.oss.kr) 325 | - 공개SW R&D, 라이선스 등 공개SW 컨설팅 지원 (02-561-0951 / support@oss.kr) 326 | - 공개SW 라이선스/보안 검증 지원 (02-561-0952 / license@oss.kr) 327 | 328 |

그림 23. 정보통신산업진흥원의 라이선스 검증 서비스


329 | 330 | ## 라. 공개SW R&D 과제의 보안 취약점 검사 331 | 공개SW 연구개발과제는 직접 개발한 소스 코드와 외부의 공개SW를 활용한 소스 코드가 함께 사용되어 외부로 배포되는 특징 때문에 보안 취약점에 대한 검사를 출시 시점에 1회 검사로 끝나는 방식이 아니라, 개발자의 개발환경부터 시작하여 소스 코드 저장소와 연동된 보안 취약점 검사 서비스를 연계하여 상시 보안 취약점이 검토되도록 다음과 같이 구성해야 한다.
332 | 333 | 개발자의 통합개발도구 플러그인을 이용하여 먼저 보안 취약점을 검사하고, 소스 코드 저장소에 업로드되면 다시 지속적 통합 환경에서 검사를 수행하고 출시 전 검사를 다시 수행해서 소프트웨어의 보안 취약점을 검사하는 방식을 의미한다. 334 | 335 | 336 | 그림 24. 공개SW 연구개발과제의 보안 검증 방식(end-ro-end approch) 337 | 338 |

그림 24. 공개SW 연구개발과제의 보안 검증 방식(end-ro-end approch)


339 | 340 | 깃허브에서는 Security 메뉴로 포함된 외부 라이브러리의 보안 취약점에 대한 검사와 소스 코드의 보안 취약점에 검사를 자동으로 수행할 수 있도록 쉽게 구축할 수 있으므로 이를 활용하는 것이 좋다. 341 | 342 |

그림 25. 깃허브 소스 코드 정적 보안 검사 서비스


343 | 344 | 345 | --- 346 | 347 | 11) https://github.com/TabbycatDebate/tabbycat [return](#part2_2_11)
348 | 12) http://www.the-pr.co.kr/news/articleView.html?idxno=43080 [return](#part2_2_12)
349 | 350 | 351 | 352 | -------------------------------------------------------------------------------- /part2/02/06.md: -------------------------------------------------------------------------------- 1 | # 6. 공개SW R&D 과제의 커뮤니티 관리 2 | 3 | ## 가. 공개SW 커뮤니티의 이해 4 | 커뮤니티를 기반으로 형성되는 소프트웨어 개발에는 소프트웨어 릴리즈를 위한 활동을 중심으로 형성되는 개발자 (공개SW 프로젝트) 커뮤니티와 공개된 소프트웨어에 대한 테스트, 버그에 대한 피드백, 신규요구사항, 의견제시 등을 중심으로 형성되는 사용자 커뮤니티가 존재하며, 이 두 커뮤니티의 상호 작용으로 지속적인 발전을 도모할 수 있다.[13](#footnote13) 5 | 6 | 일반적으로 공개SW 프로젝트의 커뮤니티 내 역할 카테고리를 설명하는 데 사용하는 모델은 월트 스카치(Walt Scacchi)의 양파 모델[14](#footnote14)이 사용된다. 커뮤니티에 투자를 많이 하고 가장 적극적인 역할은 가운데 있고, 양파 껍질 바깥쪽에서 일할수록 활동과 투자 수준이 줄어드는 구조이며 거의 모든 커뮤니티에는 다음과 같은 특징이 있다. 7 | - 개발 자원의 지리적 분포 8 | - 분산된 의사결정 기능 9 | - 개발 및 의사결정의 투명성 10 | - 지속적인 가치 있는 기여를 통해 영향력을 얻는 능력주의[15](#footnote15) 11 | 12 |

그림 26. 공개SW 소프트웨어 커뮤니티 구성원의 역할


13 | 14 | 가장 중심에 있는 핵심 개발자는 프로젝트의 창시자 또는 핵심 개발자로 프로젝트의 최종 결정권을 보유한다. 이 사람들은 대개 프로젝트에서 가장 경험이 많은 실력자이며 수는 많지 않지만, 이들은 모든 커뮤니티 구성원을 지도하거나 멘토링을 하는 사람들이다. 이 사람들은 커뮤니티의 소스 코드 주 저장소에 외부 참여자의 기여 결과물을 병합하도록 승인하는 커밋 비트 권한을 가지고 있으며 가장 큰 책임을 맡고 있다. 이 핵심 기여자가 커뮤니티 참여자에게 조언이나 피드백을 준다면 그것은 매우 주의를 기울여야 하는 일을 의미한다.
15 | 16 | 커뮤니티 관리자는 커뮤니티가 외부 커뮤니티 또는 기업과 협력이 필요한 경우 핵심 개발자와 협의를 거쳐 필요한 의사결정과 실행을 담당한다. 이 사람들은 프로젝트의 지속성을 담보하는 파트너들을 발굴하고 프로젝트가 다양한 분야에서 활용될 수 있도록 홍보를 하는 등 비즈니스 관점에서 매우 중요한 역할이다. 프로젝트 관리자는 커뮤니티 내부에 다수의 프로젝트가 있는 경우 각각의 프로젝트를 집중적으로 관리하는 사람들이다. 리눅스 재단, 오픈스택 재단, 아파치 재단 등 단일 프로젝트가 아닌 다수의 프로젝트가 활성화된 대규모의 공개SW 커뮤니티는 개별 프로젝트의 관리를 집중할 수 있는 프로젝트 관리자를 통해 커뮤니티 참여자들과 소통한다.
17 |
18 | 개발자는 일반적인 기여자이다. 이 사람들은 프로젝트에 어느 정도 정기적인 기여를 제공하고 대부분의 토론에 꽤 활발하게 참여한다. 다른 사람들이 한 기여를 검토하는 데 협력하기도 하며 신입 기여자들에게 멘토링을 제공하기도 한다.
19 | 20 | 능동적 사용자는 프로젝트의 적극적 사용자들로 신입 기여자의 후보가 되는 그룹이다. 프로젝트의 결과물을 주변에 적극적으로 홍보하며 자신도 항상 프로젝트 결과물을 사용하면서 발견한 버그를 공유하고, 이 중 일부는 일정한 시간과 연습을 거친 후 프로젝트의 신입 기여자가 된다. 일반 사용자의 질문에 대한 답변을 적극적으로 하며 사람들이 커뮤니티에 잘 정착할 수 있도록 지원하는 중요한 역할을 한다. 이 사람들은 프로젝트에 도움이 되는 귀중한 피드백, 버그 보고, 기능에 대한 아이디어를 계속 제공하며 프로젝트를 지탱하는 가장 중요한 원동력이다.
21 | 22 | 가장 바깥쪽의 계층은 수동적 사용자들이다. 개발자나 사용자의 입장으로 적극적 참여는 하지 않지만, 프로젝트를 관심 있게 지켜보고 응원하는 사람들로 비정기적인 피드백을 제공한다.
23 | 24 | 수행자는 공개SW 연구개발과제의 결과물을 공개한다고 하더라도 여기에서 그치는 것이 아니라 결과물 활용 확산을 위해서 이러한 공개SW 커뮤니티의 구조를 이해하고 커뮤니티 기반의 관리 및 지원 체계구축을 위한 노력을 지속하는 것이 필요하다.
25 | 26 | 과제와 관련한 국내외 커뮤니티가 이미 활성화되어 있는 경우에는 새로운 커뮤니티를 만드는 것 보다 기존의 활성화 된 커뮤니티 일원으로 참여하여 활동하는 것이 좋은 접근이다. 만약 공개SW 연구개발과제와 관련한 커뮤니티가 없어서 신규로 결과물 활용을 위한 기반으로 조성하기로 계획했다면 다음과 같은 준비가 필요하다. 27 |

28 | 29 | ## 나. 커뮤니티 거버넌스 30 | 커뮤니티는 자발적인 참여와 기여가 핵심 원동력이 되는 구조이므로 커뮤니티가 잘 유지되기 위해서는 커뮤니티 참여자를 어떻게 효과적으로 조직해낼 것인지 고민해야 한다. 강제적 규칙이 없는 느슨한 협의로 의사결정이 이루어지는 조직을 어떻게 구성하고 운영해야 하는지, 커뮤니티에서 공개한 소프트웨어를 사용하는 사용자를 어떻게 지원할 수 있는지도 고려해야 한다. 커뮤니티 거버넌스란 커뮤니티 참여자가 수행할 수 있는 역할과 커뮤니티의 참여 방법, 프로젝트 내 의사결정 프로세스를 설명하여 커뮤니티의 참여자들이 혼란으로 빠져나가는 것을 방지하는 사회적 구조를 의미한다.[16](#footnote16)
31 |
32 | 공개SW 커뮤니티 거버넌스 모델은 의사결정의 관점에서 보면 한 개인이나 집단이 중앙 집권적인 권한을 갖는 선의의 독재형(benevolent dictatorship) 모델과 참여자들이 분권적인 권한을 가지는 능력 중시형(meritocratic) 모델로 구분할 수 있으며, 기여의 개방성 관점에서 보면 소수 전문가 중심으로 폐쇄적으로 개발한 후 결과물을 공개하는 성당형(cathedral style) 모델과 다수참여자의 아이디어가 자유롭게 교류되면서 소프트웨어가 개발되는 시장형(bazaar style) 모델로 구분할 수 있다.
33 | 34 | 커뮤니티가 성장하면 참여자들의 역할과 책임에 따른 운영조직이 구성되고 커뮤니티 운영조직과 커뮤니티 참여자 간 투명한 합의를 기반으로 커뮤니티 운영이 이루어져야 한다. 이를 위해서 과제 수행자는 다음과 같은 커뮤니티 관리 활동을 예상하여 수행 조직을 구성할 때 각각의 업무를 담당할 수 있는 인적자원의 배치가 사전에 필요하다. 35 | 36 | > 표 11. 공개SW 커뮤니티 관리업무의 예
37 | 38 | | 구 분 | 커뮤니티 관리 활동의 예 | 39 | |:-----:|----------------------| 40 | |프로젝트 관리 | 로드맵, 제품 배포, 요구사항 관리, 추가 기능 개발 및 리뷰 | 41 | |커뮤니티 관리 | 참여자 관리, 의사소통 채널 관리, 포럼, 메일링 리스트, 이벤트 관리 등 | 42 | |라이선스 관리 | 라이선스 관련 법률적 분쟁 협의 및 해결 | 43 | |소프트웨어 개발 |개발, 소스 코드 관리(커밋, PR), 테스트, 할당된 이슈 및 버그 처리, 데모 제공 등 | 44 | |시스템 운영 | 소소 코드 저장소, 자동화 배포 시스템, 이슈 및 버그 관리 시스템, 문서화 도구, 품질 관리 시스템, 공식 웹사이트 등 | 45 | 46 | 연구 수행자는 공개SW 연구과제의 결과물 활용을 위해 커뮤니티를 관리할 적합한 거버넌스 모델을 결정해야 한다. 먼저 구축한 커뮤니티에 참여하고자 하는 외부의 기여자들이 커뮤니티 구성원 그룹의 역할과 책임을 식별하고, 기여자가 되면 지켜야 할 행동 규약이나 기여를 위해 프로젝트에서 준비한 지원이 가능한 채널을 안내하는 문서 등을 작성하여 공유하는 것이 필요하다.
47 | 48 | 일반적인 커뮤니티 거버넌스 문서의 주요 내용은 다음과 같은 항목으로 구성하는 것이 좋다. 49 | 50 |


51 | 52 | 53 | 커뮤니티의 구성 현황에 따라 각각의 커뮤니티 거버넌스 문서는 다르게 구성되나, 일반적인 커뮤니티의 거버넌스를 구성할 때 참고할 수 있는 문서는 다음과 같다. 54 | 55 | - 아파치 재단(Apache Foundation) : http://www.apache.org/foundation/governance/ 56 | - 이클립스 재단(Eclipse Foundation) : https://www.eclipse.org/org/documents/ 57 | - SKT - HANU : https://github.com/openinfradev/community/blob/main/governance/README.md 58 | - 하모니카 – Hamonize : https://github.com/hamonikr/hamonize/wiki/Governance 59 | 60 |
61 | 62 | ## 다. 커뮤니티 구성원의 고려사항 63 | 리눅스 재단(Linux Foundation)의 Todo Group에서 제시하는 공개SW 커뮤니티 참여를 위한 고려사항은 다음과 같다.[17](#footnote17) 64 | 65 | #### 공개SW 커뮤니티 참여를 위한 고려사항 66 | - 작업 중인 내용 전달
67 | 커뮤니티를 위해 작업 중인 내용을 '비공개로' 작업하지 마십시오. '일찍 릴리스, 자주 릴리스'의 조언을 기억하십시오. 일반적으로 커뮤니케이션 채널을 확인하여 계획한 일이 이미 완료되었는지 확인하는 것뿐만 아니라 새로운 기능을 구축하거나 버그를 수정하려는 의도를 표시하여 커뮤니티(및 유지 관리자)가 기여를 수락하는 가장 좋은 방법을 계획하는 데 도움이 될 수 있습니다. 커뮤니티는 귀하가 성공하기를 원하므로 귀하가 기여를 준비할 때 도움을 받는 것이 좋습니다.
68 | 69 | - 사용하는 사람과 자원을 인정
70 | 공개SW에 대한 기여는 대부분 다른 프로젝트의 코드를 포함하고 있습니다. 기여에 사용한 다른 작업/라이브러리/개발을 인정하고 커뮤니티가 전체 프로젝트에 도움이 될 수 있는 이러한 외부 자원도 찾도록 도와주세요. 71 | 72 | - 커뮤니티에 환원
73 | 소스 코드의 명백한 기여 외에도 조직에서 하드웨어 선물을 주선하거나(가능한 경우) 팀을 위한 모임을 주선하거나 단순히 새 구성원을 위한 질문에 답하는 데 시간을 보내는 것과 같이 커뮤니티에 되돌릴 수 있는 다른 방법을 고려하십시오. 소스 코드는 확실히 중요하지만, 진정으로 성공적인 공개SW 프로젝트는 '코드가 아닌' 기여에서도 번창합니다. 74 | 75 | - 출구 전략 계획
76 | 언젠가는 귀하의 조직이 커뮤니티를 종료해야 할 수 있습니다. 커뮤니티에 들어온 것보다 더 나은 상태로 커뮤니티를 떠나도록 노력하십시오. 이를 위해 할 수 있는 몇 가지 간단한 작업은 다음과 같습니다. 77 | + 후임자 또는 코드를 인수할 사람 식별 78 | + 그 후계자를 나머지 커뮤니티에 소개 79 | + 귀하의 퇴장으로 인해 변경해야 할 사항에 대해 계획할 시간을 가질 수 있도록 가능한 한 빨리 커뮤니티에 알리십시오. 80 | + 커뮤니티를 탈퇴하는 때도 귀하의 행동은 귀하 및/또는 귀하의 조직에 반영된다는 점을 기억하십시오. 81 | 82 |
83 | 84 | ## 라. 웹사이트 및 포럼 85 | 공개SW 연구개발과제의 결과물 확산을 위한 커뮤니티를 구축하기 위해서 처음 사용자를 위한 프로젝트의 소개를 담은 공식 웹사이트와 사용자와 개발자의 쉬운 커뮤니케이션이 가능한 게시판 형식의 포럼과 같은 커뮤니티 서비스 구축이 필요하다.
86 |
87 | 수행자는 과제 수행 환경에 따라서 직접 구축형(웹사이트 제작)으로 구성하거나 외부 호스팅 서비스(웹사이트 호스팅, github page 등)를 이용할 수도 있다. 88 | 89 |



90 | 91 | ### 마. 기여자 가이드라인 92 | 공개SW 연구개발과제의 수행자가 커뮤니티를 구축하는 경우, 우선 커뮤니티의 참여자들이 모두 볼 수 있도록 기여자 행동 강령 규약을 정의하고 분쟁이 일어나는 경우 어떻게 처리하는지 사전에 공표되어야 한다. (부록1. 기여자 행동 강령 규약 참고)
93 | 94 | 또한 기여자들이 프로젝트에 기여한 내용에 대하여 라이선스 관련 분쟁이 생기는 경우 어떻게 조치하게 되는지에 대한 내용을 포함한 기여자 라이선스 동의서(부록2. 기여자 라이선스 동의서 참고)를 작성하고 깃헙 액션을 이용하여 기여자가 소스 코드의 기여물 반영을 요청하기 전 단계에서 직접 서명하도록 구성하는 것이 좋다.
95 | 96 | 그리고 과제 수행자는 외부 기여자가 쉽게 과제 결과물에 참여할 수 있도록 기여를 원하는 부문별(개발, 문서화, 테스트 등)로 구분하여 상세한 가이드라인(부록3. 기여자 가이드라인 참고)을 제공하고, 기여에 따른 권한의 변경 및 커뮤니티의 의사결정 방식을 투명하게 공개해야 한다. 97 | 98 |


99 | 100 | - 네이버 공개SW billboard.js 기여자 가이드라인 예 : https://github.com/naver/billboard.js/blob/master/CONTRIBUTING.md 101 | - 카카오 공개SW buffalo 기여자 라이선스 동의서 예 : https://docs.google.com/forms/d/e/1FAIpQLSejX1wS1YCArZ7huZlKpuhWUWhGbLflOU93ZoTZiSR-ZPsm6w/viewform 102 | 103 |
104 | 105 | ### 바. 마일스톤 및 로드맵 공유 106 | 수행자는 외부 참여자가 공개SW 연구개발과제에 참여하는 결정을 할 때 참고할 수 있도록 과제의 향후 마일스톤과 로드맵을 누구나 확인할 수 있도록 공개하는 것이 필요하다.
107 | 108 | 마일스톤 및 로드맵의 작성은 깃허브에서 제공하는 프로젝트 탭의 메뉴를 이용하거나 로드맵을 표시할 수 있는 별도의 문서 도구(Wiki, confluence 등)를 이용할 수도 있다. 109 | 110 |


111 | 112 |
113 | 114 | ## 사. 협력기업 관리 115 | 수행자는 공개SW 연구개발과제의 결과물을 확산할 수 있도록 공개한 소프트웨어를 사용하는 기업, 기술지원을 제공하는 기업, 교육이나 기타 서비스를 제공하는 기업을 커뮤니티의 멤버로 확보하고 참여기업들과 프로젝트가 함께 성장할 수 있도록 지속해서 파트너십을 관리해야 한다. 116 | 이를 위해서 협력기업 확보를 위한 다양한 온 오프라인 행사에 참여해야 하며, 협력기업의 솔루션 및 서비스를 적극적으로 홍보해야 하며, 주기적인 협의체를 운영하면서 협력기업의 비즈니스 전략을 커뮤니티에서 수용하는 태도가 필요하다. 117 | 118 |


119 | 120 |
121 | 122 | ## 아. 지식 재산권 관리 123 | 공개SW 프로젝트는 소프트웨어 저작권으로 지식 재산권을 보호할 수 없으므로 대부분의 공개SW 프로젝트들은 상표권을 이용하여 프로젝트의 재산권을 보호하는 방식을 사용한다. 따라서 협력기업들이 활용할 수 있도록 상표, 로고 등을 준비하고 사용의 범위 및 제약을 규정하여 협력기업과의 관계를 유지하는 것이 중요하다. 124 | - 캐노니컬 재단(우분투)의 지적 재산권 안내문 : https://ubuntu.com/legal/trademarks 125 | 126 |


127 | 128 |
129 | 130 | ## 자. 모니터링 131 | 수행자는 외부 기여자의 참여 독려, 협력기업의 확보 또는 외부 홍보들에 사용할 수 있도록 프로젝트의 다양한 지표를 상시 확인할 수 있는 모니터링 환경을 준비해야 한다. 공개한 프로젝트의 다운로드 수, 커뮤니티 사용자 수, 일일 이슈 수 등의 다양한 지표를 별도의 대시보드로 구성하여 상시 프로젝트의 현황을 확인할 수 있는 체계를 구축하는 것이 좋다. 132 | 133 |


134 |
135 | 136 | ### :notebook: 클라우드바리스타 커뮤니티 사례 137 | 138 | - 클라우드바리스타 커뮤니티의 다양한 통계 정보 제공 139 | 140 | + 저장소별 소스코드 다운로드 수 및 기여자 현황 141 |


142 | 143 | + 소스코드 복제(Clone) 및 방문자 통계 정보 제공 144 |


145 | 146 |
147 | 148 | ## 차. 홍보 149 | 단순히 결과물을 공개하는 것으로는 공개SW 프로젝트를 지속할 수 없으므로, 수행자는 공개SW 연구개발과제가 커뮤니티를 기반으로 지속할 수 있도록 다양한 채널을 통해서 결과물을 홍보해야 한다.
150 |
151 | 공개SW 커뮤니티를 홍보하기 위하여 페이스북, 슬라이드쉐어, 유튜브 등의 온라인 소셜 네트워크와 세미나 및 밋업 등 오프라인 행사를 적극적으로 개최하고 국내외 컨퍼런스에 참여하여 공개한 결과물을 소개하거나 메일링 리스트를 통해서 결과물을 홍보할 수도 있다.
152 |
153 | 과제 수행자는 이러한 결과물 홍보 과정에서 구축된 커뮤니티와 협력 가능한 참여기업을 발굴해야 하며, 프로젝트의 지속을 위하여 커뮤니티의 참여기업과 후원 관계를 형성하여 자생할 수 있는 커뮤니티 운영조직을 구성하거나, 직접 커뮤니티의 유지관리가 어려운 경우에는 외부의 공개SW 프로젝트를 관리하는 재단 또는 협회 등과 협력을 통해 유지관리 체계를 구축할 수도 있다. 154 | 155 |


156 | 157 | - 국내 공개SW 관련 단체 : 한국공개소프트웨어협회, 오픈소스소프트웨어재단 158 | - 해외 공개SW 재단 목록 : https://opensource.com/resources/organizations 159 | 160 |
161 | 162 | ### :notebook: 클라우드바리스타 커뮤니티 사례 163 | - 클라우드바리스타 커뮤니티에서는 자체 행사 개최, 타 행사 참여를 통하여 홍보를 수행하며, 개발 결과물의 공유를 위한 SNS 채널 확보 164 | 165 | 166 | - 연 2회(6월, 11월) 커뮤니티 자체 컨퍼런스 개최 167 | + 커뮤니티의 홍보 및 개발 소스코드의 주요기술을 소개 168 |


169 | 170 | - 국내 공개SW 관련 컨퍼런스 및 전시회 참가 171 | - 연중 4~6회, 국내 주요 행사의 세션 발표 및 결과물 전시
172 | (전시 : 소프트웨이브, 대한민국 과학기술대전, 행사 : KRnet, 한중일 공개SW활성화 포럼, OpenInfra Community Day, KCC 등) 173 | - 개발결과물의 공유 채널 174 | + 자료에 최적화된 소통 채널을 통한 정보의 공유 175 |


176 |
177 | 178 | ## 카. 문서화 179 | 문서화는 공개SW 프로젝트 접근성을 향상시킬 수 있는 수단으로 새로운 개발자 및 사용자의 유입을 촉진할 수 있는 필수 조건이다. 특히 SW 기술이 고도화됨에 따라 복잡한 SW의 이해를 높기 위해 상세한 매뉴얼과 주석은 과거보다 중요해지고 있다.
180 |
181 | 예를 들어, 공개SW 프로젝트에 대한 개요, 설치 방법, 사용 방법에 대한 정보를 상세하게 제공하면 사용자는 자신의 목적에 맞는지 빠르게 확인하고 쉽게 설치하여 사용할 수 있게 된다. 소스 코드에 상세한 주석이 제공된다면, 새로운 개발자가 해당 공개SW의 동작 방식과 소스 코드 작성 의도를 쉽게 파악하여 개선 코드와 새로운 아이디어를 제안할 수 있도록 한다.
182 |
183 | 하지만, 많은 공개SW 개발자들이 공개SW 프로젝트의 문서화에 소홀하기 때문에 공개SW 프로젝트 참여의 주요 어려움으로 부족한 정보와 부정확한 문서가 자주 언급되고 있다. 따라서, LICENSE 문서를 통해 공개SW 라이선스 정보를 명확하게 제공해야 하고, README 문서에서 프로젝트에 대한 개요, 설치 옵션 및 방법, 프로젝트 구성 정보, 사용 방법, 추가 정보 등을 제공할 필요가 있으며, 별도의 상세 매뉴얼을 통해 공개SW의 사용 방법을 친절하게 소개해야 한다. 또한, 소스 코드 개발 시 상세한 주석을 제공하여 SW의 동작 방식, 작성 의도를 명확하게 하고 소스 코드 버전 관리에도 도움을 줄 수 있다.
184 |
185 | 이러한 공개SW 문서화는 홈페이지·포털 구축을 통해 정보를 제공하는 대규모 프로젝트의 문서화 방식보다는 비용적인 부담이 크게 적기 때문에 소규모 프로젝트에서 효율적일 수 있다. 또한, 대규모 프로젝트의 경우에는 사용자를 위한 문서와 개발자를 위하여 프로젝트를 구성하는 하위 프로젝트 단위의 정보를 체계적으로 구성하여 웹사이트 내 별도의 문서로 제공하여 커뮤니티 사용자와 개발자의 참여에 도움을 줄 수 있다. 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 |
고려사항구성 예
•가독성 있는 프로젝트 개요와 프로젝트 구성 정보
•정확한 설치 방법과 옵션 및 의존성 정보
•정확한 라이선스 정보
•상세한 사용 방법 및 매뉴얼
•규칙화된 상세한 주석

197 | 198 | --- 199 | 200 | 13) TTA 공개SW 소프트웨어 연계 ICT 표준화 전략, 2020 [return](#part2_2_13)
201 | 14) https://www.researchgate.net/figure/An-onion-diagram-representing-a-generic-OSSDproject-organizational-hierarchy_fig1_4251362 [return](#part2_2_14)
202 | 15) https://github.com/todogroup/ospo101 [return](#part2_2_15)
203 | 16) 개방형 연구개발을 위한 공개소프트웨어 커뮤니티 거버넌스 지침(한국정보통신협회, TTAK.KO-11.0257) [return](#part2_2_16)
204 | 17) https://github.com/todogroup/ospo101 [return](#part2_2_17)
205 | 206 | 207 | -------------------------------------------------------------------------------- /part2/03/annex1.md: -------------------------------------------------------------------------------- 1 | # 부록 1 기여자 행동 강령 규약의 예 (하모니카) 2 | 3 | ## 기여자 행동 강령 규약 4 | 5 | ### 서약 6 | 개방적이고 친근한 환경 조성을 위해, 기여자와 유지자는 프로젝트와 커뮤니티에서 연령, 신체 크기, 장애, 민족성, 성 정체성과 표현, 경력, 국적, 외모, 인종, 종교 또는 성적 정체성과 지향과 관계없이 모두에게 차별 없이 참여할 것을 서약합니다. 7 | 8 |
9 | 10 | ### 표준 11 | 12 | **긍정적인 환경을 조성하기 위해 기여자가 해야 할 행동은 다음과 같습니다:** 13 | - 소외하지 않고 배려하는 언어 사용 14 | - 서로 다른 경험과 관점 존중 15 | - 열린 마음으로 건설적인 비판을 수용 16 | - 커뮤니티에 가장 최선이 무엇인지에 주력 17 | - 다른 커뮤니티 구성원들에 대한 공감 표현
18 |
19 | 20 | **긍정적인 환경을 조성하기 위해 기여자가 피해야 할 행동은 다음과 같습니다** 21 |
22 | 23 | - 성적인 언어와 이미지 사용, 다른 사용자가 원치 않는 성적 관심이나 접근 24 | - 소모적인 논쟁, 모욕적이거나 비하하는 댓글과 개인적 또는 정치적인 공격 25 | - 공개적이거나 개인적인 괴롭힘 26 | - 동의가 없이 집주소 또는 전자주소 등의 개인 정보의 공개 27 | - 부적절한 것으로 간주할 수 있는 다른 행위 28 | 29 |
30 | 31 | ### 책임 32 | 프로젝트 유지자는 허용되는 행동의 기준을 명확히 해야 할 책임이 있습니다. 또한, 피해야 할 행동에 대해 적당하고 공정한 시정 조처를 할 것입니다.
33 |
34 | 프로젝트 유지자는 이 행동 강령을 따르지 않은 댓글, 커밋, 코드, 위키 편집, 이슈와 그 외 다른 기여를 삭제, 수정 또는 거부할 권리와 책임이 있습니다. 또한, 부적당하거나 험악하거나 공격적이거나 해롭다고 생각하는 다른 행동을 한 기여자를 일시적 또는 영구적으로 퇴장시킬 수 있습니다. 35 | 36 |
37 | 38 | ### 범위 39 | 이 행동 강령은 프로젝트 영역에 적용되며, 프로젝트 또는 커뮤니티를 대표할 경우 공개 영역에도 적용됩니다. 프로젝트 또는 커뮤니티 대표의 예로는 공식 프로젝트 이메일 주소, 공식 소셜 미디어 계정사용 또는 온/오프라인 이벤트에서 임명된 대표자의 활동이 있습니다. 프로젝트의 대표는 프로젝트 유지자에 40 | 의해 더 정의되고 명확히 될 것 입니다. 41 | 42 |
43 | 44 | ### 강제 45 | 모욕적인, 괴롭힘 또는 기타 하지 말아야 할 행동을 발견하면 root@hamonikr.org 을 통해 프로젝트팀에 보고 해 주세요. 모든 불만 사항은 검토하고 조사한 뒤 상황에 따라 필요하고 적절하다고 생각되는 응답을 할 것입니다. 프로젝트팀은 사건의 보고자와 관련한 비밀을 유지할 의무가 있습니다. 구체적인 시행 정책의 자세한 사항은 별도로 게시할 수 있습니다.
46 |
47 | 행동 강령을 따르지 않거나 강제하지 않은 프로젝트 유지자는 프로젝트 리더의 다른 구성원의 결정에 따라 일시적 또는 영구적인 제재를 받을 수 있습니다. 48 | 49 |
50 | 51 | ### 참고 52 | 이 행동 강령은 기여자 규약 의 1.4 버전을 변형하였습니다. 그 내용은 https://www.contributorcovenant.org/ko/version/1/4/code-of-conduct.html 에서 인할 수 있습니다. -------------------------------------------------------------------------------- /part2/03/annex2.md: -------------------------------------------------------------------------------- 1 | # 부록 2 기여자 라이선스 동의서 예 2 | 3 | ## 하모니카(HamoniKR) 프로젝트 개인 기여자 라이선스 계약 4 | 5 | 어떤 개인이나 단체의 기여와 함께 부여된 지식 재산권 라이선스를 명확히 하기 위해 HamoniKR 프로젝트는 각 기여자가 서명한 파일에 기여자 라이선스 계약 ("CLA")을 가지고 있어야 하며 이는 아래 라이선스 조건에 대한 동의를 나타냅니다. 이 사용권은 기여자로서의 보호와 HamoniKR 프로젝트의 보호를 위한 것으로 다른 목적으로 자신의 기여물을 사용할 권리를 변경하지 않습니다.
6 |
7 | 귀하는 하모니카(HamoniKR)에 제출된 귀하의 현재 및 향후 기여에 대해 다음 약관을 수락하고 이에 동의합니다. 여기에서 하모니카(HamoniKR)가 배포한 소프트웨어 사용자에게 부여된 라이선스를 제외하고 귀하는 귀하의 기여에 대한 모든 권리, 소유권 및 이권을 보유합니다. 8 | 9 |
10 | 11 | ### 1.정의 12 | "기여자"는 하모니카(HamoniKR)와 본 계약을 체결하는 저작권 소유자가 승인한 저작권 소유자 또는 법인을 의미합니다. 법인의 경우 기여하는 법인 및 해당 법인을 통제하거나 공동 통제하는 기타 모든 법인은 단일 기여자로 간주합니다. 이 정의의 목적상 "통제"는 (i)계약 또는 기타 방식으로 해당 법인의 지시 또는 관리를 유발하는 직간접적 권한 또는 (ii)50% 또는 더 많은 발행 주식, 또는 (iii)그러한 법인의 실 소유권을 의미합니다.
13 |
14 | '기여물'은 하모니카(HamoniKR)가 소유하거나 관리하는 제품('저작물')에 포함하거나 문서화하기 위해 귀하가 의도적으로 하모니카(HamoniKR)에 제출한 기존 저작물에 대한 수정 또는 추가를 포함한 원본 저작물을 의미합니다.
15 |
16 | '제출됨'은 전자 메일, 소스 코드 제어 시스템 및 문제 추적 시스템에 대한 커뮤니케이션을 포함하되 이에 국한되지 않는 하모니카(HamoniKR)에 전송되는 모든 형태의 전자, 구두 또는 서면 커뮤니케이션을 의미합니다.
17 |
18 | 저작물을 논의하고 개선할 목적으로 하모니카(HamoniKR)에서 대신하여 관리하지만, 귀하가 "기여물이 아님"으로 눈에 띄게 표시되거나 서면으로 지정한 커뮤니케이션은 제외됩니다. 19 | 20 |
21 | 22 | ### 2. 저작권 라이선스 부여 23 | 본 계약의 이용 약관에 따라 귀하는 귀하의 기여물 및 이러한 파생 저작물에 대하여 하모니카(HamoniKR) 에서 배포한 소프트웨어의 사용자에게 다음의 파생 저작물을 복제하고 준비할 수 있는 영구적이고 전 세계적이며 비독점적이며 무료이며 기술특허사용료가 없고 취소할 수 없으며 공개적으로 표시하고, 24 | 공개적으로 수행하고, 제 라이선스를 부여할 수 있는 저작권 라이선스를 부여합니다. 25 | 26 |
27 | 28 | ### 3. 특허 라이선스 부여 29 | 본 계약의 이용 약관에 따라 귀하는 하모니카(HamoniKR)에서 배포한 소프트웨어의 사용자에게 영구적이고 전 세계적으로 비독점적이며 무료이며 기술특허사용료가 없고 취소할 수 없는 저작물을 제작, 사용, 판매, 수입 및 기타 방식으로 양도할 수 있는 라이선스를 부여합니다.
30 |
31 | 어떤 단체가 귀하의 기여 또는 귀하가 기여한 저작물이 직접 또는 기여한 특허 침해를 구성한다고 주장하는 경우 이 특허 라이선스가 부여되며 해당 기부 또는 저작물은 본 계약에 따라 해당 법인에 대한 해당 소송이 제기된 날짜에 종료됩니다.
32 |
33 | 귀하의 고용주가 귀하의 기여를 포함하여 귀하가 만든 지식 재산에 대한 권리를 보유하고 있는 경우 귀하는 해당 고용주를 대신하여 기여할 수 있는 권한을 받았거나 귀하의 고용주가 하모니카(HamoniKR)에 대한 귀하의 기여에 대해 그러한 권리를 포기했음을 진술합니다. 34 | 35 |
36 | 37 | ### 4. 귀하는 귀하의 각 기여가 귀하의 원래 창작물임을 진술합니다.(다른 사람을 대신하여 제출하는 경우 섹션 6 참조). 귀하는 귀하의 기여 제출물에 귀하가 개인적으로 알고 귀하의 기여의 일부와 관련된 제3자 라이선스 또는 기타 제한(관련 특허 및 상표를 포함하되 이에 국한되지 않음)에 대한 완전한 세부 사항이 포함됨을 진술합니다. 38 | 39 |
40 | 41 | ### 5. 귀하가 지원을 제공하고자 하는 경우를 제외하고 귀하는 귀하의 기여에 대한 지원을 제공할 것으로 기대되지 않습니다. 무료로 또는 유료로 지원을 제공하거나 전혀 제공하지 않을 수 있습니다. 42 | 43 |
44 | 45 | ### 6. 귀하의 원본 창작물이 아닌 저작물을 제출하려는 경우, 출처 및 라이선스 또는 기타 제한 사항(관련 특허를 포함하되 이에 국한되지 않음)에 대한 전체 세부 정보를 식별하여 제공물과 별도로 저작물을 "제3자를 대신하여 제출 : [여기에 이름이 지정됨]" 으로 눈에 띄게 표시하여 하모니카(HamoniKR)에 제출할 수 있습니다. 46 | 47 |
48 | 49 | ### 7. 귀하는 이러한 표현이 어떤 측면에서든 부정확할 수 있다는 사실을 알게 된 시점에 사실이나 상황을 하모니카(HamoniKR)에 알리는 데 동의합니다. 50 | -------------------------------------------------------------------------------- /part2/03/annex3.md: -------------------------------------------------------------------------------- 1 | # 부록 3 기여자 가이드라인 문서 예 2 | ## Contributing to Hamonize 환영합니다! 3 | 먼저 시간을 내서 프로젝트에 참여해 주셔서 감사합니다.
4 | 이 문서는 프로젝트 참여 방법에 대한 가이드라인입니다.
5 | 언제든지 저희에게 여러분의 아이디어를 PR 요청으로 문서변경을 제안해주세요.
6 |
7 | 8 | + 소스 코드 저장소 9 | - 하모나이즈 저장소 : https://github.com/hamonikr/hamonize 10 | - 하모니카 프로젝트 깃헙 : https://github.com/hamonikr/
11 |
12 | 13 | + 개선 제안 14 | Hamonize 프로젝트에 제안하려는 경우 최대한 상세하게 이슈에 등록해 주세요.
15 | 이슈를 작성하기 전에 이미 요청이 있는지 이슈 목록을 확인해주세요.
16 |
17 | 18 | + 버그 보고 19 | 버그 발견 시 이슈에 BUG 라벨로 정보를 제공해주세요.
20 | 최대한 상세하게 작성해주시고 스크린 캡처를 첨부해주시면 더 좋습니다.
21 |
22 | 23 | + 기여 가능한 부분 24 | - 개발 25 | - 기획 / 퍼블리싱 26 | - 문서 27 | * 참여 부분을 저희에게 알려주세요. 더욱 자세하게 알려드립니다.
28 | 이슈 또는 Slack 채널을 이용해 주세요.
29 | #hamonize 방 : 누구나 참여할 수 있는 커뮤니티 채널
30 | 31 |
32 | 33 | - 컨트리뷰션 하는 방법
34 | 1. Fork
35 | Upstream Repository를 자신의 GitHub 계정으로 Fork 합니다.
36 |
37 | 2. Clone
38 | Fork한 Repository를 자신의 Local working directory로 Clone 합니다.
39 | ``` 40 | $ mkdir -p $working_dir 41 | $ cd $working_dir 42 | $ git clone https://github.com/hamonikr/hamonize.git 43 | ``` 44 | 3. Create a branch
45 | 개발용 branch를 생성하여 해당 branch에서 작업 및 테스트를 수행합니다.
46 | ``` 47 | $ cd hamonize 48 | $ git checkout -b myfeature 49 | ``` 50 | 4. Commit
51 | 수정 사항을 commit 합니다.
52 | ``` 53 | $ git commit -a -m '[commit message]' 54 | ``` 55 | 5. Push
56 | 수정 사항을 자신의 GitHub Repository에 Push 합니다.
57 | ``` 58 | git push origin myfeature 59 | ``` 60 | 6. 빌드 테스트
61 | travis-ci 를 통해 수정한 소스 코드가 정상적으로 빌드 되는 것을 확인해주세요.
62 | 1) travis-ci.com 에 접속, github 계정으로 로그인
63 | 2) 포크한 hamonize 저장소 활성화
64 | 3) 환경변수 GITHUB_TOKEN 등록
65 | 4) release 브랜치를 작업한 브랜치의 상태로 업데이트
66 | 5) travis-ci에서 이뤄진 빌드의 상태가 'passed' 인 것을 확인
67 | 7. Pull Request 생성하기
68 | 자신의 Github Repository에서 수정 및 테스트가 완료되면, New pull request 버튼을 클릭해 Pull Request를 생성합니다.
Pull Request를 생성할 때, comment로 해당 이슈가 논의된 위치와 수정된 사항에 대한 설명을 포함해 주세요. 69 | 70 | 8. CLA
71 | 생성한 Pull Request에 Contributor License Agreement 사인 방법을 안내하는 댓글이 생성됩니다.
안내에 따라 CLA 사인을 완료하면, Upstream Repository의 관리자가 요청된 Pull Request를 검토할 것입니다. 72 | 9. Feedback
73 | 프로젝트 관리자가 Pull Request를 검토한 후, 수정을 요청하거나, 거절하거나, 수락할 것입니다. -------------------------------------------------------------------------------- /part2/03/faq.md: -------------------------------------------------------------------------------- 1 | # 3장 자주 묻는 질문과 답변(FAQ) 2 | 3 | + ### Q1 왜 공개SW 개발방식으로 개발하는 것이 좋은가요? 4 | 공개SW 개발방식은 기존의 내부 자원으로 수행하던 연구개발 방식과 비교하면 다수의 (고객, 개발자, 경쟁사, 협력사 등) 참여를 통해 개발 속도 향상, 개발 비용 절감, 빠른 고객 요구사항 반영, 잠재 고객 확보, 선제적 개발자 확보, 외부 사용자에 의한 품질 검증, 생태계 사전 조성 등의 많은 장점이 있는 방식입니다.
5 |
6 | 글로벌 산업에서 두각을 나타내고 있는 구글, MS, 아마존 같은 기업들도 안드로이드, 텐서플로우, vscode, 쿠버네티스 같은 공개SW 연구개발 프로젝트를 공개하고 이를 기반으로 시장을 선도하고 있으며, 대표적인 공개SW 프로젝트 저장소인 깃허브의 사용자 수와 조직의 수는 연 평균 80% 이상 성장하고 있습니다. [18](#footnote18) 7 | 8 |
9 | 10 | + ### Q2 공개SW 개발방식과 기존 개발방식의 차이점은 무엇인가요? 11 | 보편적으로 공개SW 개발방식은 외부 개발자들의 참여를 허용하기 위해 깃허브와 같은 공개된 소스 코드저장소에 소프트웨어 개발과정을 공개하면서 개발이 진행됩니다. 기존의 개발방식은 일부의 개발자들에 의해 통제되어 소수의 협력으로 개발하게 되지만, 공개SW 개발방식은 누구나 참여할 수 있도록 개발과정이 공개되어 수행하게 됩니다.
12 |
13 | 공개SW 개발방식은 다수의 외부 참여를 통해 다양한 아이디어를 수용할 수 있고 이를 기반으로 소프트웨어의 문제해결 시간 단축과 많은 사용자에 의한 소프트웨어 품질에 대한 검증을 효율적으로 수행할 수 있습니다. 14 | 15 |
16 | 17 | + ### Q3 공개SW R&D를 수행하게 되면 반드시 전체 프로그램 소스 코드를 공개해야 하는지요? 18 | 그렇지 않습니다. 기존 공개SW 프로젝트들도 전체 소스 코드를 공개하는 경우가 아닌 특정 라이브러리, 모듈 등을 공개하는 경우도 있습니다. 또한 동일한 SW 중 일부 기능을 제공하는 소스 코드는 공개해서 자유롭게 사용하도록 허용하면서도 일부 기능은 상용SW로 판매하는 경우도 있습니다. 따라서, 공개SW R&D의 추진전략에 따라 소스 코드 공개 범위를 검토할 수 있습니다. 19 | 20 |
21 | 22 | + ### Q4 공개SW R&D 결과물에 적용할 공개SW 라이선스 선택의 기준은 무엇인가요? 23 | 공개SW R&D 결과물에 적용할 라이선스 선택기준은 추진전략입니다. 추진전략이 다양한 산업과 사용자들의 자유로운 사용을 장려하기 위한 경우는 될 수 있으면 제약조건이 없는 퍼미시브(허용적) 라이선스 계열을 적용하는 것이 권장되고, 공개SW R&D 결과물을 공개 후 특정 기업이나 개발자들의 상용/독점 사용을 제한하고 싶은 경우는 스트롱 카피레프트 라이선스 계열을 적용하는 것을 권장합니다. 공개SW 라이선스에 대한 보다 자세한 내용은 연구계획 수립을 위한 가이드라인 편에서 참고하실 수 있습니다. 24 | 25 |
26 | 27 | + ### Q5 공개SW 연구개발 과제의 성과지표는 어떻게 구성해야 하나요? 28 | 공개SW 연구개발과제의 성과지표는 공개한 프로젝트의 성숙도를 표현할 수 있는 다양한 지표를 선정하여 관리할 수 있습니다. 소스 코드 저장소의 활성화 정도를 표시하는 저장소, 스타, 커밋(commit), 포크(fork), 이슈(Issue), 풀리퀘스트(Pull Request) 등의 지표와 커뮤니티의 활동성을 대변하는 기여자 수, 커뮤니티 사용자, 홍보 채널, 각종 행사 참여 수, 기술 문서 등의 지표, 그리고 결과물의 활용성을 의미하는 기술이전, 적용사례, 파트너 참여기업 수 등의 지표도 사용할 수 있습니다.
29 |
30 | 이러한 다양한 지표를 이용하여 소스 코드 저장소의 README 파일에 배지 이미지 형식으로 가시화하여 구성하면 프로젝트의 사용자에게 신뢰할 수 있는 프로젝트로 보일 수 있으므로 적극적으로 활용하는 것이 좋습니다. 31 | 32 |
33 | 34 | + ### Q6 공개SW 담당자로서 필요한 역량은 어떻게 준비해야 하나요? 35 | 한국정보통신기술협회의 표준으로 배포 중인 공개소프트웨어 기반 개방형 혁신 연구개발 역량 성숙도 모델 (TTAK.KO-11.0246)에 따르면 공개SW 연구개발과제 수행을 위해 필요한 역량은 다음과 같습니다. 36 | * 공개SW 기반의 비즈니스 전략 37 | * 공개SW 연구개발 거버넌스 정책과 조직의 구성 38 | * 공개SW 프로젝트의 성숙도 평가 39 | * 공개SW가 포함되는 소프트웨어 공급망 관리 40 | * 공개SW 커뮤니티 거버넌스 41 | * 공개SW 개발을 위한 개발환경 42 | * 공개SW 연구개발에 적합한 성과지표 관리 43 |
44 | 45 | 정보통신산업진흥원(NIPA)의 오픈소스 소프트웨어 통합지원센터에서는 공개SW 교육지원사업으로 대상별 맞춤형 교육을 운영하고 있으니 이를 활용하여 과제 수행에 필요한 역량을 사전에 준비할 수 있습니다. 46 | 47 |
48 | 49 | + ### Q7 공개SW 개발과정을 미리 학습하려면 어떻게 하는 것이 좋을까요? 50 | 공개SW 프로젝트마다 각기 다른 개발문화와 절차를 가지고 운영되기 때문에 과제 수행에 참여하는 연구원은 다양한 공개SW 프로젝트에 참여하여 자신의 소스 코드를 다른 프로젝트에 기여 해보는 과정을 통해 공개 SW 개발방식을 배울 수 있습니다. 만약 어떻게 공개SW 프로젝트에 기여하는지 모르는 경우는 다음과 같은 문서를 참고할 수 있습니다. 51 | * 네이버 – 컨트리뷰션 시작하기 : https://naver.github.io/OpenSourceGuide/book/BetterContribution/why-contribute-to-open-source.html 52 | * 깃허브 – 공개SW 가이드 : https://2korean.github.io/open-source-guide/how-to-contribute/ 53 | * SKT – 공개SW 기여하기 : https://sktelecom.github.io/guide/contribute/ 54 | 55 | 그리고 정보통신산업진흥원(NIPA)의 오픈소스 소프트웨어 통합지원센터에서는 공개SW 컨트리뷰션 아카데미를 운영하여 공개SW 개발방식을 실제 공개SW 프로젝트의 경험자들과 함께 배워볼 수 있도록 제공하고 있으므로 공개SW 개발방식을 학습하기 위해 이 과정을 활용하는 것도 좋습니다. 56 | 57 | 58 | 59 | 65 | 66 |
컨트리뷰션 아카데미
URL : https://www.oss.kr/contribution_academy

60 | 언어, 협업 개발문화, 시작의 두려움 등 다양한 이유로 공개SW 진입장벽이 높게만 느껴지는 개발자들을 위한 '공개SW 컨트리뷰톤' 멘토링 행사.

61 | 컨트리뷰션 아카데미를 통해 선배 개발자가 직접 기여하는 공개SW 프로젝트 가이드와 함께 공개SW 기여에 대한 진입장벽을 뚫어 참여·공유·협업 방식의 글로벌 개발문화와 다양한 기여(Contribution)를 직접경험하는 프로그램.

62 | 예비 컨트리뷰터 인재들이 자신의 잠재적 공개SW 역량을 강화하고, 다양한 글로벌 기술 분야에서 코드 63 | 기여, 코드 리뷰, 테스트, 버그 리포트, 기능제안, 이슈 댓글, 질문,&건의, 번역, 문서작성 등의 다양한 방법 64 | 으로 공개SW 문화에 기여할 수 있는 기회를 제공.
67 | 68 |
69 | 70 | + ### Q8 과제에서 사용할 외부의 공개SW 프로젝트를 어떻게 평가할 수 있나요? 71 | 공개SW 연구개발과제 수행 시 외부의 공개SW 프로젝트를 활용해야 하는 경우, 비슷한 기능을 제공하는 다수의 프로젝트에 대하여 조사를 하게 되며, 발견된 프로젝트 중 어떤 프로젝트가 더 과제 수행에 적합한지 평가하기 위한 기준이 필요합니다.
72 |
73 | 공개SW 프로젝트를 평가하는 경우에는 일반적인 소프트웨어의 품질속성과 공개SW의 특성을 반영한 품질 속성, 그리고 과제 이해관계자의 요구사항과 연구원의 역량 등을 복합적으로 고려하여 평가해야 합니다.
74 |
75 | 한국정보통신기술협회의 공개SW 성숙도 및 적용성 평가 지침(TTA.KO-11.0133)은 공개SW 프로젝트의 성숙도 및 적용성을 평가하기 위한 항목과 평가방법을 제공하므로, 외부의 공개SW 프로젝트의 평가에도 활용할 수 있으며 수행 중인 공개SW 연구개발과제의 성숙도를 자체 평가하는 용도로도 활용할 수 있습니다. 76 | 77 |
78 | 79 | + ### Q9 공개SW 프로젝트에서 사용하는 개발 방법론은 어떤 것이 있나요? 80 | 기존의 소프트웨어 개발 방법론인 폭포수 모델에서는 요구사항 개발, 설계, 구현, 검증, 관리와 같이 순차적인 절차에 의해 개발이 진행되지만, 공개SW 개발방식에서 외부 기여자의 참여는 이러한 순차적인 단계에 대한 고려가 없으므로 소프트웨어 개발의 전 과정에서 외부 기여자의 요청에 대한 수용이 가능한 소프트웨어 개발 방법론이 필요합니다.
81 |
82 | 공개SW 개발 방법론에 대한 명확한 정의는 없지만, 보편적으로 공개SW 개발에 사용되는 개발 방법론은 점진적 순환을 기본으로 하는 스크럼, 칸반 등의 애자일 개발 방법론이 자주 사용되며 자유로운 외부 기여자의 참여를 소프트웨어 개발과정에 적용하기 위해 연구개발 과제 수행에 적합한 브랜치 모델(git-flow, githubflow 등)을 기반으로 소스 코드의 형상 관리가 요구됩니다. 83 | 84 |
85 | 86 | + ### Q10 공개SW 연구개발 과제의 결과물을 배포할 때는 소프트웨어의 소스 코드만 배포해도 되나요? 87 | 과제의 결과물로 소프트웨어 소스 코드만 배포해도 되지만 공개SW 개발방식의 장점을 활용하기 위해서는 공개한 프로젝트를 사용하려는 외부 사용자가 사용하기 쉽도록 소프트웨어 소스 코드, 빌드 결과 파일(exe, jar 등), 배포용 패키지(rpm, deb, appImage 등), 제품 설명서 같은 여러 가지 프로그램 사용을 돕는 파일도 함께 배포하는 것이 좋습니다. 88 | 89 |
90 | 91 | + ### Q11 공개한 프로젝트 사용자에게 프로젝트의 품질을 어떻게 보여줘야 하나요? 92 | 성숙도가 높은 공개SW 프로젝트는 코드 커버리지, 릴리즈 관리 도구를 연동하여 항상 사용자에게 소프트웨어 소스 코드의 품질에 대한 신뢰성을 제공합니다. 공개SW 프로젝트의 다양한 메타데이터를 이미지 형태로 제공하는 서비스(https://shields.io/)를 이용하여 배지 이미지를 소프트웨어 소스 코드 저장소의 README 파일에 표기하여 품질을 가시화하는 것도 좋은 방법입니다. 93 | 94 |
95 | 96 | + ### Q12 공개SW 연구개발 과제의 라이선스 검증은 어떻게 해야 하나요? 97 | 공개SW 연구개발과제의 수행 중 외부의 공개SW를 획득하여 활용하기 위해 기존의 소프트웨어 소스 코드에 결합하는 시점과 공개SW 연구개발과제의 결과물을 배포하는 시점에는 반드시 라이선스 검증을 통해 의무사항의 준수 여부를 확인하고 조치해야 합니다.
98 |
99 | 연구개발과제 수행 조직 내부의 자원으로 라이선스 검증이 어려운 경우에는 정보통신산업진흥원(NIPA)에서 공개SW 라이선스 검증서비스(https://www.oss.kr/license_verify)를 1년에 3회를 무료로 제공하고 있으므로 이를 활용하여 검토를 수행하고 조치할 수 있습니다. 100 | 101 |
102 | 103 | + ### Q13 공개SW 프로젝트의 보안 취약점은 어떻게 검사할 수 있나요? 104 | 대부분의 공개SW 연구개발과제는 직접 개발하는 소프트웨어 소스 코드와 함께 외부의 공개SW를 활용하여 개발하게 되는 경우가 많습니다. 이처럼 직접 개발한 소스 코드가 아닌 외부에서 가져온 공개SW 프로젝트에 대한 보안 취약점도 함께 검사하고 발견된 취약점에 대하여 수시로 패치가 수정되어야 안전한 결과물을 공개할 수 있습니다.
105 |
106 | 기존의 소프트웨어 보안 취약점 점검은 제품 출시 전 1회 검사 후 소프트웨어를 배포하는 것이 일반적이나 이런 방식은 외부에서 획득한 공개SW 프로젝트의 취약점이 발견되는 경우에 빠른 조치가 어렵습니다. 따라서 소프트웨어의 지속적 릴리즈를 관리할 수 있는 도구와 보안 취약점 검사를 연동하여 항시 외부 라이브러리의 보안 취약점을 검사하는 과정을 수행하도록 구축하는 것이 필요하며, 깃허브의 Security 메뉴를 이용하면 소스 코드 정적검사와 보안 취약점 데이터베이스를 통한 보안 검사를 쉽게 수행할 수 있습니다. 107 | 108 |
109 | 110 | + ### Q14 공개SW 연구개발과제는 커뮤니티 구축이 필수인가요? 111 | 공개SW 개발방식의 장점을 활용하기 위해서는 다수의 외부 참여자가 활동할 수 있도록 커뮤니티를 잘 구축하고 운영하는 것이 중요합니다. 하지만 공개SW 연구개발 과제의 수행 기간이 짧은 경우에는 과제의 결과물을 연구개발하는 것과 동시에 커뮤니티를 구축하고 운영하기 쉽지 않습니다.
112 |
113 | 수행 기간이 짧은 과제의 경우는 커뮤니티를 구축하고 운영하지 못하더라도 본 가이드에서 제시한 연구과제 결과물의 공개를 우선 수행하고, 과제 수행 기간 종료 후 커뮤니티의 구축 및 활성화를 추가로 계획하는 것도 좋은 방법입니다. 114 | 115 |
116 | 117 | + ### Q15 커뮤니티를 구축하기 어려운 경우는 어떻게 수행해야 하나요? 118 | 모든 공개SW 연구개발 과제가 커뮤니티를 신규로 구축하고 운영해야 하는 것은 아닙니다. 신규 커뮤니티의 구축보다 좋은 방식은 기존의 커뮤니티에 참여하여 연구개발 결과물을 기존 커뮤니티에서 공유하고 참여하면서 함께 성장하는 것입니다.
119 |
120 | 하지만 적절한 분야의 기존 커뮤니티가 없으나 커뮤니티를 활용하고자 하는 경우 신규 커뮤니티를 구축하고 운영을 전담할 수 있는 담당자 및 적절한 예산과 자원을 배정해야 합니다.
121 |
122 | 만약 커뮤니티 구축이 어려운 경우에는 국내에서 공개SW 커뮤니티 운영을 지원할 수 있는 한국공개소프트웨어 협회 또는 오픈소스 소프트웨어재단과 같은 단체와 함께 운영하는 것도 좋은 방법입니다. 123 | 124 |
125 | 126 | + ### Q16 커뮤니티를 구축하려고 하지만 과제 예산으로 수행이 어려운 경우 지원을 요청할 방법은 없나요? 127 | 과제 수행기관 자체적으로 커뮤니티 구축에 필요한 환경이 부족한 경우에는, 정보통신산업진흥원(NIPA)에서 운영하는 오픈소스 소프트웨어 통합지원센터의 공개SW 커뮤니티 지원사업을 통해서 신청(https://www.oss.kr/community_support)하여 커뮤니티 운영에 필요한 온·오프라인 모임 장소 및 전용 장비 활용 등 커뮤니티 운영에 필요한 지원을 받을 수 있습니다.
128 |
129 | 문의처 : 2021 공개SW 커뮤니티 지원 운영사무국, 02-561-0552, comm@oss.kr 130 | 131 |
132 | 133 | + ### Q17 공개SW 연구개발과제를 공개하고 후원을 받을 수 있도록 구성해도 되나요? 134 | 이미 많은 공개SW 프로젝트가 지속해서 유지되기 위해서 후원자들이 쉽게 후원할 수 있도록 만들어진 Open Collective, Tidelift, Ko-fi, Patreon 등 다양한 크라우드펀딩(crowdfunding)[19](#footnote19) 방식의 서비스를 이용하고 있습니다.
135 |
136 | 공개한 프로젝트가 지속해서 유지되기 위해서 예산을 확보하는 것은 필수적인 일이며, 리눅스민트 같은 프로젝트는 기업이나 개인이 쉽게 후원에 참여할 수 있도록 구성하고 후원자들의 내역과 후원금을 다음 이미지와 같이 커뮤니티에 투명하게 공개하며 운영하고 있습니다. 137 | 138 | 139 |

그림 27. 리눅스민트(linuxmint) 프로젝트의 후원금 공개 페이지


140 | 141 | --- 142 | 18) 공개SW 활성화를 위한 공개SW 연구개발 생태계 연구(소프트웨어정책연구소, 2021) [return](#part2_2_18)
143 | 19) 크라우드펀딩은 소셜 네트워크 서비스를 이용해 소규모 후원을 받거나 투자 등의 목적으로 인터넷과 같은 플랫폼을 통해 다수의 개인들로부터 자금을 모으는 행위이다. [return](#part2_2_19)
144 | 145 | -------------------------------------------------------------------------------- /part2/03/refList.md: -------------------------------------------------------------------------------- 1 | # 참고문헌 2 | 3 | 1. 공개소프트웨어 기반의 개방형 혁신 연구개발 역량 성숙도 모델(한국통신학회, 김형채, 2019) 4 | 2. 공개소프트웨어 거버넌스 프레임워크 및 적용 가이드(정보통신산업진흥원, 2015) 5 | 3. 공개SW 소프트웨어 활성화를 위한 성숙도 및 적용성 평가 모델(OSMAAM)의 설계 및 구현에 관한 연구 (정보화정책, 정윤재, 오승운, 김형채, 2013) 6 | 4. 오픈소스 SW 연계 ICT 표준화 전략보고서(정보통신기술협회, 2020) 7 | 5. 오픈소스 SW 시장조사(정보통신산업진흥원, 2020) 8 | 6. 공개 소프트웨어 연구개발 수행 가이드라인(정보통신산업진흥원, 2018) 9 | 7. 공개SW 활성화를 위한 공개SW 연구개발 생태계 연구(소프트웨어정책연구소, 2021) 10 | 8. 공개 소스 소프트웨어 프로젝트의 생명 주기와 품질 유지 방안 - 정보과학회지 제26권 제712호 (2008.7) 이민석 11 | 9. 개방형 연구개발을 위한 공개소프트웨어 커뮤니티 거버넌스 지침(한국정보통신협회, 2016) 12 | 10. 공개SW 커뮤니티 거버넌스, 김형채, 2018, https://www.youtube.com/watch?v=4Urs-2IxsFQ 13 | 11. 하모니카 커뮤니티, https://hamonikr.org 14 | 12. 공개SW 연구개발 프로젝트 거버넌스 프랙티스(오픈테크넷, 김형채, 2021), https://www.youtube.com/watch?v=tzh_W2LnP_Q 15 | 13. OSPO 101 교육 모듈, https://github.com/innovationacademy-kr/ospo101 16 | 14. 카카오 올리브 서비스, https://olive.kakao.com 17 | 15. 네이버 공개SW billboard.js, https://github.com/naver/billboard.js/blob/master/CONTRIBUTING.md 18 | 16. 카카오 공개SW buffalo, https://docs.google.com/forms/d/e/1FAIpQLSejX1wS1YCArZ7huZlKpuhWUWhGbLflOU93ZoTZiSR-ZPsm6w/viewform 19 | 17. SKT 공개SW HANU, https://github.com/openinfradev/community/blob/main/governance/README.md 20 | 18. 누구나 쉽게 이해할 수 있는 입문, 브랜치란, https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html 21 | 19. github-flow 사용법, https://hellowoori.tistory.com/56 22 | 20. A framework for software ecosystem governance(Alfred Baars, University of Amsterdam, 2012) 23 | 21. Essentials of Systems Analysis and Design, Joseph S Valacich, University of Arizona, Joey F.George, Iowa State University, 2015 24 | 22. Evolution Patterns of Open-Source Software Systems and Communities(Yotsuya, Shinjuku, 2002) 25 | 23. LF-Using Open Source and Improving the Impact of your Enterprise Open Source Development and Participation(Linux Foundation, 2019) 26 | 24. Motivating the contributions An Open Innovation perspective on what to share as Open Source Software(J. Linåker, H. Munir, K. Wnuk, C.E. Mols, 2018) 27 | 25. Open RnD and open innovation- Exploring the phenomenon(Ellen Enkel1, Oliver Gassmann2 and Henry Chesbrough, 2009) 28 | 26. Open Source Software Ecosystems- A Systematic Mapping(Oscar Franco-Bedoyaa,b, David Amellera, Dolors Costala, Xavier Francha, 2017) 29 | 27. Scacchi-OSS-Ecosystems-7July15(Walt Scacchi, 2013) 30 | 28. Understanding Free-Open Source Software Development Processes(Walt Scacchi, Joseph Feller, Brian Fitzgerald, 2006) 31 | 29. Open Source Initiative, https://opensource.org/ 32 | 30. Udacity Git Commit Message Style Guide, https://udacity.github.io/git-styleguide/ 33 | 31. Semantic Versioning 2.0.0, https://semver.org/lang/ko/ 34 | 32. CI/CD pipeline with GitHub Actions, https://nimbella.com/blog/ci/cd-pipeline-with-githubactions 35 | 33. Quickstart for GitHub Actions, https://docs.github.com/en/actions/quickstart 36 | 34. Debating tournament tabulation software for British Parliamentary and a variety of two-team parliamentary formats, https://github.com/TabbycatDebate/tabbycat 37 | -------------------------------------------------------------------------------- /part2/target-configuration2.md: -------------------------------------------------------------------------------- 1 | # 가이드의 대상 및 구성 2 | 3 | 최근 국내외 많은 기업, 대학, 연구기관들은 소프트웨어 소스 코드를 협력적, 재사용 가능 자산으로 인식하기 시작하면서 공개SW R&D 과제가 증가하고 있다. 기존의 소프트웨어 개발조직들은 조직 내외부의 참여를 수용하는 공개SW 개발방식을 도입하면서 개방, 참여, 공유의 문화가 확대되고 있지만, 여전히 대부분의 과제 수행기관은 공개SW R&D에 대한 계획과 수행의 어려움을 호소하고 있다.
4 |
5 | 본 가이드 라인의 목적은 공개SW R&D를 계획하고 수행하는 기업 및 연구소, 대학의 연구책임자 및 연구원들을 대상으로 [파트1]에서는 공개SW R&D 수행 전 연구계획 단계에서의 정책수립 시 검토해야 하는 사항을 제공, [파트2]에서는 실제 공개SW R&D를 수행 단계에서의 실무 검토사항을 제공 목적을 가진다. 공본 가이드 라인은 [그림1]과 같이 공개SW R&D 연구계획 수립단계와 공개SW R&D 수행 단계로 구성되어 있으며 본 공개SW R&D 연구계획을 위한 가이드 라인의 목적은 공개SW R&D를 수행하기에 앞서 반드시 검토해 할 단계별 정책검토 사항을 제시함에 있다.
6 |
7 | 본 가이드라인은 그림1과 같이 연구개발과제의 연구계획 단계와 수행 단계로 구성되어 있으며, [파트2]에서는 공개SW 연구개발과제 수행자를 위한 수행 시 필요한 내용을 중심으로 제시하고 있다. 연구개발과제의 계획을 수립하려는 경우는 [파트1]의 연구계획 수립을 위한 공개SW R&D 수행 가이드라인을 참조하기 바란다. 8 | 9 | >라이선스, 특허, 보안취약점 관리
10 | 11 |

그림 1. 공개SW R&D 수행 가이드라인의 구성


12 | 13 | -------------------------------------------------------------------------------- /part2/terms-definition2.md: -------------------------------------------------------------------------------- 1 | # 용어정리 2 | 3 | - ### 브랜치(Branch) 4 | 소프트웨어 소스 코드 관리 시스템의 주 작업 공간에서 개발 상황에 따라 파생되어 독립적으로 작업을 진행할 수 있는 작업 공간 5 |

6 | - ### 형상 관리(SCM, Software Configuration Management) 7 | 소프트웨어 개발 프로세스 각 단계에서 소프트웨어의 변경 점을 체계적으로 추적하고 관리하는 일렬의 활동. 단지 소스 코드의 버전 관리만을 의미하는 것이 아니라 소프트웨어의 생명 주기 동안의 요구사항, 설계 문서, 소스 코드, UI 문서, Test Case 및 각종 결과물에 대해서 형상을 만들고, 형상들의 관계 및 변경사항, 변경 시점 등을 체계적으로 관리하는 활동으로 소프트웨어 개발에서 필수 활동이며 최근 가장 많이 사용되는 형상 관리 도구는 Git을 이용하고 있다. 8 |

9 | - ### Git 10 | 2005년 리누스 토르발스가 리눅스 커널의 개발을 위해 만들었으며, OSS(GPL2)로 개발자가 중앙 서버에 접속하지 않은 상태에서도 코딩 작업을 할 수 있도록 지원하는 버전 관리 시스템. 11 |

12 | - ### 릴리즈 관리 13 | 소프트웨어 계획, 설계, 일정 관리, 테스트, 배포 및 제어 프로세스를 뜻하는 릴리스 관리는 팀이 기존 생산 환경의 무결성을 유지하면서 기업이 요구하는 애플리케이션과 업그레이드를 효율적으로 제공할 수 있도록 보장하며 릴리즈 제어와 배포 자동화가 중요한 역할을 한다. 14 |

15 | - ### 전자정부 표준프레임워크 16 | 전자정부 표준프레임워크는 웹 기반 정보화 시스템 구축 시 필요로 하는 애플리케이션 아키텍처, 기본기능 및 공통컴포넌트를 제공하는 표준프레임워크로 실행환경, 개발환경, 운영 환경, 관리환경과 공통컴포넌트로 구성되어 있으며 정보시스템 개발을 위해 필요한 기능 및 아키텍처를 미리 만들어 제공함으로써 효율적인 애플리케이션 구축을 지원. 17 |

18 | - ### 마이크로서비스 아키텍처(Micro Service Architecture, MSA) 19 | 단일 프로그램을 컴포넌트별로 나누어 작은 서비스의 조합으로 구축하는 방법. 각 컴포넌트는 서비스 형태로 구현되고 API를 이용하여 타 서비스와 통신하게 된다. 각 서비스는 독립된 서버로 타 컴포넌트와 의존성이 없으므로 독립된 배포를 하게 되고 각 컴포넌트가 독립된 서비스로 개발되어있기 때문에 부분적인 확장이 가능하다. 20 |

21 | - ### 커밋(commit) 22 | 저장소에 소스 코드의 일부의 최신 변경사항을 추가함으로써 이러한 변경사항을 저장소의 최상위 리비전(head revision)의 일부분으로 만들어주는 것 23 |

24 | - ### 코드 커버리지(Code Coverage) 25 | 소프트웨어의 테스트를 논할 때 얼마나 테스트가 충분한가를 나타내는 지표 26 |

27 | - ### 포크(fork) 28 | 다른 사람의 Github repository에서 내가 어떤 부분을 수정하거나 추가 기능을 넣고 싶을 때 해당 respository를 내 Github repository로 그대로 복제하는 기능 29 |

30 | - ### 풀리퀘스트(Pull Request, PR) 31 | GitHub 저장소에 Push된 소스 코드 변경사항을 다른 개발자들에게 알리는 행동. 32 |

33 | - ### 컨트리뷰터(Contributor) 34 | 공개SW 프로젝트에서 소프트웨어 소스 코드 개선, 문서화, 기능제안, 디자인, 테스트 등 다양한 분야의 참여를 모두 포괄하여 해당 프로젝트에 참여하고 도움을 주는 모든 활동의 참여자를 의미. 35 |

36 | - ### Static Application Security Testing (SAST) 37 | 애플리케이션 소스 코드 또는 바이너리 코드를 입력으로 사용하고 이 코드에서 알려진 취약한 코드 패턴을 스캔하여 잠재적인 취약성을 식별하는 결과를 생성하는 작업. SAST 도구는 일반적으로 소프트웨어 개발의 초기 단계에서 후기 단계, 특히 코드를 프로덕션으로 보내기 전에 사용. 38 |

39 | - ### 기여자 라이선스 동의(Contributor License Agreement, CLA) 40 | 지식 재산권이 회사/프로젝트(일반적으로 공개 SW 사용권을 준수하는 소프트웨어)에 기여되는 조항을 정의하는 내용. 41 | -------------------------------------------------------------------------------- /publish.md: -------------------------------------------------------------------------------- 1 | # 발간사 2 | 3 | 공개SW R&D 실무 수행 가이드라인을 발간하며, 공개SW(공개소프트웨어, 오픈소스SW)를 잘 활용할 수 있는 가이드라인은 4 | ’18년에 처음 제작되어 관련 연구자들이 공개SW란 무엇이고, 공개SW 개발 방식의 R&D에 대한 의미를 이해하고 공개SW 연구개발의 확산에 도움을 주고 있습니다. 5 | 6 | 그러나, 기존 가이드라인은 백과사전식 정보 제공으로 인하여 R&D를 수행하는 실무자들이 실제 수행 과정에서 적용하는데 한계가 있어서, 현업에서 연구를 수행하는 실무 연구원과 대학(원)의 학생들은 공개SW의 활용, 이를 통한 개발 및 개발된 소스코드 공개 방법에 대해 어려움을 호소하고 있다고 들었습니다. 7 | 8 | 이에, SW컴퓨팅 분야 등 국가연구개발사업에서 공개SW를 활용하여 R&D를 수행하는 방법에 대한 정보 등 공개SW R&D를 이미 수행한 연구원의 노하우 등을 반영하여 실제 연구 수행과정에서 참고할 수 있는 가이드라인을 새롭게 만들었습니다. 9 | 10 | 공개SW는 소프트웨어 저작권자가 해당 소스코드를 공개해 이를 사용, 복제, 수정, 배포할 수 있는 권한을 부여한 소프트웨어를 말합니다. 정부는 2020년 5월 소프트웨어진흥법 제25조 2항에서 소프트웨어 소스코드를 공개하여 외부의 기여자가 참여하도록 하는 공개SW 개발방식의 활용을 채택하여 결과물을 공개SW로 배포하도록 법을 개정한 바 있습니다. 11 | 12 | 공개SW R&D 과제는 결과물의 기술이전을 통해 사업화로 이어지던 기존의 일반적인 R&D 과제와 다르게 R&D 결과물을 사전에 공개하고 활용 확산을 위한 관리 및 지원체계를 잘 마련하는 것이 중요합니다. 13 | 14 | 금번에 발간하는 가이드라인은 공개SW R&D를 계획하고 수행하는 기업 및 연구소, 대학의 연구책임자 및 연구원들에게 도움을 주고자 크게 2개 파트로 구성하고 있습니다. ▲ 첫 번째 파트는 연구를 수행하기 전에 사전 연구계획 준비과정에서의 정책 수립시 검토할 사항을 제시하고, ▲ 두 번째 파트에서는 연구 수행 중에 발생하는 실무자의 궁금한 점을 모아서 연구개발 단계별로 따라할 수 있도록 구성하고 있습니다. 또한, 파트별로 자주 묻는 질문을 FAQ로 구성하여 설명하고 있습니다. 15 | 16 | 본 가이드라인이 공개SW 연구개발은 어떻게 하나요?, 전체 소스코드를 공개해야 하는 건가요?, 어떤 라이선스를 17 | 적용해야 하나요?, 특허권리 주장은 가능한가요? 등 실무에서 발생하는 여러 궁금한 점을 이해하고 과제를 수행하는 18 | 데에 있어서 도움을 줄 것으로 기대합니다. 19 | 20 | 또한, 본 가이드라인이 SW 기반기술에서 인공지능, 빅데이터, 클라우드, 블록체인 등 신기술 분야의 개방형 21 | 혁신 연구개발 확산에 도움을 주어 기업의 신시장 창출과 미래성장 동력의 확보 등 산업 전반의 경쟁력 향상에도 22 | 이바지할 수 있기를 기대하며, 공개SW 연구개발 과제에 신청, 참여하는 수요자에 도움을 주기 위해 가이드라인 23 | 제작 작업에 참여하신 분들의 노고에 감사드립니다. 24 | 감사합니다. --------------------------------------------------------------------------------