Bobulate

The terms of service of a website vary from the stupid to the sensible, from short to very lengthy. The Facebook terms, for instance, have been re-worked in an attempt to be plain English and are very wordy indeed — but not stupid. No, stupid is a website with terms saying “This file may not be downloaded from this site.” Imagining (if you have any technical knowledge at all) how someone can come up with that is likely to leave you with a sprained hindbrain. Not recommended.

Now, it’s sensible to read the terms of use of a website; but not necessarily mandatory. Often there’s a checkbox saying “yes, I have read the Terms and Conditions” (with a link to the T&C). You can still check that without actually having read the legalese. Perhaps a setup where you must click on three randomly chosen highlighted terms in the T&C text before you can continue would improve matters? In any case, you don’t necessarily have to read the T&C, so have you really accepted them? Ars Technica reports on a recent court decision that says that the terms are enforceable even if you haven’t read them. There’s some limitations there, on the reasonableness of the terms and I imagine that a lot depends on how the T&Cs are used. Via Ars you can end up at two different reports at TechDirt, one for enforceable and one for non-enforceable. In other words, the jury (ha!) is still out on this one, but it’s worth keeping in mind when designing a site with a click-through agreement.

The FSFE sites have no user agreement (this is something we should fix, actually, since we both provide a service and publish user content). KDE’s UserBase has Guidelines and a code of conduct, which don’t cover all the bases, but it’s a start. Gitorious has something that looks a lot more like traditional terms of service — one might argue at some point whether not-reading those terms allows one to escape from the choice of venue, in light of the two court decisions listed above.

LinuxTag in Berlin is one of the recurring and very fun events, both on the community and business sides of the Free Software equation. The call for papers is open until the 29th of January. The NLUUG spring conference on systems administration has a call that is open until tomorrow, but tends to be somewhat lenient in the submission deadline. I think it would be cool to have a talk on “Konsole as a sysadmin tool”; I don’t think general Free Software talks fit the bill all that well. There will probably be an FSFE stand at the conference, though, to talk about licensing and the importance of Free Software in sysadmin tasks, even if it’s not an all-that-obvious fit for the conference theme.

Though the call for papers closed a long time ago, you can still attend CampKDE starting on Friday. This is the North American get-together of KDE developers and users, in San Diego this time around.

Much of the time I work from home for the Freedom Task Force, which is the “legal department” of the Free Software Foundation Europe. It’s nice to work from home, although my colleagues know that that also means long lunches (picking kids up from school, feeding them, bringing them back) and occasional emergency stops. On the other hand it also means that I can go on til all hours of the night if needed. (I won’t claim that’s always efficient — if I wanted to be efficient I might follow Isabel Drost’s lifehacking approach).

But sitting at home is not always the best thing to do: it’s lonely (at least as far as those colleagues are concerned) and it can be difficult to bounce ideas off one another. No matter how much VoIP and Jabber and whatnot we throw at it, nothing really beats a planning session over lunch (except maybe one over dinner + drinks). In addition, it’s fun to sit together and just get work done: that’s the old “hey, look, I just fixed bug #17!” approach which works well at software sprints and which conveys progress so well.

And let’s not forget the benefit of having someone watching over your shoulder, to prevent unfortunate cake-recipe posts and the like.

So, with all that in mind, I’m in Berlin this week for a few days of intense FSFE office time. I’ll be working with Matthias on website things, Karsten on planning and sales and Hugo on legal things. Evenings will probably be a little more KDE-themed as a way to unwind — when visiting the Kapital of Germany I might as well, and anyway I owe Claudia a lovely home-cooked dinner. One KDE thing in particular is going over the Fiduciary License Agreement that KDE e.V. uses and providing better guidelines for its use and administration — as well as checking that it still matches the policies used. That’s one of the cases where work-work and volunteer-work collide (in a pleasant fashion).

So, Berlin. See you around (well, at the office, which is in Linienstrasse).

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.

Now I’m prime again, not square, I thought I’d take a moment to jot down what’s really precious to me. That’s my family (Mignon, Mira and Amiel), good food (wine, cheese and coffee), responsible lifestyle choices (bicycle, local organic vegetables and the train). I work to live, and those are what I work for.

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

Straightforward simple carrot cake. Still the subject of a classic joke in the Netherlands (“vies hé?”).

Non-straightforward is my latest proposal for fixing the issue of decades once and for all. Obviously the year 1 AD started on December 25th, 4 AD, as calculated by the best scholars. So 10 years later is December 25th, 14 AD. But — and this is important — on September 2nd, 1752, 11 days were skipped, so the end of the 175th decade isn’t December 25th, 1754 AD but 11 days later, on January 5th. It’s a good thing the reform of the Roman calendar under Julius Caesar was done before 1 AD, or we would have to shift by two months to compensate for the newly created January and February, as well. So remember, we can celebrate the last day of the decade in just 1460 days.

One and a half cup grated carrot. Three quarters of a cup of sugar (I use cane sugar). One tbsp. “koek en speculaaskruiden” or an equivalent mixture of cloves and cinnamon. Pinch of salt. Mix thoroughly, then stir in two eggs and half a cup of cooking oil (sunflower or corn oil). Whisk with a fork until foamy. Mix in one and a half cup self-raising flour (or plain flour 1 tsp. double-acting baking powder per cup of flour). Pour into a bread pan (what are the sizes on those things anyway?) and bake at 160C for 40 minutes or until a fork comes out clean. Frost with icing sugar and mascarpone or cream cheese.

Optionally you could add raisins or nuts, but I usually do not: the kids and neighbours don’t like them, and whenever I end up baking I make too much and give away plenty all ’round.

A little while back, Michael Meeks published a lengthy piece about copyright assignment (not nearly as lengthy as the articles he links to on untangling Wittgenstein’s net). Go on, read it (Michael’s stuff, not the net). It’s worth your time. When you get to the bottom, follow the link to Dave Neary’s take on assignment as well.

I’m going to take the time to respond to Michael and Dave with two different hats on: my FSFE hat (work-work, where I do legal and licensing stuff in the Freedom Task Force) and my KDE hat (volunteer work, where I have hacked on various bits and pieces for over a decade). This isn’t an entirely independent article on assignment, but looks at their comments on it. First off: there’s no right answer. Just like I say during my licensing talks at conferences: it (licensing or copyright assignment) is a choice that needs to be made, and that choice needs to be compatible with your goals, your morals, your business needs (if any), your sense of community (if any) and your desire to deal with administrative details.

One or two points of fact, though: the FSF does not require assignment — not for all GNU projects, at least. For some, yes. I made this exact same mistake at the GNU hacker’s meeting in Gothenburg last month. After all, it’s easy to find articles stating that the FSF requires assignment — even on the FSF site — and not so easy to find ones that do not. After all, it’s hard to search for the absence of a document. Andy Wingo can probably point out some.

Qt is still subject to a contributor agreement, but it is not a copyright assignment, but rather a license — in other words, the original author retains the copyright but grants the Qt organization (that is, Nokia Oy) a very broad copyright license (including sublicensing) and a patent license (for patents covered by the contribution). There’s some pretend remuneration. There’s little in the way of protection offered to the contributor, but I think it would take some far-fetched scenarios to find a patent danger in there (but do comment on their existence).

Michael’s examination of assignment forms (including Sun’s SCA) is missing one form that is used in Europe (and elsewhere), and that is FSFE’s Fiduciary License Agreement (FLA). This is a copyright assignment form — no patents involved, which makes some sense because there’s no software patents as such in Europe — that assigns those assignable rights to a Fiduciary, and then licenses those rights back. The assignable rights vary a little by jurisdiction (and Europe has lots of them), so that makes the form a little bit longer than it might otherwise be. In addition, there are variations as to whether you can assign future work or not — things like that.

(1) Subject to the provision of § 2, Beneficiary assigns to FSFE the Copyright in computer programs and other copyrightable material world-wide, or in countries where such an assignment is not possible, grants an exclusive licence, including, inter alia:

Here the FSFE is the Fiduciary. The Fiduciary is a party you trust to handle the copyright responsibly. By default you own the copyright — and I assume you trust yourself to do the right thing with licensing on the work you do for yourself — and the rights (most of them, anyway) are assigned to your estate. Presumably you trust your executors to do the right thing as well.

That actually leads into one of the reasons that you might want to think about copyright assignment — or at least about what happens with your code and the rights to your code when you’re no longer actively involved with the Free Software projects you contribute to. It happens — people drop out, no longer want to participate, or indeed pass away. Copyright assignment is one way to manage the risk (and possibly administrative burden) attached to something long-lasting like copyright.

Back to the FLA: the effect of clause 1 is that the Fiduciary gets control over the rights to display, reproduce, distribute, create modified or derived works and to allow third parties to do so. While re-licensing isn’t explicitly in there, the authorization to third parties implies it. There needs to be an exclusive license so that the Fiduciary knows they are the one party who may act as if they hold the rights. So once the Fiduciary has the rights, what happens?

