남의 코드 가져다 쓸 때

공개된 코드는 값이 0원일 뿐이고 조건은 0이 아니에요. 이름만 적어 주면 되는 조건도 있고, 내 코드까지 같이 공개하게 만드는 조건도 있어요. 갈리는 지점은 정해져 있어요.

쉽게 말하면

상인회 공용 창고를 떠올려 보세요. 문이 늘 열려 있고 누구나 부품을 꺼내 씁니다. 대신 선반마다 종이가 한 장 붙어 있어요. 어떤 선반은 "가져가서 쓰고, 여기서 가져갔다고 적어 두세요" 한 줄이 전부예요. 어떤 선반은 "이 부품을 넣어 만든 물건은 설계도까지 같이 공개하세요" 라고 적혀 있어요. 문이 열려 있다는 것과 조건이 없다는 것은 다른 말이에요. 종이를 안 읽고 집어 오는 게 사고의 시작이에요.

이 종이가 라이선스예요. 코드를 만든 사람이 "이런 조건이면 써도 좋다"고 미리 써 둔 허락서예요. 돈을 안 받는 대신 조건을 걸어 둔 거라, 조건을 안 지키면 값을 안 낸 것과 같은 상태가 돼요.

이름을 안 받아 둔 경우
납품 확인서 오픈소스 사용: 있음 라이선스: 미기재

이름이 없으면 확인을 안 한 거예요. 나중에 세려면 코드를 처음부터 다시 뒤져야 해요.

이름까지 받아 둔 경우
부품 명세서 지도 표시 · MIT 달력 · Apache 2.0 검색 · AGPL 3.0 (곁가지)

이름이 있으면 판단이 돼요. AGPL 한 줄이 어디에 쓰였는지 오늘 물어볼 수 있어요.

조건은 몇 갈래로 갈려요

라이선스 이름은 수백 종이 있지만, 사장님이 실제로 마주치는 갈래는 몇 개뿐이에요. 이름을 다 외울 필요는 없어요. 어느 갈래인지만 알면 판단이 서요.

갈래대표 이름내가 지킬 것내 코드도 공개?
느슨한 쪽MIT, BSD, Apache 2.0저작권 표기와 라이선스 전문을 결과물에 함께 싣기. Apache 2.0 은 고친 곳을 표시하는 조항이 더 붙어요없어요. 그래서 사업에서 제일 많이 써요
옮겨 붙는 쪽GPL 2.0, GPL 3.0이 코드를 넣은 프로그램을 남에게 건네주면, 그 프로그램 전체를 같은 조건으로 내줘야 해요네. 이게 문제가 되는 갈래예요
서비스까지 미치는 쪽AGPL 3.0파일로 건네주지 않고 웹서비스로만 제공해도, 그 서비스를 쓰는 사람에게 소스를 제공해야 해요네. 웹서비스 사업에는 가장 무서운 갈래예요
선을 그어 둔 절충LGPL, MPL 2.0LGPL 은 그 부품을 갈아 끼울 수 있게 붙였다면 내 코드는 안 열어도 돼요. MPL 은 내가 고친 그 파일만 같은 조건으로 유지해요부분만요
열려 있지만 오픈소스는 아닌 쪽SSPL, BUSL소스는 보이는데 "이걸 그대로 서비스로 팔지 말라" 같은 제한이 붙어요. BUSL 은 만든 회사가 정해 둔 날짜가 지나면 열린 조건으로 바뀌는 구조예요다른 종류의 제약이에요
소프트웨어가 아닌 것CC BY, CC BY-SA, CC BY-NC사진·글·아이콘에 붙는 조건이에요. NC 는 비상업 전용이라 사업에는 못 써요SA 는 같은 조건 유지
종이가 없는 선반LICENSE 파일 없음허락이 없다는 뜻이에요. 공개돼 있다고 해서 써도 된다는 뜻이 아니에요쓰면 안 돼요

이름을 처음 봤을 때

낯선 이름이 나오면 승인된 오픈소스 목록(opensource.org)과 국제 라이선스 목록(SPDX)에서 그 이름을 찾아보세요. 둘 다 없으면 원문을 읽어야 하고, 원문이 애매하면 쓰지 않는 게 답이에요. 애매한 걸 안고 가는 비용이 대체품을 찾는 비용보다 늘 커요.

왜 남의 조건이 내 코드까지 미치나

