최근 한 프로젝트를 완료하면서 이를 깃허브에 공개하였다. 공개를 하면서 처음으로 라이센스를 적용했는데, 은근히 헷갈리는 것들이 많았다. 이번 기회에 라이센스를 모두 정리해보려고 한다.

오픈소스 라이센스에 대한 배경 지식

라이센스의 필요성

오픈소스에서 라이센스는 매우 중요하다. 오픈소스에 기여하는데 있어서 라이센스가 없다면 오픈소스라고 보기 어려울 정도다. 사실, 소스 코드 역시 하나의 저작물이고 개인 혹은 법인의 창작물인만큼, 여타 저작물과 마찬가지로 저작권의 영향을 명시적으로 표기해주는 라이센스를 붙이는 것은 좋은 습관이다.

그렇다면 라이센스는 과연 무엇일까? 법리적인 해석을 들 수도 있지만, 개념은 간단하다.

가끔 블로그 글이나 SNS 게시물을 보다보면, 이런 내용이 담긴 글들을 가끔 볼 수 있었다.

불펌 금지!!, 퍼갈 때 출처 남겨주세요!, 퍼가면 고소합니다, 신경 안 쓰니 마음껏 퍼가세요~ 등등... 그런데 이러한 내용이 실제로 법적 효력이 있을까? 유의미한 효력일지는 모르겠지만, 실제로 존재한다. 만약 글을 작성하는 플랫폼에서 특수한 저작권에 대한 조항을 넣지 않는 한, 일반적으로 모든 게시물은 라이센스에 대한 명시가 없어도 기본적으로 저작권자 본인에게 그 저작권이 인정이 되고, 따라서 간단한 SNS 게시물이라도 사용자의 동의 없이 무단으로 복제해서 이용하는 행위는 법적으로 금지되어 있다.

라이센스는 이러한 저작권의 범위와 해석을 명시적으로 표기한 법리적인 약속이자 선언이라 할 수 있겠다. 그런데 이런 저작권에 대해서 문제점이 하나 있다. 저작권 의식이 강화된 것은 분명 좋은 일인데, 만약에 내가 작성한 게시물을, 사람들이 널리 퍼뜨렸으면 좋겠고, 이 정보를 공개적으로 배포하고 싶다면 어떨까?

문제는 기본적으로 라이센스를 명시하지 않으면 디폴트가 저작권이 본인에게 귀속되기에, 사람들이 자유롭게 자신이 퍼뜨리고자 하는 정보를 가져다가 쓸 수가 없다. 소프트웨어 쪽에서는 이게 문제가 되는데, 소프트웨어를 정보와 지식이라 보고, 이를 널리 퍼뜨리려는 사람들에게 이 저작권 귀속의 한계는 소프트웨어 기술 발전을 오히려 가로막을 수 있기 때문이다.

그렇기 때문에 오픈소스 계에서는 오히려 사람들에게 소스의 사용을 자유롭게 하기 위해서, 그 권한을 허가하는 라이센스를 주로 사용한다. 이러한 계약을 명시한 것이 바로 오픈소스 라이센스이다. 그런데 이 오픈소스 라이센스, 어디서부터 시작됐을까?

라이센스의 역사

처음 컴퓨터 공학이 나타나고 소프트웨어 공학이 발전하기 시작했을 때만 해도, 소프트웨어에 대한 저작물 개념이 희박하였다. 실제로 과거에는 이른바 불법 복제 및 유포가 대놓고서 빈번히 이루어졌었고, 사람들은 대부분 이에 대해 어떠한 문제 의식을 가지지 않았다. 타 저작물과 다르게 소프트웨어는 겉보기에는 저작물처럼 보이지도 않고, 심지어 복제도 워낙 간단하게 할 수도 있기에 저작물에 대한 의식 자체가 약했다. 그렇기 때문에 본격적으로 저작권에 대한 경각심이 강해지고, 실제로 보이지 않는 지적 재산권에 대한 법률이 1980년 대를 기점으로 크게 강화되기 시작했다. 소스 코드 역시 지적 재산권으로 인정받는 시대가 도래한 것이다.

