FOSS 와 GNU Project. 저작권과 라이센스의 역사

msung99·2022년 9월 12일

오픈소스sw 저작권 및 라이센스

소프트웨어

정의 : 컴퓨터 머신에게 사용자가 어떤 목적에 알맞게 명령,지시할 수 있는 명령과 관련된 데이터들의 집합

Open 의 의미

새로운 오픈소스의 승인과정 (Self-correcting process)

협업(collaboration) 과정을 통해 만들어지는 특징을 지님

1) 본인이 새로운 소스, 알고리즘등을 개발한다.

2) 무조건 바로 open 하는것이 아니라, 어떤 커뮤니티에서 reviewer 들이 리뷰를 한다.

3) 해당 소스가 리뷰어들을 통해 accept 되거나 또는 reject 된다.

4) accept 되면 오픈된다. 그러면 다른 사람들은 오픈된 해당 소스(오픈소스)를 복사해서 사용하든, 수정하든, 배포하든 한다.

오픈소스 예시

Britannica (1768)
- 백과사전
- 전문 writer 와 reviewer 에 의해 리뷰
Wiki (2001)

오픈소스 sw

정의 : 소스코드가 공개되어 있는 SW 를 말하며, 일반적으로 "자유롭게 복제/배포/수정"할 수 있다.

=> "자유롭게 복제/배포/수정" 할 수 있지만, 규칙 및 규약(obligation) 을 잘 지키며 써야한다!

특징

협업에 의해 만들어지는 특징이 있다.
아주 다양한 종류의 라이센스(license) 와 관련되어 있는데, 이때 이 license 라는것은 obligation(의무사항)과 연관이 있다.

저작권(copyright)

창작자에게 어떤 등록 절차도 없이 자연발생적으로 생긴다.

=> 창작물을 만들었을때, 그 창작물에 대한 사용할 권한, 수정할 권한, 배포할 권한등이 있을 것이다. 이러한 다양한 권한이 바로 저작권이고, 이는 창작자에게 자연발생적으로 주어진다.

저작권 등록 (Copyright registration)

창작자의 창작물을 저작권을 위배하고 함부로 사용하여 피해를 입을 경우, 법정 소송까지 가게 될 경우가 있다. 이때 해당 창작물이 언제 저작물을 가지게 되었는지를 알아야 하는데, 이 경우를 대비해 저작권 등록 날짜가 필요하므로 저작권 등록은 필수이다!

라이선스 (License)

license (라이선스)란 창작물을 사용할 권한을 의미
창작물을 만들었을 때 어떤 특정 방식의 배포, 사용등의 허가(permission) 을 사용자에게 제공할 것인지에 대한 permission 들의 집합
만일 라이선스에 적힌 사용 방식을 어기게되면, 해당 소스를 사용할 권한도 잃게되고, 법적 책임도 져야함

정의 : 소프트웨어 소유자(licensor) 와 사용자들(licensee) 간의 계약
=> 위반할 경우 라이선스 위반 및 저작권 침해로 이에 대한 법적 책임을 져야함

licensor : 창작자 (소유자) <=> licensee : 창작물을 받는사람 (사용자)

cf) 구글링 하다보면 가끔씩 소스코드가 있는데, 라이선스가 없는 것들이 있다. (Unknown license)

=> 주의!) 저작권이 없는것이 아니다. 저작권은 자연발생적으로 발생하므로 있는것이고, 라이선스는 없으므로 해당 소스를 사용할 권한이 없는 것이다. 사용하면 안된다!

Proprietary Software (사유 또는 독점 소프트웨어)

사용 조건이 제한적이고, 수정이나 재배포는 허용되지 않는 소프트웨어

일반적으로 소스 코드가 비공개되며, 대중에게 소스가 공개되지 안는 바이너리 형식으로 제공됨
=> ex) window 10 을 구매해도 소스를 제공받는 것이 아니라, 바이너리 형식으로 제공되는 것이다.
소유권을 사는 것이 아니므로, 수정이나 배포가 불가능함

Free Software (자유 소프트웨어)

GNU project (free software 운동) : 소프트웨어가 너무 공개되지 않으니, 소프트웨어 기술 진보 측면에서 좋지 않다는 취지로 주관된 운동

소프트웨어가 소스코드 비공개로 전황되는 것에 대한 반발로 자유 소프트웨어 운동이 일어남