여기가 이 문서의 핵심이에요. 원리를 알면 표를 안 봐도 판단이 돼요.

  1. 1코드는 만들어진 순간 저작권이 생겨요. 공개했다고 권리가 없어지지 않아요.
  2. 2라이선스는 권리를 포기하는 문서가 아니라 조건부 허락서예요. "이 조건이면 허락한다"는 문장이에요.
  3. 3조건을 어기면 허락이 사라져요. 남는 건 허락 없이 남의 저작물을 쓴 상태예요.
  4. 4그래서 옮겨 붙는 쪽 라이선스는 "내 부품을 쓴 결과물도 같은 조건으로 나눠라"를 조건으로 걸 수 있어요. 그 조건을 지키기 싫으면 부품을 쓰지 않으면 돼요. 강제가 아니라 거래예요.
  5. 5정리하면 이건 전염이 아니라 계약 구조예요. 옆 파일이 자동으로 물드는 게 아니라, 하나로 합쳐진 하나의 결과물을 내보낼 때 그 결과물에 조건이 따라붙어요.

그래서 다툼의 실제 쟁점은 늘 하나예요. 어디까지가 하나의 결과물인가. 갈래마다 이 선이 다르고, LGPL 과 MPL 은 그 선을 문서에 못 박아 둔 절충안이에요.

무너지는 지점은 정해져 있어요

조건은 코드를 넣는 날 발동하지 않아요. 특정 행동을 하는 날 발동해요. 그 행동 목록이 짧아서, 미리 알면 대비가 돼요.

이 일을 하는 순간무엇이 발동하나지금 확인할 것
웹사이트를 공개한다화면을 그리는 코드는 손님 컴퓨터로 그대로 내려가요. 이게 건네주는 행동이에요. 옮겨 붙는 쪽이 화면 코드에 섞였다면 이 순간부터 의무가 생겨요손님에게 내려가는 코드와 서버에만 있는 코드를 갈라서 보기
서버에만 두고 웹으로만 서비스한다GPL 계열은 대개 잠잠해요. 건네준 게 아니니까요. AGPL 은 이때도 발동해요목록에 AGPL 이 한 줄이라도 있는지
앱 스토어에 올린다스토어 약관과 GPL 조건이 충돌해 앱이 내려간 사례가 알려져 있어요. 심사에서 막히거나 등록 후 문제가 돼요앱으로 낼 계획이면 GPL 계열은 시작부터 배제
무료였던 걸 유료로 바꾼다비상업(NC) 조건은 그날부터 위반이에요. 코드는 그대로인데 쓰임새가 바뀌어서 걸려요요금제를 붙이기 전에 NC 가 섞였는지
투자나 매각 실사를 받는다검사 도구로 전체 목록을 자동으로 뽑아요. AGPL 한 줄이 발견되면 조건 조정이나 재작업 요구가 붙고, 거래 일정이 밀려요실사에서 처음 세지 말고 지금 세기
회사 안에서만 쓴다건네준 게 아니라 대부분 조건이 잠잠해요. 다만 협력사나 관계사에 넘기는 것은 건네준 것으로 볼 수 있어요"우리끼리"의 범위가 어디까지인지

손으로 세는 건 불가능해요

직접 고른 부품이 열 개라도, 그 열 개가 데려오는 부품이 수백 개가 돼요. 부품이 또 부품을 쓰기 때문이에요. 그래서 목록은 눈으로 세지 않고 도구로 뽑아요. 정확한 개수는 내 프로젝트에서 뽑아 봐야 알아요. 사람이 할 일은 그 목록에서 옮겨 붙는 쪽과 NC 를 골라내는 것뿐이에요.

쓰면 안 되는 경우

쓰는 법보다 이게 더 중요해요. 아래는 검토 없이 그냥 안 하는 쪽이 싼 경우들이에요.

  1. 1유료로 팔 제품의 심장에 GPL·AGPL 계열을 넣지 않아요. 곁가지라면 조건을 지키며 쓸 수 있지만, 심장에 들어간 건 나중에 빼는 게 아니라 다시 만드는 일이 돼요.
  2. 2비상업(NC)은 사업에서 아예 후보에서 빼요. 지금 무료로 운영해도 사업 홍보 목적이면 다툼의 여지가 있고, 언젠가 돈을 받으면 그날부터 확실한 위반이에요.
  3. 3LICENSE 파일이 없는 저장소는 쓰지 않아요. 별이 많고 유명해도 종이가 없으면 허락이 없어요. 정말 필요하면 만든 사람에게 직접 물어보고 답을 문서로 남겨요.
  4. 4라이선스 전문을 지우거나 만든 사람 이름을 바꾸지 않아요. 조건을 없애는 행동이 아니라 위반을 만드는 행동이에요. 표기를 유지하는 건 대부분 조건 중 가장 쉬운 항목이에요.
  5. 5AI가 짜 준 코드도 그대로 믿지 않아요. 유명한 공개 코드가 통째로 들어오는 경우가 있어요. 낯설게 잘 짜인 큰 덩어리가 나오면 출처를 물어보고, 핵심 부품은 사람이 한 번 확인해요.
  6. 6애매한 상태로 손님에게 내보내지 않아요. 한 번 내려간 코드는 회수할 수 없어서, 뒤늦게 고치면 이미 나간 것에 대한 정리가 따로 필요해요.