(2) FSFE grants to Beneficiary a non-exclusive, worldwide, perpetual and unrestricted licence in the Software. This right’s [and licence’s] scope shall encompass and include all the rights [and licences] specified in § 1. Furthermore, FSFE grants to Beneficiary additional nonexclusive, transferable license to use, reproduce, redistribute and make available the Software as needed for releases of the Software under other licences. This re-transfer shall not limit the scope of FSFE’s exclusive licence in the Software and FSFE’s rights pursuant to §1.

You get it all back and can continue to license, sublicense, modify, etc. the work. In other words, you can continue to behave almost as if it were still your copyright. This is important because the Fiduciary wants to support the use of the software as much as possible. So you’re even free to create a derivative work and make it available under another license. I have not considered whether it would be possible to release it under a proprietary license — there might be some tricky interactions between the assignment and the re-assignment.

This FSFE FLA is available under a license that allows modification, so you can take the FLA and modify it for your own purposes. KDE has done so. The KDE FLA adds some restrictions to what the Fiduciary is allowed to do in terms of relicensing, but these clauses were added after some lengthy deliberation.

In any case, an FLA is an adaptable mechanism for assigning copyright to a Fiduciary — some party you trust. Just having the tool available doesn’t mean much, though: there are issues of policy as well. To return to the beginning: some projects / organizations have a policy of requiring assignment (though some instrument). Others do not. KDE is unusual in that it makes it possible to assign copyright to the organization, but does not require contributors to do so.

So let’s carry on with Michael’s comments.

To whom are you assigning it? This is a very important question — because you need to trust the fiduciary. Michael points out that a non-profit (association or foundation, with a constitution written to support particular goals) is probably a better Fiduciary than a corporation. The reason for that is relatively straightforward: money. You can buy a company, buying a non-profit is much more difficult. Not impossible, mind you. The FSFE acts as Fiduciary for a few projects. KDE e.V. acts for its own project. When asked, I tend to advise finding an existing trusted party (like FSFE or KDE e.V. or perhaps the Linux Foundation) who is willing to act as Fiduciary (FSFE takes it case-by-case, KDE e.V. is probably most interested in KDE-technology related projects, and I can’t speak for the Linux Foundation but they strike me as a potential partner). Setting up your own organization is possible, but has some costs. Those are costs in filing and administration, in setting up meetings, and providing long-term viability to the organization.

An assignment document should have an escape clause if the Fiduciary turns out not to be faithful (fides is Latin for faithful, more-or-less). The FSFE assignment has such a termination (or auto-revert) clause. So does the KDE one. So does the FSF’s assignment. Michael points out a few others, and such a clause should be seen as an additional form of risk-mitigation

Benefits and risks: Note well that “single owner” and “re-licensing” are listed as both a benefit and a risk. Which is as it should be: a single copyright holder also means a single point of failure (in terms of a take-over) while multiple holders means many points of failure (in terms of necessary re-licensing or negotiation). But a single copyright holder means success because it can manage negotiations, sublicensing, re-licensing and assets (in the sense of “your software has value to its users” even if not monetized) and multiple copyright holders is a success because of its resilience in the face of take-overs and flexibility in accomodating different viewpoints.

Again, it depends on what you think is most important and how you weigh the risks. I like the KDE e.V. approach with a non-profit association that holds a fair amount of the rights — but nowhere near all of them, on any part of the code — and then multiple individual (and corporate) rightsholders. That makes it both resilient and possible to go to court saying “we (KDE e.V.) represent a 30% stake in the copyright in this work”.

That last item relates to “defending the code.” There simply haven’t been enough cases of license enforcement to say whether a centralized copyright holder is useful or not. Harald (through gpl-violations.org) is very successful in enforcement in Europe, but he has rights (including assigned copyright!) to some well-defined and popular pieces of the Linux kernel which are fairly easy to detect. Besides which, not every developer wants to get involved in this stuff, so it might be difficult to find any individual developer to enter into a copyright enforcement suit.

On re-licensing I would add that “license tourism” by a Fiduciary should be avoided, perhaps by wording in the FLA, perhaps in the constitution of the Fiduciary. You don’t want to start with (say) the GPL and end up with the code under something totallylargely incompatible (Artistic). So once again: you need to trust the Fiduciary and set up some policy to make sure it all works.

