クライアントはソースコードを必要としますが、他のプロジェクトで再利用する多くの共有コードが含まれています

開発したアプリケーションバイナリでソースコードを配信したいクライアントがいます。元々はソースコードについては何も言わなかったが、最近は必要だと言った。契約は確定していません。彼らは作業に同意し、署名せずに、この条項とともに戻ってきました。

問題は、私が長年にわたって作成したコードベースがあり、作成するほとんどのアプリケーションのテンプレートとして使用していることです。プロジェクトの範囲よりもはるかに大きい。

また、製品に使用するつもりなので、比較的小さなプロジェクトには提供したくありません。

この業界でこれが起こったのはこれが初めてではないと思います。この問題を回避する最良の方法は何ですか？共有ライブラリのようなものが役立つと思います。

最初に留意すべきことは、ソースコードにはバイナリとは別の価値があるということです。ソースコードの配信を必要とする契約への署名を拒否するか、ソースコードの配信に対する追加の支払いを要求することは完全に合理的です。契約は双方向の文書です。彼らが「大企業」であり「常にこれを行う」という理由だけで、他の部分に何が必要かを指示させないでください。最初に、何を提供し、どのように報酬を受け取りたいかを決定します。その後、弁護士と契約を結び、何を変える必要があるかを考えます。次に、交渉します。

多くの若者が契約を開始するときに行うことをしないでください。彼らは多くの経験を持っているようで、あなたはそうではないので、ただ署名しないでください。それは食い物にする良い方法です。

ソースが必要な理由を調べてください。後で別の開発者を使用するオプションを選択できるように、彼らはそれを望むかもしれません。または、彼らはあなたがバスにぶつかるのを恐れているという理由だけでそれを望み、突然彼らは改善できないバイナリを残されるでしょう。この2番目の場合は、ソフトウェアコードエスクローサービスを調べてください。これらのサービスは、倒産し​​た場合やソフトウェアを維持できない場合に備えて、ソースコードを保持しています。これは、他の顧客にサービスを提供するためにコードを専有的に保持したいという欲求と、何か悪いことが起こった場合に維持できないバイナリのセットをバッグに残さないという欲求の両方を満たすことができます。

「いいえ」は完全にすばらしい答えです。実際、それは信じられないほど有用な答えであり、なぜか私には理解できず、非常に過小評価されています。

「こんにちは、ソースコードも無料で欲しいと突然決定しました。」
「こんにちは、いいえ」

それほど難しくありません、本当に。

彼らはお金のとんでもない金額を支払うことを希望する場合はその後、上で彼らは何すでにあなたを借りて、あなたは彼らが実際に必要とする唯一の情報源が含まれ、アプリケーションのトリミングバージョンを与え、彼らは絶対に入手ケア取るかもしれない非 -exclusive権利を。

単純なことを複雑にしないでください。

あなたの質問は、「この問題を回避する最良の方法は何ですか？」です。しかし、あなたは問題として何を見ていますか？他の人たちは、それは交渉の問題だと正しく指摘しています。すべてには価値があり、クライアントに要求されたものを提供する代償を与えるのはあなた次第です。

ただし、コードを提供することの意味を慎重に検討し、契約に書き込む必要もあります。クライアントがそれを見ることができるというだけですか？クライアントはそれを変更できますか？特に、長年にわたって作成したコードベースにクライアントに排他的権利を付与し、ほとんどのアプリケーションのテンプレートとして使用して、今後自分で使用できないようにすることを検討しますか？

契約には、コードを使用する権利を誰がどのような方法で持っているかを明示する必要があります。

ソースコードにはライセンスが必要であることを忘れないでください。ソースコードを引き渡すと、会社はソースコードを使用して、ライセンスで許可されているすべてのことを実行でき、それを超えると著作権侵害になります。したがって、ソースコードを引き継ぐ場合、ソースコードの独占的な著作権を保持し、ソースコードの使用が正確に許可されていることを完全に明確にする契約があります。そしてもちろん、ソースコードとライセンスは無料では提供されません。

大手企業があなたの著作権を侵害する可能性は低いでしょう。なぜなら、逮捕されると、金銭的損害は別として、彼らの評判に大きな損害を与えるからです。一方、問題を将来修正できるという保証のないソフトウェアの支払いは、クライアントにとって受け入れられない可能性があります。

以前、私は通常、クライアントにMITライセンスの下でソースコード（ライブラリとすべて）を提供しました。ライブラリが適切に編成されている場合、その特定のクライアントに必要なファイル/リソースのみを提供しますが、それ以上は提供しません。それは私にとってもクライアントにとっても公平だと思います。しかし、以前はライブラリの一部ではなかった契約の下で、特定のクライアント向けに記述された新しいコードの問題が常にありました。そこで、プロジェクトを開始する前に、クライアントと問題について話し合いました。一部のクライアントはそのコードの所有権を望んでいましたが、そうでない人もいました（私は常に負のインセンティブを与えました。しかし、実際には一部のクライアントにとって、議論は非常に混乱し、時にはプロジェクトを承認するために3人または5人の異なる人々（弁護士を含む）に話しかけることになりました。

だから今、私のすべてのライブラリは、私が常に開発に使用するカスタムフレームワークの一部であり、このフレームワークを使用するが、フレームワークは異なるライセンスを持つ異なる製品であることをクライアントに説明します。（「フレームワーク」が知られていない可能性があるため、説明するときに「ソフトウェアコンポーネント」を使用することがあります）。私は常にMITライセンスの下で使用されたファイルのコードを提供します（すべてのコードがうまく編成されているため）低レベルのコード（新しいものも）はフレームワークに残っています（私と彼らによって再利用されます）が、関連するコード彼らのアプリケーションに対する唯一の目的は、彼らが彼ら自身の条件の下に保つことです（そのコードは私が別のプロジェクトで再利用するためにほとんど役に立たないでしょう）。もちろん、それはすべて契約に適切に書かれています。これも公平だと思います。

重要なのは、「これらのコンポーネントは異なる製品」であり、すべてが開始前に契約書に書かれていることです。

そのため、共有ライブラリの使用についてのあなたの考えは正しいかもしれません。しかし、リスクを軽減するライセンスの下で、使用したソースコードを提供してみませんか。それは公平だと思います。

これに対処する方法は、交渉することです。

もし彼らがソースコードが欲しいなら、彼らはそれを支払う準備ができているべきであり、それがいくらであるべきかを決めるのはあなた次第です。

一方、...彼らがあなたが望むものを支払う準備ができていないならば、彼らは「彼らのビジネスを他の場所に連れて行く」ことを決めるかもしれません。

ビジネスの世界へようこそ:-)

また、将来見込み客と話をするときは、早い段階で必ずこの問題に言及してください。全員の時間を無駄にしないためです。

また、あなたがやっていることは、オープンソース開発者にとって、そしてオープンソースソリューションを探している（教育を受けた）顧客にとって嫌悪感があるということも注目に値します。

これは、あなたがすでに契約上これを行うことに同意している可能性があり、異なる顧客と相互に互換性のない条件に同意している可能性があるため、手遅れかもしれません。

顧客にソースコードを提供する方法は2つあります。著作権の所有権とライセンス。

一部のお客様は、ソースコードの所有権を求めます。これは、プロセスの最後に彼らがあなたにお金を支払うことを意味し、その代わりにあなたが彼らのために作成したコードの著作権著作権を彼らに与えるでしょう。この理由の1つは、ソースコードに知的財産の重要な可能性があり、会社のバランスシートでこれを評価したい場合です。このシナリオでは、この資格を付与した顧客からライセンスも取得しない限り、他のプロジェクトでそのソースコードを継続して使用する資格はありません。

顧客が自分で「既製」の製品を購入している場合、彼らはソースコードの所有権ではなく、ソフトウェアを使用するためのライセンスを受け取ることを期待するでしょう。彼らは、あなたが同じ（または類似の）ソフトウェアを他の多くの組織に販売していること、そして顧客ベースが広いために購入コストが安くなることを期待しているはずです。

ただし、この質問の状況は、この2つのごまかしです。

これが私にできることです。共有コードを使用（および変更）するライセンスを顧客に付与します。顧客からクイズされた場合、これは既に複数のプロジェクトで使用している共有コードであり、この作業を継続して使用することに基づいた将来の作業のために現在の入札単価が設定されていることを指摘します。これにより、このプロジェクトでの顧客の時間は短縮され、結果として顧客は低価格で支払ったことになります。プロジェクトで使用されるコードの他の共有ライブラリと同様に、このコードを使用し、他の開発チームがこれを開発するためのライセンスと、このライブラリに基づく他のプロジェクトを許可するライセンスがあります。ただし、すべてのコードの所有権を希望する場合は、代替品を作成しても構いませんが、これは追加料金になります。

すでにコミットした内容によっては、代替機能を無料で作成するか、ソースコードを提供する必要があります。

ライブラリにはさまざまな種類があることを忘れないでください。C ++の標準テンプレートライブラリは、ソースコードレベルに含まれるライブラリの良い例であり、一般的なコードの使用方法と非常によく似たプロジェクト実行可能ファイルにコンパイルされます。

提供するソフトウェアでサードパーティを使用する場合、このサードパーティのソースコードがない可能性があります。サードパーティのバイナリを使用して、引き続きソフトウェアを会社に配信します。すべてのプロジェクトで共有されるフレームワークとして開発したコードは、たとえ所有者であっても、サードパーティとまったく同じです。この場合、会社は、フレームワークのバイナリについて、サードパーティとまったく同じリスクを抱えています。この場合、フレームワークのソースコードを会社に提供するのはなぜですか。あなたは彼女にライセンス契約とそのAPIドキュメントを提供できます。コードに業界に革命をもたらす次の大きなものが含まれている場合、それは別の話ですが、一般的にはそうではありません。