오픈소스를 섞어 쓴 코드도 영업비밀·저작권으로 보호받나요? 「오픈소스라서 안 된다」는 항변을 배척한 판결들

퇴사한 개발자가 경쟁사로 옮기거나 협력사가 납품받은 코드를 다른 곳에 쓴 사건에서, 코드를 가져간 쪽이 꺼내는 주장 가운데 하나가 있습니다. 「그 코드는 원래 인터넷에 공개된 오픈소스로 만든 것이니 비밀도 아니고 창작물도 아니다」라는 항변입니다. 개발 과정에서 오픈소스를 활용한 회사라면, 코드 주인으로서 이 항변이 받아들여질지 궁금할 수 있습니다. 이 글은 판결 검색 서비스에서 이 항변이 실제로 다투어진 판결을 찾아 읽고, 법원이 어떤 경우에 이 항변을 물리쳤고 어떤 경우에 받아들였는지를 정리했습니다. 미리 정리하면 오픈소스를 썼다는 사실만으로 보호가 사라진 판결은 드물었지만, 오픈소스 덕분에 상대방이 이긴 판결도 분명히 있었습니다.

핵심 요약 이 글이 읽은 오픈소스 관련 판결 21건 가운데 17건에서 법원은 「공개된 오픈소스를 썼으니 비밀도 창작성도 없다」는 항변을 받아들이지 않았습니다. 대법원은 GPL 조건이 붙은 프로그램을 고쳐 만든 프로그램의 원시코드도 실제로 공개되지 않았다면 영업비밀이 될 수 있다고 보았고, 하급심은 어떤 오픈소스를 고르고 어떻게 고치고 조합했는지와 결과물 자체가 공개됐는지를 기준으로 삼았습니다. 반면 대부분이 공개 코드이고 몇 시간이면 작성할 수 있는 짧은 코드는 보호받지 못했고, 코드에 남은 「오픈소스로서 배포·수정 가능」 표시가 형사 고의를 부정하는 사정이 된 예도 있었습니다. 자기 코드를 지키려는 회사는 자사가 직접 고치거나 더한 부분과 사용한 오픈소스 목록을 구분해 기록해 두는 것이 다툼에서 도움이 될 수 있을 것으로 보입니다. 다만 라이선스 위반에 따른 책임은 별개의 문제이고 이 글은 그 문제를 다루지 않습니다.

이 글은 어떤 판결을 읽었나요?

이 글이 읽은 판결은 오픈소스나 공개 코드가 보호 여부 판단에 실제로 쓰인 21건이고, 같은 사건의 1심·항소심·상고심을 하나로 묶으면 17개 사건입니다. 판결 21건 가운데 법원이 「오픈소스라서 보호되지 않는다」는 취지의 항변을 배척한 것은 17건이었고, 오픈소스라는 사정 때문에 일부 코드의 보호가 부정되거나 무죄의 이유가 된 것은 3건이었습니다. 나머지 1건은 판결문에서 그런 항변을 찾지 못했고, 법원이 오픈소스와의 대조 결과를 창작성 판단의 근거로 쓴 판결입니다. 감정이나 검출 도구로 오픈소스 부분을 걸러 내거나 대조한 방식이 판결문에 나온 것은 13건이었습니다. 이 숫자는 이 글이 찾아 읽은 판결에 한정된 것이고, 국내 판결 전체의 경향을 보여 주는 통계로 읽어서는 안 됩니다.

판결에 적용된 영업비밀의 정의도 짚어 둘 필요가 있습니다. 현행 「부정경쟁방지 및 영업비밀보호에 관한 법률」(이하 "부정경쟁방지법") 제2조 제2호는 영업비밀을 「공공연히 알려져 있지 아니하고 독립된 경제적 가치를 가지는 것으로서, 비밀로 관리된」 기술상 또는 경영상의 정보로 정의합니다. 그런데 대법원 2006도8369 사건처럼 선고가 오래된 판결들이 적용한 것은 이와 달리 비밀이 「상당한 노력에 의하여 비밀로 유지된」 것이어야 한다는 당시의 문언이었습니다. 따라서 비밀관리에 관한 판단 부분은 당시 문언과 현행 문언이 다르다는 점을 감안해 읽어야 합니다.

