Dave Neary writes about the potential ills of copyright assignments. I agree with Dave that if you require a copyright assignment as a pre-condition to contribution that you will inevitably limit the amount of participation you have. It becomes just one more barrier to entry that one has to jump over.
The answer, however, is not to have no copyright assignment program in place. Having no such program can actually be quite detrimental for the reasons succinctly outlined by the FSF: you can't defend rights or make decisions on licensing on behalf of others. Limiting the number and types of individuals involved in defense and maintenance of licensing is a good reason to have copyright assignment, as it allows both more agile response and to put risk in response to things like licensing disagreements off of the individual hacker in the middle of some hamlet in the pastoral Canadian countryside (or whatever pastoral countryside they may live in).
Having some sort of copyright assignment option in place also prevents problems that can arise whenever someone disappears from the project. It's hardly fair for the future community of your project to forever be tied to licensing decisions taken by predecessors who can no longer be reached.
So how does a project avoid getting stuck in this "rock and a hard place" type decision between "keeping your community open" and "protecting the technology and rights of others"? Simple: have an optional copyright program that your contributors can engage in. This isn't "perfect" from a purists point of view, but it can make things a lot simpler down the line if it's something the bulk of the community gets on board with.
In KDE we have the Fiduciary License Agreement (FLA) which does a neat little bit of legal polka in which the signatories (the contributor and KDE e.V. in this case) swap about rights to the copyrights. After signing, both now have the ability to continue to make decisions on the copyrights and KDE e.V. can defend the code in our shared repository and make licensing decisions if needed.
"Oh no!" some will say, including apparently Dave, "But what happens if KDE e.V. goes evil?! Now they can do bad things!" Well, all I can say is that if you've signed your rights away with no understanding in place as to what the other party can do with those rights then, yes, you made a silly move and deserve everything you get.
With KDE's FLA, we have another document that goes with it: the FRP, which is pronounced "eff are pee" if you are a lawyerish type or "frap!" with a good amount of emphasis on the 'ap' if you are a bit more light hearted. The frap, er... FRP lays down specific guidelines as to what KDE e.V. can do today and in the future. It's a separate document to keep that part out of the courts should we ever need to defend your rights, since it's only really useful between the signatories and could give a GPL violating defendant enough rope to play out a case for a long time playing "let's define this other term first" with the court. The important part is that it protects the rights of the individual without requiring us to enter into some mistrustful standoff based on "I own my property, and I'm not going to share any rights with you so you can't screw me later! Bwuahaha!"
So the FLA is a socially responsible relationship that displays respect for both the individuals and the community simultaneously. It lives in balance between a proper level of trust between parties (e.g. not too much) and respect for the current and future legal health of the project.
When it comes to corporate entities holding all the rights, something Dave also notes can be dangerous, my recommendation is the same: get an agreement with them first before signing over anything. We did this with the Free Qt foundation and it helped preserve the future of Qt quite nicely even though there was a single copyright holder. This made the decision to relicense Qt under the LGPL very easy while preventing the proprietization of Qt.
In my experience when people talk about the danger of assigning copyrights to a company, the reaction to the suggestion that they get something signed first that lays out the rules by which the agreement should be maintained and dealt with the in the future is usually met with "That's a good idea ..." and a bunch of silence. Then usually a few days/weeks/months later they'll repeat the same argument as if there was no good answer.
Oh, and if you're reading this, Dave: Trolltech is now Qt Software, the commercial version of Qt is only different in licensing terms from the open one, Qt was never "community code [they] forked commercial versions off of" (when they did use community code such as Phonon or Webkit, they stuck with LGPL and multiple-copyright holder licensing) and since then Qt Software has announced that they are opening their repositories for public involvement (something I wish was already completed, but these things take time to arrange organizationally and legally). :)
Finally, to everyone who has contributed copyrightable materials to KDE in any meaningful manner (source code, artwork, documentation, etc), please consider signing an FLA. I have. Why? Because I feel it's the most responsible way of handling my relationship with the KDE community in terms of sharing governance of my contributions at no cost or risk to me.
KDE e.V. is currently having some legally sound boilerplate language for signers to pick from for the "what contributions this covers" created for us (for my personal KDE FLA I used a broad "all copyrightable works produced by me in the kde.org repositories now or in the future" phrase, but we want to get a gradient of legally accurate phrases you can pick from to paste in there). We will also be hosting a FLA signing area at this year's Akademy so you can do this in person. It takes all of 5 minutes. You might even get a cookie or a hug or both from Adriaan for doing so. We're still working out those details. ;)
Also, depending on regional law and employee agreements in place, companies that contribute to KDE can also sign an FLA on behalf of their company's contributions rather than have each of your employees do so. It's a great way to show your support for the community you are helping to make better and getting so much from in return.
p.s. This is yet another one of those topics where I see a lot of either/or argumentation ("assign copyrights for the good of the project!" vs "assigning copyrights is bad") when the reality is a lot less black and white. There are balanced, middle-path answers to be had if sought out. The opt-in FLA/FRA is one such answer. It's interesting how often the best of intentions (in this case "protecting our creations") can so easily devolve into either/or thinking that produces no truly good results in any direction.
Wednesday, April 08, 2009
Subscribe to:
Post Comments (Atom)

