HanBitN MSA?
한빛N MSA(Micro Seminar Assemble)는 한빛미디어 디지털콘텐츠개발연구소에서 준비한 세미나 시리즈다. 학교와, 학원 등에서 다루지는 않지만, 현업에서 일을 할 때 필요한 지식, 기술, 정보 등을 전달하는 걸 목표로 진행되는 세미나다.
현업 사례(LG전자)로 알아보는 안전한 오픈소스 사용법
열렸는데요, 닫혔습니다.
'Open' Source, 단어 자체의 의미로는 공개된 코드지만 전부 가져다 사용할 수 있다는 의미가 아니다. 그저 아낌없이 주는 나무가 아니라는거다. 상업적으로 사용하는 경우 자칫 실수했다간 법적소송까지 갈 수도 있고, 사용하고자 하는 오픈소스에 보안 취약점이 있을수도 있다. 이렇게 까다로운 오픈소스를 어떻게 안전하게 사용할 수 있을지 이번 세미나를 통해 얻어가보자.
본 게시글에 사용된 강의 자료는 한빛미디어의 지원을 받았습니다.
오픈 소스?
요즘 개발자들은 무에서 유를 창조하는 것 보다, 이미 개발된 기능이 있다면 오픈소스를 많이 가져다쓴다. 새로 짤 필요가 없다는 점에서 리소스를 아낄 수 있다는게 크나큰 장점이다. 오픈소스를 안쓰고 개발한다는건 생각하기 힘든 일이라 봐도 될 것 같다. 그런데, 오픈소스는 공개되어 있으니 그냥 사용해도 될까?
그 전에 오픈소스가 도대체 뭔지부터 살펴보자. 오픈소스는 라이센스 방식을 통해 소프트웨어를 자유롭게 쓸 수 있게끔 해준다. 이때 복사, 수정, 사용, 재배포도 할 수 있다.
자유롭게 사용가능하다해서 다 오픈소스라고 생각하면 안된다. 대표적인 반례로 프리웨어(ex. 알집, V3)가 있다. 프리웨어는 소프트웨어는 무료로 배포되지만 소스코드를 제공하지 않고, 개인 사용시에만 무료로 사용가능한 조건이 붙어있다. 이 경우엔 오픈소스가 아니다.
그럼 공개되있다고 다 오픈소스인가? 위 사진을 보면 소스도 공개되있고 PyPi에서도 공개되있는데, 라이센스를 자세히 보면 Other/Proprietary License라고 쓰여있다. 다시 말해 그냥 좋다고 쓰다간 소송각 제대로 잡힐 수 있다는거다. 그래서 공개되있다고 다 오픈소스는 아니다.
오픈 소스 라이센스
OSI라는 기관에서 최소한의 오픈소스 라이센스라면 '이정도 기준은 준수해야 된다'는걸 정해놓고 충족 여부에 따라 approved license로 인증했다. 대표적으로 MIT, Apache-2.0등이 있겠다. 사실 approved 되지 않은 라이센스 자체만 놓고보면 되게 많다.
"THE BEER-WARE LICENSE" (Revision 42):
You can do whatever you want with this stuff.
If we meet some day, and you think this stuff is worth it, you can buy me a beer in return.
하나 꼽아보자면 이름부터 재밌는 "Beer-ware License"가 있다. 단순히 내 코드 가져다 쓰고 맘에 들었다면 나중에 맥주 한 잔 사달라는거다. 이렇게 자유롭게 라이센스를 만들 수 있다보니 정말 다양한 종류가 존재한다.
오픈 소스 배포시 주의사항
이렇게 다양한 오픈소스가 있는데, 각 오픈 소스 라이센스 별로 배포를 할때 의무사항을 정말 잘 지켜야 한다. 개발자라면 특히 라이센스에 대한 부분을 정확히 인지해야 한다. 단순히 '오픈소스, 그냥 공개 되어있고 자유롭게 쓰라고 해둔건데 조금 잘못썼다고 설마 소송까지 가겠어?' 라는 안일한 생각을 가졌다간 정말 소송이 걸릴 수 있다. 실제로 소송이 걸린다면, 라이센스에 지켜야할 의무사항이 명확하게 있기 때문에 이기기 어렵다.
오픈소스 소송사례로 한컴-아티팩트가 있다. 한컴이 의무사항을 지키지 않아 제기된 소송이 합의로 끝났지만, 말이 합의지 사실은 진거랑 다름없다. 이렇게 소송걸리면 이기기 힘드니 미리미리 그림 속 포돌이가 잡으러 오는 일이 없도록 준비해야 한다.
이미 승패가 갈린 싸움이다보니 이런걸 이용하는 사람도 있다. 대표적 사례로 Linux System Copyright 트롤로 유명한 Patrick Mchardy가 있다. 소송을 무기로 금적적인 이익을 취득하고자 여러 회사들을 상대로 합의를 유도하며 돈을 뜯어낸 사람인데, 이렇게 악의를 가지고 접근하는 사람이 있는 만큼 더욱 조심해야 한다.
- 라이센스 고지 의무
- 소스코드 공개 의무
소송각을 피하기 위해 우리는 위 2가지 의무사항을 지켜야 한다.
먼저 고지의무를 알아보자. 컴퓨터에 프로그램 설치를 위해 다음 버튼을 광클하다 갑자기 넘어가지 않았다면 대부분 이용약관 동의창에서 막혔을 것이다. 이 약관을 잘 읽어보면 '어떤 오픈소스를 따른다'고 표시되어 있는데, 바로 고지의무 때문에 명시해둔거다! 사실 이용약관을 다 읽고 넘어가는 사람은 없을거라 생각하지만.. 앞으로 프로그램을 설치할 일이 있다면 이용약관을 한 번 내리며 라이센스 고지 부분이 있는지 찾아보자.
두번째로 소스코드 공개 의무다. GPL, LGPL을 보면 라이센스 원문에 'SW 배포할때 소스코드도 동봉해야된다'라고 명시되어 있다. 우리가 개발하다 가져다 쓴 오픈소스가 해당 라이센스를 따르는 경우, 해당 소스코드를 취합해서 공개해야 한다. 강연자분이 근무하시는 LG전자의 경우 공개할 의무사항이 있는 오픈소스가 쓰이면, 소스코드를 취합해서 업로드하고 있다고 한다.
소스코드를 공개해야 한다니, 어디까지 공개해야될지 그 범위를 잡기가 애매하다. 오픈소스만 취합해 공개하면 되는걸까? 라고 생각하기엔 GPL의 경우 오픈소스랑 묶이는 executable 단위로 공개해야 하고, LGPL은 링크되는 단위로 공개해야 한다.
이렇게 라이센스별로 소스코드 공개 범위가 다 다르기 때문에, 라이센스별 소스코드 공개 범위를 확인 후에 최대한 공개하지 않는 방향으로 설계할 수 있다.
ex. AGPL-3.0
AGPL을 따르는 경우, 소프트웨어가 판매하는 제품이랑 같이 나가는 경우 (ex. TV + α) 소프트웨어를 설치하기 위해 필요한 인증키를 다 제공해야 한다. 그래서 회사에서 해당 라이센스 사용시 유의해야 한다.
"배포시 소스코드 제공의무와 범위"
오픈소스를 그냥 사용할때는 의무사항이 없다. 근데 이걸 내가 배포하는 소프트웨어에 포함해 배포할때는 해당 의무사항을 지켜야 한다. 그래서 사내 웹서비스를 개발했는데, 사내용으로만 쓰고 있다면 배포에 포함되지 않기에 라이센스 의무사항이 있다.
근데 가끔 몇몇 라이센스(ex. AGPL)에서 네트워크 서비스까지 배포의 범위로 묶는 경우가 있다. 이런 경우 의무사항을 지켜야하니, 내가 배포하는 소프트웨어의 타입과 포함된 오픈소스 라이센스를 보고 개발해야 한다.
라이센스 확인
본격적으로 라이센스를 어떻게 확인하면 되는지 살펴보자.
크게 3가지로 나뉘며, 위 사진은 1번에 해당한다.
- 소스코드 안에 작성된 라이센스 원문 확인
가장 심플하고 단순한 방식이다. 대부분의 오픈 소스들이 파일 단위로 많이 써놓는데, 소스 파일의 상단부에 저작권, 라이센스가 명시된 경우가 많다.
- README, LICENSE 파일 확인
파일단위로 작성되어있지 않다면, 루트 경로로 가서 README, LICENSE 파일을 확인해보자. 해당 파일 안에다 명시해놓은 경우도 있다.
- 웹페이지
대부분 1~2번 케이스에서 끝나지만 가끔 배포하는 웹페이지에 명시해놓은 케이스도 있다고 한다. 이런 경우 최대한 배포하는 쪽에서 라이센스 정보를 확인하자.
이렇게 오픈소스를 확인했다면 따로 엑셀같은데다 사용한 오픈소스 목록을 정리해두자. 그래야 나중에 배포하게 됐을때 라이센스별 의무사항을 지킬 수 있다. 의무사항 이행의 중요성은 말할 필요도 없다.
💡 유의사항 💡
간혹 Github를 보다가 license 표기가 아예 안된 경우, 가져다 쓸 수 있을까?
라이센스가 아예 표기되지 않았더라도 오픈소스는 그 자체로 지적재산권의 보호를 받는다. 그래서 라이센스가 아예 표기되지 않은 경우에도 기본적으로 쓸 수 없다고 생각하면 된다. 물론 저작권자의 허락이 있으면 얼마든지 쓸 수 있으니, Github Issue를 통해 허락을 구하자.
Dependency 누락
위 사진을 보면 requirements.txt에 있는 scancode 모듈이 여러 패키지를 추가로 다운받는걸 볼 수 있다. 이게 바로 Dependency인데, 실제로 내가 사용한건 몇 개 안되더라도 막상 설치되는 패키지가 엄청나게 많은 경우가 이에 해당한다.
'나는 이것만 가져다 썼는데, 여기에 대해서만 확인하면 되지 않아?'라고 생각했다간 포돌이와 마주할 수 있다. 오픈소스 정보를 확인할때 가장 주의해야할 부분이다. 우리가 소프트웨어를 배포할때를 생각해보면 설치한 패키지를 전부 묶어서 배포하기 때문에, 내가 배포하려는 소프트웨어에 포함된 오픈소스 목록을 전부 취합해야 한다.
예시를 하나 들어보자. 내가 쓴 오픈소스는 MIT인데, 패키지 내에 있는 오픈소스는 GPL인 경우가 있다면, 결과적으로 고지의무랑 소스코드 공개의무가 같이 딸려오는거다. 이렇게 내가 직접적으로 설치한 패키지가 아니라도, 추가적으로 설치된 패키지 때문에 소스코드를 공개하는 경우도 있다.
이런 점에서 반드시 디펜던시 정보를 확인해야한다. 만약 디펜던시를 누락했다면, 이는 내가 몇몇 라이센스에 대해 의무사항을 지키지 않았다는 것이고 결국 소송각이 잡힌다. 간혹 라이센스 중에는 수정하면 안된다고 명시한 경우도 있고, 배포시 바이너리 형태로 배포해야 하는 경우도 있어서 정말x100 라이센스를 잘 확인해 최대한 분리설계를 해야합니다.
이걸 언제 다 하죠?
개발자 특) 노가다 눈으로 못봄
어쩔 수 없이 디펜던시 정보를 다 확인해야되는 상황에서, 디펜던시 정보가 너무 많은 경우에 이걸 하나씩 transitive하게 하나씩 찾는건 정말 큰 노가다가 된다. 코드 치는 시간보다 라이센스 정리하는 시간이 훨씬 클게 뻔한데, LG전자에서 제공하는 FOSSLight를 통해 자동화하는 법을 알아보자.
FOSSLight Scanner는 소스코드, 바이너리, 그리고 디펜던시에 대해서 오픈 소스 분석을 수행한다. Dependency Manifest 파일이 있다면 Scanner에서 해당 패키지들을 transitive하게 다 설치하고, 각 패키지별 라이센스를 다 추출해 report로 뽑아주는 식이다.
물론 이 작업을 해주는 다른 오픈소스들(ex. scancode)도 많지만, 이번 세미나에서는 FOSSLight 기준으로 설명해주셨다. 사용법에 대한 자세한 내용은 위 링크를 참고하자.
https://fosslight.org/fosslight-guide/started/1_install.html
여기서 멈추지 않고 라이센스 고지 의무와 소스코드 공개의무도 자동화해준다. Scanner에서 추출한 report를 FOSSLight Hub에 업로드하면 오픈소스별 보안 취약점, 라이센스별 고지의무, 소스코드 공개의무를 다 확인할 수 있다. 데모사이트도 있다고 하니 관심 있다면 위 가이드 페이지를 참고하자!
보안
지금까지는 '소송으로부터 안전하게 쓰는법'을 알아봤다. 근데 오픈소스는 소스코드 자체가 공개되어 있기에, 라이센스만 준수한다고 안심할순 없다. 바로 보안 이슈인데, LOG4J, 하트블리드같은 경우가 대표적이다. 오늘은 없었는데 내일은 다시 보안취약점이 생길 수 있기에 우리가 사용하는 오픈소스들의 보안취약점 정보를 항상 모니터링해야한다.
주기적인 모니터링을 위해서는 소프트웨어에 포함된 오픈소스 목록을 리스트업 해야한다. 이를 SBOM(Software Bill of Materials)이라 하는데, 소프트웨어 안에 포함된 모든 정보들을 관리한다고 보면 되겠다. 여기다 내가 쓴 패키지 정보, 라이센스 정보를 넣어두고 관리하자.
SBOM 포맷은 다양하게 관리할 수 있는데, 자체적으로 엑셀에 name, version, license를 관리할 수 있고, SPDX라는 표준 포맷도 있다. 이건 국제표준으로, 고객사에 SW를 납품할 때 어떤 오픈소스가 포함되었는지를 해당 포맷의 작성을 요청하는 경우도 있다. 근데 SPDX의 경우 분량이 많아 간소하게 관리하려면 엑셀에 꼭 필요한 정보만 관리해도 충분하다고 알려주셨다.
정리할때 중요한 것은 오픈소스 버전을 꼭 확인해야 한다는 점이다. 버전별로 보안패치가 들어가고 안들어가고 하잖기에, 보안취약점 정보를 정확하게 확인하려면 반드시 버전을 정리해야한다. 그리고 오픈소스별 버전 추출은 앞서 말한 FOSSLight Scanner을 통해 가능하다.
마지막으로 FOSSLight를 통해 보안취약점을 모니터링 하는 방법을 알아보자. 먼저 Scanner에서 오픈소스 이름, 버전, 라이센스를 추출하고 Hub에 업로드하면 리스트업된 오픈소스 목록들에 대한 보안취약점을 매일 확인해 보여준다. 추가로 취약점이 확인 된 경우엔 알림메일도 보내준다. 회사에서 내가 개발하는 소프트웨어의 오픈소스 목록을 프로젝트별로 관리하고, 보안취약점 모니터링 정보를 매일 메일로 받는 용도로 쓸 수 있다.
FAQ
간혹 라이센스를 확인해보면 듀얼 라이센스라 해서, MIT or GPL-3.0으로 묶인 경우가 있다. 이런 경우 둘 중 하나만 선택하면 되는데, 의무사항이 좀 더 작은걸 골라 최대한 의무사항을 작게 만들면 된다고 한다. 위 예시에서는 MIT를 선택하면 된다. 이 질문은 강연자분이 컨설팅을 하실때도 자주 들어오는 질문이라고 하셨다.
여기서 주의점. 요즘 라이센스 중에 or commercial(ex. GPL-2.0 or commercial license) 같은게 있는데, 상용으로 뿌리는 이유는 간단히 말해 "너 이거 안지키면 이만큼의 돈을 청구할거야."라는 의미니 더욱 주의해서 사용해야 된다.
- 스택오버 플로우 코드를 구글링해서 찾은 경우, 그냥 써도 되는가?
- 자동 생성된 파일 내에 라이센스가 있는 경우 어떻게 해야 하는가?
- 라이센스 고지에 있어 어디까지 명시해야 하나요?
- 이외 다수
이외에 위와 같은 FAQ와 더불어 참가자분들의 질문을 받으며 오픈소스의 사용에 있어 조금 더 도움될만한 팁들을 많이 얻어갈 수 있었다. 영양가있는 질문들이 많았기에 위 질문에 대한 답변이나, 다른 개발자들이 던진 질문의 내용들이 궁금하다면 아래 링크에서 확인해보자.
후기
오픈소스를 안전하게 사용하는 방법을 다루는 시간보다 질의응답 시간이 길었다고 느꼈을 만큼, 참가자들의 학구적인 분위기 속에서 진행된 이번 세미나였다. 이런 분위기가 오랜만이라 강연자와 참가자간의 티키타카를 듣는 내내 귀가 즐거웠다.
조금 아쉬운 점이 있다면 내가 이삭줍기 느낌으로 몇 번 기여해본 경험은 있지만, 막상 오픈소스를 가져다 쓴 경험은 없다는 점이었다. 그렇지만 사람들의 질문 속에 들어있는 경험들을 간접적으로 들으며 오픈소스 사용이 라이센스 때문에 굉장히 까다로운 일이라는 것을 알 수 있었다. 오픈소스를 사용하는데 이렇게나 많은 고려사항이 필요하다니. 오픈소스를 사용하는 개발자들에게 이번 세미나가 조금은 애매함을 덜어줬을거라 생각한다.
무엇보다 내가 오픈소스에 문외한이라 경험이 없다보니 세미나를 듣고나서 당장 확실히 얻어간다고 자신있게 말할 순 없지만, 나중에 오픈소스를 사용하는 날이 온다면 적어도 이번 세미나에서 언급된 내용들이나, FOSSLight가 가이드 역할을 해줄거라 기대해본다.
자세한 내용은 한빛미디어에서 제공한 아래 VOD를 확인하자.