GPL 조건이 붙은 프로그램을 고쳐 만든 코드도 영업비밀인가요?

이 질문에 정면으로 답한 판결이 대법원 2006도8369 판결입니다. 이 사건의 회사는 GPL(General Public License, 일반공중사용허가서) 조건이 붙어 공개된 VPN 프로그램을 개작해 자사 프로그램을 만들었고, 그 원시코드는 공개하지 않았습니다. 그 뒤 회사의 전 임원 등이 이 소스코드를 경쟁 사업에 썼다는 이유로 영업비밀 침해 혐의를 받았습니다. 피고인들은 두 가지를 주장했습니다. 하나는 GPL에 따라 소스코드를 공개해야 할 의무가 있으므로 애초에 비밀이 될 수 없다는 것이고, 다른 하나는 회사가 GPL을 어겼으니 정당한 권리자가 아니라는 것이었습니다.

대법원은 두 주장을 모두 받아들이지 않았습니다. 대법원은 먼저 「원 프로그램을 개작한 2차적 프로그램의 저작권은 원 프로그램 저작권자의 동의 여부를 불문하고 2차적 프로그램 작성자에게 귀속되고」라고 하여, 개작 프로그램의 권리가 고친 쪽에 있다고 보았습니다. 다만 이 결론에는 개작 프로그램이 원 프로그램에 비해 「새로운 프로그램이라고 할 정도의 창작성」을 갖추어야 한다는 전제가 붙어 있습니다. 이어서 대법원은 「비록 공소외 1 주식회사가 … 원시코드의 공개를 거부함으로써 GPL을 위반하였다고 하더라도, 공소외 1 주식회사가 …의 저작권자에 대하여 그로 인한 손해배상책임 등을 부담하는 것은 별론으로 하고,」라고 하면서, 원시코드가 비공지성·경제적 가치·비밀유지의 요건을 갖추었다면 영업비밀에 해당한다는 원심 판단이 옳다고 했습니다(대법원 2009. 2. 12. 선고 2006도8369 판결).

원심은 공개 의무와 실제 공개를 더 분명하게 나누었습니다. 원심은 공개를 거부한 회사가 원 프로그램 저작권자에게 개작권 침해 책임을 질 수는 있다고 보면서도, 그 관계는 「원프로그램의 저작권자와 개작프로그램의 작성자 사이의 원프로그램에 대한 일종의 이용허락계약관계에 불과할 뿐이고, 개작프로그램이 실제로 일반 공중에게 공개되지 아니하였다면, 개작프로그램이 공개된 원프로그램을 개작한 것이라는 이유만으로 일반 공중에게 공개된 것으로 취급되어야 한다고 볼 수는 없다.」고 판단했습니다(서울중앙지방법원 2006. 11. 1. 선고 2005노3002 판결). 결국 피고인들에 대한 원심의 형(2명 징역 8월, 2명 징역 6월, 각 집행유예 1년)이 그대로 유지됐습니다. 원심이 일부 무죄로 본 부분은 장비에서 실행파일을 쉽게 떼어 낼 수 있었다는 사정 때문이었고, 오픈소스와는 관계가 없었습니다.

이 판결을 읽을 때 주의할 점이 있습니다. 대법원이 판단한 것은 개작 프로그램의 원시코드가 영업비밀에 해당하는지였고, 회사가 GPL을 어겨도 된다는 것이 아니었습니다. 대법원은 원 저작권자에 대한 손해배상책임 같은 라이선스 위반의 결과를 「별론」으로 남겨 두었습니다. 따라서 이 판결은 공개 의무를 다하지 않은 회사도 그 코드를 빼내 간 사람에게는 영업비밀을 주장할 수 있다는 의미로 보이고, 공개 의무 자체가 사라진다는 의미로 읽기는 어렵습니다. GPL 문제를 다룬 다른 형사 판결도 같은 방향이었습니다. 서울남부지방법원 2015고단3010 판결에서 피고인은 문제의 프로그램이 공개된 ProperJavaRDP를 개작한 것이라 GPL에 따라 공개되어야 하므로 영업비밀이 아니라고 주장했으나, 법원은 영업비밀의 정의를 들어 이 주장을 배척하고 징역 6월에 집행유예 2년을 선고했습니다(서울남부지방법원 2018. 9. 7. 선고 2015고단3010 판결, 항소기각 2018노1758 확정). 이 판결은 GPL에 관한 법리를 따로 설명하지는 않았습니다.