실제로 겪는 장면

장면 1 · 외주 개발자가 말했다

오픈소스 쓰면 기간이 반으로 줄어요. 라이선스는 문제없습니다.

맞는 말이고, 실제로 안 쓰는 게 더 위험해요. 다만 "문제없다"는 확인 가능한 형태로 받아야 해요. 어떤 것을 썼고 각각 라이선스 이름이 무엇인지 목록으로 적어 달라고 하세요. 이름을 적지 못하면 확인을 안 한 거예요. 이 요청은 개발 기간을 늘리지 않아요. 도구로 몇 분에 뽑히는 목록이에요.

장면 2 · 투자 실사 담당자가 요구했다

쓰신 오픈소스 목록 주세요. AGPL 있으면 조건 조정하고 넘어가야 합니다.

실사에서 처음 세면 늦어요. 개발을 시작할 때 목록을 만들어 두는 비용은 거의 0인데, 다 만든 뒤에 바꾸는 비용은 재작업이에요. 순서를 바꾸는 것만으로 아끼는 돈이라, 이 문서에서 가장 실용적인 한 줄이에요.

장면 3 · 권리자 쪽에서 메일이 왔다

귀사 서비스가 해당 라이브러리를 사용하면서 저작권 표기와 라이선스 전문을 포함하지 않았습니다. 조치를 요청합니다.

첫 연락은 대개 소송이 아니라 시정 요구예요. 이 사례처럼 표기를 빠뜨린 것뿐이면 고지 화면을 만들어 넣는 것으로 끝나는 경우가 많아요. 사고를 만드는 건 위반 자체보다 무시예요. 답을 안 하면 요구 수준이 올라가요.

남에게 맡길 때

외주에 맡기든 직원이 만들든, 나중에 책임은 사장님 이름으로 남아요. 그래서 계약 단계에서 요구할 것과 납품 때 확인할 것을 나눠 두면 편해요.

발주·계약 때 요구할 것납품 때 확인할 것
쓴 남의 코드 목록(이름과 라이선스가 적힌 부품 명세서)을 납품물에 포함목록 파일이 실제로 있고, 코드에 든 것과 개수가 대충이라도 맞나
GPL·AGPL 계열은 사전 승인 없이 쓰지 않는다는 조항목록에 그 계열이 있나. 있다면 심장인가 곁가지인가
라이선스 고지 화면(또는 페이지) 포함그 화면이 실제로 열리고, 목록이 비어 있지 않나
원본 LICENSE·NOTICE 파일을 지우지 않고 유지파일이 남아 있나. 지웠다가 나중에 복구하는 게 더 번거로워요
제3자 권리 침해가 없다는 보증과, 문제가 생겼을 때의 대응 책임말이 아니라 계약서 문장으로 남았나
폰트·아이콘·사진은 코드와 별도 목록으로시안에만 유료 글꼴이 쓰이고 라이선스는 안 산 상태가 아닌지

내 결과물에서 직접 확인하는 게 정확해요

말로 듣는 것보다 내려받은 코드 안을 보는 게 정확해요. 바이브캠퍼스에서 만든 것도 내려받아 다른 곳으로 옮길 수 있으니, 무엇이 섞여 있는지는 그 폴더 안에서 확인하면 돼요.

자주 묻는 것

