[OSS] Introduction of Open-Source Software | Programming

* 핵심 역량 정의

1) 오픈 소스 소프트웨어 개념 및 생태계 이해
2) 다양한 오픈소스 소프트웨어 이해
3) 오픈소스 관리도구 및 커뮤니티에 대한 경험
4) 오픈 소스 기반 기초 개발 능력

 

 

 

1. Open-source

1) 정의 ⭐

- 사람들이 수정하고 공유할 수 있는 것(디자인은 공개적으로 접근 가능)

- 물리적 형태나 구조도 가능

- 컴퓨터 시스템 속 소프트웨어로 생각해보자면, 사람들이 수정하고 공유할 수 있는 소프트웨어를 의미함(Open Source Sowftware)

 

2) Open Source Software(OSS)⭐

- 사람들이 수정하고 공유할 수 있는 소프트웨어를 의미

 

3) 오픈소스 소프트웨어의 역사

(0)

- Free Software Foundation의 Richard Stallman에 의해 1998년 2월 2일 전까지는 "free software"라고 불렸음

- 상업 소프트웨어로부터 자유로운 대안을 만들겠다는 의지

- GNU is Not a Unix(GNU) 프로젝트 시작됨

- 텍스트 편집기(Emacs), 컴파일러(gcc), 디버거(gdb)가 개발됨

- Free 소프트웨어 운동에서 리처드 스톨만이 "Free Software Foundation"을 설립함

- 1989년에 그는 오픈 소스 라이선스 "GNU General Public License(GPL)"를 배포함

 

(1)

- 1998년 2월 2일부터 Eric Raymon와 Richard Stallman, 적극적인 참가자들 모집하기 시작
- 이전 레이블에서는 "free software" 또는 "source code available" 소프트웨어로 불림
-  넷스케이프 법률 및/또는 마케팅 직원이 free software style license 하에 브라우저의 코드를 드러낼 깊은 고려
- 그 회의에서, 그들은 new term의 필요성에 대해 강하게 동의함

 

(2) 

- 그 주 후반, 1998년 2월 5일 VA Research에서 전략에 대한 브레인스토밍을 하기 위한 그룹이 모였습니다.
- 매독(Maddog)은 이전 용어로 자유롭게 배포할 수 있다(freely distributable)고 언급했으며, 새로운 용어가 협력 개발(cooperatively developed)되었습니다. 에릭(Eric)은 자유 소프트웨어, 오픈 소스와 소스웨어를 오픈 소스 모델을 옹호하는 주요 옵션으로 나열함. 토드가 "open source" 모델을 옹호앴고  에릭은 이를 지지했습니다.
- 이후 에릭 레이먼드가 언론에, 팀 오라일리가 사업에, 두 명이 다 프로그래밍 커뮤니티에 이 용어를 홍보한 시기가 있었습니다. 이 용어는 매우 빠르게 퍼지는 것처럼 보였습니다.
- 1998년 4월 7일, 팀 오라일리(Tim O'Reilly)는 이 분야의 주요 지도자 회의를 개최했습니다. 제1차 "프리웨어 서밋"으로 미리 발표되었고, 4월 14일까지 제1차 오픈 소스 서밋으로 언급되었습니다.

---

 

(3)

[ OSI - Open Source Initiative ]⭐

- 오픈 소스는 단순히 소스 코드에 접근하는 것을 의미하지 않는다.

- 오픈 소스 소프트웨어의 배포 조건은 아래의 기준을 준수해야 함

• 자유 배포
• 2차 저작물 허용
• 개인/단체에 대한 차별 금지
• 사용 분야에 대한 제한 금지
• 라이센스의 배포
• 라이선스 적용상의 동일성 유지
• 다른 라이센스의 포괄적 수용
• 라이선스의 기술적 중립성
• 소스코드 공개
• 소스코드 수정 제한 가능

 

(4) 

- 이제는 다양한 오픈소스 소프트웨어 커뮤니티가 있다.
- Community: 특정 목의 개발, 유지, 확장 및 홍보라는 공동의 목적에 의해 연합된 사람들의 공동체 집단

 

- 오픈 소스 소프트웨어 커뮤니티

• 오픈 소스 소프트웨어의 특정 기관을 개발, 유지, 확장 및 홍보한다는 공유된 목적에 의해 연합된 사람들의 그룹
• 이러한 커뮤니티는 종종 구성원이 다양한 지리적 지역을 차지하고 다양한 산업에 걸쳐 작업하는 전 세계적으로 분포되어 있습니다
• 그들을 하나로 묶는 것은 오픈 소스 소프트웨어 프로젝트에 대한 그들의 공통적인 비전과 커뮤니티에 참여하는 동료애 및 집단 정체성의 정신입니다

 

4) 사용자의 4가지 자유⭐

