또한 IANAL 은 소프트웨어 지적 재산권 문제 를 구체적으로 이해하거나 전문 으로하는 변호사와 상담하는 것이 좋습니다 .
그러나 답은 매우 간단하다고 생각합니다. 1. 고객과 "오픈 소스"라는 용어를 논의 할 필요가 없다고 생각합니다 (해당 진술에 대한 의견을 작성하기 전에 미리 읽어보십시오). 2. 계약에서 다음 사항을 분명히 진술해야합니다. 귀하가 공동으로 소유 한 고객에 대해 생성 한 모든 저작물은 파생물을 생성 할 수 있습니다. 이것은 오픈 소스 프로젝트에 기여하는 것을 포함하여 각자가 원하는대로 사용할 수 있음을 의미합니다 (오픈 소스 프로젝트의 IP 요구 사항을 참조하십시오). 비. 귀하는 무료로 포함하기에 충분한 기존 작업 제품에 대한 소유권을 보유하며, 파생 저작물 생성을 포함하여 해당 코드를 영구적으로 사용할 수있는 제한없는 라이센스를 고객에게 발급합니다 c.
또한 DAMN SURE가 (제한되지는 않음) 매우 제한적이지 않은 발명의 양도 조항을 사용하여 계약에 서명 한 적이 없어야합니다. 그렇지 않으면 법적으로 SOL 일 수 있습니다. 계약서의 내용에 관계없이 법에 의해이를 제한 (하지만 제거하지는 않음)하는 여러 주 (예 : 캘리포니아)가 있습니다. 이것은 고용 계약에서 예상되지만 (제한은 협상 될 수 있음) IMHO는 독립 계약자 계약에 대해 부여되지 않아야합니다.
가장 큰 과제는 소스 코드의 공동 소유권을 수락하는 것입니다. 이는 계약자를 사용할 때 소프트웨어 개발 계약에 매우 자주 사용되는 특정 언어 인 "임시 작업"교리 와 충돌합니다 .
그들이 IP를 이해한다면, 이것에 동의하지 않을 수도 있습니다-그러나 나는 그들이 당신이 다루고있는 클라이언트 유형이 아니라고 생각합니다. 고객을 위해 작성된 모든 컨설팅 / 맞춤 코드에 대해이를 수행하는 매우 큰 소프트웨어 회사가 적어도 하나는 있다고 확신 할 수 있습니다. 동의하지 않을 경우에는 기간 ( 하지만 파트너에게 추천 할 것입니다).
공동 소유권이있는 경우 해당 프로젝트의 제한 사항에 따라 해당 코드를 공개 소스 프로젝트에 기고하려면 IP 방식을 사용해야합니다.
또한 오픈 소스를 선택적으로 선택하고 싶을 것입니다. 직접 경쟁 업체에 유용한 소스 산업별 코드를 열면 고객에게 서비스 중단을 초래할 수 있습니다. 고객이 맞춤 쓰기로 비용을 지불 한 전체 앱을 무료로 사용할 수 있다는 사실을 알게된다면 처음부터 작성하지 않고 방금 설치했다고 생각할 수도 있습니다. 또한 서비스에 대한 인식 가치를 떨어 뜨 렸습니다.
나는 이것이 당신의 질문 1, 2, 4를 다룬다 고 생각합니다.
질문 3은 문제가 될 수 있습니다. 파생 작업을 생성하는 오픈 소스 프로젝트의 라이센싱 모델에 따라 고객은 확실히 비용을 지불 할 수 있지만, 해당 코드의 전체 또는 일부를 소유하지 않았을 수 있습니다 오픈 소스 프로젝트의 라이센스 모델. 그것은 당신이 그것을 할 수 없다고 말하는 것이 아닙니다-계약서의 추가 조항으로 그것을 다루고 IP 변호사에 의해 운영하고 싶을 수도 있습니다-또는 고객이 요청한 후에 만 그렇게 할 수 있습니다- 그러면 변호사가이 상황을 다루는 계약서의 부록을 검토하게하는 비용을 청구 할 수 있습니다.