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

Sto lavorando a un prodotto per un cliente che deve essere valido e adatto allo scopo.

È costruito su uno stack LAMP (PHP / Cake), quindi ci sono licenze GPL, MIT, PHP, APACHE:

BASE "COSÌ COM'È", SENZA GARANZIE O CONDIZIONI DI QUALSIASI TIPO, esplicito o implicito, incluse, senza limitazione, garanzie o condizioni di TITOLO, NON VIOLAZIONE, COMMERCIABILITÀ o IDONEITÀ PER UNO SCOPO PARTICOLARE . L'utente è l'unico responsabile della determinazione dell'adeguatezza dell'uso o della ridistribuzione dell'Opera e si assume tutti i rischi associati all'esercizio delle autorizzazioni ai sensi della presente Licenza.

La mia logica che il mio prodotto è valido e adatto per scopi:

• Il documento UAT firmato dimostra validità e idoneità allo scopo.
• Lo stack è così ampiamente utilizzato da sviluppatori, industria e utenti finali (statistiche di netcraft, gartner ecc.), Che esiste un consenso sul fatto che sia adatto allo scopo. (vale a dire che possiamo ignorare la dichiarazione di idoneità allo scopo nella dichiarazione di non responsabilità della garanzia)

È un punto valido? Posso dichiarare che il mio software è adatto allo scopo?

Prima di tutto, come altri hanno già detto, c'è una differenza tra il software effettivamente funzionante rispetto al software venduto con una garanzia legale che funziona.

Il testo della dichiarazione di non responsabilità citato indica che il licenziante originale da cui è stato ottenuto il software non offre alcun tipo di garanzia. Puoi offrire tu stesso il software con una garanzia allegata. Gli autori originali non offrono una garanzia legale sul funzionamento del software, ma non c'è motivo per cui non sia possibile fornire tale garanzia al proprio cliente. (Che tu pensi che sia una buona idea allegare una garanzia legale a qualcosa che non hai scritto è completamente un'altra cosa.)

In particolare, la sezione 4 della GPL afferma:

Puoi addebitare qualsiasi prezzo o nessun prezzo per ogni copia che trasmetti e puoi offrire supporto o protezione in garanzia a pagamento.

Non sono sicuro che una licenza debba concederti la possibilità di aggiungere esplicitamente garanzie (non sono un avvocato, ma penso che la risposta sia no - la mia intuizione è che dovresti essere in grado di offrire garanzie praticamente su qualsiasi cosa tu voglia ). In ogni caso, la GPL offre in modo inequivocabile la possibilità di aggiungere le proprie garanzie durante il trasporto del software a un client.

Non sono sicuro di BSD, dal momento che richiede di preservare la dichiarazione di non responsabilità, ma forse puoi offrire la protezione della garanzia nonostante la dichiarazione di non responsabilità contenuta nella licenza. In effetti, potresti dire: "Asserisco una garanzia che questo lavoro nel suo insieme è adatto per uno scopo (anche se alcuni lavori da cui deriva questo lavoro più grande non hanno tale garanzia)." Assicurati sempre, ovviamente, che i termini della 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. È necessario consultare un avvocato per redigere il testo di tale garanzia.

Si tratta di una dichiarazione di non responsabilità standard, spesso fornita per software, in particolare software libero.

Significa solo che il fornitore del software non fornisce garanzie sulla idoneità del software. Si può benissimo essere convinto se stesso che il software è buono per quello che fa, ma lui non vuole entrare nel campo minato legale che sta garantendo esso.

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

In breve: se non lo paghi, non avrai mai nessuno che ti garantisca alcun tipo di fitness. E anche se paghi qualcuno, potrebbe non garantirlo.

Penso che le altre risposte coprano vari aspetti della tua domanda, ma non credo che stiano affrontando direttamente i tuoi particolari.

Sì , è possibile rilasciare una garanzia per il software creato, incluso il software, con le varie licenze OSS menzionate.

Tu (e la tua azienda) sarete i soli portatori della responsabilità generata da tale garanzia. E questa è tutta una garanzia: è una responsabilità. Garantisci la tua responsabilità se il prodotto non funziona.

Non stai chiedendo di farlo, ma non puoi respingere tale responsabilità "a monte" verso gli altri componenti software / editori che menzioni in quanto hanno espressamente negato di accettare tale copertura di responsabilità.

