클라이언트가 소스 코드를 원하지만 다른 프로젝트와 재사용하는 많은 공유 코드가 포함되어 있습니다.

개발 된 응용 프로그램 이진으로 소스 코드를 제공하려는 클라이언트가 있습니다. 그들은 원래 소스 코드에 대해 아무 말도하지 않았지만 최근에 필요하다고 말했습니다. 계약이 완료되지 않았습니다. 그들은 그 일에 동의했고, 서명하지 않았으며,이 조항으로 돌아 왔습니다.

문제는 : 수년에 걸쳐 만든 코드베이스를 가지고 있으며 필자가 작성한 대부분의 응용 프로그램의 템플릿으로 사용되었습니다. 프로젝트 범위보다 훨씬 큽니다.

또한 제품에 사용하려고하므로 비교적 작은 프로젝트에 제공하고 싶지 않습니다.

이것이 이것이이 업계에서 처음 일어난 것은 아니라고 생각합니다. 이 문제를 피하는 가장 좋은 방법은 무엇입니까? 공유 라이브러리와 같은 것들이 도움이 될 것이라고 생각합니다.

가장 먼저 염두에 두어야 할 것은 소스 코드는 바이너리와 별개의 가치를 가진다는 것입니다. 소스 코드 전달이 필요한 계약서 서명을 거부하거나 소스 코드 전달에 대한 추가 지불을 요구하는 것이 합리적입니다. 계약은 양방향 문서입니다. 상대방이 "대기업"이고 "항상이 일을하기"때문에 필요한 것을 지시하지 않도록하십시오. 먼저, 무엇 을 기꺼이 전달하고 보상 을 원하는지 결정하십시오 . 그런 다음 계약을 변호사에게 가져 가서 변경해야 할 사항을 해결하십시오. 그런 다음 협상합니다.

계약을 시작할 때 많은 젊은이들이하는 일을하지 마십시오. 그들은 경험이 많고 당신이하지 않는 것처럼 보이기 때문에 서명하지 마십시오. 그것은 찢어지는 좋은 방법입니다.

그들이 소스를 원하는 이유 를 살펴보십시오 . 그들은 나중에 다른 개발자를 사용할 수있는 옵션을 원할 수도 있습니다. 또는 버스에 부딪 칠 우려가 있기 때문에 그것을 원할 수도 있습니다. 갑자기 개선 할 수없는 바이너리가 남게됩니다. 이 두 번째 경우에는 소프트웨어 코드 에스크로 서비스를 살펴보십시오 . 이러한 서비스는 파산하거나 소프트웨어를 유지 관리 할 수없는 경우를 위해 소스 코드를 보유합니다. 이렇게하면 다른 고객에게 서비스를 제공하기 위해 코드를 독점적으로 유지하려는 욕구와 나쁜 일이 발생할 경우 유지 관리 할 수없는 바이너리 세트로 가방을 들고 있지 않은 욕구를 모두 충족시킬 수 있습니다.

"아니오" 는 완벽하게 훌륭한 답변입니다. 실제로 이해할 수없는 매우 유용한 답변입니다.

"안녕하세요, 우리는 소스 코드도 무료로 원한다고 갑자기 결정했습니다."
"안녕."

그렇게 어렵지는 않습니다.

그들은 돈을 터무니없는 금액을 지불하고자하는 경우, 을 통해 그들이 무엇을 이미 당신을 빚을, 당신은 그들에게 실제로 필요한 경우에만 소스를 포함 응용 프로그램, 그들은 절대적으로 얻을 관리 복용의 손질 버전 줄 수도 비 -Exclusive 권한을.

단순한 것을 복잡하게하지 마십시오.

귀하의 질문은 "이 문제를 피하는 가장 좋은 방법은 무엇입니까?"입니다. 그러나 무엇이 문제라고 생각하십니까? 다른 사람들은 그것이 협상의 문제라는 것을 올바르게 지적했습니다. 모든 것이 가치가 있으며, 고객이 요청한 것을 제공하는 가격을 책정합니다.

