...and if SCO is right...?
The Linux kernel (which is the subject of at least some of SCO's claims) is, as a whole, clearly an independent development. The development history is sufficiently public to make that clear. But it is worth considering a few things:
- The source to various proprietary Unix systems tends to be more
widespread than many people think. Numerous companies have source
licenses, and, despite careful procedures, copies can leak out.
- There is considerable reputation value in making contributions
to the Linux kernel. Perhaps more than any other free software
project, the kernel is surrounded by developers who would like to get
their names into the changelog, even if that means submitting spelling
fixes.
- Some people are lazy or unable to program at the level required for kernel development (or both). Some of those people may have access to some flavor or other of proprietary Unix. And some of them might just be sufficiently dishonest to present somebody else's code as their own.
It is also worth bearing in mind that there is no process for checking the pedigree of code submitted to the Linux kernel. Kernel developers (like other free software developers) have more than sufficient integrity to keep them from stealing code, and the process relies upon that fact. If a developer can convince Linus or another major kernel hacker that a patch makes sense, in it goes. Some kernel code is heavily reviewed, but there are vast amounts of code that may not have ever had a serious look by anybody other than its author.
Beyond all that, of course, is the unpleasant scenario of tainted code being deliberately submitted to the kernel with the express intent of creating legal problems.
The end result is that there might be code of dubious parentage in the kernel. Such code is probably small, and not in the kernel core. But the existence, say, of a purloined device driver somewhere in the kernel would not be entirely surprising. The kernel community might just wake up one morning to find that there are plagiarists in its midst.
What happens then? Obviously, a code purge would be called for. Unless SCO explicitly puts any offending code under the GPL (which it might have to do to preserve its own right to distribute the kernel), any infringing code must be pulled from the kernel. That code could be excised even if SCO does release it; its presence would certainly be galling to a number of people. A big "purge and rewrite" operation could, among other things, delay the release of the 2.6 kernel.
Future code contributions would receive a higher degree of scrutiny - this may well happen regardless of how the SCO suit turns out. Even if it has not yet happened here, free software projects are vulnerable to injections of tainted code. Developers may have to be prepared to explain how they came up with a particular patch. It is hard to imagine the kernel adopting a bureaucratic mechanism where develpers must sign code releases with warranties and indemnification agreements, but it could happen. Adding that kind of friction to the system can only serve to slow down development, of course.
Most frightening, perhaps, is what happens if the kernel development community discovers that one or more of its members has been polluting the well with unfree code. The resultant shattering of trust could impair that community's ability to work together for a long time. In the worst case, if important developers are implicated in dishonest activities, a major fork of kernel development is not out of the question.
A successful suit would also make waves in the business world, of course. In the worst case, companies could move away from free software out of fear of lawsuits; this scenario seems unlikely, however. But companies could hold back on code releases or contributions to free software projects out of fear of being accused of illegal copying. A general chilling effect which slows adoption of Linux is a real possibility.
Happily, the most likely outcome is that SCO and its lawsuit go down in
flames. They have picked on, perhaps, the most transparently developed
piece of code in history by way of a huge company with seriously scary
lawyers, deep pockets, and the will to defend itself. But the worst-case
scenario is worth keeping mind for this simple
reason: even if the Linux community doesn't get burned this time, it could
happen in the future. We need to pay a great deal of attention to where
our code comes from.
