소프트웨어 라이선스의 이해

전 직장에서 안드로이드 앱을 개발할 때는 사용하는 라이브러리를 모두 조사하고 법조팀에서 라이센스 위반인지 조사해 주었습니다. 막연히 알고 있던 오픈 소스의 개념과 사용할 수 있는 것과 아닌 것에 대해 이해를 조금 더 높이고자 자료를 정리합니다. 아래 내용은 대부분 책 오픈소스 소프트웨어 라이선스에서 가져온 것임을 밝혀 둡니다.

---

용어 정리

오픈소스

국내에서는 “오픈소스”를 지칭하는 용어로 OSS(오픈소스 소프트웨어), 공개 소프트웨어, 오픈소스라는 용어를 주로 사용합니다. 하지만 국외에서는 FOSS (Free Open Source Software)라는 용어를 더 익숙하게 사용하고 있습니다. 여기서 Free는 "공짜"를 뜻하는 게 아닌 "자유"를 뜻합니다.

행위자

오픈소스와 관견된 행위자는 3가지로 분류할 수 있습니다.

• 라이선서(Licensor): 라이선스를 적용한 원 저작자
• 기여자(Contributor): 라이선서와 라이센스의 대상 솟프트웨어를 수정한 저작자
• 라이선시(Licensee), 수령자(Recipient), 귀하(You): 라이선스 적용을 받는 대상자로써 오픈소스 소프트웨어를 사용하는 사람

자유(Free) 소트프웨어 운동 by FSF

GNU(GNU is not UNIX) Manifesto

 

블리저드의 게임 개발자 같은 외모를 지니신 이분의 이름은 리처드 스톨먼입니다. emacs의 작성자이기도 하고 GNU 프로젝트와 FSF(Free Software Foundation, 자유 소프트웨어 재단)의 창립자입니다. GNU의 약자는 GNU is not UNIX인데 재귀의 말장난인데, GNU가 UNIX 계열 운영체제이지만 유닉스 코드를 포함하지 않은 자유 소프트웨어임을 강조하기 위함입니다. 리누스 토발즈가 만든 커널이 GPL계열로 공개되면서 GNU와 합쳐져서 리눅스가 되었고 이후 오픈 소프트웨어의 시대를 본격적으로 열게 되었습니다.

 

GNU에서는 "자유 소프트웨어"를 다음과 같이 정의합니다.

실행의 자유

어떤 사람 또는 조직이 원하는 어떠한 목적을 위해서는 자유 소프트웨어를 실행할 수 있음을 의미한다. 사용자나 목적에 차별이 있으면 안된다.

연구와 수정의 자유

누구든지 해당 소프트웨어의 작동 원리를 파악하고 연구할 수 있어야 하고, 이를 위해 소스 코드의 공개와 접근이 보장되어야 한다. 티보이제이션(수정 소프트웨어가 같은 하드웨어에서 동작하지 않는 것)은 이 자유를 침해하는 것.

재배포의 자유

자신의 이웃을 도울 수 있도록 SW를 재배포할 자유. 수령한 SW의 원본 또는 수정본의 소스 코드나 실행 바이너리 모두를 재배포 할 수 있어야 한다.

수정 프로그램 배포의 자유

수정, 변경 사항을 자유롭게 배포해 커뮤니티 전체가 그로 인한 이익을 공유할 기회를 제공할 수 있어야 한다.

오픈소스 라이선스 요건 by OSI (에릭 레이먼드 / 브룩스 페런스)

성당과 시장(The Cathedral and the Bazaar)

오픈소스를 이야기할 때 에릭 레이먼드가 만든 OSI(Open Software Initiative)를 언급하지 않을 수 없습니다. 에릭은 "성당과 시장"이라는 유명한 컬럼을 기재하였고, 컬럼에서 폐쇄된 소프트웨어 생태계인 기업을 성당에, 오픈 소프트웨어 생태계를 시장에 비유하면서 자유롭게 공개하여 발전하는 소프트웨어가 이슈를 빨리 해결하고 좋은 소프트웨어가 된다고 강조했습니다. OSI에서는 오픈소스가 갖추어야 할 조건은로 다음 10가지를 뽑았습니다.

 

1. 자유 재배포