Q. 오픈소스는 공짜인 줄 알았어요
돈은 대개 안 내요. 대가가 조건 지키기예요. 값이 0원인 것과 의무가 0인 것은 다른 말이에요. 그리고 실제로 가장 많이 쓰이는 갈래는 조건이 아주 가벼워요.
Q. 그럼 결국 대부분은 표기만 하면 되는 건가요?
네. 사업에서 실제로 쓰는 것들 상당수가 저작권 표기와 라이선스 전문 동봉이 조건의 전부예요. 그래서 고지 화면 하나를 만들어 두는 게 가장 값싼 대비예요. 한 번 만들면 계속 쓰니까요.
Q. 내 코드를 공개하게 되면 남이 베끼는 거잖아요
공개 의무가 있는 갈래를 골랐을 때만 생기는 일이에요. 안 고르면 안 생겨요. 그래서 무엇을 쓸지 고르는 시점이 유일하게 값싼 결정 지점이에요.
Q. 이미 넣어버렸어요. 어떻게 하나요?
순서가 있어요. 어디에 얼마나 들어갔는지 확인 → 대체품이 있는지 → 조건을 지키면서 갈 수 있는지 → 만든 쪽이 유료 상업 라이선스를 따로 파는지. 마지막 방법이 의외로 흔해요. 같은 코드를 조건 없이 쓰게 해 주는 유료 라이선스를 파는 프로젝트가 많아요.
Q. 회사 안에서만 쓰면 안전한가요?
건네주는 행동이 아니라 대부분 잠잠해요. 다만 관계사나 협력사에 넘기는 것, 그리고 웹으로 외부에 서비스하는 것은 다르게 볼 수 있어요. AGPL 은 웹 제공만으로도 발동해요.
Q. 위반하면 얼마를 물어야 하나요?
여기서 단정하지 않아요. 사안마다 다르고 나라마다 달라요. 실제로 요구를 받았다면 한국저작권위원회 상담 창구나 저작권·IT 계약 경험이 있는 변호사에게 확인하세요. 확실한 건 하나예요. 초기 대응으로 끝나는 경우가 압도적으로 많아요.

확인해 보세요

내 서버에서만 돌리고 손님에게는 웹으로만 보여줘요. 소스를 내줘야 하는 쪽은?

하나 더

무료로 운영해 온 서비스에 유료 요금제를 붙이려고 해요. 코드에 비상업(NC) 조건이 하나 섞여 있어요.

직접 해보기

내 결과물 안에 무엇이 섞였는지 보세요

스튜디오에서 만든 결과물은 내려받아 다른 곳으로 옮길 수 있어요. 내려받은 폴더에서 LICENSE 나 license 라는 이름을 찾아보세요. 하나도 없다면 아직 남의 코드가 안 섞였다는 뜻일 수도 있고, 목록을 아직 안 만든 상태일 수도 있어요. 어느 쪽인지 아는 것이 시작점이에요.

스튜디오 열기

더 깊이 (안 읽어도 괜찮아요)

"전염"이라는 말이 오해를 만들어요 · 옆에 있는 파일까지 자동으로 물드는 게 아니에요. 하나로 합쳐진 하나의 결과물을 내보낼 때, 그 결과물 전체가 같은 조건으로 나가야 한다는 뜻이에요. 그래서 실제 쟁점은 늘 "어디까지가 하나인가"예요. 부품을 갈아 끼울 수 있게 느슨하게 붙였는지, 아예 한 몸으로 녹여 넣었는지에 따라 답이 달라져요. 개발자에게 물어볼 정확한 질문은 "이거 어떻게 붙였어요"예요.

비유가 어디부터 다른가 · 공용 창고 비유는 "조건이 붙는다"까지만 맞아요. 창고에서 빌린 물건은 반납하면 끝인데, 코드 조건은 이미 내보낸 결과물에 계속 붙어 있어요. 한 번 손님 컴퓨터로 내려간 코드는 회수할 수 없거든요. 그래서 뒤늦게 고칠 때는 앞으로 나갈 것을 고치는 일과 이미 나간 것을 정리하는 일이 따로 생겨요.

고지 화면은 한 번 만들면 자산이에요 · 설정 안쪽에 오픈소스 라이선스 목록이 들어 있는 앱을 본 적 있을 거예요. 그게 이 문서의 결론이에요. 목록을 도구로 뽑아 한 화면에 넣어 두면 느슨한 쪽 조건은 사실상 전부 충족돼요. 앱을 스토어에 낼 때도 이 화면을 요구받는 경우가 많아서, 미리 만들어 두면 두 번 일하지 않아요.

확인처 · 라이선스 이름 확인은 opensource.org 승인 목록과 SPDX 라이선스 목록. 조건 원문은 각 저장소의 LICENSE 파일. 국내 상담은 한국저작권위원회. 계약 조항과 실제 분쟁은 저작권·IT 계약 경험이 있는 변호사예요. 라이선스 해석을 블로그 요약으로 끝내지 않는 게 이 주제의 유일한 안전장치예요.

이것만 기억하세요

  • ·공개된 코드는 값이 0원일 뿐이고 조건은 0이 아니에요
  • ·느슨한 쪽은 표기만, 옮겨 붙는 쪽은 내 코드까지 공개하게 만들어요
  • ·조건은 넣는 날이 아니라 내보내는 날 발동해요. AGPL 은 웹 제공만으로도요
  • ·유료로 팔 제품의 심장과 비상업(NC)은 처음부터 후보에서 빼요
  • ·맡길 때는 부품 명세서를 요구하고, 납품 때 고지 화면이 열리는지 확인해요
VibeCampusNew build