Home [ade] cookies

Postscriptum and prescription of the FLA

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

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.

Tags: , ,