Barriers to entry: This is, in fact, a biggie. It depends on the community creating the software whether asking or requiring assignment will be a barrier or not. I can imagine that in an established loosely-knit community of individual developers (read: the KDE community) introducing assignment is both scary and seen as a barrier to entry. That’s why you could choose the optional-assignment route, for partial centralization. In a corporate led project, assignment may be much less of a barrier. In mixed settings, I think optional-assignment or a really darn good explanation is needed (an explanation that I won’t be able to provide here, as it depends very much on individual circumstance).

Dave writes very briefly: he refers to assignment as a “superfluous barrier to entry”. I disagree with that — it can be superfluous, or, given explanation and circumstances, can be quite necessary. For a project with a community of individuals with no monetization of the software itself planned and an established brand and a broad scope (e.g. desktop projects) it probably is the former.

It’s at this point — in listing items under barriers to entry — that I feel Michael is lacking clarity. There’s a number of problems listed, in the moral, social and organizational spheres, all of which may influence the influx of contributions and affect user uptake of the software. However, I don’t see how these are specific to copyright assignment. When thinking of participating in a project, “the paralysis of uncertainty” can strike for any of a number of reasons. Licensing? Trademarks? Maybe the project is run by complete jerks only I haven’t realized it yet? Perhaps Mr. Knightly does feel affection for Jane Fairfax, and merely dissembles to poor Harriet Smith as a cover? [Sorry, I’ve been reading Jane Austen’s Emma and it will lead to any number of conspiracy theories.] The same applies to corporate unwillingness and scarcity: these are not issues that are particularly brought to a head by copyright assignment, but always exist in open collaborative projects.

The “death of trust” (gosh, isn’t that a melodramatic title) touches on two issues: the trust expressed (or lack thereof) by demanding an agreement beforehand and the issue of recognition when rights have been assigned. The former can be a real barrier to entry — but that was Dave’s point. The latter is easy to deal with, and indeed should be dealt with, by identifying individuals where that makes sense. For instance, my contributions to KPilot (since deceased) should be administered like so in the copyright header in the source files:

Copyright [year] KDE e.V. [contact email]
Author: Adriaan de Groot

The reason for still listing individual authors even after assignment is because of moral rights — pesky non-assignable, non-transferrable, non-heritable (I think) rights. Plus, it’s a means of giving recognition (if so desired) while correctly stating where the copyright (or exploitation rights) resides.

Carrying on to the end — from here until the Recommendations at the end of Michael’s piece I have trouble understanding what the problem is, unless it’s “do not assignments to untrusted parties who have an incentive to proprietize” — we find the Recommendations. Sensible recommendations, by and large. I especially appreciate the suggestion of a proxy for approving license updates — I had not seen that before. But all in all, it comes down to a very old Dilbert punchline: “try identifying the problem, then solving it.” That means considering the role you play (contributor, manager) and the style of contributions to the software and intentions for future growth.

[[ No, wait, let’s make that the new decade’s recipes. I’m with the “convention determines usage” on the decades front: the 80s do not include 1990. Oddly enough, I side with the centuries-and-millennia from one group, so my decades and centuries don’t run in sync. I guess it’s all about the Ordinals vs. the Cardinals (weren’t they from St. Louis?) John Layt, are you going to support that feature too? ]]

So, baking. I’ve taught Mira how to crack open an egg into a bowl for baking a cake without getting bits of shell and gunk into the batter. It cost a half dozen eggs over a bunch of practice sessions, but now I can delegate that bit to her. She’ll be baking bran muffins all by herself, soon. But today we made a pecan cake which turned out really well, so I thought I’d share the recipe. This also serves as a demonstration for what you can get if you’re one of the lucky winners of the Freedom Food donation drive from the FSFE.

Pecan Cake: Mix three (3) eggs, one cup of sugar, half tsp. of salt and one tsp. vanilla extract with a hand mixer on high for about 10 minutes. Add 1 cup of chopped or whole pecans and one cup self-raising flour (maybe a tad more). Mix briefly until all blended, then in the oven at 160C for 30 minutes or until a fork comes out clean. Frost with 100g mascarpone and 100g icing sugar and 2 drops lemon juice.

See, my recipes, like my time-reckoning, use a mix of units and conventions. Basic stuff gets North American units applied, but I’ve never used an oven that didn’t have a scale in centigrade (well, except during CampKDE last year, where I baked cookies for most of the attendees, but that was .. exceptional, shall we say).

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.