법원은 왜 「오픈소스를 썼으니 비밀이 아니다」라는 항변을 받지 않았나요?

GPL 사건이 아니어도, 공개 코드를 가져다 썼다는 항변은 여러 하급심에서 다투어졌습니다. 판결들이 항변을 물리친 이유는 크게 세 갈래로 정리됩니다.

첫째, 법원은 어떤 오픈소스를 고르고 어떻게 엮었는지 자체를 개발자의 기술력으로 보았습니다. 서울중앙지방법원 2016노3163 판결은 「프로그램 개발자는 수많은 오픈소스 중 어떤 부분을 선택할지, 선택한 부분을 어떤 방식으로 배열하고 개변할지에 관하여 상당한 수준의 개발 작업을 거칠 수밖에 없다」고 보았습니다(서울중앙지방법원 2017. 2. 15. 선고 2016노3163 판결). 그 1심도 「공개된 소스파일을 이용목적에 맞게끔 수정·조합하여 필요한 제품을 구동할 수 있도록 구현하는 것도 기술력의 중요한 부분이고」라고 판단했습니다(서울중앙지방법원 2016. 8. 11. 선고 2013고단7560 판결). 대전지방법원의 형사 항소심은 한 걸음 더 나아가, 공개된 소스코드가 일부 들어 있더라도 「공개된 소스코드들이 나머지 부분들과 유기적으로 수정·조합된 것이 전체로서 영업비밀이 된다고 봄이 타당하다.」고 했습니다(대전지방법원 2023. 1. 18. 선고 2020노1107 판결, 상고기각). 이 사건에서 감정상 유사도는 전체 기준 1.5%, 오픈소스를 뺀 기준 1.3%였는데, 법원은 수치가 낮다는 사정만으로 피고인이 코드를 활용하지 않았다고 보기는 어렵다고 판단했습니다.

둘째, 재료가 공개되어 있다는 것과 완성된 결과물이 공개되어 있다는 것은 별개로 판단됐습니다. 앞의 2016노3163 판결은 문제가 된 파일들에 관해 「위 1 내지 13번 각 파일 자체가 공개되어 있는 것은 아니다」라고 하여, 결과물 파일이 공개된 적이 없다는 점을 근거로 삼았습니다. 이 판결에서 피고인 2명에게는 각각 징역 4월과 징역 1년 6월이 선고되고 형의 집행이 유예됐습니다. 수원지방법원의 형사 항소심도 같은 구조였습니다. 1심은 문제 부분이 오픈소스이거나 공지된 기술, 또는 개발자라면 쉽게 만들 수 있는 단순 기능함수로 볼 여지가 많다는 점 등을 들어 무죄로 판단했습니다. 그러나 항소심은 감정상 일부 파일만 오픈소스였고 나머지 파일들에 대해서는 오픈소스라는 의견이 없었다는 점 등을 보고 1심을 파기해, 징역 10월에 집행유예 2년, 법인에 벌금 1,000만 원을 선고했습니다(수원지방법원 2023. 11. 30. 선고 2020노5599 판결).

셋째, 오픈소스를 출발점으로 삼았더라도 자사 장비나 시스템에 맞추는 데 든 비용과 노력이 인정됐습니다. 서울중앙지방법원 2021가합551365 판결은 코드가 대부분 오픈소스라는 피고의 주장에 증거가 없다고 보았습니다. 나아가 법원은 설령 오픈소스를 이용했더라도 장비 사양에 맞추어 개별화하는 데 「상당한 시간, 노력 및 비용이 들었으리라고 추단할 수 있다」고 판단해 2,000만 원의 배상을 인정했습니다(서울중앙지방법원 2023. 8. 25. 선고 2021가합551365 판결, 항소기각 확정).

