Leading items

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:

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:

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 GNOME.org front page features the following text:

This announcement will be made by Jeff Waugh, who has also promoted the event on the GNOME mailing lists with this request:

This, in turn, has raised some eyebrows within the GNOME community. It has been pointed out that the GNOME Foundation charter reads like this:

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:

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

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 linux-arm.org web site, which describes itself as:

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