Rules under Work - page 6

 
pronych:

The source can be a well-designed template, with lots of extra features, classes, etc.

I understand that you can use standard tools to bang out the intersection of the masks, and it's not a shame. But if a huge amount of work was put into the template, then how? No, here you are ready?

Have you read the job order? There's nothing but rubbish like crossing masks. If you would not regret to give it away, as long as it works, delete all unnecessary things from the template.

Interesting:

I have not seen any "good" ideas in Forex that cost more than a "good" software implementation.

The answer to this question - The source code has the ability to allow the customer to claim to be the rightful owner

So let him be the copyright holder. He came up with a not so good idea, you wrote not so good software and got not so good money for it, everyone should be happy. You won't even remember such a software in a week. There are good ideas, but they will never be in work orders. Since the value of such an idea is incomparable with its software implementation, no moron would put it on public display, and even in private would not show it to an unknown programmer. Those who came up with a good idea can learn the language.

 
pronych:
Right

Then write to Service Desk. If the idea is suitable (the wording can be adjusted if necessary).

pronych:

So let's think at once (quietly, while developers are asleep))), what kind of additions we would like to ask for in section 'Work'?

Problems are better solved as they arise :) You've started a proper thread, as ideas arise it will be expressed.
Общайтесь с разработчиками через Сервисдеск!
Общайтесь с разработчиками через Сервисдеск!
  • www.mql5.com
Ваше сообщение сразу станет доступно нашим отделам тестирования, технической поддержки и разработчикам торговой платформы.
 
Interesting:

In my opinion, there is another, alternative way - there is a mediator-arbitrator (in our case, MQ) between the contractor and the customer, and the contractor gives the whole package of materials + sources to the mediator (who checks them against the TOR), after which the customer receives a notice from the mediator that the work is completed and must pay for it.

Depending on exclusivity of the work and initial arrangements after the payment the client receives the maximum open source code or just the compiled files.

In this case as you understand the intermediary receives a certain remuneration.

PS

Although it seems to me MQ doesn't like it very much...

They have enough to do as it is...
 
Interesting:

In my opinion, there is another alternative way - an intermediary-arbitrator (in our case, MQ) gets between the contractor and the client, the contractor gives the whole package of materials + sources to the intermediary (who checks them against the ToR), after which the client receives a notice from the intermediary that the work has been completed and is obliged to pay for it.

Not very familiar with the shop idea from MQ. Does your idea diverge from the shop idea?
 
pronych:
Not really, to everyone.)) However, of course, it's also an option... For me, it's more convenient to have one file ready. This complicates the task (read -'cost') But the conversation is not even about it. Such an approach splits the idea, and the customer we have not know (or do not know! They may be different) in such things, though not a fool )) I think the checkbox "I want sources" is enough, and it just solve most of the issues before agreeing on the terms of reference. If this issue will be understandable, you can continue to discuss the job.

1. Why? In terms of a partially closed template, in which only certain modules are open, it's a viable idea.

I'm even sure that in terms of cost and time, this approach would be much cheaper.

2. Perhaps the checkbox is needed, but it's not just about source code, but about transferring all rights to the client (Exceptional rights, allowing client to do whatever he wants and restricting action of the doer).


Otherwise, tell me who prevents the contractor to sell the results of his work to third parties (say through a MAGAZINE)?

Who is stopping the customer from doing the same? But it is possible that several customers will pitch in to pay for one job, and then what?

 
AlexeyFX:

So let him be the copyright holder. He came up with a not very good idea, you wrote not very good software and got not very good money for it, everyone should be happy. You won't even remember such software in a week. There are good ideas, but they will never be in work orders. Since the value of such an idea is incomparable with its software implementation, no moron would put it on public display, and even in private would not show it to an unknown programmer. Those who came up with a good idea can learn the language.

1. Not a very good idea (in my opinion) personally, not only I will not automate it, and discuss it too lazy. Well, I have no desire to clone experts on two washers and sell them for $ 10.

Although if the idea is worthy, and 2 MACHINES can be the basis for any TS.

2. Just a question of who owns the final rights in my opinion is the most important. As far as I personally understand this question, if the copyright holder is the customer, he can do anything that is suitable (sell the work, alone or with the help of third parties to make changes to the code, use the code in their own developments, etc.), while it is likely that any reference to the artist can be removed.

If the contractor retains all or part of the rights to the code, he has the right to claim his rights, financial or copyright, from the customer. In this case, the contractor has the right to use the algorithms and the code for his own benefit.

Normal orders and normal work will definitely appear (after the terminal will be used on real accounts and serious traders will be interested in it).

PS

