The latest round in the battle for office document formats has
gone against Microsoft's Office Open XML (OOXML) submission. It certainly
won't be the last we hear about it, as there is another vote in February,
but it does, at least, slow down the fast-track proposal for making
the format an international standard. The process has been anything but
regular, with allegations of ballot box stuffing in Sweden and last minute
voting class changes by eleven countries. These kinds of shenanigans do
very little to enhance the reputation of the International Organization for
Standardization (ISO) nor do they promote confidence in their standards.
The vote, which closed 2 September, was made by members of the Joint
Technical Committee, Information Technology (JTC1). Each country which is
a member of ISO and wishes to join, can be either a Participating ("P") or
Observing ("O") member of the committee. In order to
pass, the proposal must get two-thirds support of the P members and no more
than one-quarter "no" votes amongst both P and O members. In both cases,
abstentions are removed before calculating the ratios.
The results, announced
on 4 September, were 53% "yes" votes by P members and 74% "yes" votes by P
members, which fails both tests, though either failing is all that is
required to defeat the measure. Many of the votes, on both sides, were
made "with comments". The comments specify portions of the OOXML spec that need
clarification or change before it can be ratified.
Those comments will be passed on to the Ecma International, sponsor of
the OOXML standardization proposal, to propose resolutions to
the comments. Ecma is also the organization that rubber-stamped OOXML as a
standard last year. They have until mid-January 2008 to submit the
proposed changes and the committee members have until the Ballot Resolution
Meeting (BRM) in late February to review and discuss them. Microsoft's
Brian Jones estimated there would be in
the neighborhood of 10,000 comments, many probably duplicates. How a
committee is supposed to analyze and handle that many resolutions, in a
week-long meeting, is unclear.
If enough of the "no" votes are satisfied that their comments have been
addressed at the meeting, they can change their votes to yes. If that vote
takes place, it will be the P members in February who get to vote.
It is quite possible that, similar to the run-up to this vote, O members
will suddenly decide to switch to P members. At this point, OOXML
proponents know roughly how many votes they need.
Andy Updegrove has been following the approval process closely in his
on eleven countries upgrading from O to P status in the two
weeks before the voting closed. Whether Microsoft is behind this sudden
interest by these countries can only be speculated upon, but nine of them
voted yes, one no, and one abstained. Regardless of why they felt the need
to jump into the voting at the last minute, it certainly seems
If the vote fails at the BRM, we still may not have seen the last of OOXML
as a proposed international standard. All of this effort has been to
"fast-track" the proposal. Ecma and Microsoft can still submit it for
approval under the regular, lengthier, standardization process. That could
easily take several years, which is why there is a big push to fast-track it.
OOXML is a complicated, 6000+ page specification, requiring a great deal of
study and consideration before a sensible decision on it can be made. By
upgrading at the last minute, it certainly appears that some of that review
may have been skipped. If a country was interested in
the process and wanted to have more input, it seems that they might have
found time to do it in the nine months of review. If it is going to be an
international standard, it should, at least, be a well scrutinized standard.
Predictably, Microsoft is proclaiming
the voting result as a victory, of sorts, just a step along the way to
ISO acceptance. In the Microsoft view, the no voters will reverse course
"once their comments are resolved." Their confidence is palpable and, to
opponents, galling. There is some indication that the pressure applied to
national bodies resulted
in a backlash, with at least one switching to a no vote because of it.
It will certainly be interesting to see how some of the comments will be
Microsoft has admitted that an employee offered "marketing assistance" to
offset the $2500 entrance fee for Swedish companies to join their national
voting committee. More than twenty showed up, just before the vote, to vote
yes. Eventually, the vote was thrown out, not because of the blatant
ballot-box stuffing, but because somehow one company voted twice. Sweden
ended up abstaining, which was a win for OOXML, as it clearly would have
been a no vote otherwise.
Microsoft has made various noises about the "inadequacies" of the Open
Document Format (ODF) standard – ISO passed it with so few comments
that a BRM was not required – and there is some truth buried deeply
in the rhetoric. The proper response is not to propose another
standard, but to improve the one that exists. ODF is implemented by
multiple projects, with open source reference implementations. It is
very unlikely that anyone, other than Microsoft, will be able to fully
It's also not clear that anyone should want to implement OOXML
as international standard. Besides being complex, the proposed standard
contradicts other ISO standards. It also has the kind of bug-for-bug
compatibility that is one of Microsoft's calling cards. An international
standard should not have to implement a sloppy collection of bugs and
compatibility hacks. It should be noted that OOXML contains some very
important features – some not available in ODF – but that does
not make it a good standard. It should not be adopted just to appease the
world's largest software maker.
Microsoft is behaving like
a company that is terrified of losing their near-monopoly in the office
software market. If they, instead, embraced the standard – leaving
behind extend and extinguish – and competed on
the feature set of their office suite, their much touted "innovation" could
shine. Unfortunately, for anyone with a historical perspective on Microsoft's
tactics, this OOXML standardization move looks like the first act of some
kind of customer lock-in scheme.
There will be close scrutiny on the participants between now and the vote in
February. Hopefully, we will see no more gaming of the standards process,
by anyone; the committee will judge the resolutions on their technical
merit, coming to a sensible decision. From what we have seen so far, that
seems unlikely, but one can hope.
Comments (11 posted)
The ath5k driver has been through more than the usual amount of legal
trouble. This driver, for Atheros wireless chipsets, was originally
reverse engineered and developed in the BSD community. It was reputed by
have been improperly
copied from proprietary Atheros code, requiring two different studies by
the Software Freedom Legal Center before Linux developers were willing to
believe that it was safe to use. This driver should be the cause of great
joy - it will make it possible for vast numbers of laptop owners to run
Linux with free drivers for the first time. But, first, there would appear
to be one more set of legal hassles to overcome.
The latest trouble started when wireless developer Jiri Slaby posted a patch which stripped the
ISC and BSD license notices from the source,
replacing them with GPLv2 license text. It should be noted that this patch
was not accepted into any repository anywhere and never became part of any
exported Linux kernel tree. Nonetheless the BSD community exploded in a
very public way. It is interesting to compare their public response to
this posting with the sort of response they very loudly insisted was their
due when they were found to have carried improperly relicensed GPL code
in their repository for some time. That notwithstanding, it is worth
taking the time to look at what has happened here.
The situation this time around is an interesting one. Much of the affected
code was written by Reyk Floeter for OpenBSD and explicitly placed by him
under a BSD-style license. The patch posted by Jiri Slaby stripped his
license text; it was thus a clear violation of Reyk's license (which
requires that the license text be preserved)
and the wrong thing to do. This patch was never applied, and it will not
be. There is no interest in the kernel community in violating anybody's
Much of the code, however, had been written earlier by Sam Leffler. He had
used the BSD license, but had also included this text:
Alternatively, this software may be distributed under the terms of
the GNU General Public License ("GPL") version 2 as published by
the Free Software Foundation.
So, when this code was relicensed under GPLv2, that act was clearly carried
out with the permission of the copyright holder. Mr. Leffler has since confirmed that this act was, by his intent,
explicitly allowed. Nobody can complain about the legality of this
This did not stop OpenBSD leader Theo de Raadt from condemning the relicensing and calling it
It may seem that the licenses let one _distribute_ it under either
license, but this interpretation of the license is false -- it is
still illegal to break up, cut up, or modify someone else's legal
document, and, it cannot be replaced by another license because it
may not be removed. Hence, a dual licensed file always remains
dual licensed, every time it is distributed.
How to square this statement with the clear notice saying that the
code may be distributed under either license is left as an exercise for the
reader. By this interpretation the BSD license becomes rather more viral
than the GPL; it cannot be removed even when the copyright notice says
otherwise. The BSD people are fine with their code being locked up and
proprietary, but it would seem that a GPLv2 relicensing, even when
explicitly allowed by the copyright owner, is a different matter entirely.
The situation has since been resolved with this patch, which was prepared
with the help of the Software Freedom Law Center. It is, perhaps, the only
kernel patch ever to have been signed off by Bradley Kuhn. All of the
required copyright attributions are now in place, and BSD-licensed code
retains that license. Some of the additions made by Linux developers,
however, remain under GPLv2, making the ath5k module, as a whole, a
This solution should keep the lawyers happy, but certain members of the BSD
community remain unimpressed. Quoting Theo de
When companies have taken our wireless device drivers, many many of
them have given changes and fixes back. Some maybe didn't, but
that is OK.
When Linux took our changes back, they immediately locked the door
against changes moving back, by putting a GPL license on guard.
Why does our brother Linux take a file that is 90% BSD licensed,
and refuse to let us see the 10% he adds?
It is a rare day in which Theo declares brotherhood with the Linux
community. It may be tempting to dismiss this statement entirely, but, still,
there is a point here. This code was obtained from developers who
placed it under the BSD license; it was not written in the Linux community.
There is something to be said for keeping it under a permissive license so
that ongoing development can be shared between the Linux and BSD
communities. Maintaining the license would be a neighborly (or even
brotherly) thing to do, but it could also have immediate benefits in the
form of shared maintenance and good will going forward.
In the end, distributing versions of the ath5k driver under GPLv2 (with the
requisite copyright attributions maintained) is something which the Linux
community is entitled to do. Anybody who does not like more restrictive
conditions being applied to BSD-licensed code is well advised to avoid
using the BSD license to begin with. But the legal ability to do something
does not make that something the right course of action. Only the
developers who have worked on the ath5k driver have the right to decide
which license they will use, but it's worth saying that allowing the BSD
community to make use of work done on the ath5k driver would be a friendly
gesture and an acknowledgment of the value of the code we got from them.
The benefits from such an act would likely outweigh any cost
associated with allowing unwanted proprietary use of the code which has
been added to this driver.
Comments (75 posted)
Enterprise distributions are an important part of the economic success
story of Linux. The creation of highly stable, highly supported
distributions has brought significant revenue streams to some distributors
and enabled the deployment of Linux into many "mission critical"
situations. Enterprise distributions encourage the commercial world to
take Linux seriously. At LinuxConf Europe, however, your editor has
stumbled into a few conversations which characterized enterprise
distributions as one of the bigger problems the development community has
now. Then a talk by Dirk Hohndel made that point again in a different
Dirk's talk was on how to get hardware vendors to support Linux. He knows
what he is talking about: as the Linux CTO at Intel, Dirk is charged with,
among other things, implementing Intel's commitment to provide free drivers
for all of its hardware. His core point is that hardware vendors
understand money better than anything else; getting them to support Linux
will require showing them that it is in their economic interest to do so.
To that end, he praised how Dell has taken care to put together hardware
which is entirely supportable with free drivers to ship with Ubuntu
pre-loaded. That sort of decision will quickly get the attention of the
There were some suggestions on what to tell hardware vendors who are
thinking about adding open source support for their products. Development
in the open is crucial; drivers should be released early and made available
for the community to work with. Intel did this with some of its early
network drivers; the resulting level of interest and community
participation exceeded all expectations. Vendors need to understand that
they cannot design software just for their device, that they need to think
bigger. This is a hard message for vendors to hear, but, in the long run,
they benefit from a better kernel which will be better suited to their
needs in the future.
It is important that software support be available immediately when
the hardware is made available. If there is no driver for several months
after the hardware release, competitors will have had time to get their
answering products to market before Linux users can use the original
product. That sort of time lag is forever in the hardware world.
Vendors also need to continue to maintain their code after it gets into the
mainline; there is nobody else who can ensure that it continues to work on
all versions of the hardware.
One thing that the community could do to help would be to improve the tone
of the discussion on our mailing lists. That tone is often quite hostile;
it does not create a friendly environment for engineers working for
hardware vendors who want to engage with the community.
There is another place where life gets difficult for hardware vendors,
though; this is where the enterprise distributors come in. When Intel
releases a driver for a new product, that driver goes into the mainline
kernel. But the release cycle implemented by the enterprise distributors
will not pick up that driver for as much as two years after it gets into
the mainline. So enterprise customers are not able to make use of that
hardware for a long time after its release, even though the driver is
Intel has competitors which will never release free drivers for their
hardware. But they do put out closed-source modules for the
enterprise distributions. So their customers are able to use that hardware
from the outset.
In other words, Intel is being punished for playing by the rules and
releasing their drivers to the community. This is exactly the wrong sort
of incentive to create for hardware vendors. If they conclude that they
will do better by just shipping binary-only modules, that is the course
they will take.
Dirk's complaint echoes other conversations your editor has heard in the
last few days. The development community has been very insistent in its
message that code should be merged upstream, and that this merge should
happen early. In the kernel area, the development cycle has been shortened
to the point that changes find their way into a stable release after a
maximum of a few months. But the enterprise distributions, by freezing
kernels for years at a time, are pushing us back to the old, multi-year
development cycle and sending a very different message to vendors.
The discussion of enterprise distributor policies is not new; see this article from last June for
a previous installment. But this discussion appears to be reaching a new
level of urgency, with some developers calling enterprise distributions one
of the biggest problems the community is facing today. There is a
fundamental conflict between the fast-moving development community and the
sort of stasis that the enterprise distributions try to create. This
conflict becomes especially acute when customers want the best of both
worlds: no changes combined with fast-moving development and support for
There are no easy solutions in sight. The enterprise distributions may be
forcing a model from the proprietary software world on Linux, but there are
reasons for the creation of that model in the first place. The kernel
development community has gotten quite good at integrating vast numbers of
changes while still producing a stable result, but any software which has
recently seen significant changes will occasionally produce unwelcome
surprises when dropped into a production environment. Slowing the rate of
development is not an option, and it should be noted that the enterprise
distributors are at the top of the list of companies which are setting the
pace. Getting around this problem is going to be a challenge - but this
community is good at facing challenges.
Comments (33 posted)
The reader survey back in
February provided lots of interesting feedback, from the responses as well
as the comments. We have been slowly implementing some of the suggestions
and we are not finished yet. Some of the comments indicated that more
advertising would be tolerated, perhaps even encouraged. With that in mind, we
have been exploring more options in that area.
We are very aware of the fine line that must be walked here. The last
thing we (or our advertisers) want to do is to annoy our loyal readers, so we
are proceeding cautiously.
The latest advertising technique we are trying is "in-text advertising".
The idea is to serve ads that are relevant to keywords in an article by
highlighting those words and popping up an ad when a reader rolls over the
word with their mouse.
We have also added the ability of subscribers – at any level –
to choose whether they see them or not. Our "project leader" subscribers
have long had the ability to turn off all advertising via the customization
options behind the "My Account" link. For in-text advertising, we
defaulted the option to "off"; subscribers can alter that if they wish and
"project leaders" can control those ads independently of other
will not see the ads.
These new ads were just added late last week, and we are still fine tuning,
but we hope it is a relatively painless way to bring in some needed revenue
without filling every square inch of the site with ads. We will be looking
at other advertising options in the near term as well, with an eye towards
maintaining a reasonable balance. As always, we are very interested in the
thoughts of our readers, either via a comment below or email to lwn-AT-lwn.net.
While we are on the subject, please keep the LWN text ads in
mind for a very cost effective means of reaching LWN readers. If you, or
someone you know, is trying to get the word out about a product, service,
job, or project, the text ad box has a prominent place on roughly half of
We are always open
to hearing other advertising options, feel free to contact us at
sales-AT-lwn.net to discuss.
Comments (137 posted)
Page editor: Jake Edge
Next page: Security>>