문제는 위에서 선술하였듯이, 자신이 만든 소프트웨어를 기술의 발전을 위해 공개하고 배포하고자 하는 사람들 역시 많았다는 것이다. 모든 소스 코드에 지적 재산권이 붙게 된다면, 우리는 매번 코딩을 짤 때마다 기존의 것을 이용하지 못하고 새로 코드를 개발하거나, 매번 사용 허가를 구하는 등 자유로운 소프트웨어 개발을 하지 못하게 될 것이다. 지식이 한 곳으로 편중되는 것을 막고 소프트웨어의 독점화를 막기 위해, 지적 재산권에 대한 반대 급부로 1985년 10월 4일, '자유 소프트웨어 재단(Free Software Foundation, 이하 FSF)'이 설립됐다. FSF는 자유 소프트웨어의 생산과 보급을 장려하기 위해 리처드 스톨만이 세운 재단으로, 소프트웨어의 자유로운 보급을 위한 법리적 문제를 해결한다. 이곳에서 자유 소프트웨어 운동의 일환으로 GNU 프로젝트가 시작됐고 GNU 선언문을 발표했다.

대표적인 오픈소스 소프트웨어인 Linux 역시, 이 GNU 프로젝트의 일환이다. GNU에서는 GPL이라는 공개 소프트웨어 라이센스를 발표했는데, 이 GPL이 오픈소스 라이센스의 거의 초기 모델이라고 할 수 있겠다. Linux 역시 GPL 라이센스를 따르고 있다.

이와 같은 운동 때문에 소프트웨어 공학은 크게 발전할 수 있었다. 당장 Linux만 해도, 현재 수많은 서버, 임베디드 시스템, 커널 시스템, IoT 기기에서 사용되고 있고, MacOS나 윈도우 운영 체제에도 큰 영향을 끼치고 있다. 만약에 Linux가 오픈소스가 아니었으면 매번 신규 소프트웨어 개발을 할 때마다 소프트웨어 저작권 문제로 골치 아픈 일들을 겪었을 것이다. 그러나 Linux가 GPL 라이센스를 사용함으로써, 리눅스를 사용하는 소프트웨어는 저작권에 대한 걱정 없이 소프트웨어를 개발할 수 있었다. 리눅스는 사용하는데 비용이 들지 않는다는 것도 큰 장점이었다. 이 점을 생각해보면 자유 소프트웨어 운동은 성공을 거둔 운동이라 할 수 있겠다.

다만 GPL 라이센스의 가장 큰 특징 중 하나가 있는데, 만약 GPL 라이센스를 붙은 소프트웨어를 사용했다면, 그 소프트웨어를 사용하는 소프트웨어 역시 GPL 라이센스를 따르며 코드를 공개해야 한다는 것이다. 예를 들어 GPL 라이센스가 붙은 A라는 소프트웨어가 있고, 이 A를 이용해서 B라는 소프트웨어를 개발했다고 하자. 그러면 GPL 라이센스에 따라서 B 역시 무조건적으로 GPL 라이센스를 따라야 하며 반드시 코드 전문을 공개해야 한다. 사실 꽤 강력한 규칙이라 할 수 있는데, 마치 트리처럼 부모 소프트웨어가 GPL이면 모든 자식 소프트웨어가 GPL을 따라야 하기 때문이다. 이러한 다소 강력한 자유지향주의는 기업들로 하여금 반발을 불러 일으켰다. 기업 입장에서는 소프트웨어로 돈을 벌어야 하는데, 자신들의 소프트웨어가 무료로 공개돼버리면 소프트웨어를 상업화할 수가 없기 때문이다.

단점이 하나 더 있는데, 바로 대중으로 하여금 '소프트웨어는 공짜여야 한다'라는 인식을 품게 하기 때문이다. GPL은 지적 재산권이 한 곳으로 독점화되는 것을 막기 위해 등장했는데, 이에 대한 반향으로 소프트웨어는 라이센스가 없다라는 잘못된 인식을 품게 할 수가 있다.

