LWN.net Weekly Edition for September 6, 2007

OOXML loses a battle

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 and O 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 Standards Blog and reported 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 fishy.

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 "resolved."

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 implement OOXML.

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)

Relicensing: what's legal and what's right

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 some to 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 license.

Much of the code, however, had been written earlier by Sam Leffler. He had used the BSD license, but had also included this text:

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 particular change.

This did not stop OpenBSD leader Theo de Raadt from condemning the relicensing and calling it illegal:

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 made completely 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 GPLv2-only product.

This solution should keep the lawyers happy, but certain members of the BSD community remain unimpressed. Quoting Theo de Raadt again:

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)

LCE: Linux, hardware vendors, and enterprise distributors

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 context.

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 relevant vendors.

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 available.

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 current hardware.

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)

LWN advertising update

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 advertising. As with Google ads, those running with Javascript disabled 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 our pageviews. We are always open to hearing other advertising options, feel free to contact us at sales-AT-lwn.net to discuss.

Comments (136 posted)

Page editor: Jake Edge

Security

Software liability laws: a dangerous solution

The readers of LWN do not need to be reminded that the software industry as a whole has a big problem with computer security. One proposal aims to redress this state of affairs: the concept of legislation designed to create financial liability for the vendors of buggy software. This idea is applauded by many such as Bruce Schneier, author of the famous book Applied Cryptography. But despite the support of notable authors, software liability laws are themselves a dangerous liability to the software industry.

One can readily find sympathy in the potential impact of software liability laws on developers of free and open-source software. Many of these developers are working on a volunteer basis, and holding them financially liable for the code they write and release freely could have a chilling effect on the development of free software. Of course, liability laws might be written to exclude programs given away for free, or they might concern themselves with vendors and leave individual developers out of the picture.

Unfortunately, the dangers of software liability laws don't subside when individual developers are granted immunity. One of our community's most prominent projects, the Linux kernel, was never intended to grow off the 386 but is now found running everything from stock markets to supercomputers and military gear. This ubiquity brings demand for services, support, and a single throat to choke, which is the bread and butter of Red Hat and other businesses. When a vendor is selling free software, and we make the vendor financially liable for bugs in the code it is selling but did not write, we risk significant disruption to our cherished development models.

Further complications arise when we imagine possible liability lawsuits. In the event of a security breach, directing blame and assigning liability can be problematic. Picture a system that runs Oracle on top of Red Hat Enterprise Linux, and imagine that the Oracle database is breached due to a bug in glibc. Does the buck stop with Oracle, Red Hat, or both? What if Novell provided the operating system, but the glibc developer who introduced the bug responsible for the breach is paid by Red Hat? An attorney might decide to sue all three parties, especially if it is unclear which component was vulnerable.

Consider also that virtually all software developers attach disclaimers of warranty to their products. These disclaimers are nearly ubiquitous in free software licenses, and are even found attached to some public domain declarations. For software liability laws to have teeth, these disclaimers must be nullified. But when dealing with software designed to address a broad range of users, one must carefully select use cases in which default warranties apply. There is a big difference between a database full of blog postings, a database full of credit card numbers and a database full of top secret government intelligence.

We must also recognize the differences in the types of failures under which warranty is considered appropriate. Ford Police Interceptors had a reputation for exploding when they were rear-ended. Ford also suffered a blow to its reputation, along with tire manufacturer Firestone, when tires on Ford Explorer vehicles were found to spontaneously fail. In both of these cases, the loss of human life was not the result of a willful human actor but was caused instead by spontaneous failure under expected operating conditions. By sharp contrast, software security breaches generally don't endanger life or limb, and successful exploits are not accidents but are rather the result of willful attack.

The difference between accidental and intentional failure is an important one. Because the laws of physics and the nature of accidents do not change, we can expect auto manufacturers to build reliable gas tanks and tires. But in computer security, attackers discover new techniques each and every year. The equation for software is always on the move.

At this point, advocates of software liability laws still hoping to sell their wares need to choose their words carefully, and so they plead for a standard based on best practice. But who defines best practice in an industry that is changing so fast? The pioneers of the Internet didn't predict many of the problems we're facing today, yet few would call them negligent. Real "best practice" is a moving target that is carried by the tides of the times, and in the world of technology, the waves are a mile tall and move thousands of miles per hour.

