Permissive 라이선스는 동작을 할까?

Permissive 라이선스는 동작을 할까?

오픈소스 관련하여 가장 사람들이 의구심을 갖는 포인트 가운데 하나는 '가져다 쓰고 좋게 수정하거나, 추가한 코드를 공개하지 않는 것을 허용하는 라이선스'를 가진 요즘 대부분의 오픈소스 소프트웨어에 관한 것입니다. 즉 가져다 쓰기만 히고 기여는 안하지 않을까? 하는 의구심입니다.

기본적으로 라이선스는 저작물 이용에 관한 권리(와 의무)를 정의한 계약서로, 소프트웨어를 만든 쪽과 이용하는 쪽 양쪽의 경제적, 비경제적 이득이 최대가 되는 조건을 합의하는 문서입니다. 특히 오픈소스 소프트웨어의 라이선스는 수 많은 기여자들의 공유와 헌신 그리고 공유를 결심할 때 기여자들이 마음속에 담고 있던 오픈소스 소프트웨어게 관한 철학을 담고 있습니다. 오픈소스 소프트웨어의 저작권에 있어서 문구보다 실제 소프트웨어 개발자의 의도가 훨씬 더 중요한 이유입니다.

오픈소스 소프트웨어 라이선스 종류는 엄청나게 많습니다. OSI라는 곳에서 '이렇게 하면 오픈소스 라이선스다'라고 정의를 했는데, 그 기준에 맞다고 나열한 것들도 수 십 개나 됩니다.

그걸 분류하면 크게 3.5 그룹 정도로 나눌 수 있습니다. 

1. (Permissive) 내가 오픈했는데, 이거 가져다 쓰고, 혹시 고치거나, 추가한 것이 있어도, 꼭 공개할 필요는 없어. 

2. (Weakly Protective) 내가 오픈한 걸 가져다 뭘 만들어 배포했는데, 수정하지 않은 내 꺼가 네가 만든 실행 프로그램의 일부이지만 동적으로 분리되어 로드되는 라이브러리로 돌아갈 때는 공개하지 않아도 되. 혹시 내 꺼를 수정했다면 수정된 내 꺼 부분은 공개해야 되. 

3. (Strongly Protective) 내가 오픈한 걸 가져다 뭘 만들어 배포했는데, 네가 만든 것이 그냥 별도의 프로그램처럼 실행될 때는 공개하지 않아도 되. 그런데 한 프로그램으로 돈다면 네가 수정하고, 추가한 모든 건 다 공개해야 되. 

3.5 (Network Protective) 3번 처럼했는데, 제품이나 프로그램으로 배포하지 않고, 내꺼를 네 서버에 올려놓고 서비스만 했더라도 같은 조건이야.

출처: http://www.dwheeler.com/essays/floss-license-slide.html

오늘의 본론.. 

이글은 여기서 요즘 많은 회사들이 적용하고 있는 Apache 계열 라이선스가 속하는 1번, Permissive 라이선스에 관한 이야기 입니다.

즉, 처음 질문을 다시하면 이런 거죠.

• 우리가 오픈했는데 다른 회사들은 우리껄 가져다 더 좋은 거 만들고, 정작 그 좋은 걸 오픈하지 않으면, 우리만 좋은 일 한거 아닌가? 그 회사는 별 노력도 없이 쉽게 돈버는 거 아닌가?

• 우리가 오픈하면, 사람들이 더 좋게 만들어 줄 것을 기대했는데, 다들 가져다 쓰기만 하고, 우리 프로젝트는 계속 우리에 의해서만 유지, 개선되는 거 아닌가?

그 문제에 대한 답은 기술 부채라는 단어에서 찾을 수 있는데요. '기술 부채'라는 단어는 다양한 의미를 가질 텐데 저는 "릴리즈가 포함된 코드"는 모두 '기술 부채'로 분류하면 된다로 생각합니다. (좀 더 자세한 '기술 부채'에 대하여는 '@이호성 님의 기술 부채' - https://brunch.co.kr/@leehosung/2 글이 비교적 쉬운 글입니다. 이 밖에도 검색을 해보시면 주옥같은 글들이 많습니다.)

우리의 질문에서 우리껄 가져다 쓴 사람 입장에서, 기술 부채 관점으로 설명하면

1. 남의 소스를 가져다가 (부채를 떠안은 것이고)

2. 버그 수정하고 (이자를 조정한 뒤에)

3. 고객에 맞게 수정하고 (부채를 늘린 것이고)

4. 새로운 기능 추가해서 (새로운 부채를 만든 것이고)

5. 고객에 릴리즈 (차용증까지 쓴 것입니다.)

이후 1번 단계에서 가져온 커뮤니티 소스가 수정되면, 새 버전에 대하여 1번,2번,3번,4번,5번을 계속 반복해야하는데 이 장면이 전혀 부가가치가 없다는 것이므로 (즉 부채를 갚는 과정에 불과하다는 것) 해서는 안되는 일입니다. 이 과정이 반복되면, 내 코드엔 부채가 복리로 쌓이게 됩니다.

그래서 더 효과적인 방법은

남의 소스(커뮤니티 버전)는 그대로 두고, 즉 부채를 가져오지 않고, 버그 수정하고, 기능 수정하고, 기능 추가한 결과를 원래 남의 소스에 적극적으로 반영하여 (pull-request) 내 고객을 위한 소스와 원래 남의 소스를 동기화 하면 나중에 남의 소스가 바뀌어도 내가 수정한 부분, 추가한 부분 새로운 기능이 그대로 남아 있거나, (나를 포함한) 커뮤니티에 의해 더 좋아져 있을 것입니다.

내가 그 코드가 좋다고 가져다 쓸 정도면, 높은 확률로 다른 사람들도 그 코드를 가져다 썼을 것이고, 그들도 모두 새로운 새로운 기능에 대한 요구가 있었을 것이고, 나는 찾지 못했던 버그를 수정했을 것입니다. 그 결과 커뮤니티 버전은 지속적으로 개선되어 있을 것이고요. 그 커뮤니티가 추가한 새로운 기능들이라는 것이 다들 비슷하게 발전하는 시장에서 일하기 때문에, 미래의 나 또는 내 고객이 원하는 기능일 가능성이 매우 높습니다.

그 결과 다른 새로운 고객이나, 기존 고객의 새로운 기능 요구에 대응할 때, 위 2,3,4과정의 반복없이 최신의 (내 이전 고객과, 내 새로운 고객이 원하는 기능의 일부가 이미 포함되어 있는) 새 버전을 기반으로, 나는 정말 해야할 일, 즉 부가가치가 생기는 일만 할 수 있게 됩니다.

그래서 Permissive한 라이선스를 사용해도, 그 코드를 가져다 쓴 쪽에서는 자기가 수정한, 추가한 기능을 적극적으로 upstream(쉽게 말하면, 원래 내가 가져왔던 코드)에 반영(즉 기여)하여 커뮤니티 버전을 발전 시키는 (내 버전과 sync를 맞추는) 것이 이득인 것입니다.

맞아요? 안 맞아요?

요약 그림 1 - 가져다 쓰고 기여를 하지 않은 경우

요약 그림 2 - Permissive 라이선스가 동작하는 이유

*