Bobulate

The FreeType library is released under a dual license: you can choose either the FTL (FreeType License) or the GPL, version 2. That means that a software stack that uses FreeType has to be license-compatible with one or the other (or both). In cases where the rest of the software stack also allows choices, this can be slightly complex. You end up with a combinatorial explosion of licenses — in theory, if not in practice.

But why is a choice necessary, anyway?

At issue is the “attribution clause”. This is common in the BSD family of licenses: the clauses usually say that you must attribute or credit the authors in the documentation accompanying the (binary distribution of the) software. Let’s look at the attribution clause of the FTL itself:

Redistribution in binary form must provide a disclaimer that states that the software is based in part of the work of the FreeType Team, in the distribution documentation. We also encourage you to put an URL to the FreeType web page in your documentation, though this isn’t mandatory.

OK, that’s fine. You can do that, by adding exactly that to your documentation. It’s not an onerous licensing requirement. But it is part of the license and must remain part of the license. This collides with the GPL version 2 because that license demands that the entire derivative work be licensed as GPL version 2 — that’s clause 2b, and the explanation in clause 2, and clause 6. Clause 6 in particular adds “You may not impose any further restrictions on the recipients’ exercise of the rights granted herein.” And the attribution clause is exactly a restriction that is not allowed by the GPLv2: the license demands that you put something in the documentation, the GPL version 2 does not allow you to add that demand to the license of the whole, end of story.

Well, it would be end of story except that two efforts in the realm of license compatibility have happened: FreeType itself is also available under the GPL version 2, so if you really want to you can apply the GPLv2 to your program and be done with it (this is good for Free Software, but one could argue that it drops the permissiveness of the BSD-style license because now you can’t produce a proprietary, binary version and satisfy the license through attribution). And on the GPL side, the GPL version 3 has clause 7b which specifically allows distribution under the GPL version 3 with an additional restriction of the form

b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it;

This is just called an additional restriction because that’s the language of the GPL. Attribution in the documentation is, like I said earlier, hardly an onerous restriction. Well .. maybe. That’s something we’ll come to some other day. In any case, it means you can write your software under the terms of the GPL version 3, then add FreeType to it under the terms of the FTL and release the whole under the GPL version 3 with an additional restriction.

To return to my earlier consideration of KDE license policies: there’s nothing there that makes it impossible to have GPLv3-or-later code in there license-wise, because you can make compatible choices. But that’s a very small sample, and KDE policy remains otherwise.

I have been invoked by John Layt to explain some bits of the KDE licensing policy. It’s related to my recent writing on copyright assignment in the sense that it discusses reasons for picking particular licenses and how licenses interact. The back story is the KDE Licensing Policy, which lays down which licenses are acceptable in the various parts of the KDE platform technologies and applications. Roughly, the libraries need to be liberally licensed (which means they can be taken proprietary or shipped with otherwise closed devices — a common choice of GUI libraries nowadays). More concretely: (LGPL 2.1+) or (LGPL 2.1 or LGPL 3 or later approved) or BSD or MIT or X11. The idea is that you can either go for any version of LGPL from 2.1 onwards, or only selected versions of the LGPL which have been approved by the membership of KDE e.V. (if you don’t want to give a blanket permission to the FSF to update the license terms) or something very liberal.

You must offer the choice, though: you cannot put just the LGPL 2.1 on there: it must be “or later”. You also cannot just put LGPL 3 on there. It must be “version 2.1 or version 3 or any later version approved by the membership.” That’s KDE policy. There is a technical (well, licensing-technical) reason for this as well, and that is license compatibility.

The issue of compatibility is more pronounced in applications, where we also allow GPL variations similar to the LGPL variations mentioned above. The reason is that the GPL version 3 is incompatible with the GPL version 2. As long as there is GPL version 2-only code somewhere in the software stack, we must be able to license the software under something compatible with that license — and that means the application code must be available under GPLv2 (or something else, but not GPLv3-only). Let’s take a look at the licenses used in libraries in a typical KDE application. I’ll use Konqueror on Kubuntu 9.04 as an example, with ldd providing the list of libraries. Here’s just a partial list:

LGPLv2 libacl.so.1
LGPLv2+ libattr.so.1
PD libaudio.so.2
BSD libbz2.so.1.0
LGPLv2+ libc.so.6
LGPLv2+ libdl.so.2
MIT libexpat.so.1
X11 libfontconfig.so.1
FTL, GPL libfreetype.so.6
LGPLv2+ libgthread-2.0.so.0
MIT libICE.so.6
LGPLv2+ libkdecore.so.5
BSD libpcre.so.3
zlib libpng12.so.0
LGPLv2+ libQtCore.so.4
LGPLv2+ libuuid.so.1