그러나 코드 제공의 의미 를 신중하게 고려하고 계약서에 작성해야합니다 . 클라이언트가 볼 수 있도록하는 것입니까? 클라이언트가 수정할 수 있습니까? 특히, 수년 동안 생성 한 코드베이스에 대한 독점적 권한을 고객에게 부여 하고 나중에 다시는 다시는 사용할 수 없도록 대부분의 응용 프로그램의 템플릿으로 사용 하시겠습니까?

계약서에 코드를 사용할 권한이있는 사람과 방법을 명시 적으로 명시해야합니다.

모든 소스 코드에는 라이센스가 필요합니다. 소스 코드를 양도하면 회사는 소스 코드를 사용하여 라이센스가 허용하는 모든 것을 수행 할 수 있으며 그 이외의 모든 것은 저작권을 침해 할 수 있습니다. 따라서 소스 코드를 양도하는 경우 소스 코드의 독점 저작권 및 소스 코드 사용이 정확히 허용된다는 계약을 체결하게됩니다. 물론 소스 코드 + 라이센스는 무료로 제공되지 않습니다.

큰 회사는 저작권을 침해 할 가능성이 적습니다. 잡히면 재정적 피해를 제외하고는 명성이 크게 손상 될 수 있기 때문입니다. 반면에 향후 문제가 해결 될 것이라는 보장없이 소프트웨어에 대한 대가를 지불하는 것은 고객에게 용납되지 않을 수 있습니다.

이전에는 보통 MIT 라이센스하에 소스 코드 (라이브러리 및 모두)를 클라이언트에 제공했습니다. 라이브러리가 잘 정리되어 있으면 해당 특정 클라이언트에 필요한 파일 / 리소스 만 제공하고 그 이상은 제공하지 않습니다. 나는 그것이 저와 고객 모두에게 공평하다고 생각합니다. 그러나 계약에 따라 특정 고객을 위해 작성된 새 코드 문제는 항상 라이브러리의 일부가 아니 었습니다. 그래서 프로젝트를 시작하기 전에 고객과 문제를 논의하기 시작했습니다. 일부 고객은 해당 코드의 소유권을 원했지만 일부 고객은 그렇지 않습니다 (저는 항상 사람들에게 높은 가격과 같은 부정적인 인센티브를주었습니다). 그러나 실제로 일부 고객에게는 토론이 매우 혼란 스러웠으며 때로는 프로젝트 승인을 받기 위해 3 명 또는 5 명의 다른 사람 (변호사 포함)에게 이야기했습니다.

이제 모든 라이브러리는 항상 개발에 사용하는 사용자 지정 프레임 워크의 일부이며이 프레임 워크를 사용하지만 프레임 워크는 다른 라이센스를 가진 다른 제품이라고 클라이언트에 설명합니다. (때로는 "프레임 워크"가 이해하기 어려울 수 있으므로 설명 할 때 "소프트웨어 구성 요소"를 사용합니다). 나는 항상 MIT 라이센스하에 사용되는 파일의 코드를 제공하고 (모든 코드가 잘 구성되어 있기 때문에) 저수준 코드 (새로운 것조차도)는 프레임 워크에 남아 있습니다 (나와 그들에 의해 재사용되어야 함). 그들의 응용 프로그램에 대해서만 그들 자신의 용어를 유지하는 것입니다 (이 코드는 아마도 다른 프로젝트에서 재사용하는 데 쓸모가 없을 것입니다). 물론 모든 것은 계약서에 올바르게 작성되었습니다. 나는 이것이 공평하다고 생각합니다.

핵심은 "이 구성 요소는 다른 제품"이며 시작하기 전에 모두 계약서에 기록됩니다.

예, 공유 라이브러리 사용에 대한 아이디어가 옳을 수도 있습니다. 그러나 위험을 줄일 수있는 라이센스 하에서 사용한 소스 코드를 제공하지 않는 이유는 무엇입니까? 나는 그것이 공평하다고 생각합니다.

이것을 다루는 방법은 협상하는 것입니다.

그들이 소스 코드를 원한다면, 그 비용을 지불 할 준비가되어 있어야하고, 얼마를해야하는지 결정하는 것은 당신에게 달려 있습니다.