free software 가 되기 위한 4가지 조건

아래 4가지 조건을 만족하면 free software 이다.

FSD (Free Software Definition)

1) 어떤 목적이던지 그 프로그램을 수행할 수 있는 자유
2) 소스코드를 분석할 수 있고 수정할 수 있는 자유
3) 그 복사본을 다른 사람에게 배포하고 줄 수 있는 자유
4) 내가 수정한 버전에 대해서 또 다른사람에게 다시 배포하고 줄 수 있는 자유

GNU / Linux

GNU 프로젝트에서 다양한 라이브러리가 탑제될때, 리눅스(linux) 운영채제가 개발됨
=> 이로써 free software 시스템에 완성되었다.

GNU 프로젝트는 컴파일러, 편집기, 디버거 등 프로그래밍과 컴퓨터 운영에 필요한 다양한 도구를 개발

실질적인 결실은 리눅스 커널과의 결합에 의해 완성

cf) linux 정식명칭 : GNU linux

Copyleft license

free software permission + share-like obligation
=> 앞서 살핀 free software 의 4가지 조건을 지켜야 하고 + "공유"를 하는것을 의무화한 라이선스

=> Copyleft license 의 대표적인 예시 : GPL

GPL (General Public License)

Copyleft license 의 대표적인 한 종류이자, 최초로 만들어진 Copyleft license
free software 창시자 리차드 스톨만(Richard Stallman) 에 의해 만들어짐

GPL (정식명칭 : GNU GPL) 특징

1) free software 의 정의, 4가지 특성을 보장
2) 해당 소스로 만들어진 수정물도 역시 동일한 라이선스하에 배포되어야 한다. 즉, 소스코드를 공유 및 공개해야 한다!
3) license progagation => 아래에서 설명!

license propagation (라이선스 전파)

GPL 코드를 가져와서 일부 내용이나 라이브러리만 수정해도 GPL license 가 전파된 것이다. 배포할때 내가 만든 소스를 포함해서 모든 파일을 공개해야함

=> 그렇다면, 리눅스도 GPL 인데, 리눅스 위에서 만들어진 소스들도 모두 다 공개해야 하는가? : 이래서 나온 에외 조항이 있다.

=> 소캣(sockets) 이나 파이트(pipes) 등으로 연결된 별도의 프로세스는 예외로 보고 공개 안해도 됨!
=> 삼성과 같은 회사들을 보면, 예외조항이나 다른 라이선스들을 통해 회피 전략을 통해서 내부의 기술을 공개 안함
리눅스 커널에서 만들어진 것들도 전파 안해도됨

LGPL (Lesser General Public License)

완화된 GPL ( <=> SGPL(Strong General Public License))
cf) 위에서 살펴본 GPL 이 SGPL 이다.
GPL 이므로 소스코드를 공개해야하는데, 공개정도 약간 완화된 라이선스

cf) GPL vs LGPL 비교

GPL

LGPL

내가 LGPL 파일을 다운받아서 수정하면 이 파일은 공개해야함.
그런데, linking 한 또 다른 파일을 공개하지 않아도 된다.
( <=> GPL 은 linking 한 다른 파일도 모두 공개해야함! )
단순히 라이브러리로써 사용한거라면 공개 안해도 된다!

Open Source Software

많은 기업들이 free software 를 거절한 이유

1) 애매모호한 문제 : 대중들에게 소프트웨어를 무료로 제공해준다는 인식 때문에 기업들이 싫어했음

2) 강력한 GPL 조항 (propagation 문제)

소스코드를 배포해야 하는 obligation(의무) 를 기업들이 싫어함
free software 를 사용하면 소스코드를 공개하라는 것이, 기업 입장에서는 친숙하지 않다.

Open Source

소스코드 공개에 보다 많은 참여를 이끌어내기 위해 "자유 소프트웨어" 라는 용어를 대체할 새로운 용어가 논의되었음

에리 레이먼드는 오픈소스(Open Source) 라는 새로운 용어를 제안했다

Free Software VS Open Source

차이점 : Free Software 의 문제점이라 할 수 있는
강력한 GPL 조항인 "같은 라이선스로 너의 소스코드도 공유해라" 라는 문제점을 없앤것이 Open Source 이다!