저작권 침해를 다툰 민사 사건에서도 판단의 방향은 비슷했습니다. 서울고등법원 2016나8574 사건에서 피고는 원고 코드가 공개된 소스를 쓴 것이어서 창작성이 없다고 항변했지만, 법원은 이를 배척하고 「이 사건 소스코드는 저작물로서의 창작성이 충분히 인정된다」고 보았습니다. 이 사건에서는 침해 금지·삭제와 함께 10억 원의 지급이 명해졌습니다(서울고등법원 2019. 7. 18. 선고 2016나8574 판결, 대법원 상고기각).

감정에서는 오픈소스 부분을 어떻게 걸러 냈나요?

오픈소스 항변이 나온 사건에서는 「어느 부분이 오픈소스이고 어느 부분이 회사가 쓴 것인가」를 가리는 감정이 자주 쓰였습니다. 물론 결론은 감정만이 아니라 비밀관리, 경제적 가치, 형사 사건의 고의 같은 다른 쟁점에도 달려 있었습니다.

앞의 2016나8574 사건의 감정은 오픈소스 부분과 통합개발환경(IDE)이 자동으로 생성한 부분을 유사도 계산에서 뺐습니다. 다만 원고가 고유한 기능을 구현하려고 오픈소스를 고친 부분은 빼지 않고 계산에 넣었습니다. 어떤 부분이 오픈소스인지는 소스 주석, 피고가 제시한 목록, 한국저작권위원회의 검색 도구 CodeEye로 유사율 50%를 기준으로 판정했습니다. 다른 판결들에서도 검출 결과가 판단의 근거가 됐습니다. 서울고등법원 2014나2011824 판결에서는 코드아이 검사 결과 「7개 java 파일 모두에서 공개소프트웨어를 발견하지 못하였다」는 점이 확인됐고, 공동으로 4,000만 원 등의 지급이 명해졌습니다(서울고등법원 2018. 1. 11. 선고 2014나2011824 판결). 서울남부지방법원 2020가합100834 판결에서는 한국저작권위원회가 「오픈소스 라이선스가 적용된 소스코드가 이 사건 소스코드에서 검출되지 않았다」는 결과를 냈고, 법원은 62,070,464원의 지급을 명했습니다(서울남부지방법원 2023. 11. 3. 선고 2020가합100834 판결). 같은 법원의 2020가합118927 판결은 오픈소스 라이선스가 명시된 파일이 없었고 피고가 어떤 오픈소스 코드인지 구체적으로 밝히지도 않았다는 점을 들어 3,500만 원을 인정했습니다(서울남부지방법원 2024. 8. 23. 선고 2020가합118927 판결).

반대 방향의 요청, 즉 같은 도구를 썼으니 그 부분을 비교에서 빼 달라는 주장도 받아들여지지 않은 예가 있습니다. 서울중앙지방법원 2022가합564023 판결에서 피고들은 상용 프로그램·오픈소스 라이브러리·템플릿을 쓴 부분을 유사성 판단에서 제외해야 한다고 주장했습니다. 법원은 그런 도구를 함께 썼다는 이유만으로 「감정대상에서 제외하는 것은 적절하지 않다」고 보았고, 피고들이 공동으로 380,372,973원 등을 지급하라고 판단했습니다(서울중앙지방법원 2026. 3. 24. 선고 2022가합564023 판결, 항소 여부 미확인).

이 판결들을 함께 보면, 법원은 오픈소스라는 주장을 막연한 일반론으로 받아들이지 않고 어떤 파일의 어떤 코드가 공개된 것인지를 구체적으로 확인하려 했던 것으로 보입니다. 상대방이 구체적인 오픈소스 코드를 대지 못하거나 검출 도구에서 일치가 나오지 않으면 항변은 힘을 잃었습니다.

그래도 오픈소스 때문에 보호받지 못한 경우는 없었나요?

있었습니다. 앞의 판결들만 보면 오픈소스 항변은 거의 통하지 않는 것처럼 보이지만, 이 글이 읽은 판결 중 3건은 오픈소스라는 사정이 회사에 불리하게 작용했습니다. 이 사례들은 회사가 무엇을 기록해 두어야 하는지를 거꾸로 보여 줍니다.

