The debate continues over whether Linux,
in any of its flavors, is ready for the desktop. If you’re an
Average Joe (like me), the answer is probably “No.” If
you’re much more technical or if your last name ends with the
qualifer “Ph.D.”, the answer may be “Yes.”
Why the disparity? Each constituency expects something very
different from the desktop.
Certainly, the graphical user interface has made my computing
life far easier. I eschew command-line instructions (ever since I
was forced to give up WordPerfect in favor
of Word in my law practice in the
mid-1990s), and my natural inclination is to look at those features
that are necessary to make the average user’s life on Linux
tolerable. However, many of the most requested and most needed
features — including WiFi, multimedia, proprietary drivers,
document formats, and fonts — are stagnating due to legal
reasons.
Let’s explore why.
(The dearth of common desktop applications on Linux is a
separate issue and one not immediately related to law, unless you
dive deeply into competition law. But that’s best left for
another time.)
WiFi Woes
There’s no question that the lack of an open source WiFi
solution causes headaches for the Linux desktop.
WiFi drivers are typically provided by chip manufacturers, such
as Intel and AMD. At present, the drivers are closed source, either
in whole or in significant part. Intel, for one, has expressed a
willingness to find a solution for this problem, but government
regulation is proving to be a key drag. More specifically,
Federal Communications Commission Part-15
Rules, which apply to wireless devices, requires:
Except as follows, an intentional or
unintentional radiator must be constructed such that the
adjustments of any control that is readily accessible by or
intended to be accessible to the user will not cause operation of
the device in violation of the regulations. (See I47 CFR
§15.15.b.)
(This same sort of notion is also encompassed in FCC rules
governing software-defined radios.) Now nothing in these statements
expressly prohibits open source implementations of such controls,
but such a requirement strikes fear in the hearts of the device
manufacturers’ attorneys. Counsel is concerned that
implementing such controls in open source code, thus permitting
users the ability to make adjustments that may cause operation of
the device in violation of the regulations, will make vendors
liable for violation of the regulations.
Quite frankly, that’s not an unreasonable position.
A group coordinated by the Open Source Development Labs is
working to better define how this issue may be resolved. Could it
be as simple as getting the FCC to affirmatively state that a
control implemented in open source does not violate the regulation?
What about other countries where this same issue arises? To be a
part of that discussion, visit
"http://lists.tuxdriver.org/mailman/listinfo/reg-legal" class=
"story_link">http://lists.tuxdriver.org/mailman/listinfo/reg-legal.
Multimedia Malaise
Multimedia is highly dependent on compression/decompression
technologies (codecs), most of which are patented. Patents make a
pure, open source play difficult, unless content providers embrace
the OGG format. (I’m not holding my
breath.)
Will GNU Public License Version 3 (GPLv3)
provide an answer? The Apache License? The Mozilla
License? Fluendo (
"story_link">http://www.fluendo.com/) has clearly made some
progress here, but unless an open source media player can be
matched to the codecs, most of which are proprietary, the lack of
media playback will continue to be a significant shortcoming of
Linux. Needless to say, there are many challenging patent issues
here.
Proprietary Drivers Dilemmas
There’s been a long-running debate regarding video drivers
and the fact that the drivers are proprietary. While the open
source community has persuaded some hardware and board
manufacturers to open source particular drivers, the fact of life
is that many of the popular (and, some would argue, necessary)
device drivers aren’t open.
The question then becomes whether you take half a loaf and try
to win the other half in time, or whether you ship what many would
consider an incomplete desktop. Clearly Eric Raymond has weighed in
on this issue in favor of proprietary driver tolerance, but I have
no doubt that the Free Software Foundation feels just as strongly
that the battle will be sooner won by holding the line. What is
interesting is that this would, to a large extent, be a simpler
issue if it simply involved patents rather than code
disclosure.
Fighting for Open Document Formats
The Open Document Format (ODF) Alliance continues to make
headway on an international scale in its attempts to convince
businesses and governments alike to take control of their own
documents. Microsoft has attempted to neutralize this issue by the
promotion of its own, so-called OpenXML
standard and by promising to interoperate with ODF. However, what
you’ve not heard Microsoft express is a willingness to open
its historical document formats —
"i">.doc,.xls, and .ppt, — so
content stored in those formats can be redisplayed by alternative
offices suites with full fidelity.
As it happened when Microsoft seized word processing dominance
from WordPerfect, end-users need the assurance that historical
documents can be redisplayed in perpetuity without a loss of
formatting. Microsoft will likely do this of its own accord when
such conversion is meaningless — that is when
"i">Vista and the new, (highly-modified) OpenXML formats are
the dominant platform. In the meantime, it will likely be
government competition authorities that press for this change.
Finicky Fonts
One last little point of control that Microsoft has over the
desktop is the ubiquity of its most commonly used proprietary
fonts, Times New Roman, Arial, and
Courier New. Several years ago Microsoft
ceased making these fonts available for free download, thus further
reducing the potential of an open alternative. This is particularly
problematic because most of the same documents stored in
Microsoft’s proprietary document formats are also stored in
one of these proprietary fonts.
This problem, however, is solvable. It is conceivable that
metrically equivalent fonts, or fonts that are rendered with the
identical spacing of the Microsoft fonts, could be produced. Thus,
a line of text in Times New Roman would render exactly the same in
the metrically equivalent font. This is necessary for full document
fidelity.
These are just a few of the barriers to desktop Linux. While not
insurmountable, solving these issues will require innovation,
compromise, and widespread support. Without such a foothold, the
Linux desktop is bound to falter.
Loading ...