그래서 자유 소프트웨어 운동을 대체하고자, 1998년 OSI(Open Source Initiative)가 등장했다. 그리고 이 무렵 오픈소스(Open Source)라는 용어도 같이 등장했다. OSI에서는 각 소프트웨어의 오픈소스 라이센스를 관리해주는 역할을 하고 있다.

그리고 이 과정을 통해서, 소프트웨어는 오픈소스 라이센스가 붙어야만 오픈소스로 인정받게 됐다. 이전에는 아무런 제약 없이 소프트웨어를 가져다 썼었고, 지적 재산권이 강화된 이후부터 마음대로 가져다 쓸 수 없게 됐다. 대신 소프트웨어를 오픈소스화하려면 오픈소스 라이센스를 붙여서 오픈소스화를 가능하게끔 변화하였다.

즉, 엄격하게 따지면 깃허브에서 아무 소스코드나 가져다 쓸 수 없다. 오직 오픈소스 라이센스가 붙은 소스 코드만 사용할 수가 있다. 그렇기 때문에 오픈소스와 라이센스는 서로 떼려야 뗄 수가 없는 불가분 관계가 됐고, 때문에 깃허브를 통해서 오픈소스에 기여를 하려면 우리는 오픈소스 라이센스에 대해서 꼭 알아야 한다.

오픈소스 라이센스 정리

깃허브에서 자주 보이는 라이센스는 크게 네 가지이다. MIT, BSD, GPL, Apache 라이센스가 그 주인공들이다. 하나하나 알아보겠다.

가장 자유롭고 편리한 MIT 라이센스

MIT 라이센스는 오픈소스를 하다보면 가장 많이 접하게 될 라이센스이다. 사실, 내가 무슨 라이센스를 써야 할 지 모르겠다, 하면 그냥 MIT 라이센스를 쓰면 된다. 내가 이번에 마무리한 프로젝트 역시 MIT 라이센스를 적용했고, 오픈소스계의 국룰이라 볼 수 있다.

MIT 라이센스는 매우 유연한 라이센스고, 존재하는 거의 모든 라이센스와 서로 호환된다. 저작권 고지만 유지되면 소스 코드를 사용, 수정, 배포하는데 제한이 없다.

MIT 라이센스는 이름 그대로 메사추세츠 공과대학(MIT)에서 소프트웨어 공학도를 위해 설계한 라이센스로, 오픈 소스 라이센스들 중 가장 짧고 간결하며 유연하기 때문에 사용하기 아주 편리하다.

MIT 라이센스는 다음 조건만 지키면 된다.

이 소프트웨어를 누구라도 무상으로 제한없이 취급해도 좋으나, 저작권 표시 및 이 허가 표시를 소프트웨어의 모든 복제물 또는 중요한 부분에 기재할 것(저작권자 표기)
저자 또는 저작권자는 소프트웨어에 관해서 아무런 책임을 지지 않는다. (책임 보증 부인)

위 조건이 끝이다. 저 두 조건은 사실 다른 오픈소스 라이센스에 대부분 붙는 기본적인 조건들이기도 하다. 즉 MIT 라이센스는 최소한의 기본 조건 외에는 제한하는 조건이 아무것도 없다.

1번의 경우 소스 코드의 사용을 허가하는 대신, 소스 코드의 원저작권자를 표시함으로써 권한을 보호하는 최소한의 조치이다. 2번의 경우 예를 들어서 내가 A라는 MIT 라이센스가 붙은 오픈소스를 이용하여 B라는 뱅킹 시스템을 만들었는데, A에 문제가 있어서 뱅킹 시스템이 해커에 의해 털렸다고 하자. 그래도 내가 A를 만든 사람한테 가서 책임을 물을 수 없다는 의미를 갖는다.

아래는 MIT 라이센스의 전문이다.

Copyright (c) <연도> <저작권 소유자>
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

다시 말하지만 이게 라이센스의 전문이고 널리 쓰이는 라이센스 중 가장 짧고 간결한 라이센스이다.

MIT와 거의 유사한 BSD

