Você pode alegar que seu produto é adequado ao objetivo quando usa software OSS que não o garante?

Estou trabalhando em um produto para um cliente que deve ser válido e adequado à finalidade.

Ele é construído em uma pilha LAMP (PHP / Cake), então há licenças GPL, MIT, PHP, APACHE:

"TAL COMO ESTÁ", SEM GARANTIAS OU CONDIÇÕES DE QUALQUER TIPO, expressas ou implícitas, incluindo, sem limitação, quaisquer garantias ou condições de TÍTULO, NÃO INFRAÇÃO, COMERCIALIZAÇÃO ou ADEQUAÇÃO A UM OBJETIVO ESPECÍFICO . Você é o único responsável por determinar a adequação do uso ou redistribuição da Obra e assume quaisquer riscos associados ao Seu exercício de permissões sob esta Licença.

Minha lógica de que meu produto é válido e adequado para fins:

• O documento assinado do UAT comprova a validade e a adequação à finalidade.
• A pilha é tão amplamente usada por desenvolvedores, indústria e usuários finais (estatísticas de netcraft, gartner etc.), que existe um consenso de que é adequada ao seu objetivo. (ou seja, podemos desconsiderar a adequação à declaração de finalidade no termo de responsabilidade da garantia)

Este é um ponto válido? Posso fazer reivindicações de que meu software é adequado à finalidade?

Primeiro de tudo, como outros já disseram, há uma diferença entre o software realmente funcionando e o software vendido com uma garantia legal de que ele funciona.

O texto de isenção de responsabilidade que você cita significa que o licenciante original do qual você adquiriu o software não concede nenhum tipo de garantia. Você pode oferecer o software você mesmo com uma garantia anexada. Os autores originais não oferecem uma garantia legal de que o software funcione, mas não há razão para que você não possa dar essa garantia ao seu cliente. (Se você acha que é uma boa ideia anexar uma garantia legal a algo que você não escreveu, isso é outra questão.)

Especificamente, a seção 4 da GPL declara:

Você pode cobrar qualquer preço ou nenhum preço por cada cópia que transmitir e pode oferecer suporte ou proteção de garantia por uma taxa.

Não tenho certeza se uma licença deve conceder a você a capacidade de adicionar garantias explicitamente (não sou advogado, mas acho que a resposta é não - minha intuição é que você possa oferecer garantias sobre praticamente o que quiser ) Em qualquer caso, a GPL oferece inequivocamente a capacidade de adicionar suas próprias garantias ao transmitir o software a um cliente.

Não tenho certeza sobre o BSD, pois ele exige que você preserve o aviso de isenção, mas talvez você possa oferecer proteção de garantia, não obstante o aviso na licença. Na verdade, você pode dizer: "Afirmo que uma garantia de que este trabalho como um todo é adequado para algum propósito (mesmo que alguns trabalhos de que este trabalho maior seja derivado não tenham essa garantia)". Sempre garanta, é claro, que os termos da garantia não violem as licenças de nenhum dos trabalhos incluídos.

No entanto, novamente, não sou advogado e, se seu cliente solicitou uma garantia de adequação à finalidade, provavelmente está procurando alguma proteção legal comprovada. Você deve consultar um advogado para redigir o texto dessa garantia.

Este é um aviso padrão, geralmente concedido para software, especialmente software livre.

Significa apenas que o fornecedor do software não garante a adequação do software. Ele pode muito bem ser convencido a si mesmo que o software é bom para o que ele faz, mas ele não quer entrar no campo minado legal que está garantindo-lo.

O mesmo se aplica ao "consenso": "A comunidade" (como você deseja defini-la) pode concordar que um determinado software seja adequado ao seu objetivo declarado, mas eles não lhe darão uma garantia.

Em resumo: a menos que você pague por isso, nunca conseguirá que ninguém lhe garanta algum tipo de condicionamento físico. E mesmo que você pague a alguém, eles podem não garantir.

Penso que as outras respostas abrangem vários aspectos da sua pergunta, mas não acredito que estejam abordando diretamente seus dados.

Sim , você pode emitir uma garantia para o software criado, incluindo o software com as várias licenças OSS mencionadas.

Você (e sua empresa) será o único portador da responsabilidade gerada por essa garantia. E isso é tudo que uma garantia é - é uma responsabilidade. Você garante que é responsável se o produto falhar.

Você não está pedindo para fazer isso, mas não pode empurrar essa responsabilidade de volta "upstream" para os outros componentes / editores de software mencionados, pois eles negaram expressamente a aceitação dessa cobertura de responsabilidade.

A questão de você emitir ou não uma licença junto com o software é uma questão relacionada, mas ortogonal. A licença fornece termos de uso. A garantia garante um grau de funcionalidade ou operação. Eu recomendo que você licencie o produto para o seu cliente, além de fornecer a garantia que eles exigem. Ter uma licença ajuda a definir a aplicabilidade da garantia que você fornece. Ele também permite que você exclua os não clientes da tentativa de reivindicar o suporte da garantia.

O que significa que você usa para determinar a adequação é exclusivamente seu critério. Depende da quantidade de risco que sua organização está disposta a aceitar. Também depende dos danos aos quais você pode estar exposto, caso o produto falhe e o seu cliente faça uma reclamação contra você. Um UAT é uma abordagem padrão e pode ser muito boa para identificar a aptidão. É uma verificação positiva para a funcionalidade esperada. O consenso é um pouco mais duvidoso, pois você não sabe ao certo como os outros estão usando esses componentes. O consenso é bom para gerar um certo grau de confiança, mas nem de longe é tão rigoroso quanto os testes definidos e específicos que validam a funcionalidade necessária.

Eu tenho trabalhado em um projeto de software médico, onde estávamos sob o mesmo tipo de regulamentação, temos que verificar e validar o produto.

E nós poderíamos fazer isso e atender aos requisitos da FDA.

Não participei da validação real das ferramentas de terceiros, mas, até onde pude entender, o que tínhamos que fazer era especificar qual finalidade o software de terceiros nos serviria. Em seguida, tivemos que validar esses produtos, significando que validamos que os pacotes de software de terceiros escolhidos atendiam a esse propósito.

Até onde eu entendi, esse tipo de validação não precisava ser um processo demorado. Apenas algum tipo de documento de meia página descrevendo os requisitos e como esse software atendeu a esses requisitos.

Essa validação seria para os dois componentes incorporados ao software real, mas também para ambientes de desenvolvimento, sistemas de controle de origem etc.

Nota: Isso se baseia em como eu entendi o que tínhamos que fazer. Eu posso ter entendido problemas. E a empresa também pode ter sido mais excessiva no processo de validação do que era realmente necessário (acho que esse foi o caso até certo ponto).

Mas o software foi validado.

Mas por que você precisa de um produto validado? Você está entregando para um segmento regulamentado, por exemplo, médico ou financeiro. Ou o cliente possui certificação ISO 9001 (ou similar)? Nesse caso, você deve estudar os requisitos para esses tipos de regulamentação para descobrir exatamente o que é necessário.

O aviso de isenção de licença da GNU existe para que, por padrão, os desenvolvedores sejam despidos de qualquer responsabilidade decorrente da execução do software.

Mesmo se você achar que os programadores devem ser responsabilizados por um software ruim, o fato é que o software é gratuito.

O aviso simplesmente diz que o que está sendo distribuído é apenas o software, não qualquer proteção de garantia.

O modelo GNU para ganhar dinheiro com software é vender serviços ou proteção por garantia.

Uma garantia é mais do que apenas uma declaração de confiança de que o produto é adequado a uma finalidade. Tem que haver algum dinheiro nele. No mínimo, "devolução do dinheiro" ou mais: uma obrigação de executar um trabalho para trazer o produto a uma condição tal que seja adequado ao objetivo coberto ou mesmo para cobrir algumas perdas e danos.

A presença ou ausência de uma garantia não mudar o que o produto é ; é apenas uma forma de seguro que altera a forma como o risco é distribuído entre fornecedor e cliente.

Esse negócio de fornecer obrigações sobre o software livre é realmente bastante comum. Qualquer pessoa que trabalhe comercialmente com software livre geralmente o corrige se o cliente tiver um problema. Se você criar uma caixa de hardware que execute uma distribuição Linux embutida nela e houver um problema devido a um bug no kernel, na biblioteca C ou em qualquer outro lugar, você a corrigirá para os clientes. A situação é que sua caixa tem o problema e você prometeu aos clientes uma caixa que seja confiável 24 horas por dia, sete dias por semana.

Seu raciocínio está com defeito por vários motivos:

• Nada na licença oferece a capacidade de alterar seus termos. Se você aceitou os termos da licença usando o trabalho, está vinculado a tudo nele. Se você não gostar mais dos termos, poderá parar de usar o software.

• Não há disposições na licença para ampla adoção do trabalho que altera os termos.

• Seu teste de aceitação do usuário não tem relação com o contrato que você fez com o licenciante. Se você garantiu que sua seleção do trabalho para inclusão em seu produto o torna adequado para a finalidade de seu cliente, isso é entre você e seu cliente. O licenciante é um terceiro não envolvido.

A frase após a que você destacou ("Você é o único responsável por determinar ...") coloca as ramificações de ter usado diretamente no seu colo.