4 September 2006

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.

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

On Friday afternoon I'll be arriving in Oldenburg, Germany, for the eleventh annual Linux developers' conference. Historically, this conference has had a strong focus on non-x86 ports of the Linux kernel, boot loader development, the GNU toolchain, and so forth. At long last, it looks like this may be my opportunity to get my Macintosh Quadra 840AV out of mothballs and back into commission, thanks to Wouter Verhelst. I should be able to fit it into my luggage if I don't bring many clothes... :-) This year, however, in addition to that, a couple of mini-conferences are being piggybacked onto the Oldenburg meeting. These include the GNU Classpath and Debian Java DevJam and the Debian Security Summit. The Java programming language is a divisive issue in the Free Software community, and has a degree of controversy that sets it apart from the usual language wars. The dominant factor in this controversy stems from what Richard Stallman refers to as the Java trap; with the specifications controlled, and the reference implementation kept unavailable on DFSG-free terms by, an industry consortium dominated by large corporations, a Free Software hacker might fear that using Java will consign them to either having to compromise their principles by using non-free class libraries (for example), or being doomed to chase the taillights of standards that could conceivably be tailored to disadvantage competitors. (Java is not alone in this respect; many people fear that Microsoft's .NET, despite being openly standardized through ISO/IEC, will in actuality be completely controlled by Microsoft.) Despite this peril, Java is attractive to GNU/Linux-using organizations. The Free Standards Group, developers of the Linux Standard Base, has received inquiries about a Free Java standard and implementation from organizations already committed to GNU/Linux. In my job, I've encountered an interest in Java from several customers and prospects. Intriguingly, these institutions are, by and large, very much aware of the Java Trap. They like the language, and are not strong advocates of Free Software, but they too are worried about vendor lock-in. They've seen the success of community-driven development as GNU/Linux moves from strength to strength, claiming territory formerly held by Microsoft and proprietary versions of Unix. Even if I can't persuade a customer to adopt a Free Java stack, I can exhort them to only code against Java standards that have seen a free implementation. That way, their development bets are hedged against any "madman theory" of the controlling vendor. Furthermore, this way they only code to standards that are seeing independent implementations, and they leave their engineers free to switch between varieties of development kit. Engineers like flexibility because it enables them to work more efficiently; sales people, marketing personnel, and strategists like efficient engineers because they make a firm more nimble. That's where the GNU Classpath and Debian Java DevJam comes in. Free Software Java enthusiasts want to see their implementations fully mature, and are working hard to make it so. The Free Software community has the opportunity to make its Java implementation not just an available alternative, but a compelling alternative to the proprietary ones on technical as well as licensing grounds. The recent release of GNU Classpath 0.18 shows just how vigorously this opportunity is being seized. Having mature software is only half the battle, however; that software has to be coherently put together and easy for the user and developer to manipulate. For many of these folks, it's not enough just to have good, Free Java virtual machines (like Kaffe and SableVM), class libraries (GNU Classpath), compilers and interpreters (gcj and gij, respectively, from the GNU Compiler Collection), and application servers (Jakarta Tomcat, JBoss, and JOnAS, among others). They also want these technologies to be mutually integrated and easy to install and use. Good software and good packaging complement each other to drive adoption of the technology, and that's what the DevJam is all about. I'm glad to see that representatives of Debian's Java packaging team will be joining not just upstream authors, but their counterparts at Fedora, Ubuntu, and Gentoo in furtherance of this goal. I've approved a budget of EUR 2000, which Petter Reinholdtsen will administrate, to support the expenses of Debian's participation in the DevJam. We've received 1500 USD in sponsorship of this event from a corporate sponsor that chooses to remain anonymous. The other mini-conference I'll be attending is the Debian Security Summit. We're bringing together the heads of our Stable Security and Testing Security teams — the two Joeys, Joey Schulze and Joey Hess, as well as a bevy of other security-minded people, with the goal of revitalizing and streamlining our security processes. Several members of the Stable Security Team have gone dormant over the past several months (or longer), leaving an increasingly small number people to handle, as of Sarge's release, not one but two stable releases. This is because we do not terminate security support for our previous stable release (in this case, Woody), until some time has passed. We've had other challenges on the security front. We had what amounted to a security support hiatus for about three weeks in June, which caused much consternation. More recently, klecker.debian.org, which provides the security.debian.org has suffered some occasional availability problems, and it hasn't always been clear what's caused them. It's my understanding that we have new hardware in place that can serve in a backup, supplemental, or failover capacity. The general feeling at DebConf 5 was that our security apparatus was in need of attention to make sure it keep pace with the demands being placed on it. I've been in fruitful contact with Joey Schulze, Steve Kemp, and others over the past several weeks, and I look forward to a productive few days.