첫 번째는 짧고 손이 적게 간 코드입니다. 서울중앙지방법원 2013노2300 사건에서 문제가 된 예외처리 소스코드 3개 파일은 각각 25줄·13줄·88줄이었습니다. 법원은 이 코드의 상당 부분이 공개소스를 기초로 했고, 작성에 1시간에서 2시간이면 충분하다는 증언이 있었던 점 등을 들어 「그 개발에 상당한 정도의 비용이나 노력이 필요하지는 않은 것으로 보이는 점」을 인정했습니다. 그 결과 이 코드는 영업비밀이나 영업상 주요 자산으로 인정되지 않았고 무죄가 유지됐습니다(서울중앙지방법원 2013. 11. 29. 선고 2013노2300 판결, 상고기각). 다만 같은 판결에서 공개된 기반기술 위에 설계한 플랫폼 정의서는 영업비밀로 인정됐습니다. 같은 사실관계를 다룬 민사 사건에서도 결론이 비슷했습니다. 민사 1심은 예외처리 코드까지 영업비밀로 보았지만(서울중앙지방법원 2013. 11. 14. 선고 2010가합53704 판결), 항소심은 한국저작권위원회 감정인이 「오픈소스를 사용한 부분이 상당한 것이기 때문에 비공지성도 희박하다」고 진술한 점 등을 들어 그 코드를 영업비밀로 보지 않았습니다(서울고등법원 2017. 4. 27. 선고 2013나77388 판결). 이 항소심에서도 정의서는 영업비밀로 인정됐고, 원고만 항소했기 때문에 1심이 인정한 3,000만 원은 그대로 유지됐습니다.

두 번째는 코드에 남은 표시가 문제가 된 경우입니다. 서울중앙지방법원 2018노1796 사건의 1심은 해당 소스코드가 공개를 전제로 하는 오픈소스라는 이유로 무죄를 선고했습니다. 항소심은 오픈소스 식별 시스템 두 가지로 확인한 결과 일치하는 코드가 나오지 않았다며 1심의 이 이유는 받아들이지 않았습니다. 그러나 항소심은 소스코드 서두에 「오픈소스로서 배포 및 수정이 가능하다」는 표시가 있었던 점 등을 들어 피고인에게 업무상배임의 고의가 있었다고 인정하기 어렵다고 보고, 무죄 결론을 유지했습니다(서울중앙지방법원 2019. 5. 31. 선고 2018노1796 판결). 항소심이 그 코드를 공개를 전제로 한 오픈소스로 볼 수 없다고 판단했는데도, 코드 안의 표시가 형사책임을 가르는 사정이 된 것입니다.

세 번째로, 침해가 인정되면서도 오픈소스의 비중이 침해금지기간을 정하는 사정으로 고려된 사례가 있습니다. 서울중앙지방법원 2016카합81253 가처분 사건에서 법원은 오픈소스코드에는 없는 함수가 채무자 제품에서 발견된 점을 근거로 침해를 인정했습니다. 그런데 채무자 제품의 소스코드는 대부분 오픈소스였고, 오픈소스를 제외하고 나면 유사한 파일은 전체 7,417개 가운데 3개뿐이었습니다. 법원은 이런 사정 등을 고려해 침해금지기간을 정했습니다(서울중앙지방법원 2017. 5. 1. 2016카합81253 결정). 이 결정은 오픈소스가 섞여 있다는 사정이 침해 여부가 아니라 금지의 기간을 정하는 데 반영될 수 있다는 점을 보여 줍니다.

세 사례의 쟁점은 서로 다릅니다. 첫 번째는 코드가 보호할 만한 비밀인지, 두 번째는 형사 고의, 세 번째는 금지기간의 문제였습니다. 다만 첫 번째 사례에서는 손이 적게 간 짧은 코드가 보호받지 못한 반면, 같은 판결에서 회사가 따로 설계한 문서는 보호를 받았다는 점이 눈에 띕니다.

회사는 무엇을 해 두어야 하나요?

위 판결에서 바로 끌어낼 수 있는 점검 항목은 다음 네 가지입니다. 회사가 이 항목을 갖추었다고 해서 분쟁의 결과가 정해지는 것은 아닙니다. 어느 항목이 실제 분쟁에서 결정적인지는 코드의 구성과 다툼의 형태에 따라 달라질 수 있습니다.

