Puoi affermare che il tuo prodotto è adatto allo scopo quando utilizza software OSS che non lo garantisce?

Prima di tutto, come altri hanno detto, c'è una differenza tra il software in realtà funzionante e il software venduto con una garanzia legale che funziona.

Il testo della dichiarazione di non responsabilità che citi significa che il licenziante originale dal quale hai preso il software non garantisce alcun tipo di garanzia. Puoi offrire il software te stesso con una garanzia allegata. Gli autori originali non offrono una garanzia legale sul fatto che il software funzioni, ma non c'è motivo per cui non si possa offrire tale garanzia al cliente. (Se pensate che sia una buona idea o meno di attribuire una garanzia legale a qualcosa che non avete scritto è completamente un'altra cosa.)

In particolare, la sezione 4 degli stati GPL:

You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.

Non sono sicuro che una licenza debba concederti la possibilità di aggiungere esplicitamente le garanzie (non sono un avvocato, ma penso che la risposta sia no - la mia intuizione è che dovresti essere in grado di offrire garanzie praticamente tutto quello che vuoi). In ogni caso, la GPL ti offre inequivocabilmente la possibilità di aggiungere le tue garanzie mentre trasmetti il software a un cliente.

Non sono sicuro di BSD, dal momento che richiede la conservazione della dichiarazione di non responsabilità, ma forse è possibile offrire la protezione della garanzia nonostante il disclaimer nella licenza. In effetti, si potrebbe dire: "Asserisco una garanzia che questo lavoro nel suo insieme è adatto per qualche scopo (anche se alcuni lavori che derivano da questo lavoro più ampio non hanno tale garanzia)." Assicurati sempre, naturalmente, che i tuoi termini di garanzia non violino le licenze di nessuna delle tue opere incluse.

Tuttavia, ancora una volta, non sono un avvocato e se il tuo cliente ha richiesto una garanzia di idoneità allo scopo, probabilmente sta cercando una protezione legale controllata. Dovresti consultare un avvocato per redigere il testo di tale garanzia.

Questo è un disclaimer standard, che viene spesso fornito per software, in particolare software libero.

Significa solo che il fornitore del software rende nessuna garanzia sull'idoneità del software. Potrebbe benissimo convincersi se stesso che il software è buono per quello che fa, ma non vuole entrare nel campo minato legale che lo sta garantendo.

Lo stesso vale per il "consenso": "La comunità" (comunque tu voglia definirla) potrebbe convenire che un dato software sia adatto allo scopo dichiarato, ma non ti darà una garanzia.

In breve: a meno che non paghi per questo, non otterrai nessuno per garantirti alcun tipo di forma fisica. E anche se paghi qualcuno, potrebbero non garantirlo.

Penso che le altre risposte riguardino vari aspetti della tua domanda, ma non credo che si stiano rivolgendo direttamente ai tuoi dati.

Sì , puoi emettere una garanzia per il software che hai creato incluso il software con le varie licenze OSS menzionate.

Tu (e la tua azienda) saranno i soli responsabili della responsabilità generata da tale garanzia. E questo è tutto una garanzia è - è una responsabilità. Stai garantendo che sei responsabile se il prodotto non funziona.

Non stai chiedendo di farlo, ma potresti non spingere tale responsabilità indietro "up-stream" agli altri componenti / editori software che hai menzionato poiché hanno espressamente negato di accettare tale copertura di responsabilità .

Se rilasciare o meno una licenza insieme al software è una questione correlata ma ortogonale. Licenza fornisce i termini di utilizzo. La garanzia garantisce un certo grado di funzionalità o funzionamento. Ti consiglierei di concedere in licenza il prodotto al tuo cliente oltre a fornire la garanzia di cui hanno bisogno. Avere una licenza aiuta a valutare l'applicabilità della garanzia che fornisci. Consente inoltre di escludere i non clienti dal tentativo di richiedere il supporto della garanzia da parte tua.

Ciò che significa che per determinare l'idoneità si usa solo la tua discrezione. Dipende dalla quantità di rischio che la tua organizzazione è disposta ad accettare. Dipende anche dai danni a cui potresti essere esposto se il prodotto dovesse guastarsi e il tuo cliente presentasse un reclamo in garanzia nei tuoi confronti. Un UAT è un approccio standard e può essere abbastanza buono per identificare l'idoneità. È una verifica positiva per la funzionalità prevista. Il consenso è un po 'più incerto dal momento che non si è certi di come gli altri utilizzino tali componenti. Il consenso è piacevole per generare un certo grado di sicurezza, ma non è neanche lontanamente rigoroso quanto i test definiti e specifici che convalidano la funzionalità richiesta.

