Skip navigation

Monthly Archives: June 2011

Licensing Questions and the Ecosystem

With Oracle donating OpenOffice.org trademark and code to the Apache Foundation, one point frequently made is the one about licensing differences. LibreOffice is under a weak copyleft license, that is, changes to existing core need to be made public (at the time a product ships). In contrast, to-be-Apache OpenOffice would be available under a non-copyleft license, meaning nobody is required to contribute anything back.

It is said that non-copyleft, or permissive, licenses are more popular with corporations, because they allow for much more flexibility in what, and when, to contribute back. Overall, it is conjectured, the projects will still see enough open contributions from corporate participants, because private forks are not cost-effective.

Let’s now have a look at how all that applies to OpenOffice.org. There are a few things to know beforehand. First, the code represents almost 20 years of development, and is, in many places, a sedimentation of bugfixes over bugfixes. Which overall results in highly coupled and fragile code. Secondly, OOo has a mature component framework, API and extension mechanism, that makes it easy for third parties to innovate on top of the existing core.

Given that, it is rather disadvantageous to keep changes to existing core code private, because of high internal maintenance costs (and a very non-linear relation between the size of the private change, and the risk to have it broken quite badly by merging new code from the upstream community). Conversely, it is highly advantageous to add more extension points to the core code, and reduce the internal coupling, since that enables later, independent functionality (that corporations could use to differentiate themselves).

So then, it seems the differences for the ecosystem between weak copyleft vs. permissive, in the case at hand, are negligible – for the former, responsible behaviour is enforced by the license, for the latter, by technical reality. Beyond existing core code, everyone is free to not publish changes either way. Of course, an Apache-licensed OpenOffice.org would permit taking the project all-proprietary at any given point in time, but such a move is clearly not in the interest of the community, and specifically not in the interest of the Apache Foundation.

Of the remaining differences, the constraints on e.g. the timing of contributing back, are simply too minor to justify the overhead of running two communities in parallel. That’s the main reason I oppose the idea – as a software engineer, I try hard to avoid duplication for no good reason.

EMail, and the Unix desktop – A rant

So this is about a long-term gripe I have, working (mostly) from a Linux desktop since well over 15 years now – and that is, getting email to work as “it’s supposed to be”. Which is a royal pain in the rear.

Let me elaborate. Before smtp server admins became really anal about spam and were blacklisting dial-up and random IP addresses, you simply used your default sendmail or postfix setup that came with your distro and everything was fine and dandy. Email clients just delegated sending to that MTA subsystem. After that good old time was over, you usually needed a smarthost to authenticate against – if you were lucky, it accepted arbitrary From-addresses, so you could even use it for both work and private mail, or share your box’s setup with your room mate.

When those last loopholes got closed, using a system-wide MTA for outgoing mail on a desktop machine quite apparently became a very, very bad idea (conceptually, and in terms of effort involved to make it work). I guess that was when everybody but die-hard Unixers switched over to all-in-one solutions like Thunderbird, Evolution, or KMail – which came with built-in MTA support. Still, there were corner cases – like mailing out patches from git or quilt, or dishing out signed gpg keys after the last keysigning party, that were, um, kinda hard to make work.

Not surprisingly therefore, the command line utilities used for that, initially nicely adhering to the Unix toolkit approach, soon grew MTA features like a hacker grows a beard. With varying levels of quality, and feature-completeness – and usually – the horror! – with the option (or the requirement), to store mail passwords in cleartext configuration files.

I personally plead guilty of tweaking/enhancing TLS support in caff (CA fire-and-forget – a nice script for signing and mailing gpg keys), because I was using Gmail for my private mail, which required that. Similarly, folks added TLS support to git-send-email, and surely tons of other not-primarily-MTA programs.

The bad news? Well, at least the two examples I gave don’t verify the server’s TLS cert at all, exposing you to trivial man-in-the-middle attacks. Or have you never used those programs in a hotel WLAN, or on a conference?

The next nice feature of a proper MTA, namely queueing mail if there’s temporarily no net, or the remote SMTP server is down, is even harder to achieve for those little tools – usually, people just queue meta-tasks then (like “TODO: re-run caff when I finally get out of this plane / send out patches to Jeff, he needs it by Monday”) – what a sucky state of affairs, in this day and age.

So, how to fix that? Well, don’t replicate MTA features all over the place – use a local, per-user MTA, plus a mail queue, and have all those tools, and your MUA, use that. After playing with sendEmail a bit (and even adding TLS cert fingerprint verification), I re-discovered msmtp, which does one thing extremely well – sending email. Plus, it has built-in support for Gnome Keyring and the Mac OS X Keychain, so you neither have to constantly type your passphrase on the terminal, nor store it plaintext. And it does TLS validation, and also (optionally) fingerprint checking. And it comes with a script to manage a local, per-user mail queue.

Well, I didn’t so much like that script, for all the wrong reasons – mostly, I probably was looking for excuses to tear it down into pieces and hack up my own solution – being two much shorter (and admittedly almost feature-less) variants thereof, enqueue.sh and runqueue.sh. The former just grabs all command line arguments, plus all of stdin, and stuffs it into a maildir-like queue – employing another little gem called safecat. The latter periodically processes all files in the queue, and then calling msmtp using the canned args and standard input. And sleeps when you’re offline.

Have now happily configured all of mutt, caff and git-send-email to just use enqueue.sh as their “sendmail” equivalent –

~/.gitconfig:

 [sendemail]
	envelopesender   = Thorsten 
	smtpserver       = /home/me/bin/enqueue.sh
	aliasesfile      = /home/me/.mutt/aliases
	aliasfiletype    = mutt

~/.caffrc:

 $CONFIG{'mailer-send'} = [ 'mailer', 'enqueue.sh -a gmail -f mail@for.me -- ' ];

~/.muttrc

 set sendmail="enqueue.sh -a gmail "

There were two rather minor bumps, first was a missing safecat for opensuse – I resuscitated an old spec file from cthiel, and added it to my opensuse buildservice repo. Debian of course has a package. Next was that opensuse’s msmtp did not have gnome keyring support enabled, presumably because it drags in some subset of the gnome stack as requirements. Naturally, on my desktop system, that’s an ignorable concern, so that’s now forked and added to my buildservice repo, too.