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
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:
The fact is, Linux has been a hell of a lot more successful at
moving to things like x86-64 and ppc64 than Windows will _ever_
be. And the reason is open source drivers.
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,
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)
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
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:
The plain language of the statue [DMCA] therefore requires that a
plaintiff alleging circumvention (or trafficking) to prove that the
defendant's access was unauthorized -- a significant burden where,
as here, the copyright laws authorize consumers to use the copy of
Chamberlain's software embedded in the GDOs [garage door openers]
that they purchased. The premise underlying this initial
assignment of burden is that the copyright laws authorize members
of the public to access a work, but not to copy it.
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:
A plaintiff alleging a violation of § 1201(a)(2) must prove:
(1) ownership of a valid copyright on a work, (2)
effectively controlled by a technological measure, which has
been circumvented, (3) that third parties can now access,
(4) without authorization, in a manner that (5) infringes or
facilitates infringing a right protected by the Copyright
Act, because of a product that (6) the defendant either (i)
designed or produced primarily for circumvention; (ii) made
available despite only limited commercial significance other
than circumvention; or (iii) marketed for use in
circumvention of the controlling technological measure.
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
Comments (6 posted)
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.
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.
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)
Page editor: Jonathan Corbet
Next page: Security>>