LWN.net Weekly Edition for September 2, 2004

Pointless ideology?

Last week's USB subsystem patch posting included a number of changes, from some data structure shrinking and continuing improvements to the new USB OTG support. A less welcome part of that patch, however, was the removal of the Philips webcam (PWC) driver, by the request of its author.

The PWC driver had a unique feature in the form of a hook which allowed the loading of a binary module into the driver. This hook was used to load a closed-source decompression routine, needed to use the camera in its higher-resolution mode. This sort of hook goes against kernel policy, so, when USB maintainer Greg Kroah-Hartman became aware of it, he prepared a patch to take it out. The PWC driver maintainer (Nemosoft Unv.), in response to this change, requested that the driver be removed altogether. He has also removed the driver and all the related files (including the binary-only part) from his web site.

Greg Kroah-Hartman's FAQ on the removal of the PWC driver is worth reading.

The reaction in parts of the community has been quite strong. This is, according to some, another example where licensing fundamentalists have, through their intolerance of binary-only modules, cost Linux users the ability to work with their cameras. The PWC driver, which was not hurting anyone, has been needlessly lost. Linux will never be able to compete with Microsoft or be taken seriously by vendors as long as this kind of silliness is going on. And so on.

Whether Linux developers should be concerned with "competing with Microsoft" is a topic for a different article. For now, let us look at the issue of proprietary modules, and the kernel developers' approach to them. The general attitude toward proprietary modules is overtly hostile. Critics claim that this attitude is the result of blind ideology which puts free software fundamentalism above the needs of Linux users. The truth of the matter is that there is no end of solid, practical reasons for discouraging the creation and use of binary-only kernel modules.

The first of these is that the copyright status of many of these modules is ambiguous at best. Any module which is a derived product of the kernel must carry a GPL-compatible license; no exception to the GPL for loadable modules exists. A serious legal challenge to the distribution of a proprietary module has not yet been made. Yet. There may yet come a day, however, when one of the many holders of copyrights on kernel code decides that a binary module violates his or her copyrights, and does something about it.

Binary modules are, by their nature, platform-specific. One of the strengths of Linux is the freedom of choice it gives with regard to hardware, but binary modules take that freedom away. Linus Torvalds put it this way:

Non-free drivers lock users into specific architectures.

When binary modules have bugs, there is no way to even track them down, much less fix them. A bad module brings down the entire kernel with it, making Linux appear to be unstable. And closed-source modules tend to have a much higher rate of bugs than free modules; they have been seen by very few eyes, rarely conform to kernel programming conventions, and their authors cannot be educated on how to do things right. A system which contains proprietary modules is less stable, and there is nothing that the kernel developers can do about it.

Closed-source modules break when the system is upgraded. The internal kernel interfaces can be changed at any time, a longstanding policy which exists for several good reasons. In-tree modules are fixed quickly; proprietary modules are fixed when the vendor gets around to it, if ever. A binary module has no future beyond whatever promises the vendor may have made regarding its support plans. Some of the more cynical among us have been known to mutter that such promises have, on occasion, not been kept. And those promises tend to be minimal in the first place; technology manufacturers are much more interested in getting people to buy new hardware than supporting their old, obsolete products.

Perhaps more to the point: binary modules are a drag on the development of the kernel. Whenever a kernel change breaks those modules, users complain loudly. The kernel developers express their lack of worry about breaking binary modules in a very clear way, but the fact is that they (and their employers) have to think before making that sort of incompatible change. Consider, for example, the change to 4KB stacks on the x86 architecture. This change makes the kernel more stable in a number of ways. But it broke the binary nVidia modules, leading to a loud chorus of protests. To the extent that those users' complaints are heard, important kernel improvements will be delayed or blocked.

Binary-only modules lack transparency; users never really know what is going on inside. There is speculation that the PWC decompression code is closed-source because opening it would reveal that the camera has far less resolution than advertised. This is almost certainly untrue, but there is no way to look at what is going on and know for sure. The lack of transparency also makes it impossible for programmers to benefit from the work that was done on the proprietary module; there may well be useful ideas there which could be applied elsewhere in the kernel, but there is no way to know. The creator of a binary-only module is benefiting from the free software development process, but is not giving back to it.

At the 2004 Kernel Summit customer panel, the technical manager from Goldman Sachs - not a person who is likely to be inclined toward ideological licensing fancies - was in the interesting position of telling the kernel developers about the advantages of having device drivers in the mainline kernel. He pointed out that drivers which have been freed and merged into the kernel do not have the sorts of stability issues experienced by users of proprietary drivers. Even the most focused and hard-nosed of users are beginning to realize that wedging proprietary code into the kernel is not in their best interest.

It is thus in the interest of all users to discourage proprietary modules. It is not a question of irrational allergies to end-user license agreements or free software fundamentalism; it is, instead, a matter of creating the most stable and capable kernel possible. Had the kernel been a friendlier environment for proprietary code, the kernel we all use now would be less capable, less stable, and less portable than it is. When you see a proprietary module break, or (as in the case of the PWC driver) be withdrawn, what you are seeing is the risk which is inherent in the use of non-free modules, not irrational behavior on the part of the kernel developers.

Comments (65 posted)

Garage door openers survive appeal