BSD 라이센스는, BSD 운영체제를 포함한 BSD 프로젝트 소프트웨어에 사용됐는데, 현재는 오픈소스에서 널리 사용되고 있다. 이 BSD 프로젝트는 공공자금이 투입됐는데, 공공자금이 투입된 프로젝트가 어느 한 단체 혹은 개인에 귀속되면 안 되기에 명시적으로 공개 사용을 허가한 라이센스이다. 언뜻 보기에는 MIT와 일부 차이점을 제외하고는 거의 똑같은데, 그 몇 안 되는 차이점 중 하나가 바로 '홍보/보증을 위한 목적으로 사용을 금지하는 조항'(3-clause BSD License)이다. MIT 라이센스에 저작자의 이름이나 기여자의 이름을 사용하여 해당 소프트웨어의 승인이나 지원을 시사할 수 없다는 조건이 추가됐다고 보면 된다.

이것이 의미하는 바는, 예를 들어서 내가 뱅킹 시스템을 하나 만들었다고 가정하자. 여기에 A라는 오픈소스 보안 소프트웨어를 사용했는데, 내가 이 뱅킹 시스템은 A라는 보안 소프트웨어를 사용했기에 안정성이 끝내준다고 홍보를 할 수가 없다는 의미이다. 만약 이를 허가하면, 실제 뱅킹 시스템이 해킹을 당했을 경우 A라는 소프트웨어의 명성에 피해를 끼칠 수 있기 때문이다.

한 종류만 있는 MIT 라이센스와 다르게 BSD에는 크게 세 가지 라이센스 종류가 존재한다.

2-clause BSD License (Simplified BSD License 또는 FreeBSD License): 저작권 고지문 및 라이센스 사본을 포함하여 소스 코드를 사용, 수정, 배포할 수 있다. 소스 코드의 사용, 수정, 배포에 따른 책임이 제한된다.
3-clause BSD License (New BSD License 또는 Modified BSD License): 2-clause BSD License와 동일한 조건에 추가로, 저작자의 이름이나 기여자의 이름을 사용하여 해당 소프트웨어의 승인이나 지원을 시사할 수 없다(위에서 말한 홍보/보증 목적 사용 금지).
4-clause BSD License (Original BSD License): 3-clause BSD License와 동일한 조건에 추가로, 소프트웨어를 사용하는 모든 광고 자료에 원 저작자의 이름을 포함할 것.

그러나 실제로 많이 사용하는 것은 2-clause와 3-clause 뿐인데, 4-clause의 경우 추가된 조건이 GPL과 호환되지 않아서 잘 사용되지 않기 때문이다(이렇듯 타 라이센스와 충돌되는 라이센스는 잘 채택되지 않는다).

정리하자면 BSD 라이센스의 주 조건은 세 가지이다(3-Clause 기준)

BSD 라이센스의 소프트웨어를 이용할 경우 소프트웨어의 원저작권자 이름과 BSD 라이센스의 내용을 같이 배포할 것(저작권자 표기)
책임 보증 부인
광고에서 활용 금지(3-Clause)

1, 2번은 MIT와 완전히 똑같고, 3번의 내용만 추가됐다고 보면 된다.

아래는 BSD 라이센스의 전문이다.

Copyright (c) <연도> <저작권 소유자>
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

전염성을 갖는 GPL 라이센스

"GPL 라이센스는 건드리는 모든 지적 재산권에 퍼지는 암같은 존재", "리눅스는 암적인 존재이다" - 스티브 발머, 2001, Microsoft CEO

마이크로소프트 사의 CEO인 스티브 발머가 했던 말이다. GPL을 공개적으로 저격했는데, 사실 여기에는 배경이 있다.

GPL(General Public License, GNU 일반 공중 사용 허가서)은 FSF에서 만든 라이센스다. 가장 큰 특징이 바로 GPL 라이센스가 붙은 소프트웨어를 사용하면, 그 소프트웨어 역시도 GPL로 공개돼야 한다는 전염성이 있다는 것이다. 라이센스가 전염되는 굉장히 특이한 라이센스로, 실제로 라이센스가 퍼지는 모습이 암세포가 증식하는 모습과 비슷하다.

마이크로소프트 사는 실제로 이 GPL 때문에 자신들이 작성한 2만 여 줄의 소스 코드를 강제로 공개해야만 했다. 사용된 일부 오픈소스에서 GPL이 걸렸기 때문이다.