These and other questions must be addressed if software liability laws are to succeed. Unfortunately, legislators are notoriously bad at understanding and regulating technology. Observers of SCO v. IBM surely agree that court cases are long, complicated and costly. Those with faith in any branch of government to appropriately legislate technology should reexamine the Digital Millennium Copyright Act, a law that continues to have a chilling effect on free software development, and Universal v. Reimerdes, the case in which 2600 Magazine's publication of DeCSS was suppressed.

Security is, of course, a problem, and the case can be made that someone must be held liable. We prosecute the criminals who breach computer security, but if we're going to put burden on anyone else, we should choose the companies that leak personal information to these criminals when their security fails. In some ways, these companies might be held liable today, but we would do well to consider tightening down the screws. By increasing the burden on these data aggregators, the demand for secure software will increase. This gives the best solutions that engineers produce a market advantage, and financially rewards security-conscious vendors. This approach to liability also addresses the need for best practices and defense in depth when implementing and maintaining networks and databases. By concentrating liability in this way, we eliminate the complications that result from playing the blame game with a group of software vendors. Whose security was breached is a much easier question to litigate than how it was done and how it might have been stopped.

As Schneier has pointed out, companies tend to convert variable cost liabilities into fixed cost insurance plans. Insurers have a financial incentive to excel at evaluating risk, and it isn't inconceivable that they might view the use of open code their experts can review a reason to offer lower premiums. Furthermore, putting liability on data aggregators allows those organizations to make choices on how much insurance they are willing to buy. A technologically sound small business might adopt best practices and spend less on insurance, or they might decide to skip out on insurance entirely. But if insurance were expensive and the danger of a security breach was still unacceptable, they might reconsider the practice of permanently storing large amounts of customer data, something that their customers tend to consider an invasion of their privacy anyway.

Software code is quite complex, but we can write all kinds of new and useful software because it is intangible and cheap to produce. Placing liability on software vendors threatens to dramatically change this landscape. We can expect to see reduced participation, hampered innovation, and skyrocketing costs. We should carefully consider whether perfect security is a goal or an expectation, and educate users on the need for compartmentalization, defense in depth, patching, and best practices in their networks. If we approach the issue in this way, we can improve security overall with minimal risk to the efficiency of the software industry.

Comments (32 posted)

New vulnerabilities

aide: checksum errors

Comments (none posted)

clamav: multiple vulnerabilities

Comments (none posted)

fetchmail: denial of service

Comments (none posted)

gallery2: multiple unspecified vulnerabilities

Comments (none posted)

kernel: denial of service

Comments (none posted)

krb5: buffer overflow, uninitialized pointer

Comments (none posted)

mapserver: multiple cross-site scripting vulnerabilities

Comments (none posted)

postfix-policyd: arbitrary code execution

Comments (none posted)

tcp-wrappers: unauthorized access

Comments (none posted)

vavoom: multiple vulnerabilities

Comments (none posted)

Updated vulnerabilities

apache2: information disclosure

Comments (2 posted)

apache: multiple vulnerabilities

Comments (1 posted)

apache: cross-site scripting

Comments (none posted)

avahi: denial of service

Comments (none posted)

bochs: buffer overflow

Comments (none posted)

bugzilla: several vulnerabilities

Comments (1 posted)

centericq: buffer overflows

Comments (none posted)

clamav: denial of service

Comments (none posted)

cups: denial of service

Comments (none posted)

gpdf: integer overflow

Comments (1 posted)

Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service

Comments (none posted)

dovecot: privilege escalation

Comments (none posted)

dovecot: directory traversal

Comments (none posted)

emacs21: denial of service

Comments (none posted)

evolution: format string error

Comments (1 posted)

evolution-data-server: malicious server arbitrary code execution

Comments (1 posted)

file: integer overflow

Comments (3 posted)

firebird: buffer overflow

Comments (none posted)

firefox: multiple vulnerabilities

Comments (none posted)

firefox: multiple vulnerabilities

Comments (3 posted)

firefox, thunderbird, seamonkey: multiple vulnerabilities

Comments (none posted)

flac123: arbitrary code execution

Comments (none posted)

freetype: integer overflows

Comments (none posted)

gcc: file overwrite vulnerability