クライアントはソースコードを望んでいますが、他のプロジェクトで再利用する共有コードがたくさん含まれています
開発したアプリケーションバイナリのソースコードを提供してほしいクライアントがいます。彼らはもともとソースコードについて何も言わなかったが、最近それが必要だと言った。契約は確定していません。彼らはその作業に同意し、署名しなかったため、この条項に戻った。
問題は、私が何年にもわたって作成し、作成したほとんどのアプリケーションのテンプレートとして使用したコードベースがあることです。プロジェクトの範囲よりはるかに大きいです。
また、製品にも使用する予定なので、比較的小規模なプロジェクトには提供したくありません。
これがこの業界で起こったのはこれが初めてではないと思います。この問題を回避する最良の方法は何ですか？共有ライブラリのようなものが役立つと思います。
最初に覚えておかなければならないのは、ソースコードにはバイナリとは別の値があるということです。ソースコードの配信を必要とする契約への署名を拒否するか、ソースコードの配信に追加の支払いを要求することは完全に合理的です。契約は双方向の文書です。他の部分に「大企業」であり、「これを常に行う」という理由だけで、何が必要かを指示させないでください。まず、あなたが喜んで提供するものと、あなたがどのようにしたいかを決めます補償される。次に、彼らの契約を弁護士に持ち、何を変える必要があるかを考え出します。その後、交渉します。
多くの若者が契約を始めたときのようにしないでください。彼らは多くの経験を持っているようで、あなたはそうではないので、単に署名しないでください。それは、取り除かれる良い方法です。
なぜソースが必要かを調べます。彼らはそれを望むかもしれないので、彼らは後で別の開発者を使用するオプションを持っています。または、彼らはあなたがバスに襲われるかもしれないと恐れているだけでそれを望んでいるかもしれません、そして、突然、彼らは彼らが改善できないバイナリを残されます。これが2番目のケースである場合は、 ソフトウェアコードエスクローサービス を調べます。これらのサービスは、あなたが倒産したり、ソフトウェアを維持できない場合に備えて、ソースコードを保持します。これは、他の顧客にサービスを提供するためにコードをプロプライエタリに保ちたいという要望と、何か問題が発生した場合にメンテナンス不可能なバイナリのセットでバッグを保持したままにしたくないという要望の両方を満たします。
"いいえ"は完全にすばらしい回答ですが、実際には非常に役立つ回答であり、何らかの理由で理解できませんが、非常に過小評価されています。
「こんにちは、私たちは突然、ソースコードも無料で欲しいと突然決めました。」
「こんにちは。」
それほど難しいことではありません。
次に、彼らが莫大な金額を支払いたい場合はover彼らが支払うものalreadyはあなたに借りがあるので、あなたは彼らに実際のソースのみを含むアプリケーションのトリミングされたバージョンを与えるかもしれません必要、そして彼らが絶対に取得するように注意してください非-独占権。
単純なことを複雑にしないでください。
あなたの質問は、「この問題を回避する最良の方法は何ですか？」です。しかし、あなたは問題として何を見ますか？他の人はそれが交渉の問題であると正しく指摘しました：すべてが価値を持っています、そしてあなたが求められているものを提供するための価格をクライアントに与えるのはあなた次第です。
ただし、コードを提供することの含意を慎重に検討し、契約に書き込む必要もあります。それはクライアントがそれを見ることができるようにするだけですか？クライアントはそれを変更できますか？そして特に、あなたが持っているコードベースに独占的な権利をクライアントに与えることを検討します何年にもわたって作成され、ほとんどのアプリケーションのテンプレートとして使用されます今後自分でそれを再び使用することはできません？
契約では、コードを使用する権利を誰がどのように使用するかを明示的に示す必要があります。
ソースコードにはライセンスが必要です。ソースコードを引き渡す場合、会社はソースコードを使用して、ライセンスが許可するすべてのことを行うことができ、それを超えるものはすべて著作権侵害です。したがって、ソースコードを引き渡す場合は、ソースコードの独占的な著作権を保持していること、およびソースコードのどのような使用が許可されているかを完全に明確にする契約を結ぶことになります。そしてもちろん、ソースコード+ライセンスは無料ではありません。
大手企業があなたの著作権を侵害する可能性は低いでしょう。なぜなら、逮捕されると、金銭的損害は別として、彼らの評判に大きな損害を与えるからです。一方、将来の問題の修正が保証されていないソフトウェアの支払いは、クライアントには受け入れられない可能性があります。
以前、私は通常、MITライセンスの下でソースコード（ライブラリとすべて）をクライアントに提供しました。ライブラリが適切に構成されている場合、特定のクライアントに必要なファイル/リソースのみを提供しますが、それ以上は提供しません。 。それは私とクライアントの両方にとって公平だと思います。しかし、以前はライブラリの一部ではなかった、契約に基づいてその特定のクライアント用に書かれた新しいコードの問題が常にありました。そのため、開始する前にクライアントとこの問題について話し始めましたプロジェクト。一部のクライアントはそのコードの所有権を望んでいますが、そうではありません（私は常にそうする人のために値段を高くするなど、マイナスのインセンティブを与えました）。しかし、一部のクライアントにとって、議論は非常に混乱し、時には3または、プロジェクトを承認するためだけに5人の異なる人々（弁護士を含む）。
したがって、すべてのライブラリは、私が常に開発に使用するカスタムフレームワークの一部であり、このフレームワークを使用するが、フレームワークは別のライセンスの別の製品であることをクライアントに説明します。 （「フレームワーク」が知られていない可能性があるため、説明の際に「ソフトウェアコンポーネント」を使用することがあります）。私は常にMITライセンスの下で使用されるファイルのコードを提供し、（すべてのコードがよく整理されているため）低レベルのコード（新しいコードでも）をフレームワークに残します（再利用するため）私と彼らによって）しかし、彼らのアプリケーションに関連するコードは、彼らが彼ら自身の条件の下で保つためのものです（そのコードはおそらく私が別のプロジェクトで再利用するために役に立たないでしょう）もちろん、すべて契約で適切に書かれています。これも公平だと思います。
重要なのは、「これらのコンポーネントは別の製品」であり、開始する前にすべて契約書に書かれていることです。
ですから、共有ライブラリの使用についての考えは正しいかもしれません。しかし、私はあなたに尋ねます、彼らに彼らのリスクを減らすことを可能にするライセンスの下で、あなたに彼らにあなたが使ったソースコードを提供してはどうですか？それは公平だと思います。
これに対処する方法は交渉することです。
彼らがソースコードを望んでいるなら、彼らはそれを支払う準備ができているべきであり、それがどれくらいであるべきかを決めるのはあなた次第です。
一方、彼らがあなたが望むものを支払う準備ができていないならば、彼らは「彼らのビジネスを他の場所に連れて行く」と決めるかもしれません。
ビジネスの世界へようこそ:-)
そして、将来見込みのある顧客と話をするときは、全員の時間を無駄にしないように、この問題について早い段階で言及してください。
また、あなたがしていることは、オープンソース開発者にとって、そしてオープンソースソリューションを探している（教育を受けた）顧客にとっての嫌悪感であることも注目に値します。
すでに契約上これを行うことに同意している可能性があり、異なる顧客との相互に互換性のない条件に同意する可能性があるため、これはあなたにとって遅すぎるかもしれません。
顧客にソースコードを提供する方法は2つあります。著作権の所有権とライセンス。
一部のお客様は、ソースコードの所有権を求めます。つまり、プロセスの最後に彼らはあなたにお金を払い、代わりにあなたは彼らのために作成したコードの著作権著作権を彼らに与えます。これの1つの理由は、ソースコードに知的財産の潜在的な可能性があり、会社のバランスシートでこれを評価したい場合です。このシナリオでは、顧客からライセンスを取得してこの権利を付与しない限り、他のプロジェクトでそのソースコードを継続して使用する権利はありません。
顧客が自分で「既製品」の製品を購入する場合、顧客はソースコードの所有権ではなく、ソフトウェアを使用するためのライセンスを受け取ることを期待します。彼らは、同じ（または類似の）ソフトウェアを他の多くの組織に販売していること、そして顧客ベースが広いために購入コストが低いことから利益を得ていることを期待しているはずです。
ただし、この質問の状況は、この2つの違いです。
これが私ができることです。共有コードを使用（および変更）するライセンスを顧客に付与します。お客様からクイズされた場合、これは複数のプロジェクトですでに使用されている共有コードであり、この作業を継続して使用することに基づいて、将来の作業のために現在の入札が行われていることを指摘します。これにより、お客様のこのプロジェクトの時間が短縮され、結果として低価格で支払われたことを指摘します。プロジェクトで使用される他のコードの共有ライブラリと同様に、このコードを使用するライセンスがあり、他の開発チームがこれを開発したり、このライブラリに基づいて他のプロジェクトを開発したりできます。ただし、すべてのコードの所有者である場合は、代わりのコードを作成してもかまいませんが、追加料金がかかります。
自分がすでにコミットしている内容によっては、代替機能を無料で作成したり、ソースコードを提供したりする必要がある場合があります。
さまざまなタイプのライブラリーがあることに注意してください。 C++の標準テンプレートライブラリは、ソースコードレベルで含まれ、一般的なコードの使用方法とよく似たプロジェクト実行可能ファイルにコンパイルされるライブラリの良い例です。
提供するソフトウェアでサードパーティを使用している場合、このサードパーティのソースコードがない可能性があります。サードパーティのバイナリを使用して、ソフトウェアを会社に配信します。すべてのプロジェクトで共有されるフレームワークとして開発したコードは、所有している場合でもサードパーティとまったく同じです。この場合、フレームワークのバイナリを使用した場合とサードパーティを使用した場合では、会社のリスクがまったく同じになります。この場合、フレームワークのソースコードを会社に提供するのはなぜですか。あなたは彼女に、ライセンス契約とその良いAPIドキュメントを提供することができます。コードに業界に革命を起こす次の大きな要素が含まれている場合、それはまた別の話ですが、通常はそうではありません。