[Gllug] [OT] Support model for Linux vs M$

j.roberts j.roberts at stabilys.com
Thu Mar 12 10:51:50 UTC 2009


Hong Chyr wrote:
> Hi all

Hi. You raise some good points IMO.

...


> I mean, consider the following scenarios:
> 
> Scenario 1: Windows
> ----------------------
> If I'm a system integrator, selling MS Server and XP licenses to a 
> customer. Would I be responsible to provide support to my customer? Or 
> can they call M$ for support?

In general (and under MS standard T&C of supply), yes. You will also 
have to pay MS (a lot of money!) for a support contract to support your 
clients. We do this.

> Scenario 2: Linux
> -----------------
> Assuming customer opted not buy their license from RH or SuSE, and I 
> came in as a Linux consultant. Setting up a whole environment for them: 
> DHCP, DNS, file and print, etc plus Ubuntu clients. I would then sell my 
> support service to them.

> How are the 2 scenarios different? It still fall on the system 
> integrator or consultant to provide support right? 

Yes it may. But it is complex.

Speaking just of the UK (but because of the EU legislative framework I 
suspect this is largely true EU-wide), a retailer is responsible to 
their customer for the performance of the products sold and is liable in 
law for that performance.

When the customer is a non-retail customer then the situation is 
modified and liability is reduced (but not negated).

It gets a lot more complex when we move from hardware support to 
software support, where licensing rather than outright sale is involved.

I do not believe any definitive dispute over the rights of a purchaser 
to enjoy promised benefits of a software-licenced system has yet been 
adjudicated by the UK courts (in terms of establishing case law).

Someone is bound to bring up the GPL here, quite rightly, and this 
restricts the liabilities of the software author. However, purchasers 
have a right to the performance that is contractually promised to them 
by their purchase, so the terms of a purchase and the details of what 
the software supplied is promised to be able to do can be quite 
important. AKA careful draft of contracts!

My company is not wealthy enough to finance the complete litigation 
career of a team of barristers to get to the bottom of such issues :)

I know you were thinking less in terms of legal liability than in terms 
of support liability, but in fact you can't have the one without the 
other...

Since many of our clients are solicitors and some are barristers in 
chambers, I have asked them on occasion about some of the issues above - 
informally, of course. This has always given rise to a great deal of 
sucking of the teeth - but no answers.

...

> Does it mean the TCO for SOHO and SME can be lower since they don't have 
> to shell out money for Microsoft licenses? Or is that not the complete 
> picture?

I don't really see that as the right way to look at it. The TCO is low 
if the correct solution is applied. By way of example:

- For a solicitor's practice using document management that is dependent 
on macro generation using Windows tools and interfaces, it would be a 
bad idea to attempt to introduce a *nix solution to gain low TCO. But 
the performance of the whole infrastructure is monitored via a 
*nix-based solution.

- For a company with infrastructure dispersed amongst various warehouses 
in the south of the UK, with a main London base, and no dependence on 
Windows automation, but with staff only familiar with Windows interfaces 
and tools and a huge staff turnover, then Linux infrastructure that is 
relatively resistant to abuse combined with Windows workstations has 
reduced TCO per head by 80% or so compared with the previous Windows 
server infrastructure. Now they are buying and happily using *nix 
netbooks for the Directors... so that's a win :)

There are many other scenarios, each with their own set of criteria...

sorry this is probably longer than you wanted!

-- 

James Roberts
Stabilys.com
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list