[P2P-F] red hat's restriction's

Thu Mar 10 01:55:55 CET 2011

Oops, I forgot the link.  I am basing my general sense of tit-for-tat on this account:
<http://en.wikipedia.org/wiki/Tit_for_tat>.  In those terms, I don't see the "equivalent retaliation" in Red Hat's move.  

-----Original Message-----
From: Dennis E. Hamilton [mailto:himself at orcmid.com] 
Sent: Wednesday, March 09, 2011 16:52
To: 'Samuel Rose'
Cc: 'P2P Foundation mailing list'
Subject: RE: [P2P-F] red hat's restriction's

Interesting.

In some sort of pure tit-for-tat, Red Hat would have offered to support Oracle's distribution (though it would have to be credible) or encroached on an area of Oracle business that it considered vulnerable to their competitive entry.  Of course, under competition law, it gets dicey how they can disengage either way.

I'm not sure how the move-countermove in the case at hand actually works as a tit-for-tat.   I think this is more like Chess or Go than a tit-for-tat situation.

Red Hat's move strikes me as defensive more  than counter-aggressive and I see no incentive for Oracle to stop pursuing support agreements for RHEL.  If Oracle starts losing RHEL support customers, it would be interesting to see what their move is then.  But if Oracle were to cease entering into new RHEL support agreements and not renew any, that's a big sacrifice just to have Red Hat go back to their previous way of identifying issues and their remedies via updates.

It's difficult for me to foresee that the Red Hat counter-move is going to be very effective.  I'd be surprised if Oracle blinked.

Let's wait and see.

 - Dennis

-----Original Message-----
From: Samuel Rose [mailto:samuel.rose at gmail.com] 
Sent: Wednesday, March 09, 2011 16:08
To: dennis.hamilton at acm.org
Cc: P2P Foundation mailing list
Subject: Re: [P2P-F] red hat's restriction's

On Wed, Mar 9, 2011 at 2:28 PM, Dennis E. Hamilton <dennis.hamilton at acm.org> wrote:
> I don't disagree that the companies are playing the wrong game.  I have no issue with that observation at all.
>

What are the "games" that you see are being played (or perceived by the players) here if not "Tit for Tat"?

> My comment about the prisoner's dilemma and tit-for-tat (the full context of where cooperation is a winning strategy) is independent of the rest of my remarks, which are based on the public statements that this thread has been based on.

>I was not responding to anything specific in Sam's analysis.
>
> On reflection, I am not clear in what way the moves by Oracle and Red Hat constitute a game of tit-for-tat.  This is not like suspension of nuclear-weapons testing or deployment of ICBMs.  What is the 'this' in "I'll stop/start this and continue so long as you stop/start this too?" Is there even an implicit offer?  Is there even a status quo ante that has any mutually-beneficial value for the commercial adversaries to return to?
>

There are many documented uses (including animal behavior sciences, and social sciences ref P. Kollock) of the application of "Tit for Tat" strategy beyond the classic nuclear war outcomes.

MOVE = Oracle (and other Red Hat competitors) to RHEL customers "We can offer you support on the RHEL brand of Linux" <- Why do the Red Hat competitors do it? It is my guess that they are focused on profit to shareholders first and foremost. Thus they are in a COMPETITION for market share, and this explains why they would start to claim they can support RHEL in addition to their own in house Linux brand.

COUNTER MOVE = Red Hat "We will no longer give away the reason why we have created updates and patches. We will simply give away patches, and leave it to our competitors to decipher why we made the patch instead of sharing that information. This will prevent our competitors from free riding on our work"

[ ... ]

Oracle makes a move to create a zero-sum outcome where Red Hat loses and Oracle gains (Oracle 1, Red Hat 0)  Red Hat responds by removing access to the information that Oracle could use to get the perceived advantage (either both 0 or both .5 depending on how you look at it).

[ ... ]