LWN.net Weekly Edition for November 9, 2006

On Novell and Microsoft

Depending on who is commenting, the recently announced agreement between Microsoft and Novell is either the ultimate victory or the beginning of the end for Linux. If there is anything that is clear about this new arrangement, it's that nobody really understands what it means yet. Perhaps, in the end, it means less than most people hope or fear.

Parts of the agreement are reasonably easy to understand. Microsoft will now officially recommend SUSE Linux to its customers who are determined to run something other than Windows on some of their machines. Microsoft will also hand out "coupons" for Novell support. A joint "research center" will be set up to work on projects of interest to both companies; virtualization, network management, and document formats are on the list of topics to be addressed. Among other things, this work could result in better support for documents in Microsoft formats, an area of active interest for many years.

The part of the agreement which has attracted the most attention, however, is the patent deal. This is also the hardest part to understand, and its real implications may take years to become clear. These seem to be the relevant points:

• The two companies have entered into a "covenant not to sue" each others' paying customers for patent violations. So SUSE (but not OpenSUSE) users should be free of the fear of being hauled into court by Microsoft's lawyers, and Windows users need no longer stay awake at nights worrying about a legal attack from Novell.

• The companies are making patent royalty payments to each other. It appears that the net cash flow is in Novell's direction, because there are more Windows products shipped than SUSE products. But the fact remains: Microsoft has succeeded in collecting a tax on every SUSE Linux distribution supported by Novell.

• Microsoft has made a promise not to sue individual developers for patent violations - sort of.

The text of the covenant not to sue has been posted. It would appear to cover Novell's paid customers for their particular use of SUSE Linux. It's not clear that the term "use" extends to the ways some of us "use" Linux - distributing it to others, for example. Microsoft can tweak or terminate the agreement at any time "pursuant to the terms of the Patent Cooperation Agreement between Novell and Microsoft that was publicly announced on November 2, 2006"; of course, the terms of that agreement are not publicly available. The agreement is currently slated to end in 2012, however.

To some, this agreement represents a total sell-out of Linux users by Novell. To others, it is simply Novell trying to eliminate a specific source of FUD against its customers. How it will really play out remains to be seen.

Novell insists that it has not licensed any patents from Microsoft - that the "covenant not to sue" is an entirely different thing. It is somewhat hard to believe that a courtroom would come to the same conclusion, especially given the fact that royalty payments are being made. The distinction may become very important to Novell. Many observers have pointed out section 7 of the GNU General Public License:

What this text means is that, if Microsoft is asserting patents against GPL-licensed code, Novell cannot distribute that code to its customers just because it has a "license" from Microsoft. There is some suspicion that Novell is trying to use the "covenant not to sue" as a way of weaseling out of this restriction, but it is difficult to imagine such a strategy succeeding. If Novell's customers cannot redistribute Linux, then Novell cannot distribute it to them.

So, should Microsoft ever go after a user of GPL-licensed code, Novell will find itself in a difficult position. Either distribution of the code in question in the lawsuit must be stopped, creating potential problems for Novell's customers, or Novell can continue distribution under its non-license with Microsoft, inviting suits from copyright holders. Either way, a Microsoft patent suit against Linux would not be a comfortable experience for Novell, even with this agreement in place.

Adding to the non-license claim, Novell's Kurt Garloff told LWN:

This is a clear position which contains all the right words. It is still hard to square the claim that no patents have been acknowledged with the royalty payments, however. If Novell acknowledges no patent infringements, what, exactly, is it paying royalties on? Perhaps it is just naked protection money for its customers. Or, perhaps, this is a concession Novell had to make to obtain the royalty stream from Microsoft.

One of the criticisms of this deal centers on the implicit acknowledgment of patent problems in Linux. Companies pursuing patent shakedowns often use the existence of paying licensees as evidence in their favor. If, however, Novell has in truth not licensed (or obtained "covenants not to sue") on any specific patents, then the value of Novell as evidence, especially in court, will be small.

A separate - and very interesting - question remains: how, exactly, does Novell's "covenant not to sue" affect the patents which Novell donated to the Open Invention Network (OIN)? Those patents are at the core of OIN's deterrent power, and it is the promise of protection from OIN which enabled the inclusion of Mono-based software into the Fedora Core distribution. If Novell's non-license covers those patents, then OIN's credibility as a deterrent to lawsuits by Microsoft will take a large hit. Your editor was unable to get an answer from Novell on this question in this article's time frame (getting answers from lawyers takes time). It would seem, however, from an inexpert reading, that the relevant patents have been truly assigned to OIN, and are no longer Novell's to non-license to anybody. If that reading is correct, then OIN's position is just as strong as it was before.

