¿Puede afirmar que su producto es apto para su uso cuando utiliza software OSS que no lo garantiza?

Estoy trabajando en un producto para un cliente que debe ser válido y adecuado para su propósito.

Está construido en una pila LAMP (PHP / Cake), por lo que hay licencias GPL, MIT, PHP, APACHE:

"TAL CUAL", SIN GARANTÍAS O CONDICIONES DE NINGÚN TIPO, expresas o implícitas, incluidas, entre otras, garantías o condiciones de TÍTULO, NO INFRACCIÓN, COMERCIABILIDAD o ADECUACIÓN PARA UN PROPÓSITO EN PARTICULAR . Usted es el único responsable de determinar la conveniencia de usar o redistribuir el Trabajo y asumir los riesgos asociados con Su ejercicio de permisos bajo esta Licencia.

Mi justificación de que mi producto es válido y apto para fines:

• El documento UAT firmado demuestra validez y aptitud para el propósito.
• La pila es tan ampliamente utilizada por los desarrolladores, la industria y los usuarios finales (estadísticas de netcraft, gartner, etc.), que existe un consenso de que ES adecuada para su propósito. (es decir, podemos ignorar la declaración de aptitud para el propósito en el descargo de responsabilidad de la garantía hasta cierto punto)

¿Es este un punto válido? ¿Puedo hacer afirmaciones de que mi software es apto para su propósito?

En primer lugar, como han dicho otros, hay una diferencia entre el software que realmente funciona y el software que se vende con una garantía legal de que funciona.

El texto de exención de responsabilidad que cita significa que el licenciante original del que obtuvo el software no otorga ningún tipo de garantía. Puede ofrecer el software usted mismo con una garantía adjunta. Los autores originales no ofrecen una garantía legal de que el software funciona, pero no hay ninguna razón por la que no pueda hacer tal garantía a su cliente. (Si crees o no que es una buena idea adjuntar una garantía legal a algo que no escribiste es algo completamente distinto).

Específicamente, la sección 4 de la GPL establece:

Puede cobrar cualquier precio o ningún precio por cada copia que transmita, y puede ofrecer soporte o protección de garantía por una tarifa.

No estoy seguro de si una licencia debe otorgarle la capacidad de agregar garantías explícitamente (no soy un abogado, pero creo que la respuesta es no, mi intuición es que debería poder ofrecer garantías sobre prácticamente lo que quiera) ) En cualquier caso, la GPL le ofrece inequívocamente la posibilidad de agregar sus propias garantías mientras transmite el software a un cliente.

No estoy seguro acerca de BSD, ya que requiere que conserve la exención de responsabilidad, pero tal vez pueda ofrecer protección de garantía a pesar de la exención de responsabilidad de la licencia. En efecto, podría decir: "Afirmo una garantía de que este trabajo en su conjunto es adecuado para algún propósito (aunque algunos trabajos de los que se deriva este trabajo más grande no tienen dicha garantía)". Siempre asegúrese, por supuesto, de que los términos de su garantía no violen las licencias de ninguno de sus trabajos incluidos.

Sin embargo, una vez más, no soy abogado, y si su cliente ha solicitado una garantía de idoneidad, probablemente esté buscando alguna protección legal verificada. Debe consultar a un abogado para redactar el texto de dicha garantía.

Este es un descargo de responsabilidad estándar, que a menudo se da para el software, especialmente el software libre.

Simplemente significa que el proveedor del software no garantiza la idoneidad del software. Se puede muy bien ser convencido a sí mismo de que el software es bueno para lo que hace, pero que no quiere entrar en el campo de minas legal que se garantiza la misma.

Lo mismo se aplica al "consenso": "La comunidad" (como quiera definirlo) podría estar de acuerdo en que una determinada pieza de software es adecuada para su propósito declarado, pero no le darán una garantía.

En resumen: a menos que pague, nunca conseguirá que nadie le garantice ningún tipo de condición física. E incluso si le paga a alguien, es posible que no lo garantice.

Creo que las otras respuestas cubren varios aspectos de su pregunta, pero no creo que aborden directamente sus detalles.

Sí , puede emitir una garantía para el software que ha creado, incluido el software con las diversas licencias de OSS que mencionó.

Usted (y su empresa) serán los únicos responsables de la responsabilidad generada por esa garantía. Y eso es todo una garantía, es una responsabilidad. Estás garantizando que eres responsable si el producto no funciona.

No está pidiendo hacer esto, pero no puede devolver esa responsabilidad "corriente arriba" a los otros componentes / editores de software que menciona, ya que han negado expresamente aceptar esa cobertura de responsabilidad.

Si emite o no una licencia junto con el software es una pregunta relacionada pero ortogonal. La licencia proporciona los términos de uso. La garantía garantiza un grado de funcionalidad u operación. Le recomendaría licenciar el producto a su cliente además de proporcionar la garantía que requieren. Tener una licencia ayuda a determinar la aplicabilidad de la garantía que usted brinda. También le permite excluir a los que no son clientes de intentar reclamar su garantía.

Lo que significa que usa para determinar la aptitud física es únicamente su criterio. Depende de la cantidad de riesgo que su organización esté dispuesta a aceptar. También depende de los daños a los que pueda estar expuesto en caso de que el producto falle y su cliente presente un reclamo de garantía en su contra. Un UAT es un enfoque estándar y puede ser bastante bueno para identificar el estado físico. Es una verificación positiva de la funcionalidad esperada. El consenso es un poco más dudoso ya que no sabes con certeza cómo otros están usando esos componentes. El consenso es bueno para generar un grado de confianza, pero no es tan riguroso como las pruebas definidas y específicas que validan la funcionalidad requerida.

He estado trabajando en un proyecto de software médico, donde estábamos bajo el mismo tipo de regulación, tenemos que verificar y validar el producto.

Y podríamos hacer eso y cumplir con los requisitos de la FDA.

No participé en la validación real de herramientas de terceros, pero hasta donde pude entender, lo que teníamos que hacer era especificar qué propósito nos serviría el software de terceros. Luego tuvimos que validar esos productos nosotros mismos, lo que significa que validamos que los paquetes de software de terceros elegidos en realidad sirvieron para ese propósito.

Según tengo entendido, este tipo de validación no tuvo que ser un proceso largo. Simplemente una especie de documento de media página que describe los requisitos y cómo ese software cumplió con esos requisitos.

Esta validación sería para ambos componentes integrados en el software real, pero también para entornos de desarrollo, sistemas de control de fuente, etc.

Nota: Esto se basa en cómo entendí lo que teníamos que hacer. Puede que haya entendido mal los problemas. Y la compañía también pudo haber sido más excesiva en el proceso de validación de lo que realmente se requería (tengo la sensación de que este fue el caso hasta cierto punto).

Pero el software fue validado.

Pero, ¿por qué necesita un producto validado? ¿Está entregando a un segmento regulado, por ejemplo, médico o financiero? ¿O está certificado el cliente ISO 9001 (o similar)? Si es así, debe estudiar los requisitos de este tipo de regulaciones para averiguar exactamente lo que se necesita.

El descargo de responsabilidad de la licencia GNU está ahí para que, por defecto, los desarrolladores estén exentos de cualquier responsabilidad derivada de la ejecución del software.

Incluso si cree que los programadores deberían ser responsables de un mal software, el hecho es que el software es gratuito.

El descargo de responsabilidad simplemente dice que lo que se distribuye es solo el software, no ninguna protección de garantía.

El modelo GNU para ganar dinero con el software es vender servicios o proteger la garantía.

Una garantía es más que solo una declaración de confianza de que el producto es apto para un propósito. Tiene que haber algo de dinero en eso. Como mínimo "devolución de dinero", o más: una obligación de realizar un trabajo para llevar el producto a una condición tal que sea adecuado para el propósito cubierto, o incluso para cubrir algunas pérdidas y daños.

La presencia o ausencia de una garantía no cambia lo que el producto es ; es solo una forma de seguro que cambia la forma en que se distribuye el riesgo entre el proveedor y el cliente.

Este negocio de proporcionar obligaciones sobre el software libre es en realidad bastante común. Cualquiera que trabaje comercialmente con software libre generalmente lo parcheará si el cliente tiene un problema. Si crea una caja de hardware que ejecuta una distribución de Linux incorporada y tiene un problema debido a un error en el kernel, la biblioteca C o en cualquier otro lugar, lo arregla para los clientes. La situación es que su caja tiene el problema, y ​​usted prometió a los clientes una caja que es confiable, 24/7.

Su razonamiento es defectuoso por varias razones:

• Nada en la licencia le da la posibilidad de alterar sus términos. Si aceptó los términos de la licencia al usar el trabajo, está obligado por todo lo que contiene. Si ya no le gustan los términos, puede dejar de usar el software.

• No hay disposiciones en la licencia para una amplia adopción del trabajo que cambie los términos.

• Su prueba de aceptación del usuario no tiene relación con el acuerdo que hizo con el licenciante. Si usted garantiza que su selección del trabajo para su inclusión en su producto lo hace adecuado para el propósito de su cliente, eso es entre usted y su cliente. El licenciante es un tercero no involucrado.

La oración que sigue a la que resaltó ("Usted es el único responsable de determinar ...") pone las consecuencias de haberla usado directamente en su regazo.