And by "unbreakable", of course, they mean that if you drop the shrinkwrap box on the floor, the CDs won't break because it's really well padded.  At least, that's what I think it means, because I don't see how anybody could think it means unbreakable security. I think I kind of feel sorry for Mary Ann Davidson, who had been distancing herself from the previous "unbreakable" campaign in more recent articles with quotes like: And Oracle no longer talks about its products as unbreakable. Earlier this week, Davidson said that the first time she heard the marketing slogan, she thought, "What idiot dreamed this up?" Of course, she also been a stauch defender of their security practices and has had 4 years to shore things up, unlike last time, she can't claim the "unbreakable" claim was made before she joined.

Due to the Gnu Public License (GPL) terms (see What is the GPL?), Oracle's action illustrates an ongoing risk to open source companies.  Oracle can absolutely take Red Hat's work (and the community's) and build a Linux support business on Red Hat's code, as long as they take care of some of the branding issues.  Actually, they're trying to dodge that one as well, by just supporting whatever Red Hat releases.

Pricing Competition

Looking at the Oracle Data Sheet, we find that Oracle will be supporting either Red Hat Enterprise Linux 3 and 4 (rhel3 and rhel4, respectively) and that you can get access to updates from the "Unbreakable Linux Network" (ULN) for only $99 per year per system.   Let's contrast that with support prices from the Red Hat store:

 Ouch!  Now that is some price competition.  Shares of Red Hat had already dropped from $26 to $20 last month on profit concerns, but the Oracle news yesterday from Ellison sent it plummeting to below $15.

Security Updates - What Are Oracle's Options?

The information Oracle has provided so far asserts that "bug fixes" will be one of the key things you get for buying their support.  I see some challenges with this and wonder which model they'll use:

1. "Total Sponge" Model.  In this model (my name for it), Oracle would just wait for Red Hat to release official updates and then repost the updates on the ULN.  This would be the easiest to execute and least fragmenting, but would mean that updates would almost always be available from Red Hat first.  However, to save $1400 per system for RHEL AS, some customers might be wiling to wait an extra day or two.
2. Independant Model.  In this model, Oracle would have their own full Engineering support team and develop and release their own patches in their own order, starting from based RHEL systems.  Even this is tricky though - what do they do when Red Hat release a full Update (think Service Pack for RH)?  Let's say Red Hat is on Update2 and has released 20 patches and Oracle has released 22 patches, which don't completely overlap with the Red Hat 20.  Now Red Hat releases Update3, which does not include all of the Oracle patches...  it's not simple.  I guess they could just ignore Red Hat Updates and do their own versions of those too.
3. Partial Sponge, Strategically Independent.  I think this is what Larry has in mind.  80-90% of the time, just operate in Sponge mode because it is easy.  However, have a small team to look for "critical" issues and push to get them out faster than Red Hat.  This shows Oracle "value" above Red Hat.

None of that is easy and I'm darn glad it isn't my job to figure out how to operationalize it.  However, there are a bunch of other questions that also come to mind. 

Open Questions for Oracle

Hopefully some enterprising reporter who reads my blog will ask Oracle these questions:

1. On just RHEL4ES, Red Hat has released 321 patches this year, averaging a little over 1 per day.  Oracle announced in 2004 that it would release security patches monthly, then 3 months later announced they would only do quarterly updates instead.  How can you compete with Red Hat's execution?

2. You have traditionally relied on private disclosure and have been criticized for very long fix times  and selective fixing by security researchers.  How will you adapt your current processes to deal with an environment of (mostly) full disclosure?

3. It is understandable that you might build a team to support server components that help run an Oracle database, but what about the other components?  Will you have support teams for firefox, OpenOffice, Gnome, X-Windows and other components? 

4. What about MySQL and Postgres support?  They Open Source database products are shipped as part of RHEL and supported by Red Hat - will you support them too?

5. RHEL3 has been out for 3 years now and includes components like Samba 3.0.  However, the Samba team identifies 3.0.23 as the stable version, while RHEL3 contains a custom version of 3.0.7.  How will you handle similar situations where you've committed to long term support for a version that is no longer the focus for the component development team?

6.  Will you have a different support Lifecycle from Red Hat for RHEL or will you mirror their support lifecycle timeline?

Interesting times coming for Red Hat Oracle users, to say the least.  I'm not going to become a Red Hat RHEL user anytime soon, but if I was, I'd certainly rather depend on Mark Cox and his team for my security, rather than the "unbreakable" Oracle team.