이 GPL 라이센스가 어느 정도로 강력하냐면, 내가 A라는 소프트웨어를 만드는데 B를 사용했다고 가정하자. B에는 GPL이 걸려있다면, 내가 만든 A 역시 강제로 GPL이 되어야 한다. 또 내가 만든 A를 다른 사람들이 가져다가 C를 만들면 C 역시 GPL이 되어야 한다. GPL 라이센스를 갖는다는 말은 그 소스 코드를 강제로 오픈소스로 공개해야 한다는 말과도 같다. 이렇게 GPL은 사용하면 사용할 수록 전염되는 특성을 갖고 있다.

이 때문에 사실 기업에서는 사용하기 매우 꺼리는 라이센스 중 하나이다. 사용하면 무조건 코드를 공개해야 하기 때문이다. 심지어 기업에서 C라는 프로그램을 만들때 B라는 오픈소스를 가져다 썼는데, B가 MIT 라이센스로 명시되어 있어서 안심하고 가져다 썼다고 해보자. 그런데 B에서 A라는 오픈소스를 사용했는데, 문제는 이 A라는 오픈소스가 GPL 라이센스를 사용하였다. 이러면 B는 MIT 라이센스라 명시를 하고 있어도 (이는 잘못된 명시이고) GPL 라이센스가 적용되고, 이에 따라서 기업이 만든 C 역시 GPL 라이센스가 되어서 무조건 코드를 공개해야 한다. 기업 입장에서는 MIT니깐 안심하고 썼는데, 거슬러 올라가보니 GPL이 섞여 있다면, 자신들도 갑자기 GPL 라이센스를 적용받게 되는 것이다. 그래서 기업 입장에서는 엮이기 꺼려하는 라이센스이다.

GPL 라이센스의 주된 사용 조건은 아래와 같다.

컴퓨터 프로그램을 어떤 목적으로든 사용할 수 있으나, 법으로 제한된 행위는 할 수 없다.
컴퓨터 프로그램의 실행 복사본은 언제나 프로그램의 소스 코드와 함께 판매하거나, 소스 코드를 무료로 배포할 것.
컴퓨터 프로그램의 소스 코드를 용도에 따라 변경할 수 있다.
변경된 컴퓨터 프로그램 역시 소스 코드를 반드시 공개 배포할 것
변경된 컴퓨터 프로그램 역시 반드시 똑같은 라이센스(GPL)를 취할 것

GPL 라이센스는 강력한 Copy-Left 정신과 전염성으로 인해, 일부 라이센스와는 충돌이 발생하여 호환되지 않는다. 현재 가장 많이 사용되는 GPL 라이센스는 GPLv2와 GPLv3가 있는데, GPLv3는 라이센스 조건을 명확히 기술하고 특허 관련 문제를 해결해서, 타 라이센스와의 호환성을 더 개선시키기 위해 등장하였다.

언뜻 보면 장점보다 단점이 더 많은 라이센스같지만 이는 관점의 차이이다. 소프트웨어의 독점을 막고 자유로운 소프트웨어 사용을 활성화시킨다는 차원에서, 이러한 소스 코드 공개의 강제성은 지금껏 소프트웨어의 독점을 막고 기술을 발전시키는데 기여하였다. 리눅스를 기반으로 여전히 수많은 소프트웨어에서 스스로 GPL 라이센스를 채택한다는 것은 그 정신을 이어가기 위해서이다.

사실 자유 SW 정신은 모르겠고 개발 다하고서 어느날 갑자기 강제로 GPL 갱신해야 한다면 솔직히 좀 꼽기는 할 것 같다.

참고로 GPL 라이센스의 엄격함과 강제성을 완화한 버전으로 LGPL이 나오기도 했다. LGPL에선 소스 코드 모두를 공개하는 대신, 오직 사용한 부분만 공개하면 된다. 그리고 만약 LGPL 코드를 단순히 라이브러리(static, dynamic library 포함)로 사용해서 프로그램을 개발했을 경우 소스 코드를 공개하지 않아도 된다. 단지 LGPL 오픈 소스 코드를 사용했다고만 명시하면 된다. (단, 여기서도 LGPL 코드를 단순히 이용한 것을 넘어서, 이를 수정했거나 이로부터 파생된 라이브러리를 개발해서 배포했을 경우에는 여전히 모든 소스 코드를 공개해야 한다.)

