pronych: А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
ここには根本的な間違いがある。契約とは、2人以上の人間の間で交わされる合意である。申込書は、あくまでも当事者の一方からの提案であり、それ自体を契約とみなすことはできません。現在審議中のルールでは、Terms of Referenceが作成されて初めて契約関係（契約の締結）が成立することになっています。この委託契約は、当事者間で 合意された業務の内容を反映することを目的としています。
ご指摘のContract to Worksのアプローチは、「古典的」なものと言えるかもしれませんが、これは、それ以外の等しい形態の契約関係の成立が生じた場合の存在を排除するものではありません。比喩的に言えば、民法第36章「契約-合意」は、publicおよびprotectedメンバと仮想関数を 持つ親クラスであり、要求仕様書は可能な限り子孫クラスの一つである。:)
...そして、「どう正しいかはわからないが、個人的にはTORは二次的なものであり、契約（申請）の添付資料に過ぎないと考えている」とも付け加えた。どの、コメントしたフレーズに重点を置いて コメントしました。コメントの本質：ある条件下では、ToRは自給自足（あなたの用語ではプライマリー）できるかもしれません。そうですね、一言で言えば、論争の対象になりますね。）
契約書がないToRは見たことがない（そして通常、ToRは単なる技術情報であり、契約書は当事者間の法的関係の主要な本質である）。
個人的には、次のような流れで使っています。
1. 作業に関する合意書/契約書（顧客、請負業者、行われる作業の主要な本質、作業の時期、顧客が請負業者に支払う金額、当事者の責任、必要に応じて追加情報を指定するもの）。
2.業務内容を詳細に記述し、実施すべき業務の具体的な特徴を示した業務指示書（TOR）（依頼者はTORを理解する義務はない）。
完成させる行為。
作品またはその段階に対する支払い。
以上のことから、通常であれば、契約（入札と読みます）はTORよりも高い地位にあると思います（TORは、作業の詳細な仕様や特定の段階での契約に基づいて形成されます）。
私たちの場合は、サービスの主催者である開発者が、実際の契約に近づけるために、アプリケーションの内容をより詳細に記述する必要があると推測しています。
また、演奏者が自らTORを作成し、顧客がそれに同意した場合はもちろん、演奏者が一定の金額（正確に指定されたもの、または注文に対する割合として）を受け取ることができる、というTORの形成過程を強調することも価値があるかもしれない。
pronych:
А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
これは、問題の一部を解決する技術的な側面です。 実際、クライアントが「最終的なファイルの種類を決める」ために、Applicationを記入する段階で決めるという要件を打ち出していますね。従って、このようなクライアントに対する要求は、（形式的な観点から）規則に反映される べきである。クライアントは、自分に何が求められているかを理解する必要があります。
さらに、契約者は（自らの利益のために）Applicationを見ただけで満足するのではなく、この件についてTerms of Referenceで直接合意してもらうべきである。
そして、一般的に、ルールで混乱させない最も簡単な方法は、単純に、あなたが「私はソースが欲しい」など、「チェックされていない」を追加する要求を入力し、ジョブのリストに反映させるとき。
私見ですが、「アプリケーション」そのものをもっと細部にわたって作り直す必要があるのではないでしょうか。それだけでなく、もっとたくさんあるはずです。例えば、演奏者が今後アルゴリズムやプログラムコードを使用することを許可/禁止する条件も確認することができます。
しかし、そのようなことをコントロールするのは非常に難しいことだと理解しています。
追記
それは、私が理解しているように、顧客とは対照的に、誰も作品を複製することを妨げず（特にソースコードの場合）、アーティストは簡単にそれを店に置くか、別の顧客に転売することができるということです。
これは、問題の一部を解決する技術的な側面です。 実際、クライアントが「最終的なファイルの種類を決める」ために、アプリケーションを記入する段階で決めるという要件を打ち出していますね。従って、このようなクライアントに対する要求は、（形式的な観点から）ルールに反映される べきである。自分たちに何が求められているのかを理解するために。
さらに、契約者は（自らの利益のために）申請を見ただけで満足することなく、この問題に関して直接、契約条件の中で合意に達するべきである。
正確には、むしろ何らかの条件付きで選択する必要があるのです。クライアントが必ずしもソースを欲しがっているのであれば、何もする必要はないが、そうでなければ、コントラクターは選択を迫られることになる。
この場合、作品の出所や独占権（ある場合）は、別途費用がかかることをお客様にご理解いただく必要があります。
よく考えてみると、こう思うのです。プログラマーが顧客の条件に従って何かを書いたら、ソースコードも渡さなければならない。まず、開発者が「新しいビルドは二度と再コンパイルする必要がない」と言い切ることはまずないでしょう。第二に、紛争を解決することが必要である。TORの策定が誤っていた、誤解していた、プログラマーが間違えただけの可能性もあります。前者の場合、顧客は新しいToRへの手直し費用を負担するか、プログラマーを放っておくしかない。2番目と3番目のケースでは、プログラマーは自分のミスを無料で修正しなければならない。ソースコードがないのに、誰が正しいかわかるのか？
お客様に渡せないソースコードの中身は？TORという優れた販売アイデアは、プログラマーの秘密よりもずっと価値がある。
自分のアイデアで書いたソフトを販売する場合、ソースコードの譲渡は論外です。
以下に基づいて、私は通常の状況下では、契約（アプリケーションを読む） ...
ここには根本的な間違いがある。契約とは、2人以上の人間の間で交わされる合意である。申込書は、あくまでも当事者の一方からの提案であり、それ自体を契約とみなすことはできません。現在審議中のルールでは、Terms of Referenceが作成されて初めて契約関係（契約の締結）が成立することになっています。この委託契約は、当事者間で 合意された業務の内容を反映することを目的としています。
ご指摘のContract to Worksのアプローチは、「古典的」なものと言えるかもしれませんが、これは、それ以外の等しい形態の契約関係の成立が生じた場合の存在を排除するものではありません。比喩的に言えば、民法第36章「契約-合意」は、publicおよびprotectedメンバと仮想関数を 持つ親クラスであり、要求仕様書は可能な限り子孫クラスの一つである。:)
Interesting:
これは、問題の一部を解決する技術的な側面です。 実際、クライアントが「最終的なファイルの種類を決める」ために、Applicationを記入する段階で決めるという要件を打ち出していますね。従って、このようなクライアントに対する要求は、（形式的な観点から）規則に反映される べきである。クライアントは、自分に何が求められているかを理解する必要があります。
さらに、契約者は（自らの利益のために）申請を見ただけで満足することなく、この問題に関して直接、契約条件の中で合意に達するべきである。
正確には、むしろ何らかの条件付きで選択する必要があるのです。お客様がどうしてもソースコードを必要とされるのであれば仕方ありませんが、そうでない場合はアーティストが選択することになります。
この場合、作品の出所や独占権（ある場合）は、別途費用がかかることをお客様にご理解いただく必要があります。
よく考えてみると、こう思うのです。プログラマーが顧客の条件に従って何かを書いたら、ソースコードも渡さなければならない。
クライアントに渡せないソースコードとは、具体的にどのようなものなのでしょうか？優れた販売アイデア、すなわちTORは、プログラミングの秘密よりもはるかに価値がある。
自分のアイデアで作ったソフトを売る場合、ソースコードの受け渡しは論外です。
ソースコードは、多くの追加機能、クラスなどを備えた、よく設計されたテンプレートにすることができます。ブロックの束（inludesなど）で構成され、その中の一部の条件だけが異なる場合があります。シグナルモジュール（1つのクラス（ファイル））だけが異なる1つのシステム（相互作用という意味でのシステム）の12個の異なるファイルのソースコードに、6ヶ月（単純な場合）を費やす覚悟がありますか？
わかります、標準のツールでマスクのクラッシュができるんです、残念でなりません。しかし、テンプレートに膨大な労力が投入されるのであれば、どうすればいいのでしょうか。いいえ、準備はいいですか？
よく考えてみると、こう思うのです。プログラマーが顧客の条件に従って何かを書いたら、ソースコードも渡さなければならない。まず、開発者が「新しいビルドは二度と再コンパイルする必要がない」と言い切ることはまずないでしょう。第二に、紛争を解決することが必要である。TORの策定が誤っていた、誤解していた、プログラマーが間違えただけの可能性もあります。前者の場合、顧客は新しいToRへの手直し費用を負担するか、プログラマーを放っておくしかない。2番目と3番目のケースでは、プログラマーは自分のミスを無料で修正しなければならない。ソースコードがないのに、誰が正しいかわかるのか？
お客様に渡せないソースコードの中身は？TORという優れた販売アイデアは、プログラマーの秘密よりもずっと価値がある。
自分のアイデアで作ったソフトを売るのであれば、ソースコードの譲渡は論外です。
1.ソースコードの強制譲渡は、行うべき業務が独占的である場合にのみ適切であるが、ご理解の通り、価格が異なる（数倍高くなる可能性がある）。
リコンパイルの問題も、最初の段階で解決することができます。
2.ToRについて。
さて、FXで「良い」アイデアを見たことがないのですが、それは「良い」ソフトウェアの実装よりもコストがかかるでしょう。
ご質問の件ですが、ソースコードは、お客様が権利者であり、そのコードで何でもできる（例えば、販売できる）と主張できる機能を備えています。
したがって、私たちは作品の独占性について話している可能性が高い（そしてここで私は、プログラマがソースコードを普及させようとしないことを支持する）。