Why should I? If I were to sign an NDA to see code, I couldn't use that knowledge anyway due to the NDA, so what would be the point? Not only that, I'd also be effectively unable to do my job as kernel maintainer, since I'd suddenly have to worry all the time whether something could be construed as being 'secret.'
Also, since everything points to there not being any IP issues in the case at all, the last thing I'd want to do is to enter into a contract with SCO. That's how you get sued, you know.
SCO recently essentially blamed you for allowing proprietary Unix code into Linux and for not checking into where the contributed code is coming from. Is the Linux development process flawed? Will it change?
FEEDBACK: What features promised in the 2.6 kernel will help nudge Linux deeper into enterprise data centers?
Send your feedback to the SearchEnterpriseLinux.com news team.
We're going to start the pre-2.6 kernels (final beta program) soon. Probably [this] week.
So the features are pretty well known, and we'll see how the beta program progresses to a final 2.6.0 release. Probably a few months.
Part of the OSDL's stated mission is to advance Linux adoption in the enterprise. You've said in the past that you've found desktop Linux work more interesting. Are you going to devote more energy now to the needs of enterprise environments?
I've always been of the opinion that the desktop loads are much more varied, and people using a desktop are also much more sensitive to 'glitches' in loads than any server load.
So making the system work well as a desktop automatically gives you a well-behaving system (as long as you avoid silly hacks like 'foreground window gets more interactivity') that is likely to also work well on servers.
The reverse is not true. Server loads are almost always 'tunable,' because you can know the behavior of a server in advance. In other words, servers are 'easy' -- you can get them right without having an acceptable desktop at all.
Upon taking a leave of absence from Transmeta, you were quoted as saying you were 'feeling somewhat guilty' over devoting more time to Linux than your work with the company. How will working for the Open Source Development Lab change or sharpen your focus on Linux?
The main advantage of moving to OSDL is that I don't have to feel guilty when I'm spending [an] inordinate amount of time on Linux. In fact, since Linux kernel maintenance is my primary job at OSDL, I'd have to feel guilty if I didn't spend my time on it. Is there any truth to the theory that the SCO Group's legal action against IBM and threats against the Linux community could inspire other open-source contributors to seek intellectual property (IP) damages?
Not that I know. In fact, there doesn't seem to be any IP claims AT ALL in the SCO suit. The IP in question seems to be clearly IBM's to give to Linux, and the whole suit is about some alleged contracts that I obviously have no insight into, but that have nothing to do with Linux or IP law (contract law is a whole different area).
The whole IP brouhaha seems to have been just the SCO Group trying to throw FUD [fear, uncertainty and doubt] and make it look like they are somehow the 'wronged underdog whose IP was stolen.' They went for the tear-jerker approach, never mind that it wasn't apparently actually their IP in the first place.
Could you provide some insight into some new features?
There's too many new things in 2.6.x to list, but a very short and incomplete list would be something like: more robust VM behavior (in particular, better latency control), better thread handling, improved scalability in a lot of areas, notably file systems, and a lot better block device layer infrastructure.
And a lot of new device support; for example, the USB development has been taking place on the 2.5.x branch (a lot of it has also been back-ported to the 2.4.x kernel, so some 'new' features are available in the newer 'old' kernels, too).
What enhancements to the kernel would drive Linux deeper into enterprise mission-critical work?
Well, we're working a lot on scalability, reliability and security, all obviously major technical issues. To a large degree, the enterprise 'acceptability' comes from non-technical work, though -- it doesn't matter how good you are if there aren't companies that support the system 24/7 and sign on the dotted line that they'll be there for you when you need them. SCO recently essentially blamed you for allowing proprietary Unix code into Linux and for not checking into where the contributed code is coming from. Is the Linux development process flawed? Will it change?
The process is fine and, in fact, the very openness of the process makes a lot of the accusations completely ridiculous. I'll guarantee you that it is a lot more likely that SCO's SVR4 code base contains open-source code than that Linux contains improper SVR4 code. (In fact, the AT&T vs. Berkeley lawsuit years ago showed that SVR4 does contain code taken from the BSD project with the copyright attributions, etc., removed, so I'm on fairly safe ground there!)
And perhaps more importantly, the thing is, the openness makes it easy for suspicious code to be pointed out, and we can go back and look where it really came from. The very fact that SCO doesn't want to point to the code in the open is only another indication of the fact that they know that, when people go back and see where it came from, it will be clear that it wasn't code that SCO had IP rights to in the first place.
These days, SCO has actually named some of the code they are unhappy about, in particular the RCU [read-copy-update] code that IBM made available to Linux. But the thing is, that code was written by IBM, and IBM even holds the patents to it (well, it was Sequent at the time, but they're long since assimilated into IBM).
The point being that the code got into Linux [in] quite legal ways -- from the real IP holder -- and we can point to exactly how it got into Linux and how IBM made not only the code available, but licensed the patents, too, the way the GPL requires. So SCO's case is clearly not about IP.
It appears that SCO's case is about the fact that IBM helped 'the competition' (never mind that SCO was into Linux back then, so it wasn't the competition back then). And SCO is unhappy about the fact that IBM wasn't their exclusive valentine, and that IBM screwed around with other partners after having dated SCO.The FUD is flying over the SCO suit. Are you hearing any feedback from enterprises that might be reconsidering their Linux implementations or their future plans to use Linux in the enterprise?
I haven't had any feedback from companies about the suit. But I've had a lot of journalists and a lot of Slashdot readers send me e-mails!