1. 자사가 직접 고치거나 새로 더한 부분을 구분해 기록해 둡니다. 법원은 어떤 오픈소스를 고르고 어떻게 고치고 조합했는지를 보호의 근거로 삼았고, 반대로 대부분이 공개 코드 그대로인 짧은 코드는 보호하지 않았습니다. 수정한 함수, 새로 만든 모듈, 설계 문서처럼 회사의 기여가 드러나는 자료를 남겨 두면 다툼에서 유리하게 쓰일 수 있을 것으로 보입니다.
2. 사용한 오픈소스의 목록을 관리합니다. 감정에서는 소스 주석, 당사자가 낸 목록, 검색 도구 등으로 오픈소스 부분을 걸러 냈습니다. 회사가 어떤 오픈소스를 어디에 썼는지 미리 정리해 두면, 어느 부분이 공개된 코드에서 왔고 어느 부분을 회사가 고치거나 새로 썼는지를 두고 다툴 범위가 줄어들 수 있습니다.
3. 사내 코드에 붙은 라이선스 표기가 사실과 맞는지 확인합니다. 한 형사 사건에서는 법원이 공개를 전제로 한 오픈소스로 볼 수 없다고 판단한 코드의 서두에 「오픈소스로서 배포 및 수정이 가능하다」는 표시가 있었고, 이 표시가 고의를 부정하는 사정이 됐습니다. 사내 코드의 라이선스 표기를 정확하게 관리해야 하는 이유가 여기에 있습니다.
4. 라이선스 의무는 별개로 점검합니다. 대법원 2006도8369 판결은 GPL 위반에 따른 원 저작권자에 대한 책임을 별론으로 남겼습니다. 코드를 가져간 사람에게 영업비밀을 주장할 수 있는지와, 회사가 오픈소스 라이선스가 정한 의무를 지켰는지는 따로 판단되는 문제로 보입니다.

이 글이 말하지 않은 것

이 글은 오픈소스를 써도 법적으로 안전하다고 말하지 않습니다. 이 글이 다룬 것은 회사 코드를 가져간 사람이 「오픈소스라서 보호받을 수 없다」고 다툴 때 법원이 그 주장을 어떻게 판단했는지이고, 회사가 오픈소스 라이선스를 지켰는지는 다루지 않았습니다. 라이선스 의무를 어겼을 때 원 저작권자에게 손해배상 등 책임을 지는지는 이 글이 답하지 않는 문제이고, 대법원 2006도8369 판결도 그 문제를 별론으로 남겼습니다. 처음에 이 글은 라이선스 위반으로 손해배상까지 가는지를 알아보려 했지만, 판결 검색 서비스에서 「오픈소스 라이선스 위반」으로 검색되는 판결 35건 가운데 라이선스 준수 여부를 판단한 판결은 없었고, 라이선스 위반을 이유로 배상을 인정한 판결도 없었습니다. GPL을 직접 다룬 판결 3건(같은 사건의 대법원 판결과 원심을 각각 센 것)은 모두 GPL 조건이나 위반이 영업비밀 지위를 없애지 않는다는 쪽이었지만, 이것을 라이선스 위반의 책임이 없다는 뜻으로 읽으면 안 됩니다.

또 대법원 2006도8369 판결과 그 원심은 당시의 컴퓨터프로그램보호법과 당시의 영업비밀 정의를 적용한 판결이므로, 현행 법령 아래에서 같은 결론이 나오는지는 사안마다 따로 살펴야 합니다. 서울중앙지방법원 2022가합564023 판결은 1심 판결이고 항소 여부를 확인하지 못했습니다. 나머지 판결도 대부분 하급심 판결이고, 판결마다 코드의 분량과 감정 결과가 달랐습니다.

자주 묻는 질문

Q. GPL 조건이 붙은 프로그램을 고쳐 만든 코드도 영업비밀이 될 수 있나요?

