Bobulate

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.

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.