1️⃣ 프로그램을 실행할 수 있는 자유

2️⃣ 프로그램을 채택하고 연구할 수 있는 자유

3️⃣ 프로그램을 재배포 할 수 있는 자유(Freedom to help your neighbour)

4️⃣ 프로그램을 개선할 수 있는 자유

 

 

 

5) 오픈소스 소프트웨어의 Community-driven 생태계

(1)

- 오픈 소스 소프트웨어의 커뮤니티 중심 생태계는 방대하고 시각화하기 어렵다.

- 많은 개발자들이 수로와 지류의 언어를 선호하면서 은유적으로 묘사하는 경향이 있습니다

- Downstream과 Upstream

 

(2) Ecosystem of open source software

• End users
• Vendor partners
• Project vendors
• Project partners
• Project associates
• Open source projects

 

 

(3)

Q. 오픈소스 소프트웨어 커뮤니티는 어떻게 구성하나요?
A. 사람들이 소프트웨어를 설계하고 향상시키는 것을 같이 하기로 동의했을 때 구성된다. 

 

Q. 오픈소스 소프트웨어 커뮤니티에 참여할 수 있는 방법은 무엇인가요?

A. 일반적으로 사람들은 소프트웨어 코드의 버그를 수정하고, 애플리케이션에 대한 새로운 기능을 만들고, 문서를 작성 및 편집하고, 로고 및 그래픽을 만들고, 소프트웨어 채택을 촉진하고, 컨퍼런스 및 기타 행사에 프로젝트를 대표하거나, 소프트웨어에 대해 궁금한 다른 사람들을 지원함으로써 단순히 프로젝트에 참여합니다. 간단히 말해서, 사람들은 이러한 커뮤니티에 대한 기여와 그러한 기여의 결과로 확립된 긍정적인 평판 덕분에 오픈 소스 소프트웨어 커뮤니티에서 회원 자격을 얻습니다

 

 

 

6) Closed Source Software

- 권한자가 사용/수정/복제/배포의 권리를 가지고 있는 독점 소프트웨어

- 오픈소스 소프트웨어와 달리, 소스코드에 접근할 수 없음

- 실행 가능한 바이너리와 컴파일된 라이브러리의 형태로 제공

- 최종 사용자 라이센스 계약은 종종 소스 코드를 분해하거나 변경하는 것을 금지함. 일부 독점 소프트웨어는 코드를 부분적으로 또는 전체적으로 노출할 수 있지만 무단 사용은 여전히 불법임. closed 소스 소프트웨어의 소유자는 소스 코드를 사용할 수 있도록 하되 수정 및 사용에 법적 제한을 가할 수 있음.

 

 

7) 왜 사람들은 오픈소스 소프트웨어 사용을 선호하는가?

• Control: 더 많은 통제권을 지님
• Training: 공개 접근이 가능하기 때문에 공유/커멘트 등을 통해 같은 실수를 하지 않게 하고 더 좋은 프로그래머가 됨
• Security Problem: 독점 소프트웨어 보다 안전하고 안정적임. 업데이트 및 업그레이드가 독점 소프트웨어보다 빠름
• Stability: 원래 제작자가 도구 작업을 중단하더라도 도구가 사라지거나 손상되지 않는 것을 확신할 수 있음
• Community

 

 

 

2. OSI Approved Licenses

1) License란?⭐

- 저작권자가 이용자에게 저작물의 이용을 허락하는 형식화된 문서입니다.

 

2) 오픈소스 라이선스들

• 1-clause BSD License
• Academic Free License
• Adaptive Puplic License
• Apache License
• Apache Software License
• Apple Public Source License
• Artistic License(Perl)
• Artistic License
• Attribution Assurance License
• Blue Oak Model License
• Boost Software License
• GNU Affero General Public License
• GNU General Public License
• GNU Lesser General Public License
• GNU LGPL
• GNU Library General Public License

 

 

 