Now, it’s important to choose at the moment of running, a license for each component such that the whole is compatible. For each component there must be a concrete choice made. So for libfreetype I could choose the GPL (I guess it’s version 2 only then, but the Debian copyright file gave me no additional information and I’m too lazy right now to look it up), and then all the other choices I make need to be GPLv2 compatible. And now you see the problem looming: if I choose GPLv2 for the Freetype part, then I can’t mix in any GPLv3-only components. Or conversely, when you put in GPLv3 code into a KDE application, you are forcing GPLv3-compatible choices in the rest of the stack.

I don’t see any GPLv3 incompatible components in this listing, but that doesn’t mean there are none anywhere in the stack, ever. So we don’t want to force the choice for GPLv3 by including GPLv3-only code. For the purpose of risk avoidance we have the policy requiring licensing as GPLv2-or-later so that we can, if need be, choose the GPLv2 version to remain compatible with GPLv2-only compatible libraries. So it’s basically us keeping license compatibility with software components using older licenses. But it’s uncomfortable to me, because at some point we might end up in a jam with license versions as other parts of the software stack migrate (although very unlikely with all the liberally-licenses software in the stack).

Bertjan blogged about it two weeks ago, and you might have deduced it from Jason’s gadget switch, but KPilot should be considered dead. Of the three “maintainers” (and I used that word only very loosely regarding myself) I don’t think any of them actually uses a PalmOS device any more. There is, quite simply, no return for us any more in working on the application, much as we might want to keep the software alive. Read Bertjan’s blog for details on what this means and where you can find the software if you would like to resurrect it. It’s under the GPLv2, so have at it.

To support such an effort, I’ll say free to a good home: one box of assorted PalmOS devices, ranging from the Palm Pilot (the original!) through to a Tungsten E and a pair of m500s. With chargers and assorted cables. Just drop me a note.

The -440 repository — that is KDE4-OpenSolaris-speak for “the Mercurial repository which holds the specfiles that are being developed for building KDE SC 4.4.0 once it is released” — has been bumped to beta2 now (version 4.3.85). We’re still in the process of rebuilding everything, as there are some new dependencies and the usual fixes and patches to be updated. I count 66 patches still applied; we have started pushing more of them upstream — especially the trivial ones like adding newlines to the last line of a file. Thanks to SadEagle for picking up some of the patches to KHTML again as well — they’re a little odd in that they apply to code that isn’t ever called but that needs to compile anyway.

xz: this is a new dependency, a general purpose compression library. Very straightforward build, no other dependencies — something that we should be trying to foist off on SourceJuicer as quickly as possible so as to make it available to more people.

libattica: Frederik Gladhorn (and whoever else worked on that), I salute you. No patches required, builds without even a single warning. If I’m going to be really picky, I’d point out that the files are licensed GNU LGPL 2.1 (the Lesser GPL) while the included COPYING file is the GNU LGPL 2 (the Library one). And there’s no tests for it, so while I can see it compiles, I have no idea if it works. Good job, anyway.

The status continues to be: it works. It’s kind of slow, and backtraces involving the Flash plugin are non-ASCII text, but for straightforward web browsing and KMail and konsole — my desktop — it’s in OK shape. As usual additional compile and runtime testers are encouraged to step forward.

Thanks to the efforts of the KDE4-OpenSolaris group — among whom I number myself, hnhn, Hajma, and Ben as well as various testers and supporters — the KDE SC 4.4 beta1 (version number 4.3.80) is available as OpenSolaris IPS packages. Note that beta2 has been released already so there is more updating to do. In the course of the beta cycles, the amount of patching that needs dealing with tends to drop — at least as long as there are no large code drops.

Speaking of large code drops, Dario tries to explain polkit — a good thing, but I’m still not sure if this thing actually exists for me or not.

Packages: there is an IPS server hosting packages for 4.3.80. This is still my FreeBSD port of the pkg.depotd, so I do hope it remains compatible with the pkg command — pkg is still under interesting development, and it does suffer from API changes every now and then. In theory, you can just add this IPS server (say, as kdedev-ips .. oh, hang on, that is one of the things that has changed: I don’t think you can free-form name your IPS servers anymore). This should be a straightforward upgrade of your existing KDE packages.

Korona 4.3.80: there is a new release of the OpenSolaris live CD Korona (by Pavel Heimlich). It is available from genunix.org. Genunix is where you can find all of the different OSOL distributions and specializations. You can also get Belenix there, which is the KDE4-with-gcc distribution of OSOL. Note that the most recent distro’s are based on an OSOL with ZFS data deduplication, which may help in reducing disk space requirements if you have virtual machines or multiple source trees checked out.

