We've had a couple of conversations with them. I think what happens is people, as [instructions] spread through a large organization, unless you're very precise with your instructions, things tend to get diluted. I think they're now being a lot more careful. Has SCO gotten better about being precise with its terminology?
And I don't think that the confusion they were creating was deliberate. Some of the reader comments that I saw in response to your recent op-ed piece for CNET, which spoke to a lot of these issues, contend that 'Unix' is really something of a generic term at this point, given that it's been around for so long and that it's sprung up in so many different forms. How do you respond to that?
Maybe in the consumer area it is treated as a term that refers a certain [general] type of computing. But in the mission-critical procurement space, people do understand what they mean by 'Unix' and what they mean by 'certified Unix.' In regard to the SCO/IBM dispute, what have you seen that concerns you?
What concerns us is anyone suggesting that they own Unix without defining what that means. And certainly to say, 'We own Unix,' as SCO Group suggested for a while, is not accurate. They own the System V Release 4 code and the software that goes with that. They don't own 'Unix' as such, and the reason that we're very concerned about that is because we were given the Unix trademark,
For all of the products that conform to that standard -- and it's pretty much every product in the marketplace that [is identified as] Unix, with maybe one exception, which we're trying to address. But other than that, they all conform to that [specification], to the level that the standard goes, which is about 2,500 thousand APIs. How many is it? What does it mean, exactly, for a product to meet the Unix specification? My understanding is that you do not look at the product code. What benchmarks are used?
I just checked it, actually. It's 9.2 kilograms of specifications. So that's nearly 20 pounds of specifications. I think it's over 3,000 [APIs] now. Some of the reader comments that I saw in response to your recent op-ed piece for CNET, which spoke to a lot of these issues, contend that 'Unix' is really something of a generic term at this point, given that it's been around for so long and that it's sprung up in so many different forms. How do you respond to that?
It really depends on whether you're talking to a general community who are using a word fairly loosely, like we all would when we're at home Hoovering the carpet. We all know that it's not a Hoover product that we're using, and most of us, if we're reminded would say, 'oh, yeah, I sort of knew that was a trademark.' So that distinction between usage on and in connection with a product, and being a little imprecise in our everyday language is very important. Fair use is something that we've always been very good about. We educate everybody who misuses the [trademark]. What does it mean, exactly, for a product to meet the Unix specification? My understanding is that you do not look at the product code. What benchmarks are used?
So, all of them conform to those standards, so they are the same as far as that goes. The thing we never want to get to do is to make them all the same, like potatoes. So what we've got to do then is to make sure that the vendors of Unix-certified products can compete on speed, added functionality above the standard, and quality. If they can compete on those, then that enables the standard and Unix-certified products to continue to evolve at a faster rate than if we had [only one Unix flavor]. How does a company get its product certified as 'Unix'? How long does it take?
If you've got a product that you've set out to create as conformant to this, and you've done a great job, then when all the tests are run -- and by the way, we don't do the tests; the vendors run the tests themselves and give us the results for audit. If they've done that, and they've done the job well, they submit those to the Open Group. And it all gets QAed and checked out. ... Once that's all done, we certify that.
The important thing is that, when the vendor comes to do that, they are saying three things. They are guaranteeing that their product conforms to the specification, no ifs, no buts, no shades of gray. The second thing that's important is that they're saying it will continue to conform; so if they do a maintenance revision, they do a patch, they do a fix, they do a product repair, the functionality, it stays conformant to that specification. And the third, and I guess in some ways most important thing is, if there is nonconformance, it's fixed and it's fixed in a prescribed time scale.
This is why, when I talk to procurement officers, they start to get excited. And I say wouldn't it be nice if you could throw away all the software licenses that you traditionally talk about, the sort of gist of which is 'all bets are off,' and get one that says it'll do exactly what it says in the specification. It will continue to do it, and 'if there's a problem, I'll fix it, and I'll fix it within a prescribed time scale.' That's why procurement officers and people who care about open systems like this. Can you comment on the status of your dispute with Apple?
It's where we've said it is, and that is, we're taking action against Apple. Our approach is always education first. And by having this trademark, they're signing on to all this?
That's exactly what they're signing on to. Can you comment on the status of your dispute with Apple?
We would much prefer to reach an agreement with them; litigation is always a last resort.
FOR MORE INFORMATION: