Rules under Work - page 4
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
... And then added: "I do not know how it's right, but I personally believe that the TOR is secondary and is only an attachment to the contract (application)". Which I commented on, with an emphasis on the commented phrases. The essence of the comment: under certain conditions, ToR may be self-sufficient (primary in your terminology). Well it so, to a word, a subject for dispute in fact there is no :)
So in real life, the contract/agreement does come first, I've never met a ToR without an agreement (and usually the ToR is just technical information, while the agreement is the main essence of the legal relationship between the parties).
Personally, I am used to the following sequence:
1. an agreement/contract for work (which specifies the customer, the contractor, the main essence of the work to be done, the timing of the work, the amount paid by the customer to the contractor, the liability of the parties and additional information if necessary);
2. Terms of reference (TOR) describing in details the task itself and providing specific characteristics of the work to be performed (the client is not obligated to understand the TOR);
Act of Completion;
Payment for the work or its stages.
Based on the above, I believe that under normal circumstances, the contract (read bid) has a higher status than the TOR (ToR are formed on the basis of the contract with detailed specification of work or a specific stage).
I assume that in ours the developers (as the organizers of the service) need to be more detailed in the content of the application, bringing it closer to the actual contract.
It may also be worth highlighting the process of forming TOR, allowing the performer to receive a certain amount (specified precisely or as a percentage of the order), of course, if the performer has prepared the TOR himself and the customer agreed to it.
pronych:
А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
This is the technical side of solving part of the problem. In fact, you are putting forward a requirement for Clients to "decide on the type of final file", to decide at the stage of filling in the Application. Accordingly, such a requirement for Clients should (from a formal point of view) be reflected in the Rules. The Clients must understand what is required of them.
Moreover, the Contractor (in its own interest) should not become complacent at the sight of an Application, but should get this matter agreed directly in the terms of reference.
And in general, the easiest way not to make a mess with the rules, but simply, when you enter the request to add "unchecked", such as "I want sources" and reflect it in the list of jobs. who needs it, he will check the checkbox. a small update, but how nice. and all at once it will be clear.
In my opinion, the "application" itself needs to be reworked in more detail. Not only that, but there should be a lot more. For example, you can also check the conditions that allow/forbid the performer to use algorithms and program code in the future.
Although I understand that such things are very difficult to control.
PS
It's that as I understand that in contrast to the customer no one interfere to replicate the work (especially if the source code) and the artist can easily put it in the shop or resell to another customer.
This is the technical side of solving part of the problem. In fact, you are putting forward a requirement for Clients to "decide on the type of final file", to decide at the stage of filling in the Application. Accordingly, such a requirement for Clients should (from a formal point of view) be reflected in the Rules. So that they understand what is required of them.
Moreover, the Contractor (in its own interest) should not become complacent at the sight of an application, but should reach an agreement on this issue directly in the terms of reference.
To be precise, it is rather necessary to make some kind of conditional choice. If the client necessarily wants the sources, then there is nothing to do, otherwise the contractor will have a choice.
In this case, the customer should understand that the sources and exclusivity of the work (if any) will cost extra money.
After thinking it over, I think this. If a programmer writes something according to the customer's terms of reference, he must also give him the source code. Firstly, it is unlikely that the developers will ever say that no new build will ever need to be recompiled again. Secondly, it is necessary to resolve any disputes. It is possible that the TOR was incorrectly formulated, misunderstood or the programmer just made a mistake. In the first case, the customer has to pay for the rework to a new ToR or leave the programmer alone. In the second and third case, the programmer has to correct his mistakes for free. How can I figure out who is right without source code?
What is in the source code that can not be passed on to the customer? A good sales idea, that is the TOR, is worth much more than some programmer secrets.
If you sell software written on your own ideas, then the transfer of source code is out of the question.
On the basis of the following I believe that under normal circumstances a contract (read application) . ..
There is a fundamental error here. A contract is an agreement between two or more persons. An application is just a proposal by one party, which in itself cannot be regarded as a contract. In terms of the rules under discussion, a contractual relationship comes into existence (conclusion of a contract) only after the Terms of Reference have been issued. The terms of reference are intended to reflect the details of the work agreed upon by the parties .
The Contract to Works approach that you have described may be called a classical one, which does not preclude the existence of any other equal forms of the establishment of the contractual relationship that have arisen. Figuratively speaking, the Chapter 36 "Contract-Agreement" of Civil Code is a parent class with its public and protected members and virtual functions, and the requirements specification is one of the possible descendant classes. :)
Interesting:
This is the technical side of solving part of the problem. In fact, you are putting forward a requirement for Clients to "decide on the type of final file", to decide at the stage of filling in the Application. Accordingly, such a requirement for Clients should (from a formal point of view) be reflected in the Rules. The Clients must understand what is required of them.
Moreover, the Contractor (in its own interest) should not become complacent at the sight of an application, but should reach an agreement on this issue directly in the terms of reference.
To be precise, it is rather necessary to make some kind of conditional choice. If the customer necessarily need the source code then there is nothing to do, otherwise the artist will have a choice.
In this case, the customer should understand that the sources and exclusivity of the work (if any) will cost extra money.
After thinking it over, I think this. If a programmer writes something according to the customer's terms of reference, he must also give him the source code.
What exactly is there in the source code that cannot be passed on to the client? A good sales idea, i.e. the TOR, is worth much more than some programming secrets.
If you are selling software that is written based on your own ideas, handing over the source code is out of the question.
The source code can be a well-designed template, with lots of extra features, classes, etc.. It can consist of a bunch of blocks (inludes, for example) and only some of the conditions in it may be different. Are you ready to give six months (in a simple case) of work, in the source code of a dozen different files of one system (system, in the sense of interaction with each other), in which only the signal module (one class(file)) differs?
I understand, we can use standard tools to crash crash the masks, and it's not a pity. But if huge efforts are put into the template, how can we do it? No, are you ready?
After thinking it over, I think this. If a programmer writes something according to the customer's terms of reference, he must also give him the source code. Firstly, it is unlikely that the developers will ever say that no new build will ever need to be recompiled again. Secondly, it is necessary to resolve any disputes. It is possible that the TOR was incorrectly formulated, misunderstood or the programmer just made a mistake. In the first case, the customer has to pay for the rework to a new ToR or leave the programmer alone. In the second and third case, the programmer has to correct his mistakes for free. How can I figure out who is right without source code?
What is in the source code that can not be passed on to the customer? A good sales idea, that is the TOR, is worth much more than some programmer secrets.
If you sell software that was written based on your own ideas, then the transfer of source code is out of the question.
1. the compulsory transfer of the source code is appropriate only when the work to be done is exclusive, but as you understand the price will be different (possibly several times higher).
The question with recompilation also can be solved at the very beginning.
2. Regarding ToR.
Well, I have not seen "good" ideas on Forex, which would cost more than a "good" software implementation.
In response to your question - the source code has the ability to allow the customer to argue that he is the rights holder and can do anything with the code (for example, sell it).
Therefore, we are most likely talking about the exclusivity of the work (and here I support the programmers do not seek to disseminate the source code).