Next steps in KDE4 on OpenSolaris are bumping everything to beta2 and plenty of runtime testing. I’m pretty happy with the stability of the desktop and KDE PIM right now, even Akonadi works; I think my main annoyance is with hangups in name resolution. Konqueror, for instance, regularly hangs (up to 10 seconds) in a dbus call (yay pstack). I think that’s either name resolution or favicon handling.

Just a heads up that the KDE4-OpenSolaris group has now got KDE SC 4.4.0 beta 1 (version number 4.3.80) building the following components: base, pim, games and graphics. For me that’s what makes a minimal desktop. Getting Akonadi up and running was the biggest challenge, because it needed a fix down in Qt related to bit-twiddling, compiler flags related to aliasing, and mutexes. One line, but it took quite some time to hunt down and rebuild.

You can get the sources for the specfiles here, and build from source. It will take a while. If you’ve built Qt 4.6.0 previously from the repo, do remember to remove it first because of this mutex change (we still don’t have a good means of getting pkgtool to decide when to upgrade). Background information for this effort may be found on KDE Techbase.

I’m writing these lines from inside Konqueror 4.3.80 on OpenSolaris. I wrote previously that Konq is much better with WordPress nowadays, so that means I can blog from a browser I like under an OS that I like (or I could boot into FreeBSD and do the same thing thanks to the efforts of miwi and the gang). It was Sinterklaas this weekend, and the ole Sint brought the kids too many toys and brought me updates to the spec files for KDE software on OSOL.

Ben Taylor has picked up the prodigious (or is it Sysiphean?) task of updating the dependency tree for Solaris 10 again.

Elsewhere in the stack, strigi was updated to 0.7.0 (thanks Jos for having an official release available), shared-desktop-ontologies was added at version 0.2 (a simple build), soprano was massaged once, then virtuoso added for version 3.52.7, then soprano massaged again, then cursed, then discarded. Then all the staightforward stuff involved in updating libs, pimlibs, base-* — that is basically updating packing lists to reflect new or changed files and removing the patches that we had pushed upstream.

Virtuoso was .. a trial, in any case. I don’t even understand why the dependency is referred to as Virtuoso when it’s about libiodbc; at that point I end up wondering why we require one ODBC library and not another (e.g. UnixODBC has a Qt SQL driver and is KDE friendly). Maybe there’s more undocumented dependencies underneath there — but I can’t find anything about it. Albert seems to be compiling something completely different when he mentions Virtuoso.

Getting libiodbc to compile at all (the code isn’t all that bad) did show up an interesting pattern: there’s a wchar_t based API and a char based API available, and the interface header does this:

#ifndef SQL_NOUNICODEMAP
#ifdef UNICODE
#define SQLInstallODBC SQLInstallODBCW

This is fine (sortof .. it’s very C-ish) except when the same interface header is included from the library itself. Since the library contains definitions for both SQLInstallODBC(char) and SQLInstallODBCW(wchar_t), the compile breaks. You end up with two definitions for SQLInstallODBCW() instead of one of each. That meant going through and patching each file in the library to not be stupid that way by adding #define SQL_NOUNICODEMAP (I suppose I could have added it to CFLAGS instead). It’s apparent that noone has ever tested this stuff with UNICODE turned on (or perhaps more restrictively, on Solaris with UNICODE on).

Once the library is no longer stupid then it turns out Soprano itself isn’t all that secure about the difference between wchar_t and char. If UNICODE support is on, then consider a line like this one:

SQLExecDirect( hstmt, ( UCHAR* )utf8Request.data(), utf8Request.length() )

Explicitly munging a UTF-8 request into UCHAR (um .. I’m not sure that the non-unicode interface is supposed to understand UTF-8, really) is going to break if that function is #defined to version that expects a wchar_t parameter there. All in all enough to make me give up on this rapidly and think about other parts of the stack instead.

Since there’s still no KDE 4.4 compilation requirements posted on KDE Techbase as of this writing, (and I don’t feel qualified to add it myself based on my rather grumpy interpretation of what needs documenting) it’s hard to figure out what we should be looking for.

Anyway, in positive news all of KDEBase built for 4.3.80, so that’s why I have konq and konsole; PIM needs some additional new patches (remember: if Akonadi, then add_includes(${Boost_INCLUDE_DIRS})) but on the whole it looks like fairly smooth sailing. Expect updated specs for a build maybe next weekend when Ben and Hajma have finished thrashing the repo.

Look at my horse
My horse is amazing

This is the last of the KDE e.V. board photo montages I’ll do from our recent board meeting in Berlin. You will note that we have considerable skills in rodeo riding as applied to dragons. But for a much better view of the KDE community (“KDE”) you should take a look at the planet or the dot.

