...and if SCO is right...?
[Posted May 16, 2003 by corbet]
As a general rule, the reaction to SCO's lawsuit against IBM has been one
of derision and disbelief. It is generally assumed that SCO does not have
a legal leg to stand on. SCO's tactics (ever-expanding FUD while refusing
to point out the allegedly infringing code) have certainly served to
reinforce that perception. But it is worth taking a moment to consider
what could happen if SCO turns out to be right. Forewarned, as they say,
is forearmed.
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.
(
Log in to post comments)