In this interview Linux's creator, Linus Torvalds, sounds off on the SCO lawsuit, patents and the future of Linux.

The trouble began last March when SCO Group sued IBM for allegedly using SCO's Unix trade secrets in Linux. SCO subsequently claimed that its UnixWare source code also was copied line by line into the Linux "kernel" that Torvalds began writing as a computer science student in Finland in 1991 and still oversees.

The legal contretemps focused new attention on the process that developers follow to create open-source applications: The source code that Linux programmers contribute to open-source software is freely shared. SCO specifically blames Torvalds for not establishing a mechanism to check whether code violates intellectual property (IP) rights such as patents or copyrights.

For his part, Torvalds remains unshaken and, in fact, is increasingly determined to promote Linux's fortunes on a full-time basis. The 33-year-old last week took a leave from chip designer Transmeta to begin a new job at the Open Source Development Lab, where he'll be able to devote all his energies to Linux.

The Beaverton, Ore.-based group is funded by several computing companies including IBM, Intel and Hewlett-Packard. At OSDL, Torvalds now is paired with Andrew Morton, one of his top lieutenants and the programmer in charge of the forthcoming 2.6 version of the Linux kernel.

At OSDL, Torvalds will focus on abstruse programming issues such as "block input-output" communications with devices such as hard drives, virtual memory for accommodating large databases, "scaling" Linux to work on large multiprocessor servers, and threads that let Linux juggle more tasks simultaneously.

He recently talked about his new post and the future of Linux in an e-mail interview.

Q: Has the SCO lawsuit changed your daily work practices at all, and do you envision a screening process before code is submitted or accepted, rather than letting copyright holders check after it's accepted?
A: We've had screening processes in place for the longest time, but they've not been for IP issues as much as a way to let people comment publicly on new features.

Does putting the responsibility to find patent infringement on the patent-holders run the risk that the patent will come to light after someone has included patented material in Linux, after which it will be extremely difficult to extricate?
Finding patent infringement has always been a responsibility of the patent holders. I didn't put it there...It is a fact that I do not encourage engineers to look up patent information, for example. You ask any lawyer about it, and they will tell you that I'm right. It's not the job of an engineer to try to find out about other peoples patents, since that just taints them, exactly something you do not want to happen.

It is a fact that I do not encourage engineers to look up patent information.

Do you think the SCO accusations will result in any changes to the process by which code is accepted into the Linux kernel?
Not that I can tell. None of the SCO accusations have anything to do with IP rights; they're all about contracts between IBM and SCO. All the IP rights blathering by SCO was just that--blathering--the kind of "holier than thou" stuff where they tried to look like they had some moral high ground. The fact is that the stuff they have actually mentioned (RCU etc.), was all IBM's intellectual property.

Looking to the future, should hardware and software companies think about offering total indemnification to customers who might get sued for using open-source code later found to contain proprietary intellectual property?
Hey, if customers pay for it, why not? It's just an extension of a support contract. By the way, I'm getting really tired of the "proprietary IP" thing. How many times do I have to repeat that the SCO case isn't about IP at all, and that SCO has just been spouting crap when they have brought up their FUD about IP issues. (Editors' note: FUD stands for fear, uncertainty and doubt.)

Now that Linux is important at IBM, Oracle, Dell, HP, SAP and others, do you get more pressure to meet shipment schedules or add specific features?
I haven't personally felt any such pressure. Which is not to say that it may not exist, but might be more of a "Linus isn't very good at picking up strong hints" kind of thing too ;)

What fraction of your time in the Transmeta years did you spend on Linux, and what fraction do you think you'll spend on it at OSDL?
At Transmeta, it depended on what was happening, but for the last few months it was almost exclusively Linux (except when the new Transmeta chips came back, which is always exciting).

Are you going to telecommute from Santa Clara, Calif., or move north to Beaverton, Ore., where OSDL is headquartered?
Telecommute. I'll be visiting physically every once in a while.

Will you change what you focus on at OSDL? For example, will you be taking advantage of their big multiprocessor servers? I'm presuming you'll be just as self-directed as ever.
Yeah, "self-directed" is a good word. It doesn't have any of the negative connotations associated with "stubborn" or "doesn't take commands very well." That doesn't mean that I won't take advantage of their big boxes, but I've always enjoyed the small (but powerful) variety more.

Are you happy that Linux is used commercially primarily on servers? Would you rather see it be more of a mainstream desktop phenomenon? Obviously the two aren't mutually exclusive, but I'm curious which future you'd rather see.
Oh, I'd obviously like to see Linux more on the desktop too, but I take the long view, and I don't think it has to happen tomorrow. The reason Linux is strong on servers is that it is a much easier market to get into, and I'm very happy with where Linux is today in that area. And I absolutely do not see the server and desktop as mutually exclusive. In fact I personally think that a large measure of the technical "goodness" of an OS is how well it responds to different kinds of users, and I think specialised niche OSs are an evolutionary dead end.