반면에 ... 그들이 원하는 것을 지불 할 준비가되지 않았다면, 그들은 "다른 곳에서 그들의 사업을하기로"결정할 수 있습니다.

비즈니스 세계에 오신 것을 환영합니다 :-)

그리고 장래에 잠재 고객과 대화 할 때는 모든 사람의 시간을 낭비하지 않도록이 문제를 미리 언급하십시오.

또한 여러분이하고있는 일은 오픈 소스 개발자와 오픈 소스 솔루션을 찾고있는 (교육을받은) 고객을위한 혐오입니다.

계약을 체결하기로 이미 계약 한 것에 동의하고 서로 다른 고객과 상호 호환되지 않는 조건에 동의 할 수 있다는 점에서 너무 늦을 수 있습니다.

고객에게 소스 코드를 제공 할 수있는 두 가지 방법이 있습니다. 저작권 및 라이센스의 소유권.

일부 고객은 소스 코드의 소유권을 원할 것입니다. 즉, 프로세스가 끝나면 돈을 지불하고 대신 코드를 작성하여 저작권을 부여합니다. 그 이유 중 하나는 소스 코드에서 지적 재산권의 상당한 잠재력을보고 회사 대차 대조표에서이를 가치있게 평가할 수 있기 때문입니다. 이 시나리오에서는 고객에게이 권한을 부여하는 라이센스를 얻지 않는 한 다른 프로젝트에 해당 소스 코드를 계속 사용할 수있는 권한이 없습니다.

고객이 직접 '기성품'제품을 구매하는 경우 소스 코드의 소유권이 아니라 소프트웨어를 사용할 수있는 라이센스를받을 것으로 예상됩니다. 그들은 다른 많은 조직에 동일한 (또는 유사한) 소프트웨어를 판매하고 있으며 더 넓은 고객 기반으로 인해 구매 비용이 더 낮아질 것으로 기대하고 있습니다.

그러나이 질문의 상황은 두 가지의 혼란입니다.

여기 내가 할 수있는 일이 있습니다. 고객에게 공유 코드를 사용 (및 수정) 할 수있는 라이센스를 부여합니다. 고객이 퀴즈를 내린 경우이 코드는 이미 여러 프로젝트에서 사용한 공유 코드이며이 작업을 계속 사용함에 따라 향후 작업에 대한 현재 입찰가가 설정되어 있습니다. 이로 인해 귀하의 고객에게이 프로젝트에 대한 시간이 줄어들었고 결과적으로 더 낮은 가격을 지불했음을 지적하십시오. 프로젝트에서 사용하는 다른 공유 코드 라이브러리와 마찬가지로이 코드를 사용하고 다른 개발 팀이이 라이브러리 및이 라이브러리를 기반으로하는 다른 프로젝트를 개발할 수있는 라이센스가 있습니다. 그러나 모든 코드의 소유권을 원한다면 교체를 기꺼이 만들지 만 추가 요금이 부과됩니다.

이미 커밋 한 내용에 따라 무료로 대체 기능을 작성하거나 소스 코드를 제공해야 할 수 있습니다.

다른 유형의 라이브러리가 있다는 것을 기억하십시오. C ++의 표준 템플릿 라이브러리는 소스 코드 수준에 포함 된 라이브러리의 좋은 예이며 일반적인 코드 사용 방법과 매우 유사한 프로젝트 실행 파일로 컴파일됩니다.

제공하는 소프트웨어와 함께 타사를 사용하는 경우이 타사의 소스 코드가 없을 수 있습니다. 귀하는 여전히 타사 바이너리가있는 회사에 소프트웨어를 제공 할 것입니다. 모든 프로젝트에서 공유하는 프레임 워크로 개발 한 코드는 사용자가 소유하더라도 제 3 자와 같습니다. 이 경우 회사는 프레임 워크의 바이너리와 타사의 위험이 동일합니다. 이 경우 회사에 프레임 워크의 소스 코드를 제공해야하는 이유는 무엇입니까? 라이센스 계약과 함께 좋은 API 문서를 제공 할 수 있습니다. 코드에 업계에 혁명을 일으킬 다음 큰 것이 포함되어 있다면 또 다른 이야기이지만 일반적으로 그렇지 않습니다.