내 소프트웨어 크랙판이 GitHub에 올라온다면, 누가 책임져야 할까

핵심 요약

• 크랙판 삭제 문제를 판단하려면 실제 배포물과 신고 내용을 구체적으로 살펴야 합니다.
• 삭제되지 않았다는 사실만으로 플랫폼이 묵인했다거나 신고가 부당했다고 단정할 수는 없습니다.
• 피해에 빠르게 대응하면서 잘못된 삭제도 막을 수 있어야 합니다.
• 개발자가 처리 과정을 이해하고 대응할 수 있어야 플랫폼을 신뢰할 수 있습니다.

“내 소프트웨어 크랙판을 지워주지 않는다.” 개발자가 이런 문제를 제기한다면, 파일 하나를 삭제하는 것으로 끝날 이야기는 아닙니다. 코드를 올리고 협업하는 공간인 GitHub를 자신의 작업물을 보호하는 데도 믿고 쓸 수 있는지 따져보게 되기 때문입니다.

개발자에게는 파일 하나 이상의 문제입니다

유료 소프트웨어를 만드는 개발자는 기능을 구현하고 오류를 고칩니다. 구매자의 문의에 답하는 것도 개발자의 일입니다. 그렇게 만든 소프트웨어의 정품 인증을 우회한 복제본이 배포된다면, 그동안 들인 노력이 허사가 되고 사업의 기반까지 흔들릴까 걱정할 만합니다.

다만 복제본의 다운로드 횟수를 그대로 판매 손실로 계산할 수는 없습니다. 다운로드한 사람이 모두 구매했을 것이라는 보장은 없기 때문입니다. 피해를 걱정할 이유가 있다고 해서 피해 규모까지 입증되는 것은 아닙니다.

개발자의 부담은 매출에만 그치지 않습니다. 어디에 어떤 복제본이 올라왔는지 찾아보는 데도 시간이 듭니다. 자신의 권리를 설명한 뒤 처리 결과를 기다리는 동안에도 신경을 써야 합니다. 그만큼 제품을 개선하는 데 쓸 시간을 빼앗깁니다.

그래서 삭제 요청에 불분명한 답변이 돌아오면 고객 지원에 대한 불만으로만 끝나기 어렵습니다. 개발자는 “내가 여기서 계속 일해도 되는가”까지 고민하게 됩니다.

‘크랙판’이라는 말 다음에 확인해야 할 것

크랙판은 보통 정품 인증이나 사용 제한을 우회하도록 변형한 소프트웨어를 가리킵니다. 하지만 신고에 그 단어를 썼다고 해서 플랫폼이 무엇을 판단해야 하는지까지 분명해지는 것은 아닙니다.

가령 저장소에 상용 프로그램을 수정한 실행 파일이 올라올 수도 있고, 실행 파일 없이 인증을 우회하는 코드만 있을 수도 있습니다. 외부 다운로드 주소만 안내하는 경우라면 이 역시 따로 살펴야 합니다.

이들은 가상의 예시지만, 같은 크랙판 신고라도 살펴야 할 내용이 다를 수 있음을 보여줍니다. 무엇이 어디에 올라왔고, 어떤 행위가 문제인지를 구체적으로 확인해야 합니다. 이름이나 저장소 소개만 보고 실제 내용까지 판단하기는 어렵습니다.

삭제하지 않았다는 이유만으로 GitHub가 불법 복제를 묵인한다고 단정해서는 안 됩니다. 반대로 삭제되지 않았으니 문제가 없는 자료라고 받아들이는 것도 성급합니다.

개별 사건을 평가하려면 무엇을 신고했고 어떤 설명을 제출했는지부터 확인해야 합니다. 플랫폼이 보낸 답변도 함께 봐야 합니다. 처리 결과와 그 판단 근거는 별개이기 때문입니다.

삭제 여부를 판단한 이유도 설명해야 합니다

플랫폼은 신고를 빠르게 처리해야 합니다. 잘못된 신고 때문에 다른 개발자의 작업물을 지우지 않을 책임도 있습니다. 어느 한쪽의 불편만 없애려 해서는 해결하기 어려운 문제입니다.

저는 플랫폼이 판단한 이유를 설명할 수 있는지를 더 중요하게 봅니다. 신고자가 무엇을 보완해야 하는지 알 수 없다면, 답변을 받아도 다음에 어떻게 해야 할지 막막합니다.

예를 들어 어떤 파일을 신고하는지 불분명한 경우와 권리 관계를 두고 다투는 경우는 다릅니다. 플랫폼이 이 차이를 짚어줘야 신고자도 같은 주장을 반복하는 대신 필요한 내용을 보탤 수 있습니다. 게시자 역시 자신의 자료에서 무엇이 문제로 지적됐는지 알아야 대응할 수 있습니다.

처리 상태도 알 수 있어야 합니다. 신고를 접수했는지, 추가 확인이 필요한지, 판단을 마쳤는지를 알려줘야 합니다. 이를 구분할 수 없으면 결과를 기다리는 동안 플랫폼에 대한 불신이 쌓이기 쉽습니다.

이는 GitHub의 실제 처리 절차를 설명한 내용이 아닙니다. 이런 분쟁에서 플랫폼을 평가할 때 살펴야 할 기준입니다. 삭제 건수나 처리 속도만 봐서는 알 수 없는 부분이 있습니다.

플랫폼의 책임은 ‘삭제 버튼’보다 넓습니다

플랫폼에 책임을 묻는다고 해서 모든 신고를 곧바로 받아들여야 한다는 뜻은 아닙니다. 그렇다고 판단이 어렵다는 이유로 당사자에게 불확실성을 모두 떠넘기는 것도 납득하기 어렵습니다.

신고자는 어떤 점이 침해에 해당한다고 보는지 구체적으로 설명해야 합니다. 플랫폼은 그 내용을 검토한 뒤 왜 그런 결정을 내렸는지 알려줘야 합니다. 다시 판단을 요청할 방법도 안내할 수 있어야 합니다. 게시자가 제기하는 이의 역시 같은 무게로 다뤄야 합니다.

GitHub를 둘러싼 이런 문제를 볼 때 저는 “얼마나 많이 지웠나”보다 “당사자가 판단을 이해하고 다음 행동을 할 수 있었나”를 묻고 싶습니다. 자신의 작업물을 맡기는 개발자에게는 그 차이가 꽤 큽니다.

개발자의 권리를 보호하면서 삭제 여부를 공정하게 판단하려면 실제 처리 과정이 뒷받침돼야 합니다. 자신의 소프트웨어가 무단으로 배포됐을 때 플랫폼이 어떤 설명을 내놓고 어떻게 대응하는지에 따라, 개발자가 그곳을 다시 믿고 쓸 수 있을지가 달라집니다.