특정 프로그램을 여러 다른 프로그램을 포함하는 SW 내의 한 컴포넌트로 팔거나 제공하지 못하도록 제한해서는 안 되고 그에 사용료를 부과해서는 안 된다. 그러나 GPL과 Apache와 같이 서로 충돌하는 오픈소스 라이선스의 프로그램들이 하나의 저작물에 포함될 수 없는 만큼 실제 재배포가 제한될 수 있다.

2. 소스코드의 배포

컴파일된 목적 코드뿐만 아니라 소스 코드의 배포를 허용해야 한다. 만약 소스 코드를 제외한 상태로 배포하려면 합리적 복제 비용으로 소스 코드를 취득할 수 있는 널리 알려진 수단, 즉 인터넷을 통해 무료로 다운로드받을 수 있게 해야 한다.

3. 2차적 저작물의 허용

원저작물의 수정이나 2차적 프로그램의 창작을 허용해야 하며 이러한 프로그램들을 원프로그램에 적용되던 라이선스와 동일한 조전으로 배포하는 것을 허용해야 한다.

4. 저작자의 소스코드 통합

개발 시에 프로그램을 수정할 목적으로 원소스 코드와 함께 패치파일의 배포를 허락하는 경우에 한해서만, 수정된 형태의 소스 코드 배포를 제한할 수 있다. 변경된 소스 코드로 설치된 SW의 배포를 명시적으로 허용해야 한다. 이때 라이선스는 원프로그램과 다른 이름이나 버전 번호를 부여하도록 요구해야 한다. 여러 개발자가 동시에 작업을 하기 때문에 각자가 기여한 소스 코드의 경중과 중요성을 분별해 일정한 품질 관리와 버전 제어가 필요하다.

5. 개인이나 단체에 대한 차별 금지

라이선스는 모든 개인과 단체를 차별해서는 안 되고, 특정 그룹 사람들이나 인종에게만 사용 허용 또는 금지해서는 안 된다. GPL상 배포의 지역적 제한을 둘 수 잇는데, 이것이 본 요건에 위배되는지는 논란이 있다. 특정국의 법률상 특정 SW의 수출입에 제한이 있을 수 있지만 이를 라이선스에 포함시킬 수 없다.

6. 사용 분야 제한 금지

특정 분야, 예를 들면 영리사업이나 유전 연구에 사용됨을 제한할 수 없다.

7. 라이선스의 배포

프로그램에 부착된 권리는 프로그램을 재배포 받은 모든 자들이 비밀 유지 약정 같은 추가 라이선스를 체결하지 않아도 그들에게 적용된다.

8. 특정 SW에 한정한 라이선스 금지

프로그램에 부착된 권리가 당해 프로그램이 특정 SW 배포 버전의 부분이 될 경우에만 인정되는 라이선스여서는 안 된다. 특정 SW에서 추출된 부분 프로그램 수령자에게 동일 권리가 부여되어야 한다.

9. 다른 SW에 대한 제한 금지

오픈소스 SW와 함께 배포되는 다른 소프트웨어에 대한 제한을 설정해서는 안 된다. 다양한 라이선스, 다른 오픈 라이선스 또는 전유적 SW와의 결합을 가능하게 한다. GPL과 결합되는 프로그램에 GPL의 적용이 확대되는 것은 결합으로 하나의 SW를 생성할 때에 한한다.

10. 라이선스의 기술적 중립성

라이선스 규정은 특정 기술 또는 인터페이스 형태에만 기초해 규정하지 않고, 다양한 기술을 도입할 수 있도록 해야 한다. 예로써 클릭랩을 의무화해서는 안 된다.

 

OSI에 의해 정립된 라이선스의 최신 목록은 링크를 참고 하세요.

라이선스의 일반적 구성

라이선스의 내용은 일반적으로 크게 서문과 본문 두 개의 영역으로로 구성됩니다. 각 영역에 포함되는 내용은 다음과 같습니다.

• 서문: 라이선스의 철학, 취지
• 본문:
  • 사용자의 권한 및 의무 조항(소스 코드 공개, 저작자와 수정 내용 일시 등 저작권 고지 등)
  • 보증 부제공 조항
  • 소프트웨어 결합에 관한 조항(양립 가능성 등)
  • 특허권 부여 및 특허 보복 조항, 특허 허락 조항
  • 유료 판매 금지 조항
  • 면책 조항: 라이선서의 품질보증 책임이나 손해배상 책임 면제 조항. 특정 국가의 강행 법규에 위반되지 않는 번위 내에서 유효함
  • 라이선시가 의무를 위반할 경우 계약을 종결시키고 이용 권한을 박탈하는 조항

라이선스의 예 -

Apache2.0 라이선스의 예: https://www.apache.org/licenses/LICENSE-2.0.txt

라이선스 구분

출처: 위키피디아

라이선스는 공개 범위에 따라 카테고리를 나눌 수 있습니다. 사용 범위에 전혀 제한이 없는 것에서 부터 사내에서만 공개하는 라이선스까지로 구분할 수 있습니다. 일단 GPL계열의 라이브러리를 사용하고 있다면 라이선스 위반이 아닌지 당장 검토가 필요합니다.

소스 코드 공개 의무

GPL계열의 라이선스도 여러 종류로 나누어 발전했습니다. 강 카피레프트인 GPL의 경우는 원자작물 뿐 아니라 2차 저작물을 공개해야 합니다. 약 카피레프트인 LGPL은 원 저작물의 공개는 필요없고 2차 저작물만 공개하면 됩니다.

 

공개SW 라이선스별 의무사항 비교: https://www.oss.kr/ 의 라이선스 가이드를 참고 바랍니다. 매년 가이드가 업데이트 되어 공유되고 있습니다.

 

대표적 오픈소스 라이선스

오픈소스로 배포되는 많은 소프트웨어들은 대부분 대부분 크게 3가지로 분류할 수 있습니다.

 

GPL2.0 (강 카피레프트)

• 복제와 배포가 이루어 질 때는 본 허가서와 프로그램에 대한 보증이 제공되지 않는다는 사실에 대해서 언급되었던 모든 내용을 그대로 유지시켜야 하며, 영문판 GPL 라이선스를 함께 제공해야 한다.
• 파일을 개작할 때는 파일을 개작한 사실, 내용 및 그 날짜 등을 파일안에 명시해야 한다.
• SW를 수정하거나 새로운 소프트웨어를 링크(Static과 Dynamic linking
  모두)시키는 경우 GPL에 의해 소스코드를 제공해야 한다.
• 프로그램의 일부를 본 허가서와 배포 기준이 다른 자유 프로그램과함께 결합하고자 할 경우에는 해당 프로그램의 저작자로부터 서면승인을 받아야 한다.
• 자신의 특허를 구현한 프로그램을 GPL로 배포하는 경우에는 그 프로그램을GPL 조건에 따라 이용하는 이용자에게 특허에 대한 사용료를 받을 수 없으며, 제3자의 특허를 구현한 프로그램인 경우에는 그 특허권자가 GPL 조건에 따라 이용하는 프로그램 이용자에 대하여 특허사용료를 받지않을 때에만 그 프로그램을 GPL로 배포하는 것이 가능하다. | - 상용 라이브러리와 동일한 기능을 제공하는 공개SW 라이브러리에GPL과 같은 엄격한 라이선스를 적용하게 되면 라이브러리를 사용하는SW의 소스코드를 공개해야하기 때문에 상용SW 개발자들은 공개SW라이브러리의 사용을 꺼려할 것이다.

LGPL2.1 (약 카피레프트)

• 상용 라이브러리와 동일한 기능을 제공하는 공개SW 라이브러리에GPL과 같은 엄격한 라이선스를 적용하게 되면 라이브러리를 사용하는SW의 소스코드를 공개해야하기 때문에 상용SW 개발자들은 공개SW라이브러리의 사용을 꺼려할 것이다.
• 오히려 이미 널리 사용되고 있는 상용라이브러리와 동일한 기능을 제공하는 공개SW 라이브러리를 LGPL로 배포하여 원 프로그램의소스코드는 공개하지 않고, 이에 사용된 해당 공개SW 라이브러리의소스코드만 공개하게 함으로써 공개SW 라이브러리의 사용을 장려하고 사실상의 표준으로 유도하는 한편 관련된 다른 공개SW를 보다 더많이사용할 수 있도록 하겠다는 것이다.
• 소프트웨어를 배포하는 경우 저작권 표시, 보증 책임이없다는표시 및 LGPL에 의해 배포된다는 사실을 명시해야 한다.
• LGPL 라이브러리의 일부를 수정하는 경우 수정한 라이브러리의 소스코드 공개해야 한다.
• LGPL 라이브러리에 응용프로그램을 링크시킬(정적, 동적 모두) 경우 해당 응용프로그램의 소스코드를 공개할 필요가없다.
• 다만 사용자가 라이브러리 수정 후 동일한 실행 파일을 생성할 수 있도록 Static Linking시에는 응용프로그램의 Object Code를 제공해야 한다.
• 특허의 경우 GPL과 동일하다. 

