podlators is the Perl distribution providing Pod::Man and Pod::Text, along with related modules and supporting scripts. The primary change in this release is the addition of configurable guesswork for Pod::Text, paralleling Pod::Man. I had forgotten that Pod::Text also had complex heuristics for whether to quote C<> text that have the same Perl-specific properties as Pod::Man. This is now configurable via a guesswork option, the same as in Pod::Man, although the only type of guesswork supported is quoting. I also updated the default regexes, which include some fixes from Pod::Man. Thanks to discussion with G. Branden Robinson, I now understand quoting in roff considerably better, which let me fix a few obscure bugs with strange page titles or configured quote characters. Pod::Man now avoids quoting macro arguments when the quoting is unnecessary, which should hopefully produce slightly more readable output. Finally, I had started using a Pod::Simple feature introduced in 3.26 in Pod::Text but forgot to update the dependency, resulting in test failures on some old versions of Perl. (The same tests didn't fail in GitHub CI, which is probably related to how I install dependencies.) That's been fixed in this release. You can get the latest version from CPAN or from the podlators distribution page.

I was in a multiple-car accident yesterday. I've been having to tell this story a fair amount in person and on IRC, so I thought I'd blog about it. Short version: it was a fender-bender. I'm doing fine, nobody was hurt, Michelle wasn't in the car, and 75% of the cars involved were driven away from the scene — including mine, by me. Want the long version? Well, I'm gonna tell it anyway. I had just pulled to a stop at a traffic light, heading northbound on Keystone Avenue where it intersects 106th Street, in Hamilton County. The line of cars at the light was pretty long, and people love to try hauling ass on the stretch between 96th Street and 106th. Apparently the person behind me was one of them. The line of cars stopped in the left lane (where I was) at the light was pretty long, and much shorter in the right — the cars over there were still moving at a good clip. I looked in my rearview mirror, thinking "if someone's trying to match pace with the cars in the right-hand lane, they're gonna need to brake pretty hard to stop." It was about 1815, so it was starting to get dark. A pair of headlights approach. Fast. Oh boy. I don't stop right up on people's tails, so if I'm hit, hopefully I won't go into the car ahead. I look forward again. Yeah, there's some room here. Screech. I didn't tense up; I felt a strange sense of calm and curiosity, as I'd never been in a car accident before. I bought my car, a Volkswagen Golf, in part because of its fairly good safety ratings. It has lots of air bags, and I always use a seat belt. Plus, in this instance I figured I wouldn't get hit a high speed. "Strange Deja Vu" by Dream Theater, from the Scenes from a Memory CD, was playing. Normally I listen to All Things Considered while commuting home, but I was annoyed because when I got in the car, I heard Nina Totenberg signing off a report, which means I'd just missed some Supreme Court coverage. Damn. Anyway. BONK. I got hit. Ouch. My teeth had chomped together too hard. Maybe they should install rubber mouthpieces in the doors of cars so you can grab them right before a crash. You know, car crashes never sound like the stock sound effects that have been around for about 50 years. I guess that's because they build cars to crumple these days instead of act like steel shrapnel bombs. Damn that Ralph Nader. My wreck doesn't sound cool and stuff. And I get to walk away, well, get back in the car and drive away, instead of my wife collecting on my life insurance policy. But I digress again. A middle-aged woman in a Honda Civic skidded into me, and knocked me into the Buick Park Avenue ahead of me, which in turn tapped the minivan ahead of him. I blinked a bit and tried to reorient myself, and then turned off the CD player. We all got out of our cars. The woman in back was very distressed, and immediately and repeatedly said the thing your insurance card tells you never to say after an accident. Oh well. Being a middle-aged woman, she'd probably have to wreck a school bus full of children — twice — before her premium would go up. Mine, on the other hand — we'll see. Called 911. Reported the incident. Tried to call my wife, but she decided not to answer. I later found out she was gabbing it up with my mom. Isn't it nice when your wife gets along with your mother? I COULD BE BLEEDING OUT ON THE COLD ASPHALT, BUT YOU TWO JUST KEEP ON TALKING. Michelle and I have the same model of cell phone, and we have call waiting with caller ID, so I know she knew it was me. Anyway, I try a couple of times, then give up and leave voice mail. Turns out the guy in front, in the minivan, was a Deputy Prosecutor for Hamilton County. He said something about being experienced in car wrecks, but I don't clearly remember it. Anyway, perhaps in part because he decided he was only "tapped" and didn't need to file an insurance claim, and perhaps in part out of professional courtesy, when the cops showed up, they let him go very quickly, so I didn't get any of his information. Everybody was fine, polite, and decent about the whole thing. The couple ahead of me, whom I got knocked into, didn't have their insurance info on them (or maybe this is a euphemism for "don't have insurance"). But, except for the deputy prosecutor guy, who was outta there, we all traded names, addresses, and phone numbers. I hope the Debian Project doesn't mind that I used my Debian Project Leader business cards for this purpose. These people (and the Carmel Police Department) now have my GPG key fingerprint. Uh oh. Anyway, that's about it. Appointment tomorrow with the insurance agent, to get help filling out INDIANA OPERATOR'S VEHICLE CRASH REPORT, State Form 38656 (R6/7-91) Stock 301 Effective 1-92, which has to be filed with the Indiana State Police within ten business days, or my driver's license will be suspended. Aww, yeah. Gotta move fast, because on Friday I leave for Mérida, Spain, to attend the 2nd Annual Open Source World Conference in Extremadura. Also have an appointment with the claims adjustor tomorrow. Then I'm hoping to just leave my car at the dealership so they can work on it over the week when I'm gone. My wife and my mom, those talkative two from a couple of paragraphs ago, will be coming along with me. My mom's got a jones to visit Spain, and I've had a jones to take my wife to Europe. We'll have a couple of extra days to see what Spain is like — I'll be there from 22 October to 28 October. I hope one day to visit Barcelona and hang out with some proper anarcho-syndicalists.

On 21 August, Don Armstrong, a Debian developer, accepted my offer to serve as my delegate in handling trademark issues vis-à-vis the DCCA. As an employee of a DCCA member company, I found it wise to avoid the perception of a conflict of interest. I should stress that any such perception would merely have been conjectural, however; at no point have I been asked by anyone to put my thumb on the scales, as it were, and deal with the DCCA or any of its member organizations in a preferential way. It is widely understood within the Debian Project that our existing trademark policy, originally formulated in 1998, is too vague, and has not scaled well to suit Debian's much greater degree of success and market penetration (on its own, and in the form of derivatives) seven years later. However, grappling with the issue has proven challenging for Debian's membership. I believe this is mainly because the Free Software hackers that comprise our organization have tended to self-educate to a far greater extent on copyright law, and even patent law, than they have on trademark law. Recently (within the past year or so), Debian gained access via its U.S.-affiliated charitable organization, Software in the Public Interest, Inc. to a pro bono legal counsel who understands the Free Software culture. Debian's difficulty with trademark management is not unique — we have been on the other side of this problem when dealing with the Firefox and AbiWord trademarks, since we customize the codebases of these software projects in our GNU/Linux distribution, but ship them with their names (and logos) intact. It so happens in these cases that the originators of the software (who hold the trademarks) approve of our modifications. One of the essential pillars of software freedom, however, is the user's right to make modifications that the authors or rights-holders in the software may not agree with. Free Software hackers can feel, with some justification, that it is misleading to uphold the freedom of a work on the one hand (by using a copyright license such as the GNU GPL), and take it away with the other (by asserting a trademark on some essential aspect of the work, such as its name). It is true that a work can be renamed, or descriptive text changed, to identify itself as distinct from an "official" version of the work, but this in turn, it is feared, can damage perceptions of the work through at least two mechanisms. Firstly, disclaimers about unofficial status may be unnerving to users who aren't schooled in the vagaries of trademark law, in which — at least in the United States — you are expected to aggressively defend your mark lest you lose a future infringement case you bring against a well-heeled defendant. Users may mistake strident proclamations of unofficial, unendorsed status in a piece of software as a warning that it is unsuitable for use, or has known severe flaws. Secondly, aggressive use of trademarks, or even just the tension observed above between giving with a copyright license and taking away with a trademark license, may lead some distributors to rename a work, obscuring its origins to the casual user. This can happen pre-emptively, before a distributor even knows whether the modifications they have made (or think they might make in the future) have met with any objection from the trademark holders in that work. The "freedom to fork" (i.e., make a derived version unendorsed by the original author) is an essential part of Free Software, and while Free Software hackers' sense of community generally leads them to eschew forking in favor of compromise and consensus, occasionally a fork ends up growing the userbase or improving the overall quality of the Free Software landscape. A hacker may fear that brash trademark assertions by an author constitute mere lip service towards the freedom to modify the work without changing its name, and may be tempted to fork it, leaving the trademark encumbrance behind. Even among those who do not guard their software freedoms quite so jealously, the fear can exist that a simple difference of opinion over some technical programming detail, such as choice of sorting algorithm or graphical toolkit, will escalate to the point where the trademark license on the work (implicit or otherwise) is withdrawn. This is the inverse of the previous situation — instead of a modifier choosing to fork a work, the original author of a work (or, at any rate, the holder of the trademark associated with it), can force the modifier to fork. The dilemma this imposes upon the people creating the modified versions — revert your existing change or be legally compelled to make an additional one — can rub people the wrong way. When forking occurs, for whatever reason, and even in the relatively benign case of "rebranding" to remove legally protected marks, the threat exists that the competitive strength of the corresponding software will be diluted. Imagine if each of four major GNU/Linux distributors rebranded their version of Mozilla Firefox, calling it instead things like "Lizardfox", "Hatfox", "Swirlfox", and "Hearstfox". How many users would deduce that the web browsers in question were all "really" Mozilla Firefox, each one with a fig leaf placed delicately over it so that the legally-minded types at the Mozilla Foundation and the distributors could wink at each other? Even the somewhat savvy GNU/Linux user may be more confused than one might expect, given that other names used for Mozilla's suite of applications include Sunbird and Thunderbird, yet there is an independent Free Software project called Firebird, which was established prior to the Mozilla Foundation's adoption of its product naming scheme. "What's in a name?", you may ask. They're important because they are simple labels we can use to refer to Free Software success stories. There's a lot of Free Software to talk about; the phenomenon of copyleft does much to ensure a competitive culture. It's difficult to achieve an unnatural monopoly in this environment, because anyone who steers a software project in a direction the users don't want to go has to cope with the prospect of seeing a group of those users organize their own community based around a derived version that does what they want. The hypothetical hydra-headed Firefox situation described above, however, is an example of false competition, because the distributors were compelled to distinguish their Web browsers for legal, rather than technical, reasons. In actuality, Mozilla Firefox is a good example of what's right about Free Software, not just because of its licensing but because a web browser is a familiar concept to nearly every computer user today. Free Software's early successes were more esoteric — GNU Make, the GNU Compiler Collection, the GNU C Library, GNU Emacs, and even the Linux kernel are not pieces of software that the general user can easily conceptualize. It is beneficial — to say nothing of convenient — to refer to the leading freely-licensed web browser as "Mozilla Firefox" rather than "a suite of mostly-compatible, similarly-named Web browsers shipped by the various GNU/Linux distributors". Those who seek to foment confusion and FUD about Free Software would doubtless capitalize on such a situation. These issues are challenging but not insuperable. A coherent policy will enable the community to establish a set of common practices, whereas now there are few conventions in the trademark arena. Ultimately, it is my hope that Debian will be able to promulgate a trademark policy that not only satisfies our needs, but serves as a model for others. To establish a successful policy, I suspect we need to build one up from basic concepts, and formulate explicit answers to fundamental questions.

• Why even have a trademark? Let's understand what protections the law affords and determine which, if any, are applicable to our endeavors. In the U.S., trademarks are managed by the federal government (rather than the states), and regulated by Title 15, Chapter 22 of the United States Code. International treaties result in trademark law being roughly similar across most jurisdictions in the developed nations, but there could exist important differences that we should learn about.
• What level of Debian involvement should be necessary for an "outside" organization to use our mark without a fuss from us? Should there be any situations where people essentially have an automatic trademark license, or should we use trademark law as an instrument to encourage (or compel) anyone trading in our name to contact us? We need to consider small-scale garage-based redistributors who simply move physical copies of our official ISO images as well as commercial derivative distributions.
• Is it feasible to apply the copyleft concept to trademarks? That is, is there some way we can turn the restrictive aspects of trademark law into a kind of compact that upholds the freedoms of a sharing community, while penalizing the activities of those who would prey upon that community?

Originally published 2005-09-14.
Updated 2005-10-15 to add licensing in comments.

Courtesy of FindLaw Legal News: WASHINGTON-President George W. Bush said Wednesday that Harriet Miers' religious beliefs figured into her nomination to the Supreme Court as a top-ranking Democrat warned against any "wink and a nod" campaign for confirmation. "People are interested to know why I picked Harriet Miers," Bush told reporters at the White House. "They want to know Harriet Miers' background. They want to know as much as they possibly can before they form opinions. And part of Harriet Miers' life is her religion." Courtesy of the United States Constitution, Article VI: ...all executive and judicial Officers, both of the United States and of the several States, shall be bound by Oath or Affirmation, to support this Constitution; but no religious Test shall ever be required as a Qualification to any Office or public Trust under the United States. Oh, well, just so long as it's a criterion, not a test. I mean, it's only essential, not a qualification or something, right?

Since I got back from the Oldenburg Linux Developers' conference, I've had my attention on our security infrastructure. Despite only being there for one and a half days thanks to a badly delayed trans-Atlantic flight, I found the conversations and collaborative spirit heartening. The bad news is that what I had planned for a writeup got rendered obsolete soon after I returned to the United States. Things have been changing rapidly, but mostly for the better. We've got three machines in the DNS rotation for security.debian.org now, which is superior to the one we had before (you can use the command dig security.debian.org to inspect the DNS record). My thanks go to our security and system administration teams for recovering from the recent overload problem provoked by an xfree86 package security update. Being somewhat familiar with that package, I can understand how its large size combined with Debian's ever-growing userbase starved the security host of bandwidth. Secondly, while I was in Oldenburg, Joey Schulze gave me a lot of insight into what a challenge one particular package is — the thing sucks up at least half of his time, dwarfing all other stable security update efforts. You've probably guessed that this package is the Linux kernel. Due in part to its success, and in part due to OS kernels being inherently attractive exploitation targets, the Linux kernel is getting a significant amount of scrutiny from a security perspective. Taking Red Hat Enterprise Linux as an example, we can see two advisories in the past two weeks: one on 28 September and one on 5 October. The one on 28 September addressed eighteen (18) different vulnerabilities as catalogued by MITRE's CVE project, and the one on 5 October — that's one week later — addressed fourteen (14) vulnerabilities, of which eight (8) were distinct from the previous advisory. (There was some overlap because the earlier advisory was for Red Hat's Linux 2.4.x kernel series, and the latter was for the 2.6.x series.) Those Debian developers who have ever handled a security vulnerability in one of their own packages can likely imagine the labor burden this is. Then reflect that Debian ships and supports a lot more Linux kernel trees than Red Hat does — this only magnifies the problem. The good news is that a team of developers focused on stable kernel security updates has been established. One of its members said to me today that he has seen a "very positive increase in kernel-related security activity". It is too soon to declare this problem resolved, but I perceive no lack of talent or dedication on the part of our developers. I am there to assist them in resolving the organizational and workflow issues so that our users can see the fruits of their energy directly. Similarly, I'm interested to see how the security.debian.org round-robin arrangement holds up after a reasonable period of real-world loads, particularly since I expect kernel package updates to sock the machines about as badly as an X Window System update. These issues are not over and done with, so an announcement declaring these problems vanquished would be premature. At the same time, the developers and users at large need to know whether or not people have their attention on them. I am wary of leaders or managers who declare issues resolved too soon, or proclaim optimism that later turns out to be unfounded, and have sought to avoid this vice. I apologize if I have tacked too far in the opposite direction. I perceive progress in this area. Let me know what you think, what you need to see, and by what metrics you measure progress and accomplishment on the security front. You can reach me at leader@debian.org (the address is already blitzed with so much spam there seems little sense in obfuscating it). (After getting some feedback on this entry, it's my intention to post it with any applicable revisions to the debian-devel-announce mailing list; please take this opportunity to "patch" this "beta", if you're so inclined.)