Remember the Chamberlain v. Skylink case? It is a DMCA lawsuit filed by Chamberlain, which argued that Skylink, by virtue of having made remotes which interoperate with Chamberlain's garage door openers, had violated the anticircumvention provisions of the DMCA. That line of reasoning was rejected by the court one year ago, mostly because Chamberlain had not explicitly prohibited the use of competing remotes.

Now an appeals court has had its say; the ruling is available in PDF format. Skylink has won once again, and the appeals judge has drawn some lines around the behavior which the DMCA can control. The result is, perhaps, an improvement in the situation, but the basic nature of the DMCA remains unchanged.

The judge has ruled that circumvention is not, in itself, a crime; for the DMCA to apply, circumvention must be associated with an actual act of infringement. That was not the case in the Chamberlain case:

So, bypassing access control mechanisms to access a copyrighted work you have purchased is legal. Unfortunately, this ruling does not go as far as one might like: under U.S. law, moving copyrighted information from a disk into main memory is an act of copying, not just an access. So this language is unlikely to, for example, make the legal problems experienced by DeCSS go away.

In the end, here's the court's interpretation of when the anti-circumvention rule applies:

That is a tighter reading than we have seen before, but it still leaves things open. Code which can be used for circumvention of an access control mechanism can violate the law if it has "limited commercial significance." How long will it take for somebody to argue that code released under a free license cannot have commercial significance?

In the end, a defeat for a DMCA plaintiff is a good thing. But this case has not brought about the sort of change that many in the community would like to see. That kind of change, it seems, can only be made by the legislative branch.

Comments (6 posted)

A report from the SCO teleconference

SCO's quarterly earnings teleconference was held on August 31, with Darl McBride, president and CEO, and Bert Young, CFO, present for the call. SCO announced an "active and productive quarter" that "exceeded every bar we set last quarter". "Exceeding every bar" includes, it seems, a net loss of $7,423,000 with legal expenditures of $7.3 million. It's all a matter of where you set the bar.

SCO managed to drag in $678,000 in SCOsource licensing, though the company declined to specify the source or the nature of the income. It was indicated that the revenue was "primarily from two sources"; one of those is clearly EV1Servers.Net, while the other remains a mystery. Their UNIX products performed much better than their legal strategy, bringing in $8,929,000 in the quarter. McBride and Young spent very little time in the teleconference talking up their UNIX products, though McBride did announce a "major upgrade to OpenServer" called "Legend" due for 2005.

In addition to the company's third quarter results, SCO announced a "Shareholder Rights Plan" and a deal with their legal teams to cap legal expenses going forward. The company also reiterated the retirement of BayStar's 40,000 shares of A-1 preferred stock in exchange for $13 million in cash, and 2,105,263 shares of common stock in SCO.

The Shareholder Rights Plan is to "deter coercive takeover tactics", though McBride denied that the plan was put into place to counter any specific takeover attempts. McBride did admit to being "concerned" about the company's stock price. As of this writing, the company's stock is trading at $3.76 per share, a far cry from the high water mark of $22.29 per share. In any case, a large fraction of SCO stock is held by insiders, making a hostile takeover unlikely even without a poison-pill "rights plan."

The deal with Boies, Schiller & Flexner, if finalized, will limit SCO's legal costs to $31 million in costs, but will boost the firm's potential take should SCO manage to win its legal battles. McBride was sketchy on the details, but Boies, Schiller & Flexner will receive between 20 to 33 percent of the take of any award. SCO has already paid out just over $15 million in the past five quarters, according to Young, and will have $12 million left over after the $31 million is taken into account. There is some ambiguity over whether SCO has committed to paying Boies that much regardless of what happens; we will have to see the actual agreement to get an answer to that question.

Despite exceeding every bar they set for the third quarter, the company is still looking at downsizing. According to Young, the company has 230 people now and is looking at closing offices in the U.S. and overseas. Young did clarify that that the company is simply moving from larger offices to smaller offices in some areas.

Once again, the questions posed to SCO during the question and answer period were largely non-confrontational -- though one reporter did press McBride on SCO's legal strategy, and asked McBride whether SCO had bothered to get a "second opinion" to protect SCO's shareholders in the face of "a plethora of legal opinion counter to" SCO's own legal position. McBride's answer, of course, was that SCO had not. McBride also pointed out that many items before the court are under seal, and that the only parties able to fully size up the case are SCO, IBM and the judge.

SCO once again chose to not to allow a representative from LWN to ask a question during the call. While SCO told reporters that they would be limited to one question during the Q&A period, Maureen O'Gara was allowed to ramble though at least six questions and follow-ups during the call. SCO shut down the Q&A rather quickly, citing time constraints.

In stark contrast to previous teleconferences and interviews, McBride refrained from any rhetoric about "stolen" code or the GPL. He did, however, take make references to "IBM-sponsored" websites that have been questioning SCO's legal position. Unfortunately, none of the reporters who were allowed to ask questions pressed McBride on this allegation. Nor did any of the reporters use the occasion to ask specific questions about the filings or McBride's assertion that IBM has not delivered all materials as ordered by the judge in the case.

In all, the teleconference was fairly tame by SCO standards. For those interested in listening to the SCO conference call, there is an archive on SCO's web site.

Comments (1 posted)