Bobulate

The Fiduciary License Agreement (FLA) between KDE contributors and KDE e.V. is one that assigns those assignable rights derived from authorship from the original author to the fiduciary (i.e. KDE e.V.) and then assigns, non-exclusively, the rights on that work to (0) use, (1) study, (2) modify, (3) distribute and (4) authorize third-parties for the same, back to the original author.

Ugh, that’s a lot of legalese, but that is also why my slogan for the KDE project is “I talk to lawyers so you don’t have to.” It’s a wonderful thing that Sebas has been talking to KDE contributors at LinuxTag and has obtained a number of signed FLA documents. That means that a good chunk of important KDE code is now actually owned — in the sense of copyright — by KDE e.V. Sebas quotes our friend Carlo Piana (he received the pineapple fortune cookie award for Coolest Lawyer, once) describing an FLA as follows:

The fiduciary licence aims at simplifying this process, by assigning the copyright to an entity as KDE e.V. which is not “scalable” and therefore provides sufficient safeguards as to the possible hijacking of the project for nefarious reasons.

Now, I’m not entirely sure about that “scalable” there. KDE e.V. is scalable, in the sense that with individual donations and supporting members we have the resources to support the growing developer and contributor communities as well as serve users in general though efforts like UserBase. I think what Carlo meant is “saleable”, in the sense of “you can’t buy a community.” I’ll have to ask him, next time we meet.

So you can’t buy a community and you can’t buy a non-profit association with strong checks and balances in its constitution. This is good, and having a strong copyleft Free Software license applied to the software as well ensures its long-term availability (don’t let that link fool you, though: the KDE platform libraries are LGPL licensed, so you can, if you really feel it is necessary, write proprietary applications on top of it — but consult your local counsel for license advice). The main issue that the FLA tries to solve is really one of license and responsibility fragmentation.

When multiple authors work on something, then each author has a share of the copyright on the creative work — at least, each author who contributes something original and creative enough to be considered a creative work. This leads to multiple authors and the requirement to agree on copyright matters between all the authors in a particular work. This fragmentation can consume considerable resources if ever there is a particular need to deal with all the rightsholders for one particular work.

Note that KDE contributors — all of them — have traditionally been rather lax in maintaining the copyright headers in our sources. We do not maintain a comprehensive list of authors in each file, nor do we follow GPLv3 article 5.a very well, in general. Figuring out exactly when 5.a applies is something I’ll leave for the real lawyers and another blog post. In any case, a consequence of the signing of the FLA’s by a number of authors is that for their work the copyright header should be changed to

Copyright [years] KDE e.V. <kde-licensing@kde.org>

Ideally we would include a postal address (of KDE e.V.) as well; the whole point of this exercise is to make it really darn clear who to contact for licensing information and to make sure that we clearly claim the copyright on these files.

Note also that the KDE licensing policy is lacking in some details and allows poor licensing hygiene by potentially mixing incompatible licenses: we have had license checks (Tom Albers has now and in the past been instrumental in moving that forward). Just because we’re not doing things optimally now doesn’t mean we can’t move forward and improve things (this applies in many fields of endeavour).

The FLA used by KDE e.V. has a big blank where you can fill in which works are covered by the FLA. There is also a pre-filled form (PDF, 50kB) which identifies the works using standard language referring to your SVN account name. That should make filling things in easier. If you didn’t sign up at LinuxTag, you could print that, fill it in, and mail the form to the KDE e.V. office. We maintain a list of signed FLA’s as well, to keep track of who has done so — let me emphasize that the signing of an FLA is optional and the choice to do so rests entirely with the individual whose creative work is covered (or would be covered) by such an FLA.

So, by concentrating the copyrights held we reduce fragmentation; given that we have a strong basis to build on with careful checks and balances in the consitution of KDE e.V., this is an improvement for the currently-hypothetical case that we would want to (or have to) relicense large parts of KDE to some other Free Software licence.

There are additional checks placed on any relicensing attempt on the part of KDE e.V. They were added as a sort of backup guarantee that KDE e.V. cannot do evil in relicensing code. However, at the same time these relicensing restrictions (written down in the Fiduciary Relicensing Policy) reduce the effectiveness of the FLA itself, because the FRP says that we at least have to try to get permission from the original author before relicensing. However, it does mean that we get to judge “reasonable effort” ourselves instead of letting someone else do it. So in the end we (as in KDE e.V., representing the KDE community as a whole) do have a stronger grasp of the code in order to be able to defend it if needed.

And, since the rights are transferred back in a non-exclusive license to the original author, the original author may fork or relicense if that’s really absolutely necessary. I should point out that that should be a real last resort and that working with the rightsholder (i.e. KDE e.V.) should be preferred. Remember, KDE e.V. exists to support (“we exist only to serve”) the development of KDE software, including the KDE workspace, KDE platform, and KDE applications. If there is some perceived need to fork, then somewhere there’s a misunderstanding of what the constitutional aims of the association are.

But I digress. There is an FLA, and it is signed by many people. Perhaps many more will do so at Akademy this year.

So where do we go from here? Maybe next weekend, we can take over the world.

The answer to this question actually depends on which hat I’m wearing. The KDE hat says: continue to consolidate licensing, pursue license checking and accuracy across the entire codebase and behave as an exemplary community software project with regards to legal matters.

My FSFE hat says that we need to take the concrete experience with KDE and with Bacula and introduce other projects in Europe and the rest of the world to this kind of lightweight legal housekeeping. The FLA has been translated into many languages, but I feel that having used it in KDE it could use a little extra precision. Also, any legal document intended for use by non-lawyers probably needs an implementation guide and HOWTO. And most importantly, those need to be well-known to projects who might need such documentation.

The modh coinniollach is not as difficult as it often seems (…) all you need to do is to delete the ‘dh’ from the aimsir fhaistineach and to replace it with ‘nn’.

My brother brought me those instructions out of an Irish paper; I’m sure it’s good grammatical advice, but I find I’m lacking the knowledge necessary to put the advice into practice.

The reason I bring this up is not one of Irish grammar (though you may consider it a shout out to my friend Shane in Japan), but one about context and documentation. I’m an IRC user. Since 1994 or so, and for most of that time I’ve been [ade] or adridg on the networks I use (Ade Lovett used to be without the brackets). For most of that time, screen + ircii or irssi have been my tools of choice — I never could get quassel to do anything useful on the operating systems I use, and konversation, while nice, doesn’t survive my KDE session. So it came as a bit of a surprise to need to use jabber; this is used for FSFE communications, so I started up kopete.

Suffice to say it’s been an extremely annoying three hours of futzing about.

There’s not much point in writing bug reports against kopete from KDE 3.5.10, so I won’t (scratch 20 minutes because a newline got into the server’s hostname when pasting it into the configure dialog); in addition I can’t always tell the difference between a bug and myself being stupid (groupchats are totally different from contacts). The only thing I can sensibly do is add some notes to the wiki for the congenitally IRCed. Now, having written a sentence like “use RMB on the systray, pick and identity and then ‘Join Groupchat…'” I realize that there’s an awful lot of context missing there as well (and it’s o-so-disrespectful of tablet users). I take my cap off for the KDE Userbase editors, for sure.

Sadly enough, this entire tale could be retold with “pdflatex” in the place of IRC and “OpenOffice” in the place of Jabber. I now have a working OOo on FreeBSD 7-STABLE without a JRE, but that too took a measure of doing. It’s just the price you pay when you start interacting with different communities with different tools.