First of all, as others have said, there’s a difference between software actually working versus software being sold with a legal guarantee that it works.

The disclaimer text you cite means that the original licensor you got the software from does not grant any kind of warranty. You can offer the software yourself with a warranty attached. The original authors don’t offer a legal guarantee that the software works, but there’s no reason why you can’t make such a guarantee to your client. (Whether or not you think it’s a good idea to attach a legal guarantee to something you didn’t write is another matter entirely.)

Specifically, section 4 of the GPL states:

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.

I’m not sure if a license must grant you the capability to add warranties explicitly (I’m not a lawyer, but I think the answer is no — my intuition is that you should be able to offer guarantees on virtually whatever you want). In any case, the GPL unambiguously offers you the ability to add your own warranties while conveying the software to a client.

I’m not sure about BSD, since it requires you to preserve the disclaimer, but perhaps you can offer warranty protection notwithstanding the disclaimer in the license. In effect, you might say, “I assert a warranty that this work as a whole is fit for some purpose (even though some works this larger work is derived from do not carry such a warranty).” Always ensure, of course, that your warranty terms do not violate the licenses of any of your included works.

However, again, I’m not a lawyer, and if your client has requested a warranty of fitness of purpose, he’s probably looking for some vetted legal protection. You should consult a lawyer to draft the text of such a warranty.

This is a standard disclaimer, that’s often given for software, especially free software.

It just means that the provider of the software makes no guarantees about the fitness of the software. He may very well be convinced himself that the software is good for what it does, but he doesn’t want to enter the legal minefield that is guaranteeing it.

The same applies to “consensus”: “The community” (however you want to define it) might agree that a given piece of software is fit for its stated purpose, but they won’t give you a guarantee.

In short: unless you pay for it, you will never get anyone to guarantee you any kind of fitness. And even if you pay someone, they might not guarantee it.

I think the other answers are covering various aspects of your question, but I don’t believe they are directly addressing your particulars.

Yes, you may issue a warranty for the software you have created including the software with the various OSS licenses that you mentioned.

You (and your company) will be the sole bearer of the liability generated by that warranty. And that’s all a warranty is – it’s a liability. You’re guaranteeing that you are liable if the product fails to work.

You’re not asking to do this, but you may not push that liability back “up-stream” to the other software components / publishers you mention as they have expressly denied accepting that liability coverage.

Whether or not you issue a license along with the software is a related but orthogonal question. License provides terms of use. Warranty guarantees a degree of functionality or operation. I would recommend you license the product to your client in addition to providing the warranty that they require. Having a license helps scope the applicability of the warranty you provide. It also allows you to exclude non-clients from attempting to claim warranty support from you.

What means you use to determine fitness is solely your discretion. It depends upon what amount of risk your organization is willing to accept. It also depends upon the damages you may be exposed to should the product fail and your client makes a warranty claim against you. A UAT is a standard approach and can be a pretty good for identifying fitness. It’s a positive verification for the expected functionality. Consensus is a little more iffy since you don’t know for certain how others are using those components. Consensus is nice for generating a degree of confidence, but it is nowhere near as rigorous as defined and specific tests that validate the required functionality.

I have been working on a medical software project, where we were under the same kind of regulation, we have to both verify and validate the product.

And we could do that and live up to FDA requirements.

I did not take part in the actual validation of 3rd party tools, but as far as I could understand, what we had to do was specify which purpose that 3rd party software would serve us. Then we had to validate those products ourselves, meaning that we validated that the chosen 3rd party software packages did in deed serve that purpose.

As far as I understood, this type of validation did not have to be a lengthy process. Merely some sort of half page document describing the requirements and how that software met those requirements.

This validation would be for both components build into the actual software, but also for development environments, source control systems, etc.

Note: This is based on how I understood what we had to do. I may have misunderstood issues. And the company may have also been more excessive in the validation process than was actually required (I have a feeling this was the case to some degree).

But the software was validated.

But why do you require a validated product? Are you delivering to a regulated segment, e.g. medical or finance. Or is the client ISO 9001 (or similar) certified? If so, you should study the requirements for these kinds of regulations your self to find out exactly what is needed.

The GNU license’s disclaimer is there so that, by default, developers are disrobed of any liability arising from running the software.

Even if you feel that programmers should be liable for bad software, the fact is that the software is free.

The disclaimer simply says that what is being distributed is the software only, not any warranty protection.

The GNU model for making money from software is to sell services, or warranty protection.

A warranty is more then just a statement of confidence that the product is fit for a purpose. There has to be some money riding on it. At the very least “money back”, or more: an obligation to perform work to bring the product to a condition such that it is fit for the covered purpose, or even to cover some losses and damages.

The presence or absence of a warranty doesn’t change what the product is; it just a form of insurance which changes how the risk is distributed between vendor and customer.

This business of providing obligations over free software is actually quite common. Anyone who works commercially with free software will usually patch it if the customer has a problem. If you make some hardware box which runs an embedded Linux distro on it, and it has a problem because of a bug in the kernel, C library or anywhere else, you fix it for the customers. The situation is that your box has the issue, and you promised the customers a box that is reliable, 24/7.

Your reasoning is faulty for several reasons:

• Nothing in the license gives you the ability to alter its terms. If you accepted the license terms by using the work, you’re bound by everything in it. If you no longer like the terms, you’re free to stop using the software.

• There are no provisions in the license for wide adoption of the work changing the terms.

• Your user acceptance test has no bearing on the agreement you made with the licensor. If you warranted that your selection of the work for inclusion in your product makes it suitable for your customer’s purpose, that’s between you and your customer. The licensor is an uninvolved third party.

The sentence following the one you highlighted (“You are solely responsible for determining…”) puts the ramifications of having used it squarely in your lap.