소스코드를 받아서 자유롭게 사용하는 것은 Free Software 와 거의 비슷하되, Obligation (강력한 GPL 조항) 에서 차이점을 보인다.
Open Source 는 공개하지 않아도 됨. 다른 라이선스로 바꾸든, 돈주고 팔든 맘대로 해도된다.

공통점, 차이점 정리

공통점 : 비영리 기관이며, 자유롭게 사용할 수 있다는 점에서는 거의 유사
차이점 : 공개여부,
Free Software 의 전파를 위해서 copyleft license 를 활용
Open source 는 다양한 기업의 참여를 이끌어내기 위해, re-license 할 수 있는 권한, 즉 permissive license 를 포함한다.

Copyleft license VS Permissive license
Copyleft license : 어떤 free software 를 다운 받고 소스코드와 다양한 권한들이 주어질 것이다. 근데 Obligation 이 있는 것이다.
(=> 어떤 Obligation 인가? : 저작자 표시는 공통 이행사항이며, 너도 동일하게 소스코드를 공개하고 이 소스코드에 대한 권한을 다른 사람에게도 주는 것)
- license ex) AGPL, GPL, LGPL, MPL
- project ex) linus, gcc, firefox
Permissive license : 권한을 받고, 오픈 안해도 되는것
- license ex) MIT, BSD, APACHE 라이선스
- project ex) python, android, apache, php

Shareware, Freeware and FOSS

FOSS(Free and Open Source Software) : Free Software 와 Open Source Software 두 개의 소프트웨어의 차이는 Obligation 에서 차이가 있었다. 이 두개의 차이점을 두고 구분하지 않는 것이다.
Freeware : 재배포 가능하고 자유롭게 쓸수있는 소프트웨어 이지만, 소스코드가 제공되지 않아서 수정할 수 없는 것
Shareware : 마찬가지로 자유롭게 사용가능하되, 사용하다보면 돈에 따라서 기능에 제한되거나, 또는 시간적으로 제한되는 것 등이 있는 것

=> Freeware 와 Shareware 는 FOSS가 아니다!
Freeware의 경우 소스코드가 없어서 Freedom 이 없고, Shareware의 경우도 제한되는 것들이 있어서 Freedom 하지 않다.

정리

Foss 외에는 사유 소프트웨어이다.

public domain

Open Source 의 장점

1) lower costs (저렴한 비용)

가성비 좋은 오픈소스(ex.리눅스)가 최고임

2) reduced development time and expense (개발시간과 비용 감축)

3) reliability and quality (신뢰성과 퀄리티)

예전엔 별로였는데, 오픈 시켜놓고 기업들이 점차 눈을 들이니 버그도 많이 부정되고 보안성도 올라감

4) availability of external support (외부 지원)

5) reduces "vendor lock-in" (lock-in 되는 것을 방지)

오픈소스에 소스코드가 있으므로 우리 회사가 고치고 싶은거 고치면 됨

Open source 의 단점

not user-friendly
Risk to intellectual property
- obligations 과 제한이 많다. 법적 문제도 많음
Hidden costs (잠재적인 비용)
- 오픈소스를 잘 못다루는경우 진입장벽에 있어서 어려움을 느낄 수 있음
- 오픈소스가 버전 up 이 되면서 기능이 계속 바뀐다.
- 커스터마이징(customizing) 이 힘듦.

Open Source SW at an Exponential Rate

소스코드가 방대해지면 개발 방법론에 변화가 있어야함
Error Propagation (에러 전파)
- 에러는 전파되는 특성이 있다.
- 예를들어 파이썬으로 여러 파일들을 만들고 여기서 한 파일에 버그가 발생했을때, 이 파일을 참조하는 것들은 다 이상한 행동이 발생할 수 밖에 없다. 즉, 그 에러를 참조한 다른 파일들 모듈들은 에러가 전파된다는 것이다.

소프트웨어 사이즈가 커지면 커질수록 에러 전파되는 특성이 있으므로, 최대한 빨리 수정되고 해결되어야 한다!

Integration Frequency (통합 빈도)

Incremental Integration

에러 한번 터지면 전체 소프트웨어에 영향 미쳐서 큰일날수도 있으므로, 단위별로 조금씩 나눠서 계속 테스트 해보자. (One-piece-at-a-time approach)

msung99

https://haon.blog

이전 포스트

BFS

다음 포스트