That question has not been settled, however, and there is a lot of concern in the community. The Fedora Project is actively considering the future of Mono in its distribution - one of many interesting decisions that project will be making in the near future.

Finally, there is the matter of Microsoft's promise not to sue individual developers. Anybody who is interested should just go read the text of the promise. As long as individual developers stay in their own basements and don't try to do anything rash - like distribute their code - they will be safe. For anybody who is trying to actually be a part of the free software development community, however, Microsoft's promise has no value at all. There is no point, even, in getting worked up about the fact that Microsoft reserves the right to change its promise at any time. For individual developers, nothing has changed at all.

In fact, for most of us, nothing has really changed. Software patent suits were a serious threat before, and they are still a serious threat. Some argue that Novell's agreement has made a patent attack from Microsoft more likely (Steve Ballmer's latest FUD is often quoted), but that is not at all clear. It is hard to see Microsoft suing Linux users; those whose pockets are deep enough to make them worth suing are certainly Microsoft customers too. A patent suit against another Linux distributor would leave Novell in a seriously uncomfortable position, and likely shatter this new partnership. The threat is there, certainly, just like it was before.

To your editor's eye, the deal looks like the following. Novell, despite trying to do a lot of the right things, finds itself a distant second in the corporate Linux market. Red Hat has proved hard to beat, and the entry of Oracle into this market - supporting Red Hat's distribution - seems unlikely to help. In this context, the deal with Microsoft must look like it has some real advantages: it might help SUSE Linux to achieve the best interoperability with Microsoft products, bring in a few more sales, provide a new royalty revenue stream, and eliminate a source of FUD which might just, still, be bothering a few potential customers. All of these could help to solidify Novell's position in the market, for a while at least.

So, the claims that Novell has sold out Linux for its own advancement are probably overblown - assuming that OIN retains its power. Most of the community will probably be unaffected, and, if we're really lucky, we might get a bit of code out of the deal. What Novell has done to itself will take longer to work out. Walking into Microsoft's embrace has not always led to long-term joy for the companies involved. On the other hand, some sort of engagement between Microsoft and Linux must happen at some point; it is not as if Microsoft will simply vanish. Novell has taken that step; whether it turns out to be a good thing (for Novell, and for the community) is something we will have to see over time.

Comments (63 posted)

Big decisions loom for Fedora

The Fedora Project is in one of those relatively rare periods where the deadlines have passed, the distribution has been shipped, and no new deadlines have yet been set. Now is the time when participants in the project can engage in a bit of introspection, and that's exactly what is going on. Over the next week or so, decisions will be made which could significantly change the way this project works.

For some background, readers may want to look at this posting from Thorsten Leemhuis and Max Spevack's state of Fedora note. The developers involved with Fedora seem to think that the Fedora Core 6 process went well, and that, as a result, FC6 is a solid distribution. They are justifiably proud of their work. That said, there are a number of issues on the Fedora developers' minds, and a number of changes which, seemingly, need to be made.

To that end, the Fedora Project Board will be meeting on November 7. The real discussion, however, will happen at a special "Fedora Summit" happening from November 11 through the 15th. It is a closed affair, featuring Max Spevack, Greg DeKoenigsberg, Bill Nottingham, Chris Blizzard, Warren Togami, Dave Jones, Jeremy Katz, Jesse Keating, and perhaps various others at times. This group of people will try to make a plan for the development of Fedora Core 7 and the future organization of the project.

Since its inception, Fedora has been criticized for not being as open to the community as its early PR had led people to hope. Much progress has been made in that direction over the last year or so, but much remains to be done. Greg DeKoenigsberg is quite clear that making the project more open is a priority, and that the time has come:

From the resulting discussion, it would appear that one significant decision has already been made, at least in principle: the Fedora Core distribution, as such, will be abolished. Fedora Extras has been sufficiently successful that it increasingly looks like the model for Fedora as a whole in the future. There does not appear to be any dissent to this idea; the hot topic, instead, seems to be how the new distribution will be named. "Fedora Linux" appears to be the leading choice at the moment.

But, then, nobody has really gotten down to discussing - in public, at least - how the new, more open Fedora will work. There will still have to be a decision-making mechanism, a way for setting the goals and priorities for the project. Red Hat is still picking up most of the tab for work on Fedora, so there are still likely to be limits to how much latitude the company is willing to give the project to set its own priorities. A good place to start might be to establish the Fedora Steering Committee - first promised in 2003 - with a significant number of outside contributors and let it provide some direction (in the open) for the project as a whole.