My previous entry about a fellow developer's GPG key causing nasty spew from gpg on my system provoked an unhappy response. I had hoped to instead stimulate a discussion^* of the problem — whether a bug in GPG, a bug in the key servers, or both. From Alexander's explanation, it looks like it's the latter. If a hunk of your key gets corrupted and then submitted to the public key servers, ever, then there's apparently no in-band way of signaling that to those key servers. Apparently you have to contact the humans who administrate the key server and arrange for something approaching divine intervention (in the sense that any large database that has many simultaneous reads and writes going on at all times via defined interfaces really should not have people mucking around with its innards in an ad hoc fashion). Just off the top of my head, it seems like one should be able to submit a GPG-signed copy of one's own entire keyring to the key servers, and have any key signatures within that be regarded as "authoritative", only capable of supersession by another signature bundled in a keyring signed by the keyring's owner. The handling of signatures not in that signed keyring would not change. (It does occur to me, though, that this means that the key servers are susceptible to an annoying attack wherein people can deliberately add corrupt signatures to other people's keys and promptly upload those keys to the public key servers. It would also be easy to automate such an attack. Oy vey. Consequently, it might be worth considering a key-owner-only update model for keyrings on the key servers.) Debian relies heavily on its web of trust, and on the GPG application specifically, and it seems a shame that this problem hasn't been addressed by now. Do we need a new protocol for communicating with key servers? Is my suggestion above completely crack-addled? If you didn't get the chance to flame me for my previous entry, don't miss your opportunity this time around. ;-) Another possibility would be to change GPG so it doesn't complain about the sorts of problems it found in my message, but that seems suboptimal. Well, okay — I'll say it — grody. Errors in any large collection of data, such as the keyrings in the OpenPGP global web of trust, are inevitable. Corrupt data is corrupt data, should be reported as such, should be susceptible to rectification, and that rectification should be able to be propagated. It seems the PGP key servers — the ones I and many other Debian developers use, anyway — are not entirely succeeding on the last front. What can we Debian geeks, as prominent contributors to the global web of trust, do to resolve the problem? Alexander: I'm sorry I gave offense, if inadvertently and only temporarily. There are certainly no hard feelings on my part. I don't really know how to constructively reply to Matthew, given his patient explanation to me at DebConf 5 that the entire purpose of that specific blog of his is to serve as a vent for his spleen — he has another for the serious stuff. Since it seems to be necessary to state this for the record, I don't regard damaged packets in a person's GPG keyring to be evidence of flaws in the owner's character or personality, or as anything to be ashamed of, but I must admit that I didn't consider that others might do so. I see a technical challenge to be surmounted (noisy spew from the gpg program that seemingly can't be eliminated without improving the way GPG clients and key servers communicate), and that's about it. I welcome people's ideas on resolving it — is there a Public Key Server Corrigendum Protocol in our future, perhaps? ^*Being relatively new to blogging, it's certainly possible I have in mind a meaning of "discussion" in mind that is excessively mundane, and not the norm. I can easily conceive that people who use their blogs primarily as megaphones to air their grievances (and there are many — one of my favorites is Billmon) are more likely to assume others apply their blogs to the same end. I'll need to give that conception more weight in the future.

Troy Heber and I have been setting up a multi-architecture Debian build cluster - basically a bunch of machines we can build/test kernels on. We got our hands on a Sun Blade 1000 a while back, and I had a good excuse to try and install it today. Troy said he'd tried one of the d-i nightlies, but had problems with it, so I decided to try sarge. I burned a sarge CD (which is 2.4 only, surprisingly), but it hangs after printing "Remapping the kernel...". Unlike other instances google finds, it never prints "done". I found that the net boot flavor has a 2.6 kernel - I tried it, but I get an oops as soon as it tries to load the scsi driver (sym53c8xx_2). It leaves modprobe hung in the D state, and all further modprobes hang behind it. Hoping that the cdrom boot method was to blame, I tried netbooting the 2.4 kernel flavor. This went smoothly, at first. But immediately after configuring the network w/ dhcp, the keyboard goes to hell. Only the left ctrl key seems to work (which I discovered using the tried and true bang-all-keys method), and it behaves like an escape. I tried a non-sun USB keyboard, but it had the same problem. I dug up an old non-USB sparc keyboard, but the box won't boot w/o a USB keyboard connected and d-i won't respond to the non-USB one anyway. I guess I could try running d-i with the text frontend, or maybe preseeding the whole thing... I remember some keyboard remapping on my sparc32 box that occurred when I moved to a 2.6 kernel - I wonder if something in userspace is attempting to compenate for that change? But that wouldn't explain why it only happens post-dhcp. Also.. I wonder why d-i is all monochrome on this box? Kind of annoying to navigate the menus when I can't see which option is highlighted. Unfortunately, this box has no serial port - I'll have to try to dig up one of the four port serial pci cards we once had lying around & try to setup serial console, which is what we'll want eventually anyway. Another option, I suppose, is to try installing woody then upgrading to sarge..

I recently found out what these new-fangled podcast things are all about. I was playing with Rhythmbox the other day and noticed it had a built-in podcast feature, and I'd recently noticed that my favorite radio station is now doing podcasts, so I decided to investigate. After a few days of that, I decided that I approved of the concept. I bought a Neuros a year or two ago, and I spend about an hour or so bike commuting with it every day. Adding music to it is slow (USB 1.1), so I normally end up listening to the same music for a week or so. What I really want is to just plug it in at night & have fresh music on there ready to go the next day. But I also want to keep the flash full, so I don't want it to flush the old stuff unless it needs to - so I wanted something kinda like a FIFO. First thing I needed was something to track podcasts for me; rhythmbox is nice, but I need something scriptable. For now I'm using podracer. Its not very configurable, but it does the trick. I prototyped this all in shell using the positron command line interface, but then immediately rewrote it in python using the positron libraries instead. I then added a wrapper for cron to run that makes sure podcasts are up to date, the neuros is mounted (very easy now that udev automatically creates device files that are unique to a device under /dev/disk/by-id/), etc. It should be trivial to split the audio-device specific code into modules - which I'll need to do as soon as I find a physically smaller, logically larger flash player that works well with linux (I was looking at the iRiver T20, but have only read bad things about linux compatability).

I switched to evolution from mutt a little over a year ago. I found that I really need a side-panel list of folders and some better calendar integration. Since then, I'd discovered muttng and other ways of dealing w/ calendar stuff at work, but I just couldn't make myself go through the MUA switch again. Today I have a couple new . (No offence intended to the gnome/evo guys - they've been responding quickly, and ia64 doesn't have a huge desktop userbase - its something I've wanted to do for a while anyway). I spent a couple hours splitting out configs so that I can share all of my common settings across machines, and have customizations where necessary for specific locations/situations. I used the 'source file ' syntax to call a shell script that uses heuristics to guess at my environment & generate relevant pieces of muttrc. I'm already (re-)impressed by how much quicker I can process mail, and of course, the fact that I can customize every little property of the MUA. And I can use my $EDITOR again :) Now I guess I should take another look at calendaring tools to go with it - I hear sunbird has pretty good support for read/writing calendar info via WebDAV...

I'm currently sitting in Denver International awaiting a flight to Houston where I'll meet up with Taggart for the flight into Mexico. There we'll meet up with some other folks (Ryan Murray, Troy Heber & Junichi Uekawa at least) and take a cab down to Oaxtepec. We've had *tremendous* trouble booking our hotel room (and by we, I mean Troy). In fact, last we heard they were cancelling our reservation. I strongly suspect this is an attempt at bribe soliciation, or maybe they actually just don't want to do business with us? Not quite sure - my employer is sponsoring my travel here, and I haven't noticed a "bribe" category on the expense report.. maybe I can list it under tip? :) Oh well, I suspect the worst case is that we can find asylum for a night on someone's floor until our accomodations get worked out. I'm very much looking forward to arriving at DebConf & seeing everyone, not to mention trying the local cuisine :)