대법원 2006도8369 판결은 될 수 있다고 보았습니다. 원 프로그램에 비해 새로운 프로그램이라고 할 정도의 창작성이 있는 개작 프로그램이라면 그 저작권은 작성자에게 귀속되고, 원시코드가 실제로 공개되지 않은 채 경제적 가치와 비밀유지 요건을 갖추었다면 영업비밀이라는 원심 판단을 유지했습니다. 다만 대법원은 공개를 거부해 GPL을 어긴 데 따른 원 저작권자에 대한 책임은 별론으로 남겼으므로, 이 판결을 GPL 의무를 지키지 않아도 된다는 뜻으로 읽기는 어렵습니다.

Q. 코드에 오픈소스가 섞여 있으면 감정에서는 어떻게 다루나요?

이 글이 읽은 판결에서는 소스 주석, 상대방이 낸 오픈소스 목록, 한국저작권위원회의 검색 도구(CodeEye) 같은 방법으로 오픈소스 부분을 가려낸 예가 여럿 있었습니다. 서울고등법원 2016나8574 판결의 감정은 오픈소스와 개발도구가 자동으로 만든 부분을 유사도 계산에서 빼면서도, 원고가 고유 기능을 위해 고친 부분은 계산에 넣었습니다. 반대로 상용 프로그램이나 오픈소스 라이브러리를 썼다는 이유만으로 감정 대상에서 빼는 것은 적절하지 않다고 본 판결도 있었습니다.

Q. 오픈소스를 썼다는 이유로 보호받지 못한 경우도 있나요?

있었습니다. 서울중앙지방법원 2013노2300 판결은 상당 부분이 공개 소스를 기초로 하고 1시간에서 2시간이면 작성할 수 있다는 증언이 있었던 짧은 예외처리 코드에 대해 영업비밀성을 부정했습니다. 서울중앙지방법원 2018노1796 판결은 소스코드 서두의 「오픈소스로서 배포 및 수정이 가능하다」는 표시 등을 들어 업무상배임 고의를 인정하기 어렵다고 보았습니다. 다만 2013노2300 판결에서도 설계 문서인 플랫폼 정의서는 영업비밀로 인정됐으므로, 회사가 직접 기여한 부분이 어디까지인지가 결론에 영향을 준 것으로 보입니다.

이 글은 일반적인 정보 제공을 위한 것이며 개별 사안에 대한 법률 자문이 아닙니다.

참고 자료

• GPL 개작 프로그램 사건: 제2심 서울중앙지방법원 2006. 11. 1. 선고 2005노3002 판결 / 상고심 대법원 2009. 2. 12. 선고 2006도8369 판결(상고기각)
• 서울남부지방법원 2018. 9. 7. 선고 2015고단3010 판결 / 항소심 2018노1758 항소기각·확정
• 서울중앙지방법원 2016. 8. 11. 선고 2013고단7560 판결 / 항소심 서울중앙지방법원 2017. 2. 15. 선고 2016노3163 판결
• 대전지방법원 2023. 1. 18. 선고 2020노1107 판결(상고기각)
• 수원지방법원 2023. 11. 30. 선고 2020노5599 판결
• 서울고등법원 2019. 7. 18. 선고 2016나8574 판결(상고기각)
• 서울고등법원 2018. 1. 11. 선고 2014나2011824 판결
• 서울중앙지방법원 2023. 8. 25. 선고 2021가합551365 판결(항소기각·확정)
• 서울중앙지방법원 2026. 3. 24. 선고 2022가합564023 판결(항소 여부 미확인)
• 서울남부지방법원 2023. 11. 3. 선고 2020가합100834 판결, 서울남부지방법원 2024. 8. 23. 선고 2020가합118927 판결
• 예외처리 코드 사건: 형사 서울중앙지방법원 2013. 11. 29. 선고 2013노2300 판결(상고기각) / 민사 제1심 서울중앙지방법원 2013. 11. 14. 선고 2010가합53704 판결, 항소심 서울고등법원 2017. 4. 27. 선고 2013나77388 판결
• 서울중앙지방법원 2019. 5. 31. 선고 2018노1796 판결
• 서울중앙지방법원 2017. 5. 1. 2016카합81253 결정
• 부정경쟁방지 및 영업비밀보호에 관한 법률 제2조 제2호(현행본, 국가법령정보센터 2026. 11. 3. 조회)