Yedelkin : ... 그러면서 "어찌가 맞는지는 모르겠지만 개인적으로 TK는 부차적인 것이고 계약서(신청서)의 부록일 뿐이라고 생각한다"고 덧붙였다. 댓글이 달린 문구 의 강조 표시 와 함께 내가 댓글을 달았습니다. 논평의 핵심: 특정 조건이 충족되면 TK는 자급자족할 수 있습니다(귀하의 용어로는 기본). 글쎄요, 그건 그렇고, 결국 논쟁의 대상이 없습니다. :)
그래서 실생활에서 합의/계약이 정말 기본이고, 합의 없이 TK를 만난 적이 없습니다(동시에 일반적으로 TK에는 기술 정보만 있고 합의에는 법적 관계의 주요 본질 정당들).
개인적으로 저는 이 순서에 익숙합니다.
1. 작업 수행에 대한 계약 / 계약 (고객, 계약자, 수행 된 작업의 주요 본질, 작업 수행 기한, 고객이 계약자에게 지불 한 금액, 책임 당사자 및 필요한 경우 추가 정보)가 표시됩니다.
2. 작업 자체를 더 자세히 설명하고 수행된 작업의 특정 특성을 제공하는 TOR(동시에 고객은 TOR에 포함된 내용을 완전히 이해할 의무는 없음)
3. 수료증명서
4. 작업 또는 그 단계에 대한 지불.
다음을 기초로 하여 정상적인 상황에서 계약(신청서 읽기)이 TOR(TOR는 작업의 세부내용이나 특정 단계가 있는 계약을 기반으로 형성됨)보다 높은 지위를 가진다고 생각합니다.
우리의 경우 개발자(서비스 주최자)가 애플리케이션의 내용에 더 자세히 접근하여 실제 계약에 더 가깝게 접근해야 한다고 생각합니다.
또한 계약자가 독립적으로 TOR를 준비하고 고객이 이에 동의한 경우 계약자가 일정 금액(정확하게 또는 주문의 백분율로 표시)을 받을 수 있도록 TOR를 생성하는 프로세스를 강조할 가치가 있습니다.
pronych : А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
이것은 문제의 일부를 해결하는 기술적 측면입니다. 사실, 당신은 고객이 신청서 작성 단계에서 결정하기 위해 "최종 파일의 유형을 결정"하라는 요구 사항을 제시했습니다. 따라서 고객에 대한 그러한 요구 사항은 (공식적인 관점에서) 규칙에 반영되어야 합니다. 고객이 그들에게 필요한 것이 무엇인지 이해할 수 있도록.
또한 계약자는 (자신의 이익을 위해) 신청서를 보고 진정해서는 안 되며, 참조 약관에서 직접 이 문제에 대한 동의를 얻어야 합니다.
pronych : 일반적으로 가장 쉬운 방법은 규칙을 똑똑하게 하는 것이 아니라, 간단하게 응용 프로그램에 들어갈 때 "소스 코드를 원합니다"와 같은 "제거됨" 확인란을 추가하고 이를 작업 목록에 반영하는 것입니다. 그것을 필요로 하는 사람은 상자를 체크할 것입니다. 작은 업데이트지만 얼마나 좋은지. 모든 사람에게 모든 것이 즉시 명확해집니다.
제 생각에는 "응용 프로그램" 자체가 더 자세히 재작업되어야 합니다. 있어야 할 뿐만 아니라 훨씬 더 많습니다. 예를 들어 출연자가 향후 알고리즘 및 프로그램 코드를 사용하는 것을 허용/금지하는 조건을 체크할 수도 있습니다.
그러한 것들이 통제하기가 매우 어렵다는 것을 이해하지만.
추신
문제는 내가 알기로는 STORE와 달리 아무도 고객이 작업을 복제하도록 귀찮게 하지 않으며(특히 소스 코드가 있는 경우) 수행자가 쉽게 상점에 넣거나 다른 고객에게 재판매할 수 있다는 것입니다.
이것은 문제의 일부를 해결하는 기술적 측면입니다. 사실, 당신은 고객이 신청서 작성 단계에서 결정하기 위해 "최종 파일의 유형을 결정"하라는 요구 사항을 제시했습니다. 따라서 고객에 대한 그러한 요구 사항은 (공식적인 관점에서) 규칙에 반영되어야 합니다. 그들이 그들에게 필요한 것이 무엇인지 이해할 수 있도록.
또한 계약자는 (자신의 이익을 위해) 신청서를 보고 진정해서는 안 되며, 참조 약관에서 직접 이 문제에 대한 동의를 얻어야 합니다.
정확히 말하면 여기에서 선택의 특정 규칙을 만드는 것이 다소 필요합니다. 고객이 소스 코드를 확실히 필요로 하는 경우에는 이에 대해 아무 것도 할 수 없으며, 그렇지 않으면 수행자가 선택할 수 있습니다.
동시에 고객은 소스 코드와 작업의 독점성(있는 경우)에 추가 비용이 든다는 점을 이해해야 합니다.
곰곰이 생각해보니 그런 것 같아요. 프로그래머가 고객의 사양에 따라 무언가를 작성하는 경우 소스 코드도 그에게 전송해야 합니다. 첫째, 개발자가 새 빌드를 다시 컴파일할 필요가 없다고 말할 가능성은 거의 없습니다. 둘째, 논란이 되는 문제를 해결해야 합니다. TOR가 잘못 공식화되었거나, 오해되었거나, 프로그래머가 단순히 실수했을 가능성이 있습니다. 첫 번째 경우 고객은 새로운 TOR에 대한 작업에 대해 다시 비용을 지불하거나 프로그래머를 혼자 남겨두어야 합니다. 두 번째와 세 번째에서 프로그래머는 자신의 잼을 무료로 수정해야 합니다. 소스 코드 없이 누가 옳은지 알아내는 방법은 무엇입니까?
고객에게 이전할 수 없는 소스 코드에는 실제로 무엇이 있습니까? 좋은 거래 아이디어, 즉 기술 사양은 일부 프로그래밍 비밀보다 훨씬 더 가치가 있습니다.
자신의 아이디어에 따라 작성된 소프트웨어를 판매하는 경우 소스 코드를 이전하는 것은 문제가 되지 않습니다.
여기에 근본적인 실수가 있습니다. 계약은 둘 이상의 사람 간의 계약입니다. 신청서는 한 당사자의 제안일 뿐이며 그 자체로는 계약으로 간주될 수 없습니다. 논의중인 규칙의 본질에 따라 계약 관계의 출현 (계약 체결)은 참조 약관의 실행 후에 만 판단 할 수 있습니다. 양 당사자가 합의한 작업의 모든 세부 사항을 반영하기 위한 것은 참조 조건입니다.
... Contract-TK 링크에 대해 설명한 접근 방식은 기존 방식이라고 할 수 있으며, 이는 발생한 계약 관계를 해결하는 다른 동등한 형태의 존재를 결코 취소하지 않습니다. 비유적으로 말해서 러시아 연방 민법 36장 "계약"은 공개 및 보호된 구성원, 가상 기능 이 있는 상위 클래스이며 참조 조건은 가능한 하위 클래스 중 하나입니다. :)
이것은 문제의 일부를 해결하는 기술적 측면입니다. 사실, 당신은 고객이 신청서 작성 단계에서 결정하기 위해 "최종 파일의 유형을 결정"하라는 요구 사항을 제시했습니다. 따라서 고객에 대한 그러한 요구 사항은 (공식적인 관점에서) 규칙에 반영되어야 합니다. 고객이 그들에게 필요한 것이 무엇인지 이해할 수 있도록.
또한 계약자는 (자신의 이익을 위해) 신청서를 보고 진정해서는 안 되며, 참조 약관에서 직접 이 문제에 대한 동의를 얻어야 합니다.
정확히 말하면 여기에서 선택의 특정 규칙을 만드는 것이 다소 필요합니다. 고객이 소스 코드를 확실히 필요로 하는 경우에는 이에 대해 아무 것도 할 수 없으며, 그렇지 않으면 수행자가 선택할 수 있습니다.
동시에 고객은 소스 코드와 작업의 독점성(있는 경우)에 추가 비용이 든다는 점을 이해해야 합니다.
"선택의 조건"에 대한 구체적인 표현을 제공하십시오. 아무도 우리를 위해 그것을하지 않습니다. 내 문구(3.1항)가 적합합니까?
고객에게 이전할 수 없는 소스 코드에는 실제로 무엇이 있습니까? 좋은 거래 아이디어, 즉 기술 사양은 일부 프로그래밍 비밀보다 훨씬 더 가치가 있습니다.
자신의 아이디어에 따라 작성된 소프트웨어를 판매하는 경우 소스 코드를 이전하는 것은 문제가 되지 않습니다.
소스 코드는 많은 추가 기능, 클래스 등이 포함된 잘 설계된 템플릿이 될 수 있습니다. 여러 블록(예: 포함)으로 구성될 수 있으며 일부 조건만 다를 수 있습니다. 신호 모듈만 다른 한 시스템(서로 상호 작용의 의미에서 시스템)의 12가지 다른 파일의 소스 코드에서 반년(간단한 경우) 작동 시간을 제공할 준비가 되셨습니까? 하나의 클래스(파일))?
나는 당신이 체커의 교차점을 강타하기 위해 표준 수단을 사용할 수 있다는 것을 이해하며 유감스럽지 않습니다. 그리고 템플릿에 엄청난 작업이 투자된다면 어떻게 될까요? 아니, 준비됐어?
곰곰이 생각해보니 그런 것 같아요. 프로그래머가 고객의 사양에 따라 무언가를 작성하는 경우 소스 코드도 그에게 전송해야 합니다. 첫째, 개발자가 새 빌드를 다시 컴파일할 필요가 없다고 말할 가능성은 거의 없습니다. 둘째, 논란의 여지가 있는 문제를 해결해야 합니다. TOR가 잘못 공식화되었거나, 오해되었거나, 프로그래머가 단순히 실수했을 가능성이 있습니다. 첫 번째 경우 고객은 새로운 TOR에 대한 작업에 대해 다시 비용을 지불하거나 프로그래머를 혼자 남겨두어야 합니다. 두 번째와 세 번째에서 프로그래머는 무료로 잼을 수정해야 합니다. 소스 코드 없이 누가 옳은지 알아내는 방법은 무엇입니까?
고객에게 이전할 수 없는 소스 코드에는 실제로 무엇이 있습니까? 좋은 거래 아이디어, 즉 기술 사양은 일부 프로그래밍 비밀보다 훨씬 더 가치가 있습니다.
자신의 아이디어에 따라 작성된 소프트웨어를 판매하는 경우 소스 코드를 이전하는 것은 문제가 되지 않습니다.
1. 소스 코드의 필수 전송은 수행된 작업이 독점적인 경우에만 적절하지만, 이해하는 바와 같이 가격이 다를 수 있습니다(아마도 몇 배 이상).
재컴파일 문제는 초기에 해결할 수도 있습니다.
2. TK 소개
글쎄, 나는 "좋은" 소프트웨어 구현보다 더 많은 비용이 드는 "좋은" 아이디어를 Forex에서 보지 못했습니다.
나는 다음과 같이 질문에 답할 것이다 - 소스 코드에는 고객이 자신이 저작권 소유자이며 코드로 무엇이든 할 수 있다고 주장할 수 있는 가능성이 있습니다(예: 판매).
따라서 우리는 수행된 작업의 독점성에 대해 이야기할 가능성이 가장 큽니다(여기서 저는 소스 코드 배포를 추구하지 않는 프로그래머를 지원합니다).
... 그러면서 "어찌가 맞는지는 모르겠지만 개인적으로 TK는 부차적인 것이고 계약서(신청서)의 부록일 뿐이라고 생각한다"고 덧붙였다. 댓글이 달린 문구 의 강조 표시 와 함께 내가 댓글을 달았습니다. 논평의 핵심: 특정 조건이 충족되면 TK는 자급자족할 수 있습니다(귀하의 용어로는 기본). 글쎄요, 그건 그렇고, 결국 논쟁의 대상이 없습니다. :)
그래서 실생활에서 합의/계약이 정말 기본이고, 합의 없이 TK를 만난 적이 없습니다(동시에 일반적으로 TK에는 기술 정보만 있고 합의에는 법적 관계의 주요 본질 정당들).
개인적으로 저는 이 순서에 익숙합니다.
1. 작업 수행에 대한 계약 / 계약 (고객, 계약자, 수행 된 작업의 주요 본질, 작업 수행 기한, 고객이 계약자에게 지불 한 금액, 책임 당사자 및 필요한 경우 추가 정보)가 표시됩니다.
2. 작업 자체를 더 자세히 설명하고 수행된 작업의 특정 특성을 제공하는 TOR(동시에 고객은 TOR에 포함된 내용을 완전히 이해할 의무는 없음)
3. 수료증명서
4. 작업 또는 그 단계에 대한 지불.
다음을 기초로 하여 정상적인 상황에서 계약(신청서 읽기)이 TOR(TOR는 작업의 세부내용이나 특정 단계가 있는 계약을 기반으로 형성됨)보다 높은 지위를 가진다고 생각합니다.
우리의 경우 개발자(서비스 주최자)가 애플리케이션의 내용에 더 자세히 접근하여 실제 계약에 더 가깝게 접근해야 한다고 생각합니다.
또한 계약자가 독립적으로 TOR를 준비하고 고객이 이에 동의한 경우 계약자가 일정 금액(정확하게 또는 주문의 백분율로 표시)을 받을 수 있도록 TOR를 생성하는 프로세스를 강조할 가치가 있습니다.
pronych :
А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
이것은 문제의 일부를 해결하는 기술적 측면입니다. 사실, 당신은 고객이 신청서 작성 단계에서 결정하기 위해 "최종 파일의 유형을 결정"하라는 요구 사항을 제시했습니다. 따라서 고객에 대한 그러한 요구 사항은 (공식적인 관점에서) 규칙에 반영되어야 합니다. 고객이 그들에게 필요한 것이 무엇인지 이해할 수 있도록.
또한 계약자는 (자신의 이익을 위해) 신청서를 보고 진정해서는 안 되며, 참조 약관에서 직접 이 문제에 대한 동의를 얻어야 합니다.
일반적으로 가장 쉬운 방법은 규칙을 똑똑하게 하는 것이 아니라, 간단하게 응용 프로그램에 들어갈 때 "소스 코드를 원합니다"와 같은 "제거됨" 확인란을 추가하고 이를 작업 목록에 반영하는 것입니다. 그것을 필요로 하는 사람은 상자를 체크할 것입니다. 작은 업데이트지만 얼마나 좋은지. 모든 사람에게 모든 것이 즉시 명확해집니다.
제 생각에는 "응용 프로그램" 자체가 더 자세히 재작업되어야 합니다. 있어야 할 뿐만 아니라 훨씬 더 많습니다. 예를 들어 출연자가 향후 알고리즘 및 프로그램 코드를 사용하는 것을 허용/금지하는 조건을 체크할 수도 있습니다.
그러한 것들이 통제하기가 매우 어렵다는 것을 이해하지만.
추신
문제는 내가 알기로는 STORE와 달리 아무도 고객이 작업을 복제하도록 귀찮게 하지 않으며(특히 소스 코드가 있는 경우) 수행자가 쉽게 상점에 넣거나 다른 고객에게 재판매할 수 있다는 것입니다.
이것은 문제의 일부를 해결하는 기술적 측면입니다. 사실, 당신은 고객이 신청서 작성 단계에서 결정하기 위해 "최종 파일의 유형을 결정"하라는 요구 사항을 제시했습니다. 따라서 고객에 대한 그러한 요구 사항은 (공식적인 관점에서) 규칙에 반영되어야 합니다. 그들이 그들에게 필요한 것이 무엇인지 이해할 수 있도록.
또한 계약자는 (자신의 이익을 위해) 신청서를 보고 진정해서는 안 되며, 참조 약관에서 직접 이 문제에 대한 동의를 얻어야 합니다.
정확히 말하면 여기에서 선택의 특정 규칙을 만드는 것이 다소 필요합니다. 고객이 소스 코드를 확실히 필요로 하는 경우에는 이에 대해 아무 것도 할 수 없으며, 그렇지 않으면 수행자가 선택할 수 있습니다.
동시에 고객은 소스 코드와 작업의 독점성(있는 경우)에 추가 비용이 든다는 점을 이해해야 합니다.
곰곰이 생각해보니 그런 것 같아요. 프로그래머가 고객의 사양에 따라 무언가를 작성하는 경우 소스 코드도 그에게 전송해야 합니다. 첫째, 개발자가 새 빌드를 다시 컴파일할 필요가 없다고 말할 가능성은 거의 없습니다. 둘째, 논란이 되는 문제를 해결해야 합니다. TOR가 잘못 공식화되었거나, 오해되었거나, 프로그래머가 단순히 실수했을 가능성이 있습니다. 첫 번째 경우 고객은 새로운 TOR에 대한 작업에 대해 다시 비용을 지불하거나 프로그래머를 혼자 남겨두어야 합니다. 두 번째와 세 번째에서 프로그래머는 자신의 잼을 무료로 수정해야 합니다. 소스 코드 없이 누가 옳은지 알아내는 방법은 무엇입니까?
고객에게 이전할 수 없는 소스 코드에는 실제로 무엇이 있습니까? 좋은 거래 아이디어, 즉 기술 사양은 일부 프로그래밍 비밀보다 훨씬 더 가치가 있습니다.
자신의 아이디어에 따라 작성된 소프트웨어를 판매하는 경우 소스 코드를 이전하는 것은 문제가 되지 않습니다.
다음을 바탕으로 정상적인 조건에서 계약 (응용 프로그램 읽기) ...
여기에 근본적인 실수가 있습니다. 계약은 둘 이상의 사람 간의 계약입니다. 신청서는 한 당사자의 제안일 뿐이며 그 자체로는 계약으로 간주될 수 없습니다. 논의중인 규칙의 본질에 따라 계약 관계의 출현 (계약 체결)은 참조 약관의 실행 후에 만 판단 할 수 있습니다. 양 당사자가 합의한 작업의 모든 세부 사항을 반영하기 위한 것은 참조 조건입니다.
... Contract-TK 링크에 대해 설명한 접근 방식은 기존 방식이라고 할 수 있으며, 이는 발생한 계약 관계를 해결하는 다른 동등한 형태의 존재를 결코 취소하지 않습니다. 비유적으로 말해서 러시아 연방 민법 36장 "계약"은 공개 및 보호된 구성원, 가상 기능 이 있는 상위 클래스이며 참조 조건은 가능한 하위 클래스 중 하나입니다. :)
Interesting :
이것은 문제의 일부를 해결하는 기술적 측면입니다. 사실, 당신은 고객이 신청서 작성 단계에서 결정하기 위해 "최종 파일의 유형을 결정"하라는 요구 사항을 제시했습니다. 따라서 고객에 대한 그러한 요구 사항은 (공식적인 관점에서) 규칙에 반영되어야 합니다. 고객이 그들에게 필요한 것이 무엇인지 이해할 수 있도록.
또한 계약자는 (자신의 이익을 위해) 신청서를 보고 진정해서는 안 되며, 참조 약관에서 직접 이 문제에 대한 동의를 얻어야 합니다.
정확히 말하면 여기에서 선택의 특정 규칙을 만드는 것이 다소 필요합니다. 고객이 소스 코드를 확실히 필요로 하는 경우에는 이에 대해 아무 것도 할 수 없으며, 그렇지 않으면 수행자가 선택할 수 있습니다.
동시에 고객은 소스 코드와 작업의 독점성(있는 경우)에 추가 비용이 든다는 점을 이해해야 합니다.
곰곰이 생각해보니 그런 것 같아요. 프로그래머가 고객의 사양에 따라 무언가를 작성하는 경우 소스 코드도 그에게 전송해야 합니다.
고객에게 이전할 수 없는 소스 코드에는 실제로 무엇이 있습니까? 좋은 거래 아이디어, 즉 기술 사양은 일부 프로그래밍 비밀보다 훨씬 더 가치가 있습니다.
자신의 아이디어에 따라 작성된 소프트웨어를 판매하는 경우 소스 코드를 이전하는 것은 문제가 되지 않습니다.
소스 코드는 많은 추가 기능, 클래스 등이 포함된 잘 설계된 템플릿이 될 수 있습니다. 여러 블록(예: 포함)으로 구성될 수 있으며 일부 조건만 다를 수 있습니다. 신호 모듈만 다른 한 시스템(서로 상호 작용의 의미에서 시스템)의 12가지 다른 파일의 소스 코드에서 반년(간단한 경우) 작동 시간을 제공할 준비가 되셨습니까? 하나의 클래스(파일))?
나는 당신이 체커의 교차점을 강타하기 위해 표준 수단을 사용할 수 있다는 것을 이해하며 유감스럽지 않습니다. 그리고 템플릿에 엄청난 작업이 투자된다면 어떻게 될까요? 아니, 준비됐어?
곰곰이 생각해보니 그런 것 같아요. 프로그래머가 고객의 사양에 따라 무언가를 작성하는 경우 소스 코드도 그에게 전송해야 합니다. 첫째, 개발자가 새 빌드를 다시 컴파일할 필요가 없다고 말할 가능성은 거의 없습니다. 둘째, 논란의 여지가 있는 문제를 해결해야 합니다. TOR가 잘못 공식화되었거나, 오해되었거나, 프로그래머가 단순히 실수했을 가능성이 있습니다. 첫 번째 경우 고객은 새로운 TOR에 대한 작업에 대해 다시 비용을 지불하거나 프로그래머를 혼자 남겨두어야 합니다. 두 번째와 세 번째에서 프로그래머는 무료로 잼을 수정해야 합니다. 소스 코드 없이 누가 옳은지 알아내는 방법은 무엇입니까?
고객에게 이전할 수 없는 소스 코드에는 실제로 무엇이 있습니까? 좋은 거래 아이디어, 즉 기술 사양은 일부 프로그래밍 비밀보다 훨씬 더 가치가 있습니다.
자신의 아이디어에 따라 작성된 소프트웨어를 판매하는 경우 소스 코드를 이전하는 것은 문제가 되지 않습니다.
1. 소스 코드의 필수 전송은 수행된 작업이 독점적인 경우에만 적절하지만, 이해하는 바와 같이 가격이 다를 수 있습니다(아마도 몇 배 이상).
재컴파일 문제는 초기에 해결할 수도 있습니다.
2. TK 소개
글쎄, 나는 "좋은" 소프트웨어 구현보다 더 많은 비용이 드는 "좋은" 아이디어를 Forex에서 보지 못했습니다.
나는 다음과 같이 질문에 답할 것이다 - 소스 코드에는 고객이 자신이 저작권 소유자이며 코드로 무엇이든 할 수 있다고 주장할 수 있는 가능성이 있습니다(예: 판매).
따라서 우리는 수행된 작업의 독점성에 대해 이야기할 가능성이 가장 큽니다(여기서 저는 소스 코드 배포를 추구하지 않는 프로그래머를 지원합니다).