csua.org/u/3je -> news.com.com/2008-1082_3-1023765.html?tag=fd_lede2_hed
But this is the sort of attention Linux's founder could probably do without. The trouble began last March when 31 SCO Group sued IBM for allegedly using SCO's Unix trade secrets in Linux. SCO subsequently claimed that its UnixWare source code also was 32 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. 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 34 Open Source Development Lab, where he'll be able to devote all his energies to Linux. 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. 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. 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? None of the SCO accusations have anything to do with IP rights; 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. 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? 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. 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). For example, will you be taking advantage of their big multiprocessor servers? 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 specialized 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. 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 36 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. 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 optimizations aren't that interesting. I just don't like how the high-level optimizations 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 ( 37 GPL)? 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. 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. 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. 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? In fact, I think it's the rea...
|
http://csua.com/feed/