Apache2.0 (비 카피레프트)

• 아파치 재단의 모든 SW에 적용되는 라이선스
• BSD 라이선스와 비슷하게 소스코드 공개등의의무가 발생하지 않는다.
• “Apache”라는 이름에 대한 상표권을 침해하지 않아야한다는조항이 명시적으로 들어가 있고 특허권에 관한 내용이 포함되어 BSD 라이선스보다는 좀 더 법적으로 완결된 내용을 담고있다.
• 특히 아파치 라이선스 2.0은 특허를 주장할 수 없다는 조항이 삽입되어 있어 GPL 2.0으로 배포되는 코드와 결합하는 것이 어렵다는 문제가 있었는데 GPL 3.0에서는 이 문제를 해결하여 아파치 라이선스로 배포되는 코드가 GPL 3.0으로 배포되는코드와 결합하는 것이 가능해졌다.
• 소프트웨어를 배포하는 경우 저작권 표시, 보증 책임이 없다는 내용을 표시해야 한다.

BSD(Berkley Software Distribution) - 페이스북이 만든 광범위한 라이선스 ”페이스북의 어떤한 특허에 대해서든지 무효라거나 집행 불가능하다는 이유로 소를 제기한 자는 페이스북이 가지는 소프트웨어에 관한 모든 특허의 이용 권한을 상실하게 된다”

양립 가능성

각 라이선스들의 내용이 다르기 때문에 어떤 소프트웨어끼리는 함께 사용할 수 없는 경우가 발생합니다. 여러 케이스가 있지만 간략히 정리하면 다음과 같습니다.

GPL3.0 & GPL2.0	GPL & LGPL2.1	Apache2.0 & GPL2.0	Apache2.0 & GPL3.0	EPL1.0 & GPL2.0
X	O	X	O	X

양립 가능 여부 판단을 위해 다음 조항들을 검토해야 합니다.

• 소스 코드 공개의 범위 및 동일 라이선스 유지의무 조항
• 라이선스의 준거법 조항
• 소송 시의 관할 국가 조항
• 특허권 하락 또는 보복 조항 등

저작권과 라이선스에 의한 법적 보호

오픈소스로 공개한 소프트웨어는 라이선스 그 자체의 내용 외에 여러가지 법에 의해 보호를 받습니다.

저작권법에 의한 보호

저작권을 침해당한 창작자 또는 기여자는 손해 배상청구권 + 판매 가처분 신청 가능

청구액: 저작권 행사로 얻을 수 있는 이익액 or 침해자가 얻은 이익액 or 저작물당 1000만원~5000만원

부정경쟁방집법상 영업 비밀로서의 보호

GPL + 2차 저작물이 영업 비밀로 보호가 가능한가?

상당한 노력으로 비밀을 유지해야 함을 증명해야 함
ex) 접근 대상자와 방법을 제한. 방화벽, 감사 로그 시스템 등

하지만, GPL상 공개 의무를 위반한 상태의 오픈소스가 정당한 비밀에 해당하기 어렵다

형사적인 보호

라이선스 위반으로 저작권 침해 시, 5년 이하 징영 또는 5000만원 이하의 벌금

법인의 대표도 벌금형 가능

  ⇒ 위반 행위를 방지하기 위한 상당한 주의와 감독을 게을리 하지 않았음을 입증해야 함

검찰 직권, 제3자 고발로 수사와 공소 제기 가능

오픈소스와 특허권의 충돌과 공존

만약 오픈소스에 다른 사람의 특허가 걸린 소프트웨어가 포함되었다면 어떻게 될까요? 이는 특허권 침해를 뜻하고 특허 괴물의 타겟이 됩니다. 현실적으로는 오픈소스 개발자가 권허권자의 산업 경쟁자가 되거나 특허침해로 많은 이익을 얻는 경우가 없기 때문에 특허 소송의 대상이 될 가능성이 낮습니다. 하지만 여러분이 키우고 있는 사업에 심대한 타격을 입힐 수 있습니다.