3) 오픈소스 라이선스의 종류

(1) permissive⭐

- 사용 상황에서 이 범주의 오픈 소스 소프트웨어는 특정 요구 사항을 부과하지 않고 사용자에게 광범위한 권한을 부여합니다. 일반적으로 저작권 및 라이센스 사용 공지에 관한 최소한의 속성만 요구합니다. 허용 가능한 라이센스의 예로는 BSD 및 MIT가 있습니다.

 

(2) copyleft⭐

- 자유 소프트웨어 라이선스(free software license)에 따른 소스코드 공유의 개념은 원본 소스코드와 원본 저작물에 대해서만 적용되는 것이 아니라 원본 저작물에 기초하여 작성된 모든 파생저작물을 동일한 라이선스 하에 공개하여야 함을 요구하고 있습니다. 이는 자유 소프트웨어 라이선스의 범주에 속합니다

• weak copyleft⭐
  : 수정사항이 포함된 코드의 공개가 필요한 라이선스는 MPL, EPL, LGPL 등의 라이선스의 범주에 해당함
• strong copyleft⭐
  : 동일한 조건에서 모든 결합코드에 대한 소스코드 해제가 필요한 라이선스는 GPL, AGPL 등의 라이선스에 적용됨

 

 

 

4) 오픈소스 SW 고지 의무⭐

(1) 저작권 고지 의무: 저작권 고지 의무는 상대방에게 저작권이 있음을 알리고, 저작권이 침해될 시 고의적 침해임을 알려 손해 배상의 범위를 확대하는 기능을 제공

(2) 라이선스 고지 의무: 오픈소스 SW를 사용한 경우 사용자들의 사용 권리를 공지

 

 

 

5) 고지 의무와 이행 방법⭐

(1) 파일 단위 고지(File Scope Approach)

: 파일에 여러 명의 기여자가 있을 경우 그 각 파일의 모든 부분에 저작권 표시를 하는 방식

 

 

(2) 종합 고지(Centralized Approach)

: 프로젝트 최상위에 AUTHORS or COPYRIGHT 파일을 만들고 저작권 정보를 모두 합쳐서 기재하는 방식

 

 

(3) 하이브리드 방식(Hybrid Approach)

: 위 두 가지 방식을 적절히 혼합하여 사용하는 방식

 

 

6) 고지문 작성 방식

 

 

 

 

7) 라이선스 분류별 고지 의무⭐

(1) Permissive Type

• MIT License 고지문 적용 방안
  1️⃣ 오픈소스 SW 해당 파일 주석 부분 혹은 NOTICE.txt에 상기 영문 고지문을 참조하여 고지
  2️⃣ 오픈소스 SW를 변경했을 경우에는 해당 파일 주석 부분에 저작권을 고지

 

 

 

(2) Weak Copyleft Type

• LGPL-2.1 License 고지문 적용 방안
  1️⃣ 오픈소스 SW 해당 파일 주석 부분 혹은 NOTICE.txt에 상기 영문 고지문을 참조하여 고지
  2️⃣ 오픈소스 SW를 변경했을 경우에는 해당 파일 주석 부분에 저작권을 고지
  3️⃣ 파일을 수정할 때는 파일을 수정했다는 사실과 그 날짜를 파일에 명시
  4️⃣ NOTICE.txt는 통상적으로 소스코드 최상위 수준에 위치하도록 고지

 

 

 

 

(3) Strong Copyleft Type

• GPL-2.0 License 고지문 적용 방안
  1️⃣ 오픈소스 SW 해당 파일 주석 부분 혹은 NOTICE.txt에 상기 영문 고지문을 참조하여 고지
  2️⃣ 오픈소스 SW를 변경했을 경우에는 해당 파일 주석 부분에 저작권을 고지
  3️⃣ 파일을 수정할 때는 파일을 수정했다는 사실과 그 날짜를 파일에 명시
  4️⃣ NOTICE.txt는 통상적으로 소스코드 최상위 수준에 위치하도록 고지

 

 

 

8) 소스코드 공개의무⭐

 

 

 

 

 

9) 오픈소스 SW 라이선스 체크리스트 (예시)

(1) Permissive Type

 

 

(2) Weak Copyleft Type

 

 

 

 

(3) Strong Copyleft Type

 

 

 

 

 

10) 오픈소스 SW 라이선스 분쟁 사례