Ho lavorato a un progetto di software medico, dove eravamo sotto lo stesso tipo di regolamento, dobbiamo verificare e convalidare il prodotto.

E potremmo farlo e soddisfare i requisiti della FDA.

Non ho preso parte all'effettiva validazione di strumenti di terze parti, ma per quanto ho potuto capire, ciò che dovevamo fare era specificare quale scopo servirebbero i software di terze parti. Quindi abbiamo dovuto convalidare tali prodotti da soli, il che significa che abbiamo convalidato che i pacchetti software di terze parti scelti hanno fatto proprio questo scopo.

Per quanto ho capito, questo tipo di convalida non doveva essere un processo lungo. Semplicemente una sorta di documento a mezza pagina che descrive i requisiti e in che modo il software ha soddisfatto tali requisiti.

Questa convalida sarebbe per entrambi i componenti incorporati nel software attuale, ma anche per ambienti di sviluppo, sistemi di controllo del codice sorgente, ecc.

Nota: questo è basato su come ho capito cosa dovevamo fare. Potrei aver frainteso problemi. E la società potrebbe anche essere stata più eccessiva nel processo di convalida di quanto effettivamente richiesto (ho la sensazione che in alcuni casi sia stato così).

Ma il software è stato convalidato.

Ma perché hai bisogno di un prodotto validato? Consegni a un segmento regolamentato, ad es. medico o finanziario. Oppure il cliente è certificato ISO 9001 (o simile)? In tal caso, dovresti studiare i requisiti per questo tipo di regolamenti per scoprire esattamente ciò che è necessario.

La dichiarazione di non responsabilità della licenza GNU è presente in modo tale che, per impostazione predefinita, gli sviluppatori non siano sollevati da alcuna responsabilità derivante dall'esecuzione del software.

Anche se ritieni che i programmatori debbano essere ritenuti responsabili per software scadente, il fatto è che il software è gratuito.

Il disclaimer dice semplicemente che ciò che viene distribuito è solo il software, non qualsiasi garanzia.

Il modello GNU per fare soldi con il software è vendere servizi o garantire la protezione.

Una garanzia è più che una dichiarazione di confidenza che il prodotto è adatto per uno scopo. Ci deve essere un po 'di denaro su di esso. Per lo meno "rimborso" o altro: un obbligo di eseguire il lavoro per portare il prodotto a una condizione tale che sia idoneo allo scopo coperto, o anche per coprire alcune perdite e danni.

La presenza o l'assenza di una garanzia non cambia il prodotto ; è solo una forma di assicurazione che cambia il modo in cui il rischio viene distribuito tra venditore e cliente.

Questo business di fornire obblighi rispetto al software libero è in realtà abbastanza comune. Chiunque lavori commercialmente con software libero di solito lo aggiusta se il cliente ha un problema. Se crei un box hardware su cui è in esecuzione una distribuzione Linux incorporata, e ha un problema a causa di un bug nel kernel, nella libreria C o in qualsiasi altro punto, lo aggiusti per i clienti. La situazione è che la tua casella ha il problema e hai promesso ai clienti una scatola che è affidabile, 24 ore al giorno.

Il tuo ragionamento è errato per diversi motivi:

• Nulla nella licenza ti dà la possibilità di alterarne i termini. Se hai accettato i termini della licenza utilizzando il lavoro, sei vincolato da tutto ciò che contiene. Se non ti piacciono più i termini, sei libero di smettere di usare il software.

• Non ci sono disposizioni nella licenza per un'ampia adozione del lavoro che modifica i termini.

• Il test di accettazione dell'utente non ha alcun rapporto con l'accordo stipulato con il licenziante. Se hai garantito che la selezione del lavoro da includere nel tuo prodotto lo rende adatto allo scopo del tuo cliente, questo è tra te e il tuo cliente. Il licenziante è una terza parte non coinvolta.

La frase che segue quella che hai evidenziato ("Sei il solo responsabile per la determinazione ...") mette le conseguenze di averlo usato esattamente nel tuo grembo.