-
오픈소스 라이선스 정리 - GPL, LGPL, MPL, BSD, Apache
-
오픈소스란?
-
깃허브(GitHub)의 소스코드는 오픈소스일까?
-
GPL 라이선스 - 이용과 배포의 자유, 동일 라이선스 유지, 소스코드 공개의무
-
LGPL - 이용과 배포의 자유, 동일 라이선스 유지, 제한적 소스코드 공개의무
-
MPL - 이용과 배포의 자유, 수정 라이선스 부분만 공개, 소스코드 공개의무 없음
-
BSD - 이용과 배포의 자유, 라이선스 유지여부 자유, 소스코드 공개의무 없음
-
Apache lilcense - 이용과 배포의 자유, 동일 라이선스 유지, 특허 주장 불가
-
마치며
오픈소스 라이선스 정리 - GPL, LGPL, MPL, BSD, Apache
개발을 진행하다 보면 의도하든 의도하지 않든 대부분 다른 개발자가 만든 소스를 기반으로 개발을 진행하게 됩니다. 오픈소스 라이선스에 대해서는 개발을 이제 막 처음 시작하거나 혹은 개인적으로 사용할 목적으로 혼자 만들고 혼자 뿌듯해할 경우라면 크게 관심을 가질 필요는 없는 주제일 수 있습니다.
그러나 스타트업을 준비 중이거나 또는 기업을 운영하거나 기업에 속해있는 개발자의 경우 혹시나 내가 가져다 쓴 소스가 법적인 문제가 발생될 소지가 있는지 정도는 알고 있는 것이 좋다고 생각합니다.
이번 포스팅에서 소개하는 라이선스는 일반적으로 알려진 라이선스를 기준하여 간단한 내용만을 다루었습니다. 만약 오픈소스 라이선스의 적용을 받는 프로그램을 이용하게 될 경우에는 반드시 해당 라이선스의 전문을 읽어보시길 바랍니다.
오픈소스란?
오픈소스는 라이선스 방식을 통해 배포된 소스코드를 의미합니다. 해당 라이선스를 기반으로 소스코드를 자유롭게 이용 및 배포까지 가능한데요. 이 과정에서 프로그램을 배포하거나 소스 코드의 접근 권한을 부여하거나 기존의 소스코드를 수정하는 등의 원 소스코드를 자유롭게 만질 수도 있습니다.
여기까지만 읽으면 '아~ 오픈소스는 내가 마음대로 이용할 수 있는 소스코드네?' 정도로 이해할 수 있지만 앞에서도 이야기했듯이 오픈소스는 '라이선스 방식을 통해 배포된 소스코드'입니다. 즉, 소스코드 이용자는 어떤 라이선스 방식을 통해 배포된 소스코드인지 확인하는 과정이 반드시 필요합니다.
깃허브(GitHub)의 소스코드는 오픈소스일까?
팀 프로젝트를 진행하다 보면 깃허브와 같은 버전관리 도구를 이용하게 됩니다. 특히 깃허브는 가장 많은 개발자들이 사용하는 버전관리 도구입니다. 그리고 대부분의 소스코드는 공개되어 있어서 마음만 먹으면 소스코드를 자유롭게 다운로드해서 이용할 수 있는데요. 그렇다면 깃허브(GitHub)의 소스코드는 오픈소스로 봐도 될까요?
정답은 '그때그때 다르다'로 이해할 수 있는데요. 그 이유는 해당 소스코드에 오픈소스 라이선스 방식을 통해 배포된 소스코드인지 명시가 되어 있으면 오픈소스로 이용이 가능하고, 그렇지 않으면 오픈소스로 이용할 수 없습니다.
만약 프로그램을 개발하던 중 'A' 개발자의 깃허브(GitHub)의 소스코드가 꼭 필요하다고 가정해 봅시다. 그럴 경우 우리는 제일 먼저 오픈소스 라이선스가 명시되어 있는지를 확인해야 하는데요. 보통 오픈소스 라이선스가 명시되어 있다면 소스코드 상단에 작성을 하게 됩니다. 만약 이러한 내용이 주석으로 작성되어 있다면 해당 오픈소스 라이선스의 규칙을 찾아보고 그 규칙범위 안에서 소스코드를 자유롭게 이용하면 됩니다. 그러나 이러한 오픈소스 라이선스가 명시되어 있지 않다면 해당 소스는 엄연히 저작권을 가진 소스코드이기 때문에 이용을 원할 경우 원 소스 개발자에게 소스 이용에 대해서 충분한 협의과정을 거쳐야 합니다.
GPL 라이선스 - 이용과 배포의 자유, 동일 라이선스 유지, 소스코드 공개의무
GPL(General Public License) 라이선스는 자유소프트웨어재단에서 만든 라이선스로 오픈소스 라이선스에 대한 추상적으로 가지고 있는 무료이용이라는 이미지를 만들어준 라이선스라고 봐도 무방한 라이선스입니다. GNU 일반 공중 사용 허가서로 불리기도 해서 GNU라는 이름으로도 사용됩니다.
해당 라이선스는 리눅스 커널이 사용하는 라이선스로 리눅스라고 하면 우리가 흔히 알고 있는 오픈소스 기반의 운영체제(OS)로 리눅스가 바로 이 GPL 라이선스의 적용을 받는 가장 대표적인 프로그램입니다.
리처드 매슈 스톨먼이 처음 만들어졌고, 오픈소스 라이선스의 가장 대표 격인 라이선스인지라 가장 강력한 조건을 가지고 있습니다. GPL 라이선스가 적용된 소스코드를 기반으로 개발할 경우 개발한 소스코드 역시 모두 공개해야 합니다.
GPL 라이선스 : 나도 나의 소스코드를 공개했으니 너도 너의 소스코드를 공개하렴
즉, GPL 라이선스의 소스코드는 개발자가 무료 또는 상업적 목적과 상관없이 소스코드를 이용하는 것에 어떠한 제한도 없지만, GPL 라이선스의 소스코드를 어떤 식으로든 사용했다면 전체 소스코드를 공개해야 하는 의무가 있습니다.
이는 다른 말로 저작권을 의미하는 카피라이트와 반대되는 카피레프트라고 불리는 조항인데요. 즉, '자유소프트웨어재단'이라는 이름에 걸맞게 모든 것을 다 오픈할 자신이 있을 때만 본 라이선스를 이용할 수 있습니다.
LGPL - 이용과 배포의 자유, 동일 라이선스 유지, 제한적 소스코드 공개의무
LGPL(Lesser General Public License)은 강압적인 GPL 라이선스 정책으로 인해 오히려 자유로운 소프트웨어를 이용함에 있어 많은 개발자들이 GPL 라이선스를 꺼리는 상황에서 나온 라이선스입니다.
LGPL 라이선스는 기본적인 라이선스 정책은 GPL 라이선스와 동일합니다. 무료 또는 상업적인 구분과 상관없이 소스코드를 이용함에 있어 별다른 제약조건은 없습니다. 또한 LGPL 라이선스를 이용한 소스코드는 LGPL 라이선스의 적용을 받습니다.
LGPL 라이선스 : 네가 나의 소스코드를 그대로 쓰기만 할꺼라면 너의 소스코드는 공개하지 않아도 괜찮아
다만 LGPL 라이선스의 경우 LGPL 라이선스의 소스코드를 그대로 사용하게 될 경우(예를 들면 라이브러리 이용)에는 본인이 작성한 소스코드를 의무적으로 공개하지 않아도 됩니다. 다만 '그대로' 쓰지 않을 경우에는 모든 소스코드를 공개해야 합니다. 예를 들어 LGPL 라이선스의 적용을 받는 소스코드를 일부 수정하거나 해당 라이브러리를 이용하여 파생되는 별도의 라이브러리를 개발하여 이를 배포하게 될 경우에는 전체소스코드를 공개해야 합니다.
MPL - 이용과 배포의 자유, 수정 라이선스 부분만 공개, 소스코드 공개의무 없음
MPL(Mozilla Public License) 라이선스는 모질라 재단에서 만든 라이선스로 라이선스 이용 시 개발자에게 많은 권한을 부여한 라이선스입니다.
해당 라이선스의 경우 다른 라이선스와는 다르게 MPL 소스파일을 이용한 부분에만 라이선스를 적용하고 있습니다.
MPL 라이선스 : 네가 만든 소스코드는 네가 알아서 하시고, 내 거 뭐만 고쳤는지만 알려 줘
MPL 라이선스는 소스코드의 경우 MPL 라이선스를 따르는 소스코드를 수정하게 되면 수정한 소스코드를 MPL 라이선스에 따라 공개해야 하고 수정된 내용을 원저작자에게 알려야 하는 의무사항이 존재합니다. 다르게 이야기하면 만약 내가 MPL 라이선스를 따르는 소스코드를 단순 사용하기만 하면 어떠한 고지도 할 필요가 없다는 의미입니다.
단, 만약 특허기술이 구현된 프로그램에 MPL 라이선스를 사용했을 경우 관련 내용을 'LEGAL' 파일에 기록하여 배포해야 한다는 조건이 있습니다.
BSD - 이용과 배포의 자유, 라이선스 유지여부 자유, 소스코드 공개의무 없음
BSD(Berkeley Software Distribution License) 라이선스는 버클리의 캘리포니아대학에서 배포하는 라이선스로 사실상 라이선스의 의무사항이 있는지 의심스러울 정도로 자유도가 매우 높은 라이선스입니다.
BSD 라이선스 : 너 하고 싶은 대로 다 해도 되는데, 만약에 문제 생기면 그 책임은 나한테 따지면 안 된다?
해당 라이선스의 경우 그 시작이 공공기관에서 만들어진 라이선스라 만들어진 라이선스는 공공이 이용가능해야 한다는 의미가 강하기 때문에 사실상 어떤 제약조건도 없는 것이 특징입니다.
무료 또는 상업적 이용에 아무런 제한도 없고, 소스코드를 수정 또는 재배포 시에도 제한이 없습니다. 그리고 그 과정에서 BSD 라이선스 원작자에게 수정 및 배포에 대한 사실을 알릴 필요도 없고, BSD 라이선스를 기반으로 만들었다는 고지 의무 또한 존재하지 않습니다. 다만, 이 과정에서 발생되는 모든 문제는 사용자에게 책임이 있다는 내용만 명시하고 있다는 점이 제약사항이라면 제약사항입니다.
Apache lilcense - 이용과 배포의 자유, 동일 라이선스 유지, 특허 주장 불가
아파치 라이선스는 아파치 재단에서 만든 라이선스로 라이선스의 제약사항은 BSD와 같은 수준으로 자유로운 것이 특징입니다.
아파치 라이선스는 아파치 재단 내의 소프트웨어에 적용할 목적으로 만들었기 때문에 큰 제약사항은 없는 것이 특징입니다.
Apache 라이선스 : 내 거 썼다고 꼭 남겨줘. 그 외에는 너 맘대로 쓰렴. 아참! 혹시 특허를 주장할 생각이라면 꿈깨
아파치 라이선스의 경우 다른 오픈소스와 마찬가지로 무료 또는 상업적 목적으로의 이용에는 제한사항이 없습니다. 또한 Apache 라이선스를 사용한 소스코드를 공개할 의무도 없습니다. 다만 고지의 의무는 있는 편인데요. 아파치 라이선스를 사용했을 경우 규정 전문을 프로그램 내에 포함시켜야 하고, 수정내용이 있을 경우 수정내용도 고지해야 합니다.
특히 Apache 라이선스의 경우 해당 라이선스를 이용해서 만들어진 프로그램은 특허를 주장할 수 없습니다. 만약 만들고자 하는 프로그램이 특허출원을 염두에 두고 만들 경우 해당 라이선스 사용을 보류하는 것을 권해드립니다.
마치며
지금까지 오픈소스에 대한 내용과 주요 라이선스를 소개했습니다. 해당 라이선스는 어디까지나 전체 오픈소스 라이선스 들 중의 극히 일부에 지나지 않습니다. 또한 해당 라이선스를 이용해서 특허출원 또는 상업적 이용을 염두에 두신 분들이라면 반드시 본인이 이용하려는 오픈소스의 라이선스 정책을 숙지하시고 이용하시기 바랍니다.
오픈소스 라이선스 정리 - GPL, LGPL, MPL, BSD, Apache
개발을 진행하다 보면 의도하든 의도하지 않든 대부분 다른 개발자가 만든 소스를 기반으로 개발을 진행하게 됩니다. 오픈소스 라이선스에 대해서는 개발을 이제 막 처음 시작하거나 혹은 개인적으로 사용할 목적으로 혼자 만들고 혼자 뿌듯해할 경우라면 크게 관심을 가질 필요는 없는 주제일 수 있습니다.
그러나 스타트업을 준비 중이거나 또는 기업을 운영하거나 기업에 속해있는 개발자의 경우 혹시나 내가 가져다 쓴 소스가 법적인 문제가 발생될 소지가 있는지 정도는 알고 있는 것이 좋다고 생각합니다.
이번 포스팅에서 소개하는 라이선스는 일반적으로 알려진 라이선스를 기준하여 간단한 내용만을 다루었습니다. 만약 오픈소스 라이선스의 적용을 받는 프로그램을 이용하게 될 경우에는 반드시 해당 라이선스의 전문을 읽어보시길 바랍니다.
오픈소스란?
오픈소스는 라이선스 방식을 통해 배포된 소스코드를 의미합니다. 해당 라이선스를 기반으로 소스코드를 자유롭게 이용 및 배포까지 가능한데요. 이 과정에서 프로그램을 배포하거나 소스 코드의 접근 권한을 부여하거나 기존의 소스코드를 수정하는 등의 원 소스코드를 자유롭게 만질 수도 있습니다.
여기까지만 읽으면 '아~ 오픈소스는 내가 마음대로 이용할 수 있는 소스코드네?' 정도로 이해할 수 있지만 앞에서도 이야기했듯이 오픈소스는 '라이선스 방식을 통해 배포된 소스코드'입니다. 즉, 소스코드 이용자는 어떤 라이선스 방식을 통해 배포된 소스코드인지 확인하는 과정이 반드시 필요합니다.
깃허브(GitHub)의 소스코드는 오픈소스일까?
팀 프로젝트를 진행하다 보면 깃허브와 같은 버전관리 도구를 이용하게 됩니다. 특히 깃허브는 가장 많은 개발자들이 사용하는 버전관리 도구입니다. 그리고 대부분의 소스코드는 공개되어 있어서 마음만 먹으면 소스코드를 자유롭게 다운로드해서 이용할 수 있는데요. 그렇다면 깃허브(GitHub)의 소스코드는 오픈소스로 봐도 될까요?
정답은 '그때그때 다르다'로 이해할 수 있는데요. 그 이유는 해당 소스코드에 오픈소스 라이선스 방식을 통해 배포된 소스코드인지 명시가 되어 있으면 오픈소스로 이용이 가능하고, 그렇지 않으면 오픈소스로 이용할 수 없습니다.
만약 프로그램을 개발하던 중 'A' 개발자의 깃허브(GitHub)의 소스코드가 꼭 필요하다고 가정해 봅시다. 그럴 경우 우리는 제일 먼저 오픈소스 라이선스가 명시되어 있는지를 확인해야 하는데요. 보통 오픈소스 라이선스가 명시되어 있다면 소스코드 상단에 작성을 하게 됩니다. 만약 이러한 내용이 주석으로 작성되어 있다면 해당 오픈소스 라이선스의 규칙을 찾아보고 그 규칙범위 안에서 소스코드를 자유롭게 이용하면 됩니다. 그러나 이러한 오픈소스 라이선스가 명시되어 있지 않다면 해당 소스는 엄연히 저작권을 가진 소스코드이기 때문에 이용을 원할 경우 원 소스 개발자에게 소스 이용에 대해서 충분한 협의과정을 거쳐야 합니다.
GPL 라이선스 - 이용과 배포의 자유, 동일 라이선스 유지, 소스코드 공개의무
GPL(General Public License) 라이선스는 자유소프트웨어재단에서 만든 라이선스로 오픈소스 라이선스에 대한 추상적으로 가지고 있는 무료이용이라는 이미지를 만들어준 라이선스라고 봐도 무방한 라이선스입니다. GNU 일반 공중 사용 허가서로 불리기도 해서 GNU라는 이름으로도 사용됩니다.
해당 라이선스는 리눅스 커널이 사용하는 라이선스로 리눅스라고 하면 우리가 흔히 알고 있는 오픈소스 기반의 운영체제(OS)로 리눅스가 바로 이 GPL 라이선스의 적용을 받는 가장 대표적인 프로그램입니다.
리처드 매슈 스톨먼이 처음 만들어졌고, 오픈소스 라이선스의 가장 대표 격인 라이선스인지라 가장 강력한 조건을 가지고 있습니다. GPL 라이선스가 적용된 소스코드를 기반으로 개발할 경우 개발한 소스코드 역시 모두 공개해야 합니다.
GPL 라이선스 : 나도 나의 소스코드를 공개했으니 너도 너의 소스코드를 공개하렴
즉, GPL 라이선스의 소스코드는 개발자가 무료 또는 상업적 목적과 상관없이 소스코드를 이용하는 것에 어떠한 제한도 없지만, GPL 라이선스의 소스코드를 어떤 식으로든 사용했다면 전체 소스코드를 공개해야 하는 의무가 있습니다.
이는 다른 말로 저작권을 의미하는 카피라이트와 반대되는 카피레프트라고 불리는 조항인데요. 즉, '자유소프트웨어재단'이라는 이름에 걸맞게 모든 것을 다 오픈할 자신이 있을 때만 본 라이선스를 이용할 수 있습니다.
LGPL - 이용과 배포의 자유, 동일 라이선스 유지, 제한적 소스코드 공개의무
LGPL(Lesser General Public License)은 강압적인 GPL 라이선스 정책으로 인해 오히려 자유로운 소프트웨어를 이용함에 있어 많은 개발자들이 GPL 라이선스를 꺼리는 상황에서 나온 라이선스입니다.
LGPL 라이선스는 기본적인 라이선스 정책은 GPL 라이선스와 동일합니다. 무료 또는 상업적인 구분과 상관없이 소스코드를 이용함에 있어 별다른 제약조건은 없습니다. 또한 LGPL 라이선스를 이용한 소스코드는 LGPL 라이선스의 적용을 받습니다.
LGPL 라이선스 : 네가 나의 소스코드를 그대로 쓰기만 할꺼라면 너의 소스코드는 공개하지 않아도 괜찮아
다만 LGPL 라이선스의 경우 LGPL 라이선스의 소스코드를 그대로 사용하게 될 경우(예를 들면 라이브러리 이용)에는 본인이 작성한 소스코드를 의무적으로 공개하지 않아도 됩니다. 다만 '그대로' 쓰지 않을 경우에는 모든 소스코드를 공개해야 합니다. 예를 들어 LGPL 라이선스의 적용을 받는 소스코드를 일부 수정하거나 해당 라이브러리를 이용하여 파생되는 별도의 라이브러리를 개발하여 이를 배포하게 될 경우에는 전체소스코드를 공개해야 합니다.
MPL - 이용과 배포의 자유, 수정 라이선스 부분만 공개, 소스코드 공개의무 없음
MPL(Mozilla Public License) 라이선스는 모질라 재단에서 만든 라이선스로 라이선스 이용 시 개발자에게 많은 권한을 부여한 라이선스입니다.
해당 라이선스의 경우 다른 라이선스와는 다르게 MPL 소스파일을 이용한 부분에만 라이선스를 적용하고 있습니다.
MPL 라이선스 : 네가 만든 소스코드는 네가 알아서 하시고, 내 거 뭐만 고쳤는지만 알려 줘
MPL 라이선스는 소스코드의 경우 MPL 라이선스를 따르는 소스코드를 수정하게 되면 수정한 소스코드를 MPL 라이선스에 따라 공개해야 하고 수정된 내용을 원저작자에게 알려야 하는 의무사항이 존재합니다. 다르게 이야기하면 만약 내가 MPL 라이선스를 따르는 소스코드를 단순 사용하기만 하면 어떠한 고지도 할 필요가 없다는 의미입니다.
단, 만약 특허기술이 구현된 프로그램에 MPL 라이선스를 사용했을 경우 관련 내용을 'LEGAL' 파일에 기록하여 배포해야 한다는 조건이 있습니다.
BSD - 이용과 배포의 자유, 라이선스 유지여부 자유, 소스코드 공개의무 없음
BSD(Berkeley Software Distribution License) 라이선스는 버클리의 캘리포니아대학에서 배포하는 라이선스로 사실상 라이선스의 의무사항이 있는지 의심스러울 정도로 자유도가 매우 높은 라이선스입니다.
BSD 라이선스 : 너 하고 싶은 대로 다 해도 되는데, 만약에 문제 생기면 그 책임은 나한테 따지면 안 된다?
해당 라이선스의 경우 그 시작이 공공기관에서 만들어진 라이선스라 만들어진 라이선스는 공공이 이용가능해야 한다는 의미가 강하기 때문에 사실상 어떤 제약조건도 없는 것이 특징입니다.
무료 또는 상업적 이용에 아무런 제한도 없고, 소스코드를 수정 또는 재배포 시에도 제한이 없습니다. 그리고 그 과정에서 BSD 라이선스 원작자에게 수정 및 배포에 대한 사실을 알릴 필요도 없고, BSD 라이선스를 기반으로 만들었다는 고지 의무 또한 존재하지 않습니다. 다만, 이 과정에서 발생되는 모든 문제는 사용자에게 책임이 있다는 내용만 명시하고 있다는 점이 제약사항이라면 제약사항입니다.
Apache lilcense - 이용과 배포의 자유, 동일 라이선스 유지, 특허 주장 불가
아파치 라이선스는 아파치 재단에서 만든 라이선스로 라이선스의 제약사항은 BSD와 같은 수준으로 자유로운 것이 특징입니다.
아파치 라이선스는 아파치 재단 내의 소프트웨어에 적용할 목적으로 만들었기 때문에 큰 제약사항은 없는 것이 특징입니다.
Apache 라이선스 : 내 거 썼다고 꼭 남겨줘. 그 외에는 너 맘대로 쓰렴. 아참! 혹시 특허를 주장할 생각이라면 꿈깨
아파치 라이선스의 경우 다른 오픈소스와 마찬가지로 무료 또는 상업적 목적으로의 이용에는 제한사항이 없습니다. 또한 Apache 라이선스를 사용한 소스코드를 공개할 의무도 없습니다. 다만 고지의 의무는 있는 편인데요. 아파치 라이선스를 사용했을 경우 규정 전문을 프로그램 내에 포함시켜야 하고, 수정내용이 있을 경우 수정내용도 고지해야 합니다.
특히 Apache 라이선스의 경우 해당 라이선스를 이용해서 만들어진 프로그램은 특허를 주장할 수 없습니다. 만약 만들고자 하는 프로그램이 특허출원을 염두에 두고 만들 경우 해당 라이선스 사용을 보류하는 것을 권해드립니다.
마치며
지금까지 오픈소스에 대한 내용과 주요 라이선스를 소개했습니다. 해당 라이선스는 어디까지나 전체 오픈소스 라이선스 들 중의 극히 일부에 지나지 않습니다. 또한 해당 라이선스를 이용해서 특허출원 또는 상업적 이용을 염두에 두신 분들이라면 반드시 본인이 이용하려는 오픈소스의 라이선스 정책을 숙지하시고 이용하시기 바랍니다.
