The Software Freedom Law Center has recently put out
based on a study of how much each Windows user is paying for
software patents. The methodology used is quite simple: look at the known
payments made by Microsoft in patent cases, then divide that sum by the
number of Windows licenses shipped. The bottom line was $21.50 per
license. That is a significant part of the total cost of a license, and
everybody who has bought a Windows license - even those of us who just
overwrite Windows with a Linux installation - is paying it.
SFLC describes this cost as a tax, and does its best to make the
While $20 might not sound like a lot, it adds up pretty quickly. A
school with only 50 Windows machines - barely enough for one class
of students - is paying $1,000 of its limited budget in patent tax,
rather than buying books or other useful supplies. A government
agency with a mere couple hundred Windows machines is paying many
thousands of taxpayer dollars in patent tax.
As the SFLC points out, the real amount of this "tax" is likely to be
higher than the estimate. The number of Windows licenses is probably
inflated by Microsoft, and there's certain to be patent settlements that
the public knows nothing about.
Software patents thus cost quite a bit of money; trying to quantify this
"tax" and spread the word is a useful thing to do. Perhaps, if more people
understand what the patent system is costing them, there will be more
pressure to make real reforms. The SFLC release wanders into slightly more
dangerous territory, though, when it says:
On the other hand, free operating systems based on Linux have never
been found guilty of patent infringement, making Linux a
patent-tax-free alternative to Windows. Not only do these free
software systems have no patent tax, they have no taxes whatsoever,
because - like all open source software - they are available to the
public at zero cost.
There is a significant difference between saying "Linux has never been
found guilty of patent infringement" and "Linux does not infringe upon any
patents." The SFLC's choice of the former wording was carefully done. The
nature of the software patent beast is such that almost any
significant piece of software must infringe upon a number of patents. The
fact that nobody has, yet, successfully prosecuted a patent case against
Linux is not a cause for great comfort.
Language like the above thus risks playing into the hands of those who
would claim that the free software world is populated by those who would
"steal" the "intellectual property" of others. Might they not say that the
absence of software patent payments by Linux users is not an example of
freedom, but, instead, an act of tax evasion? If Microsoft were to decide
to bring a software patent suit against a developer or user of Linux, it
could use this release to great advantage: what better example could there
be of how the free software community's refusal to pay patent royalties
puts companies like Microsoft at an unfair competitive disadvantage?
Putting the focus on Linux in this discussion seems like the wrong
direction to take. While free software developers make diligent attempts
to avoid known patents, the same must certainly be true of companies like
Microsoft. Our lack of patent infringement judgments is more a matter of
luck, lack of sufficiently deep pockets, and, if some sources are to be
believed, some users quietly paying patent royalties to avoid ending up in
court. We need to get the software patent problem fixed, rather than brag
about our avoidance - so far - of public settlements.
Comments (13 posted)
As of this writing, the GNOME.org front
features the following text:
At 9am, April 19th 2007, join industry leaders and community
developers for a major announcement about Open Source and Free
This announcement will be made by Jeff Waugh, who has also promoted the event on the GNOME mailing lists
with this request:
Those paying close attention over the last 12 months will have a
fair idea what this is about, but please resist the temptation to
reply to this post about it, as we're hoping to keep it under wraps
This, in turn, has raised some eyebrows within the GNOME community. It has
been pointed out that the GNOME Foundation
charter reads like this:
In almost every sense of the word, GNOME is an open project. This
is one of our greatest strengths, has always been, and should be
the balefire by which we plot our course into the future...
This principle has real, concrete meaning for the foundation: All
discussions must be publicly viewable, any person must have the
opportunity to contribute to the decision-making process, and every
GNOME contributor must have the direct ability to influence the
decisions which are made.
How, it was asked, do secret plans for a high-profile announcement of a
major new direction for the project fit with those words from the charter?
Where is the "publicly viewable" discussion which led up to these plans?
How has it been possible for any person within the community to contribute
to the process which led to this decision? Some developers see this sort
of secrecy as being inconsistent with the open ideals of the GNOME project,
and they have been asking why things are being done this way.
Jeff has explained the reasons behind this
We'd like to exploit the promotional potential of this announcement
for the betterment of the GNOME community and the commercial
ecosystem around it. It is, in effect, a public secret -- the Board
knows, the Advisory Board knows, a particular subset of the
community knows (and have been participating for ~9 months) and
heaps of people in the broader community know about it but just
don't know that's what we're announcing.
Your editor is not privy to the substance of this announcement - though, as
it happens, he will be present when the announcement is made, so stay
tuned. Members of
the GNOME community have been talking about taking advantage of
opportunities in the embedded area for some time now, though. The venue
the project has chosen (the Embedded Linux
Conference) and the discussion of "mobility" give some strong hints as
well. So it may well be that the core of this announcement will not come
as a great surprise to active members of the GNOME project.
More to the point, there are limits to how much a group like the GNOME
board can change the direction of such a big project. The project's
direction will be determined (and demonstrated) by the code, documentation,
artwork, and so on which gets
created and contributed; there is little else that matters. Perhaps the
board can arrange partnerships with companies which may result in the
creation of certain kinds of code; as long as that code is developed in a
community-friendly manner and does not bypass the normal review process,
there is little to complain about.
Still, it's hard to avoid just a touch of discomfort with the sight of free
software projects behaving like corporations. Hype-building, press
releases, and flashy announcements may succeed in attracting the attention
of the press, but they are not the best way for these projects to
communicate with their users. We all benefit from the transparency that
the free software process provides; free software users are generally happy
to avoid the sorts of surprises that come with proprietary code. We
do not need to be - and don't want to be - herded by way of carefully
planned press events.
That does not appear to be what's going on here; instead, the GNOME board
has simply chosen a relevant conference to announce projects that some
GNOME developers have been working on for some time. Perhaps some
companies will announce that they intend to use and support this work. It
may well be true that
the board's tactics will lead to wider coverage of what's going on, with
a presumably positive effect on the GNOME user and developer communities.
As long as the GNOME developer community is not surprised by what comes
out, all should be well. But projects which want to take this approach in
the future should always think carefully whether their attempts to catch
the flighty attention of the press may leave their core developers feeling
Comments (10 posted)
The opening keynote talk at the 2007 Embedded Linux
was given by Thomas Gleixner. Thomas has been a significant
contributor to the kernel for some time; most recently, he is the force
behind much of the high-resolution timer work which has been merged for
2.6.21. His experience with the embedded Linux industry has prompted him
to put together a talk on how that industry works (or doesn't) with the
development community. When things go badly, he says, the result is a true
Linux (and the kernel in particular) is, says Thomas, a sort of "mutual
benefit society" which is jointly maintaining a common good. This society
will only work as long as the stakeholders give to it as well as taking
from it. The giving part, unfortunately, is often lacking in the embedded
There are a lot of reasons given for the use of special, closed, vendor
kernels in embedded situations. According to Thomas, these reasons do not
hold water. They include:
- "Vendor kernels are developed by experts." Thomas looked at some
specific vendor kernels to see what level of expertise was to be found
there. In one kernel from a system-on-chip vendor, this allegedly
2.6.10 kernel had patches to about 10,000 different files - out of
just over 16,000 total. Another kernel, from a distribution vendor,
had modified 8,000 files. Yet another, from a board vendor, had only
patched 6500 files. Says Thomas: "don't ask me why" these vendors
felt the need to make so many changes.
To give some perspective, the patch from 2.6.10 to 2.6.11 only touched
5600 files. These vendor kernels are far larger than the (invasive)
real-time preemption patch set, which only hits 725 files. These
massive patches are not a sign of expertise - quite the opposite,
instead. Experts don't mess with things which do not need changing
and they get their changes back into the mainline.
- "Vendor kernels offer better time to market." Thomas's counterexample
here was an email from a vendor which had been struggling with a
(self-inflicted) driver problem for a month. Working with the
community, instead, allows vendors to avoid making silly mistakes and
to fix them when they do happen.
- "Users prefer vendor kernels." This is only true when there is no
choice. When there is a choice, users prefer kernels with
ongoing development and maintenance, and for which they can get
support from the community.
- "Vendor kernels help Linux." That help is hard to see. Thomas
pointed out this
discouraging note from the folks at Cirrus:
I think we will just maintain our own port for the 93xx. I
am not going to want to support code not written by Cirrus
Logic. So I give you kuddos for getting to the port first,
but using GIT makes it easy to remove your work and add ours.
It is hard to see how this sort of attitude helps Linux in any way.
Instead, we have vendors tossing aside the work done by the community
in the name of "not invented here."
What really flows from vendor kernels is user lock-in, community
detachment, and waste of resources. None of these are good for users, for
the vendor, or for the Linux community as a whole. They are, instead, the
embedded Linux nightmare.
As an example of community detachment, Thomas offered the linux-arm.org web site,
which describes itself as:
This site is the definitive resource for the community of
developers and users of the Linux Kernel on the ARM Family of
This site, Thomas points out, was launched in 2005 - ten years after the
community ARM port was launched. It does not even do the courtesy of
linking to the real community ARM
site. It is, instead, an example of a vendor trying to create its own
community which has little to do with the people actually creating the
With regard to waste of resources: a Linux developer recently rewrote a
system-on-chip driver to make it suitable for the mainline. In the
process, a 7,000-line driver became a much better 1,300-line driver. Using
the COCOMO model, Thomas estimates that about $180,000 was wasted in the
creation of this vendor driver.
An even more egregious example is a fork of the real-time preemption tree
by "an unnamed company" a couple of years ago. No patches have ever been
published from this fork, and there has not been a single email exchange
with the preempt-rt developers. The resulting code is still based on a
kernel from about the 2.6.14 era, and is completely unmaintainable.
Unfortunately, a customer now wants serial ATA support, putting this
company in a difficult situation. Thomas asks: "why the hell is this
company using Linux?" He estimates that at least ten staff-years have been
wasted in this fork.
The end result of this nightmare can be seen in the form of unhappy
customers, a bad reputation for free software, fragmentation of the code
base, a feeling of being ripped off among kernel developers, and wasted
resources. In addition, Thomas fears that the kernel development process
risks being dominated by the enterprise Linux companies, which do work with
the community. If the embedded world wants to avoid all of these problems,
it needs to start talking with the community and getting its code into the
mainline kernel. Then Tux can get a good night's rest, and world
domination will get back on schedule.
Comments (37 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: MadWifi: Much ado about nothing?; new vulnerabilities in the kernel and php
- Kernel: Schedulers: the plot thickens; How much memory are applications really using?; A peek at the DragonFly Virtual Kernel (part 2)
- Distributions: An LWN.net Distribution List update; new releases from CentOS, Foresight, Mandriva, openSUSE, and RedHawk
- Development: Google Summer of Code 2007 kicks off,
PostgreSQL Access Control Extension RFC, Pimlico launched, GCC status report,
new versions of Lighttpd, mnoGoSearch, Eventum, eSpeak, GARNOME, Xfce, GnuCash, SQL-Ledger, Wine, Claws Mail, openEHR, hexter, Qsynth, PyQwt, AsciiDoc,
PeaZip, PyQt, PyPE, DrPython.
- Press: The Next Challenge for Linux, The Windows Patent Tax, KDE at CeBIT,
Mandriva raising new funds, Microsoft's 'Men in Black', Collaborative Software
Initiative launches, Linux on Palm Treo phone, interview with Linux Foundation's
Christine Martino, Intel's Mobile Internet Device, the Mule project,
NASA's CosmosCode, Feisty Fawn's new debugging tool, the state of Debian,
MadWi-Fi security bug.
- Announcements: FSFE's free software lawyer list, OpenPBX becomes CallWeaver,
Summer of Code updates, Glide for Linux, Univa becomes Red Hat ISV partner,
survey on GPL v3, Linux Device Driver development course,
LPI in Latin America, aKademy registration opens, KDE-Forum Romania,
Chinese XFree86 site.