Tales from the Gryphon

Suppose I have a set of Trade Marks, all legally set up and registered. I write up some software, and I am so enamored of my Marks that I intertwine them with every bit of my code (hey, they look pretty, OK, which is why I make them my Marks). Indeed, the effort of ripping them out would be essentially the same as rewriting the code. I, then, being the free software guy that I am, license the code under the MIT license.

However, I do love my marks — so I have an aggressive trade mark enforcement policy, and I actively pursue usage of my marks by anybody unless they have approval from me — and I don’t allow them to use my mark if they have modified my code (I mean, who knows what butchery of my mark and my reputation shall then ensue?)

Should this piece of software be considered free by Debian? While the freedom to modify and distribute the software is effectively been taken away from the users of my software, there are those who argue that the software is free, since the freedom has been taken away by Trade Mark law, and not copyright law. By a strict reading of the letter of the DFSG, they claim that since only copyright licenses are mentioned, any other abrogation of freedom does not count. This is wrong.

The bottom line is whether the users have the freedom to modify the software, not exactly how the restriction of freedom was achieved. One should be looking at the freedoms, the so called spirit of the social contract, and not a strict interpretation of the exact wording of what is supposed to be a guideline, anyway (and yes, I know that the guideline argument has lent itself to abuse in times past).

I have long been interested in moving the debian-policy package away from CVS, but had never quite managed to gather enough motivation to do the switch. Debian policy has long had an Alioth project, but I finally managed to file a support ticket, and nag Wichert into creating the arch project for policy.

The first step was to convert the CVS version into an arch repository, and this is where cscvs comes in. cscvs is nice, but I am told that Canonical has a better, private version, and helpful folks there offered to do a managed conversion to arch for me using these cutting edge tools. I declined, being persnickety enough to want to convert Debian technical policy using tools in Debian itself. And, apart from two change-sets (numbers 117 and 125), cscvs managed to do the conversion to arch (the bazaar flavour) nicely on its own (well, after a few false starts as I climbed the learning curve). Came to 283 change-sets. Have a look at my Debian policy branch. It can be registered at http://arch.debian.org/arch/private/srivasta/archive-etch/.

The next step was to create a baz archive on arch.debian.org, and use Clint’s ACL recipe to allow people in the dbnpolicy group to have write access. And then, since I wanted this branch to also have the full set of distinct patch logs, I cycled through all 286 patches in my local branch, replayed and committed them into the remote branch one by one. You may browse the public, or release, branch as well. This version can be registered at http://arch.debian.org/arch/dbnpolicy/etch/.

I have been fairly comfortable with my current mail filtering solution. Unlike some other blogs on Planet, when last I was doing exhaustive checks, I had not had a false positive in six months (now I just do random spot checks). The false negatives creep up from a few a week to a few a day (with a mail feed of about 1k emails a day). And the stuff that is classified as a definite spam is REJECTed (I do keep a copy), which means that a legitimate correspondent would have an idea something went wrong (unless they are ignoring such bounces form their own MAILER-DAEMON).

Part of the reason for this satisfactory performance is that I use a layered approach, with several tools playing off each other, ameliorating each others mistakes. Admittedly, this took painful training — I created a testcrm user, and bounced a copy of every mail I got to it using a .forward. Then, over a course of two months, I would painstakingly go over the classification, training on error, until the failure rates dropped to levels I felt comfortable with, and moved the CRM114 and Spamassassin configuration over for my own use.

I recently added a hand crafted Greylisting implementation to MIMEDefang — in good MIMEDefang tradition, this is a heavily tweaked version of an implementation on the mailing list, using PostgreSQL. I have modified it to not greylist every single new email that comes my way, but to only greylist stuff that CRM114 and Spamassassin have been unable to classify strongly as Spam or ham. mail that has been strongly classified already, in turn, affects greylisting.

Here is the SQL code for the implementation, and the mimedefang-filter itself, showing how I integrate CRM114 and Spamassassin along with greylisting in a Sendmail Milter.

Have fun.

No longer having an excuse for not creating my web site (researched a ISP, check; set up machine, check; ran through other items on the to do list; check), I natually had had to create new ones. Thus I embarked on a long process of educating myself about colour theory. It was an interesting journey. I had never understood the horse shoe shaped chart the used for colour calibrations; I have a lot to learn. And all the theory in the world does not make it easier for me to select a color scheme that does not suck.