A while back, you said one of your main jobs isn't so much writing Linux code but rejecting submissions that aren't up to snuff. Is that still the case, and is that what you really enjoy?
It's still true that most of my time isn't coding per se. Most of my time is spent merging code, and talking to people about issues. The "rejection" part may not be most of it, but to some degree it's the most important part--i.e. I see myself as not just a common repository, but also as an arbiter of "good taste." I'm by no means the only arbiter of good taste; every subsystem maintainer is one too, of course. But for the occasional (very rare, I'm happy to say) spats, I often end up being the final arbiter.

Are there other open-source software development communities you particularly admire?
If I'd have to pick two, I'd pick KDE and the GCC group. I often end up clashing with the compiler people, because the kernel ends up having rather strict needs, and I hate how much slower GCC has become over the years. But there's no question that they're doing some good stuff. And I just like the KDE group, and have found it very responsive when I had issues. (Editors' note: KDE is the creator of a graphical interface for Linux. GCC builds the compiler used to turn source code written by humans into machine code that computers understand.)

I was talking to (Red Hat Chief Technology Officer and GCC backer) Michael Tiemann about his view that general-purpose compilers, well written, will incorporate broad optimisations that ultimately will produce superior code to compilers with chip-specific optimisations. But now I'm hearing that Intel's C compiler produces much faster software than GCC. Have you tried the Intel compilers, now that you can compile Linux with them?
I haven't really ever gotten around to using the Intel compilers, but I like the fact that there is competition and a baseline to compare against.

And I personally disagree with Michael about general-purpose compilers. Yes, there should be a lot of shared code, but when it comes down to it, the thing that matters most for modern CPUs is just generating good tight code, and the generic optimisations aren't that interesting. But hey, that's just my personal opinion. I'm not really a huge compiler person; I just don't like how the high-level optimisations in current GCC versions are slowing things down without actually giving much of a boost to generated code for C.

I personally think that the BSD license is a dead end for serious projects.

Do you ever wish you'd opted for a BSD-style license instead of the General Public License (GPL)? (Unlike the GPL, BSD-style licenses such as those used for the Apache Software Foundation Web server and the FreeBSD Unix offshoot permit open-source code to be made proprietary.)
Absolutely not. I personally think that the BSD license is a dead end for serious projects, since it inevitably results in forking with no way to re-join if it becomes commercially viable. (Editors' note: Forking is dividing a programming project into two different, overlapping projects.)

Forking a project is in my opinion hugely important, since forks are how all real development gets done, and the ability to fork keeps everybody honest (i.e. if you don't do a good job and keep your users happy, they can always fork the project and go on their own). But equally important is the ability to join back forks, when/if some group finds the right solution to a problem. And that's where the GPL comes in: you can really think of the whole license as nothing more than a requirement to be able to re-join a forked project from either side.

What fraction of Linux contributors these days are paid to do so?
Almost everybody of the major developers involved is paid to develop Linux in one form or another. Few of them started out that way, but once they proved their prowess, they had little trouble finding companies to pay them for doing Linux work.

Who are your top deputies?
They change over time, and they tend to be subsystem-specific. For example, over the last year or so, it's been Andrew Morton (virtual memory, filesystem interactions, "generic" code), David Miller (networking), Greg Kroah-Hartman (USB, PCI hot-plugging), Jeff Garzik (network device drivers), Jens Axboe (block device layer), Dave Jones (AGP and clean-ups), Kai Germaschewski (build infrastructure and ISDN), Pat Mochel (device manager infrastructure and sysfs), Russell King (PCMCIA and ARM), Rusty Russell (cleanups and module handling) and Al Viro (filesystems).

And that's ignoring the architecture maintainers who handle their own architectures (Itanium, PowerPC and AMD64) and other people that I probably just forgot. It's also ignoring people who have very specific subsystems, like Roland McGrath and Ingo Molnar who have worked on the signal handling and threading code, for example.

But it really does change over time. And some people fade in and out over long periods--they'll be very active for a few months, then they go away for some time, then they come back.

Do you think Linux suffers from the issue that it's more fun to experiment with new ideas and new modules than it is to perform comparatively mundane work such as updating a driver for some out-of-date tape backup system or auditing older code for security vulnerabilities? Do you think Linux suffers more or less from this than traditional proprietary development processes?
I don't think Linux "suffers" from it. In fact, I think it's the real driving force for most new features.

The mundane work has to be done as well, of course, but people do do it. Sometimes it happens just because they are paid to do it, but quite honestly, more often (I think) because the people involved are just proud of what they do, and dotting the i's and crossing the t's is part of making a good product.

Some drivers etc. do get left behind, but usually it's because literally nobody cares about them anymore. They're either so out-dated that they aren't used anymore (quite common for some old ISA crud--I don't think people even remember how many strange CD-ROM controller cards there were), or because the people who haven't updated their hardware also don't tend to update their kernels. The latter happens in the embedded space, for example: Once it works, you literally don't touch it any more.

What's the most exciting feature of 2.5? (The 2.5 kernel, which Torvalds oversees, is the development version that will be replaced by the 2.6 "production" version for real-world use.)
Excitement is in the eye of the beholder. I doubt most people find my "exciting feature" very interesting. To me, the most important part of 2.5.x development has been the new block IO (input-output) layer infrastructure, and the POSIX threading stuff (the latter got back-ported to 2.4.x too). Both are to some degree just internal cleanups, and just make it easier to do things right, rather than huge user-visible features in their own right.

But there's a lot of other stuff. The VM (virtual memory) is a lot nicer, and we scale a whole lot better. Better interactive behaviour (this is largely from the VM work, but the scheduler etc have been worked on).

Any thoughts about what big changes will come with 2.7?
Ask me after the kernel summit. That's going to be one of the big discussion points. (Editors' note: The kernel summit is the meeting of minds that will take place later this month before the Ottawa Linux Symposium.)

Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved.
ZDNET is a registered service mark of CBS Interactive. ZDNET Logo is a service mark of CBS Interactive.