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

salsaman at xs4all.nl salsaman at xs4all.nl
Thu Mar 12 12:43:19 UTC 2009


On Thu, March 12, 2009 11:51, j.roberts wrote:
> 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.

So, you count the cost of the Windows lock-in to be a part of the TCO of
any alternative solution ?

IMO, these lock-in-related costs should be quoted as part of the TCO for
the original Windows install. Then we would get a truer picture of the
relative values.


There is also a morale thing - all of the people I know who work in IT
because they enjoy such work, prefer Linux to Windows. Most people who
prefer windows do such work because it is a job they can do and have been
trained to do (rather than want to do). But YMMV.


Salsaman.
http://lives.sourceforge.net


-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list