I'm always on the lookout for a better way to maintain and share my calendar. I currently have a hybrid solution - evolution/webcalendar. I use evolution to store all of my HP appointments, because it can easily import ical appointments. It also has a pop-up reminder mechanism, which is certainly a must. But what sucks is that I want to see/be reminded of the same appointments whether I'm on my laptop at home, or in the office on my workstation. evolution doesn't share its calendar with other clients. Outside of work, I use webcalendar - which is actually pretty feature rich. It can send e-mail reminders and even has a .ics interface that evolution can poll. That way I can overlay my (read-only) webcalendar appointments on top of my evolution calendar, so I only have to maintain those appointments in a single place, and can still get pop-up reminders. Unfortunately, this hasn't been working with recent evolutions - and when it did, it was flaky - random crashes, etc. A problem with webcalendar is that everyone I invite to an event needs to have an account. I want to be able to invite anyone in the world, with just their e-mail address. When I'd first read about hula, I let my mind go wild with how it might work. Wouldn't it be cool if this was just a simple to install/configure/use client that people could just install and run locally? And then what if all these clients could somehow be organized into useful groups? Like I could tell my client that I'm an HP employee, and it could talk to some hp hula server to see my coworker's schedules? And I could also see my buddy's calendar that lists all the concerts he's going to this month, by communicating with his client directly, in an rss fashion? No required central server, just a client that knows how to collect/post information in standard formats and present it in a useful way. Well, that's not what hula's all about, it seems. It looks very centralized, and isn't something many of my friends could configure themselves. I installed sid's hula today; which is admittedly about 6 months out of date. I was initially impressed with the ease of install & the pretty web page, but quickly became disappointed by the admin architecture. Adding a user is terribly, terribly non-intuitive. And the whole thing looks overly complex, like its inherited a lot of design cruft. But, once you log in as a user, things look fine. hula's calendar looks nice, and I'd seen a flash video that makes newer versions look really spiffy. So, I wanted to see if I could easily import an e-mailed invitation into it. This means I'd need to give hula access to my e-mail. You can have hula pull mail from a remote server - I was hoping to connect it to my imap server as a read-only client for this test. However, it seems that hula will only pull mail every N hours, where N is configurable globally. I really just want to have an active imap session, using hula as a front-end, but that feature doesn't look like its there. I also couldn't find anyway to import an existing calendar/.ics file. Anyway, I've seen enough to know that hula isn't going to work for me yet. It doesn't appear to offer me anything that I don't already have, or simplify anything I do already have.

I've got mail through CAcert.org webmail (probably, CAcert Web of Trust -> Find an Assurer -> Email Me). It might be written in Japanese, but mail that I've received is encoded wrongly, so that I can't read the message. For instance, it includes the following line (od -c -t x1):

0000000   F   u   m   i   t   o   s   h   i 302 227   l  \n
        46 75 6d 69 74 6f 73 68 69 c2 97 6c 0a

MIME header of the mail says it is "text/plain; charset=UTF-8". If this byte sequence is decoded as UTF-8, "302 227" (in hex, 0xc2 0x97) would be "END OF GUARDED AREA (EPA)" (in UCS-2, it is 0x97), and "l" (in hex 0x6c). It doesn't make sense. However, the decoded byte sequence 227 154 (in hex 0x97 0x6c) could be read as in Shift-JIS. It does make sense. So, the mail was wrongly encoded, that is, encoded in UTF-8, not by each characters (in Shift-JIS), but by each bytes. Anyway, I can read the received mail by the following commands:

cat msg   iconv -f UTF-8 -t UCS-2BE   tr -d '\000'   lv -Is

Maybe, CAcert.org webmail just encodes Shift-JIS text in UTF-8 as if it were single byte character sequences. I hope it will be fixed. I'm not sure this is a bug of CAcert.org webmail or users web browser that post text in Shift-JIS (wrongly, should be UTF-8?). I've changed default language to English from Japanese for now. (Even in English, it seems that an user can send Japanese text through the webmail, though).

New upstream version of kazehakase has been released on day of Niku (29) and Hidetaka Iwai packaged it. It now be built with GNU TLS so that it depends on libgnutls-dev. But when I built his package in my environment, it failed because of gnutls_session_t was not defined. This is because I had installed libgnutls11-dev that provides libgnutls-dev, so it satisfied build-dependency. However, latest (or actual) libgnutls-dev is development package for libgnutls12 and this is what kazehakase should build-depends on. I wonder kazehakase should build-depends on libgnutls-dev (>= 1.2.6) or build-conflicts libgnutls11-dev. Probably, it wouldn't appear FTBFS bug on buildd, because buildd will try to install libgnutls-dev....

I'm very exited this week because the company I work for just released a piece of open source software, Halfs, a Haskell Filesystem. There are a few groups thinking of using it, including darcs, a revision control system, and house an operating system written in Haskell. Since it requires kernel modules and a very specific Linux kernel (for now), I decided to release a virtual machine image that folks can download and just use on any architecture as described in the "virtualization environment" section of the quick start guide.

The following are my own opinions and impressions: It seems that California is taking action against Diebold, who has been working hard to break democracy in the US by selling broken hardware and software meant for voting. An advisory panel to Secretary of State Kevin Shelly recommended that California should ban the use of some 15,000 machines. This is really good news. One has to wonder that with no paper trail, and the number of screw-ups we know about already, how many more screw-ups were there? And on the SCO front, it seems that one of their major investors wants their money back. SCO has been trying to make money by suing people involved in Linux, including IBM. This might make it a little hard to pursue aggressive (and in my opinion, unethical) legal avenues against Linux users and vendors.