Simon Hobson

Cumbria

IT

Oh dear ! For someone claiming to be a legal professional this writer seems remarkably ignorant on the subject. After the third reading, it becomes obvious that the author is unclear who the article is addressed at - certainly the risks/issues differ depending on whether you are building systems for in-house use or for sale/licence to third parties.

Picking the piece apart :

"There are usually no contractual commitments of quality or fitness for purpose. "

Ever read a standard commercial software licence ? This is exactly one of the standard terms in just about every 'shrink wrap' licence I've ever read.

"The licensee will have to bear the risk of any errors in the code, ..."

Ditto.

"OSS licences contain very few (if any) of the warranties that might generally be included in proprietary software. For example, those relating to the suitability of the software for a particular use, meeting a particular specification or being developed to a particular standard of care."

Ditto !

In short, you pick up just about any off the shelf package and you will find clauses that basically absolve the vendor of any risks/liabilities whatsoever. Exactly the disclaimers that the author criticises OSS licences for

"Crucially, the licence includes no indemnity protection against claims by third parties for intellectual property rights (IPR) infringement, so the user of the software is not automatically protected from such legal actions."

Ahh, at last, a statement that is accurate-ish !

Now we come to the reall biggie, the one that proves the author knows NOTHING about the licences he tallks about :

"One significant limitation is that once the OSS has been modified, the licensee is usually obliged to put these modifications back into the open source community."

This simply is NOT true ! It's one of the 'myths' put about by certain anti-OSS people as part of their FUD campaign. Go read the common licences again, typically you can create a derived work from a GPL licenced program and you are NOT forced to distribute it. You can use it internally without any problem - it is only if you redistribute the program that the licence requires that your derived works are offered under the same terms.

Think about it, it makes sense and is designed to stop someone taking an OSS program, fiddling with it, and then selling it as a closed package.

BUT, depending on what you have done, you may still be able to distribute YOUR program as closed source. Typically this would be where you have written something that is used as part of a suite, but which is not itself inextricably linked with the original code. Your program may be a standalone piece of code (although it might not do anything useful without the rest of the suite) and it can be closed source - as long as you don't try and restrict use or distribution of the other OSS components in the suite.

A good example might be where a vendor builds an 'appliance' using (for example) Linux as it's core OS but with a proprietry program layered on top - just like the PVR sat under my telly. Even if the closed program can't run without dynamically linking to certain libraries etc, typically it is still OK to keep it closed AS LONG AS the vendor doesn't try to claim that the whole system is closed.

There are plenty of closed source packages that work with/rely upon OSS software - please stop spreading this innaccurate FUD.

All in all, whilst there are some real and useful pieces of information in the article, it's completely spoilt by the serious factual errors - of the sort we expect to see from the FUD departments of major closed source vendors.