특허성과 호환성의 Apache 라이센스

Apache, 혹은 아파치 라이센스는 아파치 재단에서 만든 오픈 소스 라이센스이다. 보통 아파치 라이센스라 함은 Apache License 2.0을 의미한다. 아파치 라이센스는 MIT, BSD와 마찬가지로 유연한 라이센스로, 타 라이센스와 호환성이 뛰어나다.

Apache License 2.0의 주 특징은 아래와 같다.

책임 보증 부인(MIT, BSD와 동일)
사용, 수정, 배포의 자유
상표 사용 제한(BSD와 동일)
변동 사항 표시: 원본 소프트웨어를 수정해서 배포할 경우, 원본과 수정된 부분을 명확하게 구분해야 하며, 수정 사항을 문서화할 것

변동 사항 표시 부분을 제외하면 타 라이센스와 다르지 않다. 특히 Apache License 2.0은 GPLv3와도 호환되어서, 아파치 라이센스를 GPL 라이센스가 적용된 프로젝트에 통합할 수 있다. 단, 여전히 GPLv2와는 호환되지 않는다.

아래는 아파치 라이센스를 적용한 예시이다.

Copyright [yyyy] [name of copyright owner]

       Licensed under the Apache License, Version 2.0 (the "License");
       you may not use this file except in compliance with the License.
       You may obtain a copy of the License at

          http://www.apache.org/licenses/LICENSE-2.0

       Unless required by applicable law or agreed to in writing, software
       distributed under the License is distributed on an "AS IS" BASIS,
       WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
       See the License for the specific language governing permissions and
       limitations under the License.

기타

보통은 MIT, BSD, GPL, Apache 선에서 선택하는 편인데, 그 외에도 많이 보이지는 않지만 다양한 라이센스가 존재한다.

MPL 2.0 (Mozilla Public License): 소프트웨어의 사용, 수정, 배포를 허용하면서도 오직 변경된 파일에 대해서만 MPL 2.0 라이센스를 적용한다. 즉 원본 소프트웨어와 수정된 부분이 서로 다른 라이센스를 가질 수 있게 한다.
LGPL(GNU Lesser General Public License): GPL 때 선술했는데, GPL이 너무 엄격해서 사람들이 기피하자 이를 완화한 버전이다. LGPL 소프트웨어를 수정 및 변형했을 때만 LGPL로 공개하고, 이외에는 다른 라이센스를 선택해도 된다.
EPL (Eclipse Public License): 소프트웨어의 사용, 수정, 배포를 허용하면서도 특허 침해에 대한 보호를 제공한다. 주로 Eclipse 재단 프로젝트에서 사용된다.
AGPL (Affero General Public License): GPL의 변형 라이센스로, 웹 애플리케이션에 대한 추가 조건이 포함된다. AGPL로 라이센스된 웹 어플리케이션은 사용자가 애플리케이션의 소스 코드에 접근할 수 있도록 기능을 제공해야 한다. 다른 종류의 소프트웨어에 대해서는 GPL과 동일하게 적용된다.

정리

라이센스	특징	차이점	공통점
MIT	가장 간단하고 자유로운 라이센스	소스 코드 공개 의무 없음, 라이센스와 저작권 고지만 필요	사용, 복사, 수정, 재배포에 대한 자유, 라이센스와 저작권 고지 필요
BSD	MIT와 유사하나 조건이 몇 가지 더 있음	- 2-Clause BSD: MIT와 거의 동일하나 보증부인 고지 필요 - 3-Clause BSD: 추가적으로 원 저작자의 승인 없이 이름 사용 금지	MIT와 마찬가지로 사용, 복사, 수정, 재배포에 대한 자유, 라이센스와 저작권 고지 필요
GPL	소스 코드 공개 의무와 동일한 라이센스 적용 의무	소스 코드 공개 의무, 수정 및 재배포 시 동일한 라이센스 적용 의무, 전염성이 강함	사용, 복사, 수정, 재배포에 대한 자유, 라이센스와 저작권 고지 필요, 소스 코드 공개 의무
Apache	특허 친화적이고 호환성이 뛰어남	소스 코드 공개 의무 없음, 특허 침해에 대한 보호, 기여자에 대한 명시적인 특허 라이센스 부여	사용, 복사, 수정, 재배포에 대한 자유, 라이센스와 저작권 고지 필요, 기여한 코드의 특허 사용에 대한 라이센스 부여