Just because the source code isn’t all delivered in a tidy bundle to my doorstep with a thank-you note attached, doesn’t mean that I won’t try stuff out. Thanks to Christoph and Holger for explaining some of the WebKit things to me. In the course of today the KDE4-OpenSolaris folks updated the soprano packages, phonon (from an SVN checkout), and futzed around sufficiently that you should be able to build the Essential KDE Desktop (I don’t know where that fits in the new branding: it’s konsole, konqueror, kmail, plus integration with GDM so you can actually log in). As always, the specfiles and patches can be found in the Mercurial repo.

We still have 21 open bugreports against KDE trunk with patches attached (these are the same as patches in that repo, only reported upstream). That’s still a bunch to “encourage” maintainers to pick up. As a general rule, we commit trivia directly (happy constructors, const mismatches), file bugs on larger items, and try to keep the amount of unmergeable cruft to a minimum. I wrote some such cruft today for Dolphin, where apparently ? (some const KFileItemList method) : KFileItemList() << item isn’t acceptable. Sun Studio is particularly picky about types in the ternary operator; come to think of it a const_cast might have done the trick as well: something to experiment with later, because that would be a mergeable-trivia kind of patch.

Sometimes it’s hard to decide what flavor a patch is: today I added find_package(Boost) include_directories(Boost_INCLUDE_DIRS) to a few subdirectories in KDE PIM; that’s because Boost doesn’t live in the default compiler search path, but Akonadi’s headers #include them — so anything using Akonadi must also have the Boost include dirs in its include search path, which wasn’t the case. It’s a minor change, but it doesn’t scream “trivial” to me, so it’s sitting in our repo as “unmergeable cruft” for now.

All that said, that part of KDE SC 4.3.77 that I’ve gotten up and running is really nice; I’ve said it before, but the stuff integrates really well, including the GNOME network manager and notifications done by the pkgbuild tools when I’m building new stuff and the device manager; there’s still plenty to work on as well, but on the whole it pebbles (a small way to rock). Now if only I could start konqueror or dolphin from the menu or krunner — must be some weird crash going on behind the scenes when there’s no tty output. [[ And as a final shot, I should add that Konqueror is almost infinitely better with WordPress now than it was in 4.3.0. ]]

Qt 4.6.0 is out. That’s the first of the trials and tribulations for today, because it suggests that packagers should update their work on Qt. Which is one of those things that can take up to half of a KDE SC minor release cycle to get right. And when you find code in WebKit that has actually shipped that looks like this (real version in FastMalloc.cpp line 1438):

void *foo() {
#if COMPILER(MSVC)
  // Without this, Visual Studio will complain that this method does not return a value.
  return 0;
#endif
}

.. then it’s not so much reading Qt code as it is looking at the DailyWTF. No duh, you need a return statement to return a value. WebKit has other bits of badness in it as well, like missing configure checks. Remember when it was all the rage to check if the platform had char *strnstr() and then working with HAVE_STRNSTR instead of going #ifdef Q_OS_WINDOWS? Anyway, our sixteen variegated patches against Qt 4.5.3 still mostly apply, so I’ll go and experiment with them.

But actually I was trying to start updating the packages for OpenSolaris in the run up to KDE SC 4.4.0, which is still two months away. Fortunately Hajma has wrestled with KDE SVN trunk compilation and the dashboard now, so we have some idea of what’s going on in trunk and can slay bugs (happy constructor pattern seems popular again) as they show up. However, building from SVN checkouts (including all of kdesupport) is a world apart from building packages where you’re looking for released tarballs, clear dependency versioning and good documentation. Unfortunately, the Techbase documentation for KDE SC 4.4 requirements isn’t started yet as of this writing. It strikes me that there’s nothing about the parts coming from kdesupport in the 4.3 requirements either — I must have missed a memo somewhere.

Soprano just released a new version, 2.3.70, meant to work with the 4.4 beta cycle, so we can get started on that. Phonon is a bit trickier, since there’s no version check for phonon done in KDEbase-runtime (in the released 4.3.77 tarball, at least) and it fails sometime during compile with a missing phonon/globalconfig.h. The strigi website hasn’t been updated in over a year, but I know Jos has been doing releases of it — I just need to find out where to get a stable tarball.

Maybe it’s just a month too early to want to build KDE SC 4.4 against anything resembling release packages or on top of a stable software stack. Certainly when the stack that you’re delivering (various support packages, then the KDE development platform, then applications and a desktop on top of that) is very deep it can be tricky to get everything in sync, but it does place a burden on packagers. There’s a lot of stuff to update when a new release comes out, and not much time to do it in (which, incidentally, makes the KDE-FreeBSD team’s 4.3.3 packages all the more impressive to me — now if only 8-R didn’t have that little root hole).