Se si rilascia o meno una licenza insieme al software è una domanda correlata ma ortogonale. La licenza fornisce le condizioni d'uso. La garanzia garantisce un certo grado di funzionalità o funzionamento. Raccomanderei di concedere in licenza il prodotto al cliente oltre a fornire la garanzia richiesta. Avere una licenza aiuta a comprendere l'applicabilità della garanzia fornita. Inoltre, consente di escludere i non clienti dal tentativo di richiedere assistenza in garanzia.

Ciò che significa che usi per determinare la forma fisica è solo la tua discrezione. Dipende dalla quantità di rischio che l'organizzazione è disposta ad accettare. Dipende anche dai danni a cui potresti essere esposto in caso di guasto del prodotto e il cliente presenta una garanzia nei tuoi confronti. Un UAT è un approccio standard e può essere abbastanza buono per identificare la forma fisica. È una verifica positiva per la funzionalità prevista. Il consenso è un po 'più incerto poiché non sai con certezza come gli altri stiano usando quei componenti. Il consenso è utile per generare un certo grado di fiducia, ma non è affatto rigoroso quanto i test definiti e specifici che convalidano la funzionalità richiesta.

Ho lavorato a un progetto di software medico, in cui eravamo sotto lo stesso tipo di regolamentazione, dobbiamo sia verificare che convalidare il prodotto.

E potremmo farlo e essere all'altezza dei requisiti FDA.

Non ho preso parte alla convalida effettiva di strumenti di terze parti, ma per quanto ho potuto capire, ciò che dovevamo fare era specificare quale scopo ci avrebbe servito il software di terze parti. Quindi abbiamo dovuto convalidare noi stessi quei prodotti, il che significa che abbiamo convalidato che i pacchetti software di terze parti scelti in realtà avevano lo scopo.

Per quanto ho capito, questo tipo di convalida non doveva essere un processo lungo. Solo una sorta di documento di mezza pagina che descrive i requisiti e come quel software ha soddisfatto tali requisiti.

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

Nota: questo si basa su come ho capito cosa dovevamo fare. Potrei avere frainteso problemi. E la società potrebbe anche essere stata più eccessiva nel processo di convalida di quanto fosse effettivamente richiesto (ho la sensazione che sia stato in qualche modo il caso).

Ma il software è stato convalidato.

Ma perché hai bisogno di un prodotto validato? Stai effettuando consegne in un segmento regolamentato, ad es. Medico o finanziario. Oppure il cliente è certificato ISO 9001 (o simile)? In tal caso, dovresti studiare tu stesso i requisiti di questo tipo di regolamenti per scoprire esattamente cosa è necessario.

La dichiarazione di non responsabilità della licenza GNU esiste in modo tale che, per impostazione predefinita, gli sviluppatori non si assumono alcuna responsabilità derivante dall'esecuzione del software.

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

Il disclaimer afferma semplicemente che ciò che viene distribuito è solo il software, non alcuna protezione in garanzia.

Il modello GNU per fare soldi con il software è vendere servizi o proteggere la garanzia.

Una garanzia è più di una semplice dichiarazione di fiducia che il prodotto è adatto a uno scopo. Devono esserci dei soldi a cavallo. Per lo meno "rimborso", o più: un obbligo di eseguire lavori per portare il prodotto a una condizione tale da essere idoneo allo scopo coperto, o anche per coprire alcune perdite e danni.

La presenza o l'assenza di una garanzia non cambia ciò che il prodotto è ; è solo una forma di assicurazione che modifica la modalità di distribuzione del rischio tra venditore e cliente.

Questa attività di fornitura di obblighi sul software libero è in realtà abbastanza comune. Chiunque lavori commercialmente con software libero di solito lo patch se il cliente ha un problema. Se crei una scatola hardware che esegue una distribuzione Linux incorporata su di essa e ha un problema a causa di un bug nel kernel, nella libreria C o in qualsiasi altro luogo, la risolvi per i clienti. La situazione è che la tua scatola ha il problema e hai promesso ai clienti una scatola affidabile, 24/7.

Il tuo ragionamento è errato per diversi motivi:

• Nulla nella licenza ti dà la possibilità di modificare i suoi termini. Se hai accettato le condizioni di licenza utilizzando l'opera, 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 dell'opera che modifica i termini.

• Il test di accettazione dell'utente non influisce sull'accordo stipulato con il licenziante. Se hai garantito che la tua selezione dell'opera per l'inclusione nel tuo prodotto lo rende adatto allo scopo del tuo cliente, è tra te e il tuo cliente. Il licenziante è una terza parte non coinvolta.

La frase che segue quella evidenziata ("Sei il solo responsabile per determinare ...") mette le conseguenze di averlo usato esattamente in grembo.