契約者がオリジナルファイルを渡さない、または年が新しく、問題が古い - ページ 2

 
Slava:

ソースコードは、仕事が完了する前に、契約者から無条件で渡されます。

ソースコードが転送されるまで、クライアントはジョブを閉じてはいけません。そうすれば、SCCBは閉鎖される。

請負業者がソースコードを渡さなかった場合、クライアントは返金のために仲裁を開く完全な権利を持っています。

これらはすべて、「フリーランス・ルール」に明示されています。

https://www.mql5.com/ru/job/rules。

出典」ページで検索すると、2件ヒットしました。

次のステップに進むことは

第三者が所有するソフトウェアのソース コードを入手 することを目的とする。


それとも、もっとフリーランスのルールがあるのでしょうか?

 
Igor Makanu:

規則上https://www.mql5.com/ru/job/rules

を検索したところ、2件ヒットしました。


それとも、もっとフリーランスのルールがあるのでしょうか?

不具合かもしれませんが、承認時に出典に関する条項があるようです。契約者が引き渡さなければならないこと。もちろん、長い間フリーで注文していないので、何か勘違いしているかもしれません。しかし、議論しているうちに、ある条項にはそれが含まれているように思えてきました。
 
Scarick:
多分私はコースが、段落のいずれかでそこに調整の間に本当にソースについてであるように釘付けにされています。契約者が与えなければならないこと。もちろん、何か勘違いしているのかもしれませんが、フリーで注文するのは久しぶりです。しかし、議論の中で、本当にポイントの1つになるような気がします。

見てみたい、だからこそ、これがルールで規定されているのかどうかを聞いているのです。

私はよくFreelanceで、テキストの最後にクライアントが指定する仕事の説明を参照してください - 仕事の終わりに開発者は、ソースコードを与えるだろう。

ということで、Freelanceのルールに具体的な文言がないために登場したのだと思います。


もし開発者が自分の開発を移管したくないのであれば、ソースコードを要求する注文を受けない。もし顧客がソースコードを入手することを100%確実にしたいのであれば、注文を受け、ToRにそれを明記する。

 
Igor Makanu:

見てみたい、だからこそ、これがルールで規定されているのかどうかを聞いているのです。

私はよくFreelanceで、テキストの最後にクライアントが指定する仕事の説明を参照してください - 仕事の終わりに開発者は、ソースコードを与えるだろう。

ということで、Freelanceのルールに具体的な文言がないために登場したのだと思います。


もし開発者が自分の仕事を移したくないのであれば、ソースコードを要求する注文は受けません。

私はフリーランスで仕事をして以来、私は)長い時間を覚えていないと言っています。でも、ToRに明記しなくても、いつもデモの段階かどこかで、ソースを捨てていました。あるいは、自分で聞いたり、自動的に送られてきたりした。この質問がTORに明記されていないことに憤慨する人はいなかった。
もちろん、私が幸運だったのかもしれないし、開発者が親切だったのかもしれない。しかし、私はあえて5つのToRをすべてチェックし、ソースコードを指定することはありませんでした。すべて問答無用で手に入れました。それよりも、筆者が当初、出典を聞かなかったことに驚いている。中身はどうでもいいのか?あるいは、うまくいっているのだから、ソースを見る必要はない、という論理なのかもしれません。

 
Scarick:
もちろん私が釘付けになっているのかもしれませんが、交渉の中で、ある条項の中に確かにソースの話があったようです。契約者が渡すべきものであると。もちろん、何か勘違いしているのかもしれませんが、フリーで注文するのは久しぶりです。しかし、議論しているうちに、本当に1項があるように思えてきたのです。
規則第3条「ステップの説明」第5項第2号には、次のように記載されています。"仕事の伝達"は、ファイルという形でソリューションを並べることで行われます。ファイル数は制限されない」。

はい、どのファイルをアップロードする必要があるかは指定されていませんが、クライアントからはソースファイルの提出を求められました。契約書にサインをした後ではありますが。そして、空いたスペースでクライアントに誠実さをアピールするのが快感なのだ。

しかし、第12項「一般規定」にも、(特に断りのない限り)お客様の完全な著作権を定義しています。

"フリーランス "サービスを通じて受託制作された本ソフトウェアの独占的権利の譲渡条件について別途約定がない限り、受託制作された本ソフトウェアの独占的権利は、お客様に 帰属します。"

つまり、受注の実行を意味するのであって、自社の開発の実行ではない(受注者側で製品に対する権利を主張することは侵害となる)。まあ、論理的に考えれば、クライアントが製品をさらに開発する必要がある場合(理論上はそうなる)、ソースコードが必要になるわけです。そうでなければ、初めからやり直さなければならない。

つまり、一方では明らかな見落としがあり、他方では原則に過剰に固執し、ほとんど野暮ったい...ということです。著作権の主張も。
 
Yevhenii Levchenko:
著作権の主張も

イモ、これは議論を終了する場所です - 知的財産の著作権は、いくつかの関与の文だけでなく、全体の手順です - 事前のクレームを取得し、第三者と協力する前に警告するが、その逆ではなく、それ以外の場合は常に何かが誰かに合っていない場合ことが判明 - それは著作権に影響を与え、その後すべてのラッシュは誰かのアイデア/執筆を保護するために

一般に、知的財産権に関する紛争は、特にデジタル製品に関しては、終わりのない議論です。

 
Igor Makanu:

知的財産の著作権は、単に所有権を宣言するだけでなく、手続き全体が必要である。

イゴール まあ、そこは、ルール上、著作権の帰属が自動的に決まってしまうので...。何も宣言しなくてもいいんです :)

人間的に簡単に解けるものばかりです。これまで、超効率的なアイデア(良い意味で生産的なアイデア)に出会ったことはありません。おそらく、そこには純粋に主義主張の論争があるのだろう。

一人は見逃し、もう一人は頑固...。

 
Yevhenii Levchenko:

イゴール そこ、ルール上、著作権の帰属が自動的に決まってしまうので......。何も宣言する必要もありません :)

人間的に簡単に解けるものばかりです。これまで、超効率的なアイデア(良い意味で生産的なアイデア)に出会ったことはありません。おそらく、そこには純粋に主義主張の論争があるのだろう。

一人は見逃し、もう一人は頑固...。

もっとありそうなシナリオは、実行者がソースファイルを持っていないことです。

彼は中間投機家であり、どこかで最終開発者と問題があった(例えば、前作からの共有が少なすぎるなど)。

 
Maxim Kuznetsov:

より可能性が高いのは、コントラクターがソースファイルを持っていないことです。

中抜き儲け主義で、どこかで最終開発者とうまくいかなかった(前作からの共有が少なすぎるなど)。

0_o

地下室でペダルをこぐ中国人の集団が、想定される実行犯の代わりにコーディングしているような?それとも、どこかの職人が塞ぎ込んでしまって、自分でパッドを見つけたような?

 
Yevhenii Levchenko:

一人は見逃し、もう一人は頑なに...。

まあそうなんだけどしかし、しばしばこのような非合意が「煙に巻く」ようになり、次に顧客が開発者に「乗り」始め--もう一度やろう、もう一度やろう、何が必要だ...、そしてこの場合--開発者の連絡先を公開すると脅して「旗を振る」のか。

イミフ、ルールで指定されていない場合、および契約書に規定されていない場合 - 誰もが彼が合うと思うように行い、道徳の独自の立場から誰かの行動を議論? 個人的な経験?

理由: