私は、有効で目的に適合している必要があるクライアント向けの製品に取り組んでいます。
LAMPスタック(PHP/Cake)上に構築されているため、GPL、MIT、PHP、Apacheライセンスがあります。
「現状のまま」の基本、保証なしOR明示または黙示のいずれかの種類の条件。これには、タイトル、非侵害、商品性、または特定の目的への適合性お客様は、作品の使用または再頒布の適切性を判断し、本ライセンスに基づく許可の行使に関連するリスクを負う責任を単独で負うものとします。
私の製品が有効であり、目的に適合しているという私の根拠:
これは有効なポイントですか?私のソフトウェアが目的に合っていると主張できますか?
まず、他の人が言ったように、実際に動作するソフトウェアと、動作する法的保証付きで販売されているソフトウェアには違いがあります。
引用する免責事項のテキストは、ソフトウェアを入手した元のライセンサーがいかなる種類の保証も付与しないことを意味します。保証書を添付したソフトウェアをご提供いただけます。元の作者はソフトウェアが機能するという法的な保証を提供していませんが、クライアントにそのような保証をすることができない理由はありません。 (あなたがそれをあなたが書いていないものに法的保証を付けることが良いアイデアであると思うかどうかはまったく別問題です。)
具体的には、GPLのセクション4は次のように述べています。
伝達するコピーごとに料金を請求することも、料金を請求しないこともあり、有料でサポートまたは保証による保護を提供することもできます。
ライセンスが保証を明示的に追加する機能をあなたに付与する必要があるかどうかはわかりません(私は弁護士ではありませんが、答えはノーだと思います-私の直感は、あなたが事実上何を望んでも保証を提供できるはずだということです) )。いずれにせよ、GPLは、ソフトウェアをクライアントに伝達しながら、独自の保証を追加する機能を明確に提供します。
BSDについては免責事項を保存する必要があるため、確信が持てませんが、ライセンスの免責事項にかかわらず、保証による保護を提供できる可能性があります。事実、「私は、この作品全体が何らかの目的に適していることを保証します(このより大きな作品から派生した一部の作品には、そのような保証はありません)。」もちろん、保証条件が含まれている作品のライセンスに違反していないことを常に確認してください。
ただし、繰り返しになりますが、私は弁護士ではありません。クライアントが目的適合性の保証を要求している場合は、厳格な法的保護を探している可能性があります。 そのような保証の文章を起草するには、弁護士に相談する必要があります。
これは標準の免責事項であり、ソフトウェア、特にフリーソフトウェアによく付けられます。
それは、ソフトウェアのプロバイダーがソフトウェアの適合性について保証なしを作成することを意味します。彼はソフトウェアがその機能に適していることを確信しているかもしれません自分が、彼はそれを保証している法的地雷原に侵入したくありません。
同じことが「コンセンサス」にも当てはまります。「コミュニティ」(どのように定義したとしても)は、特定のソフトウェアがその目的に適合していることに同意する場合がありますが、保証はありません。
要するに、あなたがそれを払わない限り、あなたは誰かにあなたにあらゆる種類のフィットネスを保証することは決してありません。そして、ifでさえ誰かに支払うなら、彼らはそれを保証しないかもしれません。
他の回答はあなたの質問のさまざまな側面をカバーしていると思いますが、それらがあなたの詳細に直接取り組んでいるとは思いません。
はい、あなたはあなたが言及した様々なOSSライセンスのソフトウェアを含むあなたが作成したソフトウェアの保証を発行するかもしれません。
あなた(およびあなたの会社)は、その保証によって生成される責任の唯一の負担者になります。そして、それはすべて保証です-それは責任です。製品が機能しなくなった場合に責任を負うことを保証します。
あなたはこれを行うことを求めているわけではありませんが、あなたはそうでないかもしれません責任範囲を受け入れることを明示的に拒否したため、その責任をあなたが言及する他のソフトウェアコンポーネント/発行元に「上流」に押し戻します。
ソフトウェアと一緒にライセンスを発行するかどうかは、関連しますが直交する問題です。 Licenseは、使用条件を提供します。 保証は、ある程度の機能または動作を保証します。必要な保証を提供するだけでなく、クライアントに製品のライセンスを供与することをお勧めします。ライセンスを持っていると、提供する保証の適用範囲を調べるのに役立ちます。また、非クライアントが保証サポートを請求することを防ぐことができます。
フィットネスの判断に使用するのは、単にyourの裁量です。これは、組織が受け入れるリスクの量に依存します。また、製品が故障してクライアントが保証請求を行った場合に受ける可能性のある損害にも依存します。 UATは標準的なアプローチであり、フィットネスを特定するのにかなり役立ちます。これは、期待される機能の肯定的な検証です。他のユーザーがこれらのコンポーネントをどのように使用しているかが明確にわからないため、コンセンサスは少し不明瞭です。コンセンサスはある程度の信頼を生み出すのに最適ですが、必要な機能を検証する定義済みの特定のテストほど厳密ではありません。
私は同じような規制下にあった医療ソフトウェアプロジェクトに取り組んでおり、製品の検証と検証の両方を行う必要があります。
そして、それを行うことができ、FDAの要件に対応できます。
サードパーティツールの実際の検証には参加しませんでしたが、理解できる限り、サードパーティのソフトウェアが提供する目的を指定する必要がありました。次に、これらの製品を自分で検証する必要がありました。つまり、選択したサードパーティのソフトウェアパッケージが実際にその目的を果たしていることを検証しました。
私が理解している限り、このタイプの検証は長いプロセスである必要はありませんでした。要件と、そのソフトウェアがそれらの要件をどのように満たしたかを説明する、単にある種の半ページのドキュメント。
この検証は、実際のソフトウェアに組み込まれている両方のコンポーネントだけでなく、開発環境、ソース管理システムなどにも適用されます。
注:これは、私たちが何をしなければならなかったかを理解する方法に基づいています。誤解している問題があるかもしれません。また、会社は検証プロセスにおいて実際に必要とされていたよりも過剰であった可能性があります(これはある程度そうだったと感じています)。
しかし、ソフトウェアは検証されました。
しかし、なぜ検証済みの製品が必要なのですか?規制されたセグメントに配信していますか?医療や金融。または、クライアントはISO 9001(または同様の)認定を受けていますか?もしそうなら、あなたは自分自身でこれらの種類の規制の要件を研究して、何が必要かを正確に見つけるべきです。
GNUライセンスの免責事項が存在するため、デフォルトでは、開発者はソフトウェアの実行に起因するいかなる責任も免除されます。
プログラマーが悪いソフトウェアに対して責任を負うべきだと感じたとしても、実際にはソフトウェアは無料です。
免責事項は、配布されるのはソフトウェアのみであり、保証の保護ではないことを単に述べています。
GNUソフトウェアからお金を稼ぐためのモデルは、サービスの販売、または保証の保護です。
保証は、製品が目的に適合しているという単なる自信の表明ではありません。それに乗るお金がなければならない。少なくとも「返金」またはそれ以上:対象の目的に適した状態にするために、または一部の損失や損害をカバーするために、製品を動作させるための作業を行う義務。
保証の有無は製品を変更しませんis;それは、リスクがベンダーと顧客の間でどのように分配されるかを変える保険の単なる形式です。
フリーソフトウェアに対する義務を提供するこのビジネスは、実際にはかなり一般的です。無料のソフトウェアを使って商用で作業している人なら誰でも、顧客が問題を抱えている場合は通常、パッチを当てます。組み込みLinuxディストリビューションを実行するハードウェアボックスを作成し、カーネル、Cライブラリ、または他の場所のバグが原因で問題が発生した場合は、顧客向けに修正します。状況はyour boxに問題があり、24時間365日、信頼できるボックスを顧客に約束しました。
あなたの推論はいくつかの理由で間違っています:
ライセンスには、条件を変更する機能はありません。作品を使用してライセンス条項に同意した場合、そのすべてに拘束されます。条件が気に入らなくなった場合は、ソフトウェアの使用を自由に停止できます。
ライセンスには、条件を変更する作業を広く採用するための規定はありません。
ユーザー受け入れテストは、ライセンサーとの合意には影響しません。製品に含める作業を選択してそれが顧客の目的に適していることを保証した場合、それはあなたと顧客の間にあります。ライセンサーは関係のない第三者です。
あなたが強調したものに続く文(「あなたは決定するのはあなただけに責任があります...」)はあなたの膝でそれを正直に使用したことの影響を置きます。