특허 허락 조항

라이선스의 본문에는 특허 허락 조항과 특허 보복 조항이 포함되는 경우가 있습니다. 특허 허락 조항은 창작자, 기여자가 자신의 특허권에 대해 하위 사용자에게 특허 라이선스(실시권)를 부여한다는 조항입니다. 쉽게 이야기해서 라이선스에 의해 소프트웨어가 가지고 있는 특허를 사용할 수 있도록 허락하는 조항입니다.

• Apache2.0 - 기여자의 행위 단독 또는 원저작물과의 결합 행위에 의해 반드시 침해되고, 당해 기여자가 라이선스를 부여할 수 있는 특허 청구항에 대해서만 라이선스를 부여
• GPL3.0 - 기여자가 소유하거나 통제하는 모든 특허 청구항 + 이후에 취득할 청구항도 포함
• MPL2.0 - 본 라이선스가 부여되지 않으면 기여자가 부여할 수 있는 모든 청구항을 포함

특허 보복 조항

특허 보복 조항은 오픈소스 사용자가 자신도 사용하는 오픈소스를 타인이 사용하는 것이 자신의 특허권을 침해한다는 이유로 특허침해소송을 제기하면 그 사용자에 대한 특허 라이선스를 해지한다는 조항입니다. 즉 오픈소스에다 함수로 특허를 걸어서 소송하지 말라는 거죠. 특허 보복 조항은 여러 분류에 따라 라이선스들을 구분해 볼 수 있습니다.

 

특허 소송 내용에 따른 분류

• MPL1.0, CPL1.1, OSL1.0 등 - 당해 오픈소스뿐 아니라 다른 소프트웨어 일반에 관한 특허권침해 소송 제기에 대해 라이선스 종료 사유로 함
• MPL2.0, EPL1.0, OSL2.0 - 당해 오픈소스에 관한 특허침해소송으로 제한

방어적 소 제기도 포함하는 라이선스

• Apache2.0, GPL3.0, EPL1.0, CPL1.0 - ‘반소와 교차 청구 포함’ 문구 포함
• MPL2.0 - ‘확인 판결 청구, 반소, 교차 청구 제외’ 문구 포함
• MPL1.1 - ‘확인 판결 청구 제외’ 문구 포함
• APSL2.0 - ‘적극적 소 제기가 있는 경우 특허 라이선스를 종료시킨다’ 문구 포함

소 제기 시 종료시키는 권리의 범위에 따른 분류

• Apache2.0, MPL1.1, EPL1.0, CPL1.1, MPL2.0 - 특허 라이선스에 한정
• OSL3.0, GPL3.0 - 저작권 라이선스까지 종료

Open Invention Network

오픈소스 방어를 위한 네트워크입니다. IBM, MS, Google 등 큰 기업들이 참여하고 있고, 라이선스에 대한 소를 공동 대응하거나 특허 서로의 특허를 교환하여 오픈소스 생태계를 유지하기 위한 크로스 라이선싱 활동도 하고 있습니다.

소스코드 스캐닝 도구

사용하고 있는 소스에 어떤 라이선스가 걸려 있는지 검사하는 툴이 많이 있습니다. 소스코드를 정적 분석하여 공개된 라이선스에서 구현한 방식과 유사도를 검사합니다. 검사결과가 우연히 라이선스의 코드와 같을 수도 있기 때문에 결과에 라이선스 위반이라고 나왔다고 무조건 고쳐야 하는 것은 아닙니다. 또 소스코드 뿐 아니라 바이너리로 배포된 저작물도 검사할 수 있는 툴도 있습니다. 해당 바이너리의 소스코드를 리버스 엔지니어링으로 찾아내는 것으로 생각됩니다.

• 상용 SW - Synopsys, Palamida
• 공개 SW - Fossology, Dependency-Check
• 바이너리 분석 툴 - binaryanalysis-ng
• 한국저작권 위원회 제공 툴

참고

오픈소스 소프트웨어 라이선스

공개SW 라이선스 가이드_개정판(2021).pdf

license-checker: node.js 소스가 사용하는 패키지의 라이선스를 체크해 주는 툴

오픈소스SW 라이선스 종합정보시스템