7 comments:
"It's hardly fair for the future community of your project to forever be tied to licensing decisions taken by predecessors who can no longer be reached."
Why? I don't see how you've arrived at that conclusion.
What about licensing decisions taken by predecessors who can be reached, but are happy with those decisions and do not wish to change them. Is it fair for the community of a project to forever be tied there?
Why would you assume that those predecessors are likely to be so unattached to their licensing decisions that they'd love to change their mind just as soon as you've told them your new plans for their work?
Since I hope at least some of the KDE guys will be present at this years LinuxTag in Berlin, is there any chance I can sign the FLA there?
"including apparently Dave"?
I made it pretty clear that there is a difference between assigning or sharing copyright with a non-profit, where we also have the by-laws, membership rules and history of the project as factors which afford trust, and a company where we have only the assurance that the corporate winds are blowing in the right direction at this moment.
I think I was also pretty measured in pointing out the down sides of not having a copyright assignment policy, including (as you point out) making licensing changes easier.
I like what KDE eV have done in this area, and I'll be pointing to it as a best practice in the future, but I think that (as usual) we agree far more than we disagree - so it is a bit of a pity that you slightly misrepresented my position with the above off-the-cuff remark.
Dave.
@grok-mctanys: "Why?"
because it renders the project unable to act and adapt as needed or desired. if you are no longer part of the project, you already have a far less interest in it, but if you are unreachable then there is no way to even know what your position is and risk holding up the entire project in your absence. that is not fair to those who continue on working on it.
consider the unfortunate but inevitable conclusion of every person's life in death. should projects end up at the mercy of their heirs (how many people have willed their copyrights to a specific person with specific instructions?) ...
"What about licensing decisions taken by predecessors who can be reached, but are happy with those decisions and do not wish to change them. Is it fair for the community of a project to forever be tied there?"
that is a completely different situation: if the contributor is still in communication of course they have a right to a say over their historical works.
such people need to either not sign a copyright assignment agreement or ensure that the guidelines that govern the agreement (e.g. the FRA in our case) align with their decisions.
"Why would you assume that those predecessors are likely to be so unattached to their licensing decisions that they'd love to change their mind just as soon as you've told them your new plans for their work?"
there is no such assumption. that's why there is an FLA and an FRA: it outlines what the boundaries are.
the idea is to make sure that both align with your position as a contributor and if that is achieved then sign them so that the project is able to do what is necessary but won't be allowed to do what is against your wishes in absentia.
and, of course, you don't need to sign an FLA at all.
remember that an FLA is an explicit agreement to the types of future decisions that can be made. no assumptions.
@milianw: yes, i'm sure you can. print out a copy, fill it in the best you can (or wait until you find one of the e.V. board members) and track down one of the e.V. board members at LinuxTag. i'm not sure who will be there this year .. but i can find out :)
@Dave Neary: "I made it pretty clear that there is a difference between assigning or sharing copyright with a non-profit [..] and a company"
i actually didn't get that from your blog entry at all :/ sorry for the misunderstanding. you may want to make that point clearer in future communication on the matter.
perhaps in your desire to make it clear the dangers of mandatory copyright assignments (esp without guidance as to what is allowed under that agreement) you gloss over the "how to do it well" concepts a bit too much? :)
"I think I was also pretty measured in pointing out the down sides of not having a copyright assignment policy"
i don't think many people would come away after reading your entry thinking it was reasonable to have a copyright assignment program in place. in fact, i think it painted very clearly in favour of the possible bad things.
from your blog entry:
"To summarise where I stand, copyright assignment or sharing agreements are usually unnecessary, potentially harmful if you are trying to build a vibrant core developer community, by making bureaucracy and the trust of your company core issues for new contributors. There are situations where a JCA is merited, but this comes at a cost, in terms of the number of external contributors you will attract."
and while i do 100% agree with the hazards you note, the conclusion i arrive it is different, namely:
it is good and responsible to have a copyright assignment program in place, though it shouldn't be mandatory and should have clear guidelines as to what it allows and doesn't allow.
"I think that (as usual) we agree far more than we disagree"
probably :)
most important is that the F/OSS community gets a balanced position on these kinds of matters. my aim was to bring some of the balance missing in the conclusions as written in all the blog entries on the matter.
btw, as a matter of continued clarification on the matter of Qt as raised in your blog: Trolltech's commercial releases of Qt were identical to the Free Software releases. the only difference was the inclusion of some plugins, the Oracle DB one being the most obvious one, due to those plugins not being Free software due to the other vendors (in this case, Oracle). Trolltech had no control over the licensing of Oracle's products, of course.
so other than the licensing differences and an optional plugin or two due to 3rd party vendor licensing, they were 1:1 identical.
There was also the ActiveX widget in the Windows version, which was used notably by Wengo in OpenWengo, and caused me some hardship when I was working there.
I'll admit that the changes were small, but this change in particular bit me (and underlined for me that there were differences between the GPL and commercial editions).
"if you are unreachable then there is no way to even know what your position is"
"an FLA is an explicit agreement to the types of future decisions that can be made."
I still don't get it.
The license of the project, which a developer has explicitly agreed to by the very act of making a contribution, is already a statement of their position on what can be done, now and in the future, with their contributions.
Why not just put the terms of the FLA in the license?
@grok-mctanys: "Why not just put the terms of the FLA in the license?"
the license and ownership of the license are two completely different things.
that said, there are several situations that "putting it in the license" just doesn't cover, for instance:
* someone violates the GPL license on your code. only the copyright holder can make claim on that violate. with the FLA, KDE e.V. (or our legal partners on our behalf) can do that, preventing you from (a) having to be around or (b) having to incur the expense and risk of being involved in such legal dealings.
* in the case of GPL v2 and v3, many people were not willing to to license their code as GPLv2+; after all ... what if v3 wasn't acceptable? so we had a lot of GPL v2 code. GPL v3 comes out, we discussed it as a community, decided it was something we should support (well, had to because of things like samba, tbh) and so we had to go around and make sure all our libraries were license GPL v2+. without that we couldn't link against things like samba. had we any code that was both GPL v2 only _and_ whose author we couldn't contact we'd have to either be stuck (and lose samba, openchange and others) or else rewrite that code. with an FLA, it wouldn't be an issue. we could take a decision as a community.
there are other situations, but these are the most common and most serious.
you can't provide for either of the above in the license for fairly obvious reasons (the first example because it has nothing to do with licensing and everything to do with ownership (and no, you can't just slap someone else's name on your work in many countries), and the second example because the license was explicitly conservative awaiting future developments)
Post a Comment