혹은 이 링크에 들어가면 라이센스에 대한 비교표를 확인할 수 있다.

깃허브에서 라이센스 추가하기

깃허브에서는 특히 라이센스를 추가하기를 권장하고 있다. 특히 깃허브에서 권장하는 공개 레포지토리의 몇 가지 조건들이 있는데, 이 조건을 만족할수록 해당 레포지토리가 노출될 확률이 높아진다. 그 조건 중 하나가 바로 라이센스이다.

깃허브 레포지토리의 Insights 란에서, Community Standards 탭을 가보자. 자신의 레포지토리가 오픈 소스에 기여하기 위한, 혹은 기여받기 위해 어느 정도의 조건을 충족하고 있는지를 확인할 수 있다. 그 중 하나가 바로 라이센스 설정이다.

해당 탭에서 Add를 눌러서 라이센스를 누를 수도 있고, 혹은 다음 과정을 따라서 License.md 혹은 License 파일을 그냥 추가하면 깃허브에서 라이센스를 고를 수 있게 도와준다.

레포지토리 메인 화면에서, Add file 버튼을 누르고, Create new file을 누른다.

여기서 파일 이름을 License 혹은 License.md (대문자로 LICENSE라 해도 상관 없다)라 지으면, 빨간색 네모 박스 친 것과 같은 버튼이 나온다. 해당 버튼을 누르면 라이센스를 선택할 수 있는 템플릿 화면으로 진입한다.

본인은 MIT 라이센스를 선택하였다. 여기서 연도와 이름을 적고 Review and submit을 누르면 아래와 같이 자동으로 라이센스 템플릿이 완성된다.

Commit Changes를 눌러서 커밋을 해보자.

이렇게 라이센스 파일이 추가된 것을 확인할 수 있다. 오른쪽에서도 해당 레포지토리가 MIT 라이센스를 따르고 있음을 확인할 수 있다.

마무리

오픈소스를 하다보면 라이센스를 자주 볼 수 있다. 개인적인 경험으로는 Solidity를 다룬 적이 있는데, 블록체인 계는 오픈 소스가 많이 활성화된 분야여서 라이센스를 접할 일이 많았다. 심지어 Solidity에서는 다음과 같이 라이센스를 명시하지 않으면 컴파일러가 경고를 내보내기도 한다.

// SPDX-License-Identifier: MIT
pragma soldity ^0.8.0;

contract ERC721Connector {
    // ...

저기서 맨 윗줄의 주석을 지워버리면, 단지 주석인데도 컴파일러 경고가 일어난다.

위와 같이 어떤 언어에서는 라이센스를 붙이지 않으면 경고를 내보낼 정도로, 라이센스를 중요시한다. 이때만 해도 그냥 '아 이런 게 있구나' 정도로만 넘어갔었고, 남들도 대충 MIT 쓰니깐 나도 MIT를 사용하고 그랬다. 그런데 소프트웨어, 코드는 엄연히 자신의 저작물이고 창작물인만큼 이를 배포하는 것 역시 나의 온전한 권리 하에 이루어지는만큼, 오픈소스의 라이센스를 이해하고 사용하는 것은 매우 중요하다. 이번 기회에 어떤 오픈소스 라이센스가 있는지 한 번에 정리해봤다. 잘 비교하고, 자신의 프로젝트에 맞는 가장 적합한 라이센스를 선택할 수 있을 것이다.

MIT? GPL? 헷갈리는 오픈소스 라이센스 정리