Okay, there haven't been any diary entries for a little while. This one intends to stop that, and at the same time be interesting and controversial.

The ideas contained within here are - in many places - playing Devil's Advocate. However, mostly I'm not. This is a serious look at the claims that the SCO Group are making, reaching somewhat different conclusions than various other commentators. I would be interested in counter-points to the arguments made.

I'm concerning myself here with the views of two commentators - Bruce Perens, and his Analysis of the SCO Slideshow (he also has the actual PowerPoint presentation to download; OpenOffice.org1.1 opens this nicely :), and Eric Raymond's this smoking gun fizzles.

Everyone has made an awful lot about the fact that the code SCO has shown appears to be derived from old Unix. I'm not sure how important this is, though, and I'll show why in a second.

Firstly, I want to describe the slides somewhat. Going from the presentation, the first slide with 'code' is slide 10. However, this is just a comment. Slide 11 gets interesting - this is the start of the Linux atemalloc() function.

I have not seen anyone really talk about the colouring on the slides. I would hope that someone who went to the presentation might be able to write up about it, but there are three colours in use on the code: black, red and blue. It seems that they colour shared code in red, code in SysV in black, code in Linux in blue (this isn't strictly accurate, but the colouring was done by hand, as was the typing it seems, so it's not like a generated diff).

Now, Bruce's claim that SCO would show their best example. I disagree. If they showed a really good example it would probably not be easily viewed on a presentation (if their claims are correct). Rather, they would show the small snippets (like this) that are conducive to the medium. Apparently, they (SCO) also stated quite clearly that this code was nothing to do with their IBM case - they indicated that it was an example of another Unix vendor (it seems quite clear now they're talking about SGI), and how this vendor also caused similar problems. The fact that they haven't taken action against that vendor also indicates that the problems they found were small, in their opinion.

Bruce then goes on to claim that because the function they are showing is heavily derived from old Unix (that is available), there mustn't be a problem. I disagree with this too. ESR's idea of proven evolution is better: at this stage, it doesn't really matter to me a whole lot if SCO are showing code that was made publically available. Why? Because if the code is shown to be copied from SystemV, there is a problem. Who checks the licence on pieces of code? I find it likely that if any code was copied from SystemV, it would have been done more or less unthinkingly, and presents a problem. So, if it can be shown that it was copied from the SystemV tree - even if it was basically derived from 'old' Unix - I think that's problematic.

While I like ESR's idea of trying to show evolution, though, I don't agree with the conclusion he came to. He has access to SVR4 source code, and has done a diff between that and Linux, and shown them to be quite different. He assumes, then, that SystemV currently looks a lot like his SVR4 code. However, that appears to contradict what SCO are saying: Slide 12 shows the equivilent diff, but this time coloured text. SCO are saying that there is one word - (ulong_t - different between the Linux function and the SystemV function.

I don't know who is right there. I may be reading more into the slides than is there (but the colouring is very consistent). But, if what SCO is saying is correct, there is no possible way that ESR's evolution tree stands up. Linux code will have come directly from a proprietary copy of SystemV. What is more damning is the locking in place:

SCO seem to be claiming the above line occurs in both Linux and SystemV. If that's the case, it seems the SystemV SMP functionality is very similar to the Linux implementation. Did SGI take their SMP code and contribute it wholesale? It seems quite clear that the direction the code was copied was Unix -> Linux: in the discussion surrounding this function (atemalloc) on the kernel mailing list in June, people offered reasons to remove the code. Many have picked up on the sound bite - that the code is "ugly" - but no-one has picked up on the fact that many parts of the code were functionally useless in Linux, including the above acquisition of the spinlock. It looks like code ported from elsewhere. Interestingly, ESR also linked to the discussion, but didn't discuss much the reasons why the code might be such a poor fit in a modern Linux kernel, and why sets of wrapper functions have been used.

I can't agree with most of the conclusions reached by others. It seems fairly clear to me that there has been copying between Unix and Linux, and that the direction is Unix -> Linux. However, we haven't been shown much in the way of examples, so the problem of over-analysis is very real.

What I think has happened: I think that the case is again going to fall down to contracts, specifically what people are allowed to do with SystemV source. Although SGI - for example - would have copyright in the code they write for the system, but is that all that they contributed? Are they even able to contribute that, under their licence? In the "open source" world, there are licences which require you to contribute your changes back to the original author. It's very obviously possible that the SCO licences could have even stronger terms of use.