The pages I ran into fell into four categories; those that talked about Color Theory and Physics, a very scant few that dealt with design, lots of practical web page construction sites that went into detail about color schemes and tutorials, and a bunch of math stuff. Hopefully these shall be useful to someone.

The grand culmination of all this research was a perl script that takes a color in hex notation, and generates a color report — for example. here is a report for #DEE3FF, which is the basis for one of the themes for this page. Of course, the generated page, though very nice in telling me how I can create a color scheme based on my initial choice of a basis color, did not actually help – since the colors initially selected clashed wildly with the graphic at the top. I had to scrap the initial choices and start over, though having the program made the process less painful than it would have been.

I need to polish up the perl script, and flesh out the descriptions of the links it creates, and perhaps add more command line options, or stuff. bling-bling is always important, especially for code.

Well, as most of us have gathered, yet another DPL election session came to a close. The highlights from a technical standpoint this year were that Devotee was modified mid-stream to grok encrypted ballots (early encrypted ballots, though rejected, contributed by testing devotee). The other, more visible, high light was that devotee now spits out dot graphs to depict the pairwise contests in the Beat matrix, and the resulting graphical representation of the results were published. The reaction being mostly positive, I went back and punched in graphs on most of previous results that were at all complex and could benefit from the graph diagrams.

While I was changing the vote pages, I responded to criticism of the navigation panel (or the lack thereof) on the vote pages, and the result(after a couple of false starts) is aesthetically more pleasing (well, to me it is).

Hmm. Bits from the secretary ain’t ever gonna happen. As this entry shows, they are deadly dull.

I finally got around to updating the SELinux UML recipe page to the latest 2.6.11.2 kernel. Of course, the new linux UML kernel expects a newer version of SELinux policy (19) than I had in my root_fs, so I’ll have to rebuild a new root file system. I wanted to get the newest version of the SELinux tools into Sid, but I seem to be coming down with a flu like thing. Since I would like to see Etch be SELinux capable, it is important that the barrier of entry be low for people wanting to play around with it.

Well, all but one, since we still do not have one of the contributions in. I also think we have an agreement about the timing of the IRC debate, so we are well on our way to having a properly educated and primed electorate. As always, look at the vote page for details.

While working on my key-signing-helper script, I came across examples of IO::Select usage that I think shall benefit devotee, though I am leery of changing things this close to a vote. Oh, well, I guess the new gpg output processing code shall see the light of day with the first GR of the season.

A while ago, my guessnet setup started messing up, just before a business trip, and I did not have the time to debug the error. After a quick consult on IRC, I installed and configured laptop-net, which worked.

While I had a working package that would let me carry my laptop from home to LUG to office, and various trips with Hotel networks once in a while, I always had to tell the system which scheme to use, since several of the networks used similar IP addresses and topologies (welcome to the world of NAT). I have never been comfortable with the fact that laptop-net did not consider MAC addresses while making its determinations.

laptop-net, on the other hand, is like a combination of ifplugd, intuitively, and switchconf, except better since it is all integrated and works seamlessly. guessnet does seem to work better for me, though, if for nothing else since it can actually determine where the laptop finds itself. I have successfully integrated guessnet in with ifplugd, and made sure that things play nice even with hotplug in the picture. So I am a happy Guessnet camper once again.

Well, yes, that sounds somewhat pompous. But I do think this is a worthwhile release goal; from where I stand I think that hard-hat security is a critical option for any OS to remain viable in the current security conscious environment, and Debian, after a period of being well ahead of the curve (thanks to Russell Coker, Colin Walters, Brian May, and others), has fallen well behind entities like Red Hat and Gentoo when it comes to providing a hardened, secure platform.

So, along with a few other people (Greg T. Norris, Lorenzo Garcia-Heirro), I have started a mini project to bring Debian’s SELinux patched packages back in sync with the latest upstream and the latest SELinux patches, and to make it easier for Debian developers to access SELinux patches. The only package that is ready to go is coreutils, and that is thanks to Greg.

I’ve just come back from the Se-Linux symposium, followed by the Central Pennsylvania LUG Security conference, which was a lot of fun. I also managed to get myself talked into upgrading to the X Org server, which is to be 3expected after spending two days sitting Next to Jim Gettys at a conference watching the neat gizmos.

And, if I get through this key signing process, I may get my key connectivity ranking up again (also thanks to getting it signed by Russell Coker). Of course, due to my weird key signing protocol this is more tedious than the norm, but hey, that’s what you get for trying to add value to your signature.