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:
If you cannot distribute so as to satisfy simultaneously your
obligations under this License and any other pertinent obligations,
then as a consequence you may not distribute the Program at
all. For example, if a patent license would not permit royalty-free
redistribution of the Program by all those who receive copies
directly or indirectly through you, then the only way you could
satisfy both it and this License would be to refrain entirely from
distribution of the Program.
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:
Like before, Novell does not acknowledge that any software it ships
actually does infringe on a patent. As soon as Novell would
determine that GPL software is affected by a MS patent, Novell
would change the software to avoid/work around being affected by
the patent.
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:
We've got a lot of work to do inside the fenceline, though.
Honestly, a lot of that work requires the disentanglement of Fedora
and RHEL -- we need the ability to innovate freely in Fedora
without adversely impacting RHEL. We didn't really have that
opportunity in the FC6 timeframe.
But now we do.
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
![[cover]](/images/ns/grumpy/lah.png)
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)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Rainbow tables; New vulnerabilities in far too many packages.
- Kernel: Task watchers; This week's kevent API; Sparse gets a maintainer.
- Distributions: Get more Science into your Distribution; new releases from andLinux, Debian, gNewSense, NetBSD; rPath Supports of Xen 3.0.3; GNU-Darwin and SEDarwin; new distribution Lintrack
- Development: Adobe donates Flash Player Scripting Engine to Mozilla,
new versions of BusyBox, LAT, Mailfromd, OpenSSH, CUPS, Linux-VServer,
DataparkSearch, Cosmo, Snd-ls, Dropline GNOME, KDE 4 Developers Snapshot,
Xfce, USB FPGA Board , PyQt, OpenEMR, McCLIM, PHP, PyEnchant.
- Press: Ideas about ideas, Red Hat on Novell/Microsoft, Linux on Dell,
Italian Linux Day, Linux in China, progress in Munich, JPEG patent surrendered,
setting up BZFlag server, math on Unix, GnuCash 2 review, QBrew review,
iPod Liberation, Web Science Research Initiative.
- Announcements: New Linuxaudio members, Google to donate to Samba, Novell partners with
Microsoft, OpenMoko phone, Austin Group specs rev 2, new Open Group API,
PostgreSQL CE exam, PHP Quebec CFP, RailsConf CFP, ICMC demo.
Next page:
Security>>