User: Password:
Subscribe / Log in / New account Weekly Edition for April 19, 2007

The patent tax

The Software Freedom Law Center has recently put out a press release 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 implications clear:

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)

Open projects and secret plans

As of this writing, the front page features the following text:

At 9am, April 19th 2007, join industry leaders and community developers for a major announcement about Open Source and Free Software mobility.

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 until Thursday.

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 move:

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 left out.

Comments (10 posted)

ELC: The embedded Linux nightmare

[Thomas] The opening keynote talk at the 2007 Embedded Linux Conference 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 nightmare.

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 world.

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 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 processors.

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 code.

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 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 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.
Next page: Security>>

Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds