pronych: А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
......然后补充说："我不知道怎么说是对的，但我个人认为，职权范围是次要的，只是合同（申请）的一个附件"。我对其进行了评论，并强调了 评论的短语。评论的实质：在某些条件下，ToR可能是自给自足的（用你的术语说是主要的）。好吧，它是这样的，对一个词来说，一个有争议的主题，事实上没有:)
所以在现实生活中，合同/协议确实是第一位的，我从来没有见过没有协议的协议书（而且通常协议书只是技术信息，而协议是双方法律关系的主要实质）。
就我个人而言，我习惯于以下顺序。
1.工作协议/合同（其中规定了客户、承包商、要完成的工作的主要内容、工作的时间、客户向承包商支付的金额、各方的责任以及必要的补充信息）。
2.职权范围（TOR），详细描述任务本身，并提供要进行的工作的具体特征（客户没有义务理解TOR）。
完成的行为。
对工作或其阶段的付款。
基于上述，我认为在正常情况下，合同（读作标书）的地位高于职权范围（职权范围是在合同的基础上形成的，有详细的工作规范或特定阶段）。
我想，在我们这里，开发者（作为服务的组织者）需要在申请的内容上更加详细，使其更接近实际的合同。
也可能值得强调的是，在形成TOR的过程中，允许表演者获得一定的金额（精确指定或作为订单的百分比），当然，如果表演者自己准备了TOR并且客户同意的话。
pronych:
А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
这是解决部分问题的技术层面。 事实上，你提出的要求是让客户 "决定最终文件的类型"，在填写申请的阶段决定。因此，对客户的这种要求应该（从形式上看）反映在《规则》中。客户必须明白对他们的要求是什么。
此外，承包人（为了自己的利益）不应该一看到申请书就沾沾自喜，而应该在职权范围内直接商定这一事项。
而在一般情况下，最简单的方法不是把规则弄得一团糟，而是简单地，当你输入请求时，添加 "未勾选"，如 "我想要来源"，并反映在工作列表中。谁需要它，他将勾选复选框。一个小的更新，但多么好。而且一下子就能清楚。
在我看来，"申请 "本身需要进行更详细的重新设计。不仅如此，还应该有很多。例如，你还可以检查允许/禁止表演者在未来使用算法和程序代码的条件。
虽然我明白这种事情是很难控制的。
PS
就是我理解的那样，与顾客相比，没有人干涉复制作品（尤其是有源代码的情况下），艺术家可以很容易地把它放在商店里或转卖给另一个顾客。
这是解决部分问题的技术层面。 事实上，你提出的要求是让客户 "决定最终文件的类型"，在填写申请的阶段决定。因此，对客户的这种要求应该（从形式上看）反映在《规则》中。这样他们就会明白对他们的要求是什么。
此外，承包人（为了自己的利益）不应该一看到申请就沾沾自喜，而应该直接在职权范围内就这个问题达成协议。
准确地说，相当有必要做出某种条件性的选择。如果客户一定要这些来源，那么就没有什么可做的，否则承包商就会有选择。
在这种情况下，客户应该明白，作品的来源和独占性（如果有的话）将花费额外的钱。
经过思考，我这样认为。如果一个程序员根据客户的职权范围写了一些东西，他也必须给他源代码。首先，开发人员不太可能说，任何新的构建都不需要再重新编译。第二，有必要解决任何争端。有可能是TOR的制定不正确，被误解了，或者程序员只是犯了一个错误。在第一种情况下，客户必须支付返工的费用，以获得新的ToR，或者让程序员独自离开。在第二和第三种情况下，程序员必须免费纠正他的错误。没有源代码，我怎么能弄清楚谁是正确的？
源代码中有哪些东西不能传给客户？一个好的销售理念，也就是TOR，比一些程序员的秘密更有价值。
如果你出售根据自己的想法编写的软件，那么源代码的转让是不可能的。
根据以下情况，我认为在正常情况下，合同（读作申请）.... ..。
这里有一个基本错误。合同是两个或更多人之间的协议。申请书只是一方的建议，其本身不能被视为合同。就正在讨论的规则而言，只有在制定了职权范围之后，才能建立合同关系（缔结合同）。职权范围旨在反映各方 商定的工作细节。
你所描述的工程合同方式可称为 "经典 "的方式，这并不排除存在其他任何平等形式的合同关系的建立，这一点已经出现。形象地说，《民法典》第36章 "合同-协议 "是一个父类，它有公共和保护成员以及虚拟函数，而要求规范是可能的子类之一。:)
Interesting:
这是解决部分问题的技术层面。 事实上，你提出的要求是让客户 "决定最终文件的类型"，在填写申请的阶段决定。因此，对客户的这种要求应该（从形式上看）反映在《规则》中。客户必须明白对他们的要求是什么。
此外，承包人（为了自己的利益）不应该一看到申请就沾沾自喜，而应该直接在职权范围内就这个问题达成协议。
准确地说，相当有必要做出某种条件性的选择。如果客户一定需要源代码，那么就没什么可做的，否则艺术家就会有选择。
在这种情况下，客户应该明白，作品的来源和独占性（如果有的话）将花费额外的钱。
经过思考，我这样认为。如果一个程序员根据客户的职权范围写了一些东西，他也必须给他源代码。
源代码中到底有什么东西不能传给客户？一个好的销售理念，即TOR，比一些编程秘密更有价值。
如果你销售的软件是基于你自己的想法而编写的，那么交出源代码是不可能的。
源代码可以是一个精心设计的模板，有很多额外的功能和类等等。它可以由一堆块组成（例如inludes），其中只有一些条件可能是不同的。你准备好在一个系统（系统，在相互作用的意义上）的十几个不同文件的源代码中付出六个月的工作（在一个简单的例子中），其中只有信号模块（一个类（文件））不同？
我明白，我们可以用标准的工具来崩溃掩码，这并不可惜。但是，如果在模板上投入巨大的努力，我们怎么能做到呢？不，你准备好了吗？
经过思考，我这样认为。如果一个程序员根据客户的职权范围写了一些东西，他也必须给他源代码。首先，开发人员不太可能说，任何新的构建都不需要再重新编译。第二，有必要解决任何争端。有可能是TOR的制定不正确，被误解了，或者程序员只是犯了一个错误。在第一种情况下，客户必须支付返工的费用，以获得新的ToR，或者让程序员独自离开。在第二和第三种情况下，程序员必须免费纠正他的错误。没有源代码怎么能分出谁是对的？
源代码中有哪些东西不能传给客户？一个好的销售理念，也就是TOR，比一些程序员的秘密更有价值。
如果你销售的软件是根据你自己的想法编写的，那么转让源代码是不可能的。
1.只有当需要完成的工作具有排他性时，强制转让源代码才是合适的，但正如你所理解的那样，价格会有所不同（可能会高出几倍）。
重新编译的问题也可以在一开始就得到解决。
2.关于ToR。
好吧，我还没有看到关于外汇的 "好 "想法，这将比 "好 "的软件实施成本更高。
在回答你的问题时--源代码有能力让客户辩称他是权利人，可以对代码做任何事情（例如，出售）。
因此，我们最有可能谈论的是作品的排他性（在此我支持程序员不寻求传播源代码）。