LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
Letters to the editor
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for September 4, 2003A quick look at Conglomerate 0.70The DocBook format is often promoted as the format of choice for free (and non-free) documentation. DocBook, as an SGML and XML standard, is compliant with as many buzzwords as anybody could wish for. The standard is well developed and highly expressive. And DocBook, of course, is all about structure. More, perhaps, than any other markup language, DocBook forces the author to concentrate on the structure of the language without thinking about how a document will be rendered in any particular medium.Anybody who has had to create a serious work in full frontal DocBook knows the rest of the story, however. DocBook is complex and verbose. Like PostScript, DocBook requires that the author maintain a deep stack in mind to track the current state of the document. And, like PostScript, DocBook is best used as the output of a higher-level tool, rather than created directly by the author. Unfortunately, given the current state of the tools available, manipulating DocBook directly with a text editor is often the only option available. So your editor, who is currently in the process of updating a substantial book which is, of course, in DocBook format, was more than usually interested in the recent announcement that Conglomerate 0.70 had been released. As stated in the announcement:
Congomerate is a free, user-friendly XML editor. It is
particularly aimed at DocBook editing, but should be able to handle
arbitrary XML document types.
For authors working in DocBook, a nice editor would be worth a great deal. So Conglomerate seemed worth checking out. The first challenge with bleeding-edge software, of course, is getting it installed and running. For Conglomerate, an attempted install on Debian sid proved doomed to failure; the maze of dependencies proved too twisted, and the packaged version in experimental had not been updated. On the other hand, version 0.70 configured, built, and installed on a Red Hat Linux 9 system without trouble. There are advantages to having a variety of distributions sitting around.
What resulted was a tool that shows some serious promise, but which is not
yet ready for production use. The sample text used (Chapter Two of
Linux Device Drivers, Third Edition) required significant editing
(with a text editor) before Conglomerate would accept it. Conglomerate
does not recognize common entities (e.g. –), and there
are differences of opinion on how certain types of tag (such as
<indexterm>) should be terminated in some situations. The
tool spews out an unending series of Gtk warnings, crashes occasionally,
True to the basic premise of DocBook, Conglomerate is all about structure. Looking at a document in DocBook will not tell you much about how it will appear in printed (or web) form, but it is full of information on how the document goes together. To that end, the window (see the screen shot on the right) is divided into two panes. The left side shows the overall structure of the document, in the usual tree presentation. The main window, on the right, shows the text. But this is no WYSIWYG presentation; instead, the document is presented as a set of nested boxes showing, once again, how things are structured. Subtrees of the document can be expanded or hidden at will, providing a sort of zoom feature.
There is no shortage of features that this tool still needs: undo, an easy way to join paragraphs, the ability to read and fix not-quite-perfect files, entity definitions, and some sort of way to quickly see what formatted output would look like. The performance and stability issues need some work. But none of this should detract from the fact that the Conglomerate developers have made substantial progress toward the creation of a desperately needed tool. Conglomerate is headed in the right direction; we're looking forward to the next release.
European software patent vote delayedLast week we reported on the impending software patent vote in the European Parliament. That vote, set for September 1, did not happen as scheduled. Thanks, at least in part, to protests in various forms, the vote has been pushed back to the September 22 Strasbourg session.What remains unclear is what will be voted on at that time. By some reports, the entire software patent proposal has been pushed back for a rewrite before the vote. By others, it is a simple delay, and the same proposal will be voted upon in Strasbourg. Real information, however, seems hard to come by. Either way, now is not the time to let up the pressure on software patents. The next few weeks should be used, by Europeans, to make sure their MEPs understand how they feel about software patents and the threats patents pose to European businesses. The "software patent factsheet" being distributed by MEP Arlene McCarthy should be challenged. It is also necessary to provide a counter to the pro-patent forces, which are evidently pressing for a removal of the interoperability exemption in the proposed law. This battle, perhaps, can be won - but it is not over yet.
Software Customer Bill of Rights[This article was contributed by Joe 'Zonker' Brockmeier] In the last week or so, Cem Kaner's Software Customer Bill of Rights has been making the rounds of the "blogosphere" and getting quite a bit of attention. Essentially, Kaner proposes ten basic rights that should be enjoyed by any user of commericial software. As End User License Agreements (EULAs) have become increasingly onerous over the last few years, Kaner's bill of rights has struck a chord with users. For the most part, the rights proposed by Kaner are already enjoyed by users of open source software. They already have the right to transfer free software to other users. They don't need to reverse engineer the software to check for security holes or to fix bugs and security glitches -- they already have the source code. (Nothing in any open source license would prevent a user from choosing to do it the hard way, however.) Kaner proposes that users should have the "right to see and approve all transfers of information from her computer." While "spyware" is a constant danger posed by proprietary software, with access to source code, users can make sure that a program isn't secretly sending data off of their computer to another machine. However, there are a few rights that would benefit users of open source software. Firstly, the unfettered right to reverse-engineer proprietary software would be a major boon to the open source software community. As Kaner points out, courts have been willing to enforce clauses against reverse-engineering in software licenses. This poses a problem for open source developers looking to achieve interoperability with commercial software, operate embedded devices with open source software or simply a way to access data saved in a proprietary format. Another right that Kaner proposes is "mass-market software should be transferrable." As mentioned previously, users already enjoy the right to transfer software that is licensed under a FOSS license. However, most users of open source software still end up dealing with proprietary software. How many open source users have purchased a laptop or desktop computer with software preinstalled that will never be use by the purchaser? The cost of a Windows XP license is built into the price of a brand-new machine. The user should have the right to transfer that software to another user who will make use of the software, if we so choose. The first item on Kaner's list, however, is "let the customer see the contract before the sale." This is particularly timely in light of Dell's hidden license policy. Even some of the Linux vendors have started using the "clickthrough" mechanism, with some of the Linux installers requiring the user to agree to the terms of the open source licenses, without allowing the user to read them first. This is probably done because of the number of licenses involved -- most distributions include software under the GNU General Public License (GPL), Lesser GPL, Artistic License, Apache License, Mozilla License, BSD License and so on. One potentially dangerous clause in Kaner's bill of rights is number ten, "When software is embedded in a product, the law governing the product should govern the software." Generally, this would be a good thing. A hardware manufacturer should not be able to use licensing terms to forbid the transfer of a router or network appliance by forbidding the transfer of embedded software. Car manufacturers shouldn't be able to exclude embedded software from warranties. However, one wonders if this might make open source developers liable in some way if their software is "embedded" in a product. Most, if not all, FOSS licenses disclaim any warranty because the software is being given away. What happens, however, if a court decides that embedded software qualifies as "goods" and that developers can be held liable for defects -- even if they have not charged for the software in the first place? This may seem like a stretch, but we do live in a very litigious society. Kaner's proposed rights would be a dramatic improvement for users of proprietary software, but they leave out many rights that FOSS users take for granted. For example, users of FOSS software expect to have access to source code. They also expect to be able to modify the software, to add or remove features that they deem necessary or desirable, and to be able to distribute the changes. Despite the fact that the Software Customer Bill of Rights doesn't quite match the average FOSS license in terms of customer rights, it would be good to see it become reality. It's time to start reversing the current legislative trends that have given far too much power, and too little accountability, to vendors of proprietary software.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||
![[Screenshot]](/images/ns/conglomerate/current-sm.gif)
![[menu entry]](/images/ns/conglomerate/menu-entry.gif)
![[literal]](/images/ns/conglomerate/literal.gif){kind=small}
markup. So, for example, rather than italicizing text marked
<literal>, it simply indicates that the tag is present.
The tool displays internal comments in a highlighted form, but does not
appear to provide a way to add or edit comments.