Another topic for the discussion is the future of the Fedora Legacy project, which was discussed here last month. It appears that the project has finally come to see Fedora Legacy - or its absence - as a problem. How that problem will be solved is far from clear at this point, however. Another nagging problem is the ongoing maintenance of rpm; that, too, looks like it may be addressed by the board meeting and the summit.

Then there are issues like the ongoing lack of a Fedora live CD. Desktop support is getting more attention, though it is hard to see how Fedora can address many of the complaints in this area (lack of official Java, flash support, etc.) while remaining true to its "free software only" rules. Making a source code management system available to the wider community remains on the "to do" list. And so on.

In other words, Fedora has a lot of work to do, still, before it becomes a truly open, community project. Nothing illustrates that better than the fact that the directions and priorities for the next Fedora release will be set in closed board and summit meetings. What seems different now is that the project insiders appear more determined than ever to get this work done. For all that Fedora is a great distribution, it needs its community to continue to grow and reach its potential. Given all that needs to be done to become more open to its community, Fedora is likely to still be very much a work in progress by the time the Fedora Linux 7 (or whatever it is called) is released. But, then, that is true of a great many free software projects.

Comments (17 posted)

Review: Linux Administration Handbook, Second Edition

Your editor is often asked if he would be willing to be a technical reviewer for an upcoming Linux-oriented book. Such requests are almost always turned down. Technical review is an important task, but it takes vast amounts of time and the compensation is mostly measured in karma points. It is a hard task to squeeze in. Evi Nemeth, however, earned special consideration many years ago when she allowed LWN's co-founders to do their Data Structures homework on the University of Colorado's lone VAX 11/780 - on the condition that they learn C. She also let your editor make some "fixes" (long since lost, mercifully) to the memory management system on the early BSD release running on that VAX. So, when Evi and company asked for help reviewing the second edition of the Linux Administration Handbook, your editor agreed to do it.

This was not a trivial task; the Handbook now weighs in at a full 1000 pages. It is derived from the classic Unix Administration Handbook, which was the definitive administration manual for its times. The second iteration is an attempt to bring the book up to date with the current Linux state of the art, an attempt which is not 100% successful. The fact remains, however, that the Linux Administration Handbook remains unmatched for its combination of clear writing, technical depth, and extensive experience in all aspects of system and network management.

A glance through the table of contents shows that some audiences will get more out of the Handbook than others. The chapters on DNS and electronic mail administration are over 100 pages - each. Networking is covered in detail, from how to wire up an RJ-45 connector through Samba administration. Backups, printing, process management, the bootstrap process, and so on are all addressed. There is also a lot of accumulated wisdom on dealing with users, working with vendors, managing system administration groups, tracking problems, etc. If you are charged with managing mostly server-oriented systems, this book has almost everything you need.

The second edition updates the Handbook in a number of ways. Ubuntu "Dapper" and Fedora Core 5 have been added to the list of covered distributions; they join RHEL 4.3, SUSE Linux Enterprise 10.2, and Debian Testing (to be Etch) as of last September. Bacula is now covered in detail (and much of the Amanda discussion has been taken out). The electronic mail chapter - while still centered mostly on sendmail - now has a reasonable section on postfix. The security chapter has been filled out with the latest tools. And so on.

As your editor can well attest, however, bringing a book up to the current state of Linux is a hard task - and it never stays current for long. Still, at times, the Linux Administration Handbook shows its age a little too much. Back in the days of VAXen and early Unix workstations, we all got very good at dealing with serial ports and making terminals talk. But how many of us need a chapter on that subject now? The security chapter passes over SELinux entirely - a major shortcoming. As far as the authors are concerned, udev seems not to exist - it is only mentioned in passing. But how does one manage a contemporary system without an understanding of udev? There's plenty of information on how deeply Ethernet hubs can be cascaded, but wireless networking is passed over almost entirely.

There is also almost no discussion of contemporary desktops. The Handbook authors avoid graphical administration tools in favor of really understanding (and being able to script) the system at a lower level, and this is good. But an administrator in this century should have a sense for how the desktop goes together and how to configure things to give users the experience and capabilities they need. The second edition does add a badly-needed chapter on the X Window System, but it leaves the upper parts of the desktop untouched.

So the second edition of the Linux Administration Handbook is not perfect. But, for a large part of the system administration space, this book has the best combination of "how to do it" (technical details) and "how you should do it" (what works well in the real world). It is still the first place your editor looks when the man page falls short. If your job requires keeping Linux systems running, especially if it's in a larger environment, you probably need this book on your shelf.

Comments (9 posted)