Personally, in my opinion, the cost of a normal TOR can be up to 50% of the total amount of the order, on average about 10% (of course the cost of the TOR itself can be much lower than the same 10% but the customer and the contractor must clearly understand the nature of the work).

There are of course unique cases when the cost of a well-formulated ToR will cost more than the job itself, but that's a separate story when in most cases the customer does not know what he wants.

Документация по MQL5: Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете
Документация по MQL5: Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете
  • www.mql5.com
Стандартные константы, перечисления и структуры / Состояние окружения / Информация о счете - Документация по MQL5
 
Interesting:

1. Why? In terms of a partially closed template, in which only certain modules are open, it's a viable idea.

I'm even sure that in terms of cost and time, this approach would be much cheaper.

2. Perhaps the checkbox is needed, but it's not just about source code, but about transferring all rights to the client (Exceptional rights, allowing client to do whatever he wants and restricting action of the doer).


Otherwise, tell me who prevents the contractor to sell the results of their work to a third party (say, through a SHOP)?

Who will prevent the customer from doing the same? But it is possible that several customers will pool together and pay for one job, and then what?

1. I agree. But the point is that in this case, you must somehow clearly indicate to the customer which results (in this case - the files) he wants to get. if there is a checkbox, or even can not be a checkbox, but an option such as, "sources completely", "sources partially", "compiled". This complicates the process and does not make sense at the application stage. Everything can be negotiated later. If the customer checked "sources", it makes sense to discuss, and if not, what questions, go ahead! )) The question about the sources, you understand, is not only sensitive, but also very slippery in this situation. I was even surprised to find no such aspect in the rules.

2. Here is also a serious question. One has to think about it. It's not just the performers who should have the obligation, but also the customers should specify more complete information even at the application stage. Perhaps it makes more sense to expand the application. Introduce some ideas. For example, to protect even a commissioned product. Personally, I always protected my developments (MT4) by checking on account. Well, the question is not about me...

 
Interesting:

1. I personally will not only not automate a good idea (in my opinion), but I am too lazy to discuss it. Well, I have no desire to clone experts at 2 MACHINES and sell them for $ 10.

Although if the idea is worthy, and 2 MACHINES can be the basis for any TS.

2. Just a question of who owns the final rights in my opinion is the most important. As far as I personally understand this question, if the copyright holder is the customer, he can do anything that is suitable (sell the work, alone or with the help of third parties to make changes to the code, use the code in their own developments, etc.), while it is likely that any reference to the artist can be removed.

If the contractor retains all or part of the rights to the code, he has the right to claim his rights, financial or copyright, from the customer. In this case, the contractor has the right to use the algorithms and the code for his own benefit.

Normal orders and normal work will definitely appear (after the terminal will be used on real accounts and serious traders will be interested in it).

PS

Personally, in my opinion, the cost of a normal TOR can be up to 50% of the total amount of the order, on average about 10% (of course the cost can be the TOR itself and be much lower than the same 10% but the customer and the contractor must clearly understand the nature of the work).

There are of course unique cases when the cost of a well-formulated ToR will cost more than the job itself, but that's a separate story when in most cases the customer does not know what he wants.

Exactly! I do not even have anything to add. I fully support the entire post. Now comes the pampering. All is still to come
 
Yedelkin:
Not very familiar with the shop idea from MQ. Does your idea diverge from the shop idea?

1. the basic idea of MAGAZINE is that the programmer creates a software solution (expert/script/indicator or library) and is able to sell it to several "customers" (or rather call them buyers) without providing the code and rights of the copyright holder.

In this case, MQ, as organizers of the service, act as intermediaries between the vendor and the buyers, protecting the both parties in a certain way. Thus, the developers need to protect the programmer's rights against illegal copying of the traded product, and to guarantee the buyer that the product is as described and "worth their money".

2. My idea is reminiscent of the idea of shop, but with some reservations - namely the customer can BUY the rights and the source code. Besides, as I understand it, it will not be possible to sell some things/solutions in the SHOP. For example there will be no opportunity to "sell" directly the TK (in the service "job" there is such an opportunity), all solutions related to their own DLL and similar things in the shop will not work.

PS

In my point of view, there are two ways (the main difference between SHOP and WORK):

1. The programmer is able to create a "good" software solution and sell it at a reasonable price to many customers. the customer is able to buy a particular software product at a reasonable price (but not exclusive rights to it);

2. Depending on the agreement for a sum acceptable to both parties, the customer can order a customised software product. He may also acquire exclusive rights to the results of the contractor's work.

 
There is also confusion (in the shop). Here you have to consider the emphasis on what you are selling. It is one thing for all and sundry, as they say, and another thing to be targeted, the customer specifying the account and broker, for future reference. How else could it be? Again, very different situations!
Reason: