copyright assignmentSeptember 17, 2011 1:31 pm Uncategorized
I’ve been very overdue for a post – I’m under the weather the past few days, so decided I need to focus on my ailing blog!
One of the recurring conversations since the Desktop Summit is the subject of a panel discussion that I moderated. There has been some talk of the panel online but since I was the moderator it was my responsibility to stay neutral to drive the conversation. So I didn’t really have the chance to chime in with my own opinion.
I did get a chance to discuss this issue with Bradley on a recent episode of our oggcast, Free as in Freedom, which we recorded around a talk by Richard Fontana that he gave at OSCON last month. I think it’s worth setting out my views here too, since it seems there’s quite a bit of strong reaction around this.
I’m only going to talk about one specific part of the issue here: when (if ever) does it make sense to grant some other entity the right to relicense your code or enforce a copyright on your behalf? This can be accomplished by “copyright assignment” or by “CLA” (license agreement), and it’s not the mechanism by which that grant is given (either CAA or CLA) that I think is of interest, it’s the concept of the grant that we should be evaluating. To make it easy, I’m just going to call it a relicense grant and an enforcement grant. I’m also mainly going to be talking about projects that have chosen a copyleft license.
The way I see it, there are a few reasons to give these grants to someone else:
- to allow them create a proprietary version of the codebase later to promote a for-profit business model
- so that they can enforce the copyrights on your behalf in case somebody violates the license
- to provide for relicensing the code to deal with some license incompatibility or to deal with some deficiency in the original license.
I think the first bullet point is easily to understand. Not to over simplify too much, but most developers aren’t interested in allowing someone else to make a proprietary version unless they’re part of that for-profit enterprise in some way. If they were interested, they probably would have chosen a permissive license.
The second point touches on another controversial area because not everyone agrees whether enforcing copyleft licenses against infringers is the right thing to do. By giving an enforcement grant, you leave that decision up to someone else. You also allow someone else to take over the hassle of dealing with enforcement. On the other hand, if you give no enforcement grant, you can enforce against an infringer yourself. (In the United States at least, you don’t need to aggregate all of the copyright holders in a work to bring an enforcement action.)
The third point is one that I think a lot of folks underestimate the importance of. I’ve had to work on relicensing efforts once in a while as a lawyer, and I think it’s something we may see more of in the future. Sometimes code may need to be relicensed in order to incorporate other code that’s licensed under an incompatible license and a new feature can’t be added without addressing the situation. Sometimes there’s a deficiency discovered in the license. We just don’t know what the issues will be down the road and whether the licenses we have are written to protect our software in case there’s a change in the law or some other fundamental change in the way software is treated. For example, I can imagine some change in the law with respect to the warrantees provisions that would beg for some adjustment to the license text.
Once you are trying to relicense a code base, it’s a lot of work and if the contributors are diverse it’s often impossible to track everyone down. Sometimes developers’ contact information has changed and they’re no longer in touch with anyone in the community. Sometimes, even, the developer has died, and you end up having a painful discussion with the surviving spouse or family, explaining why free software is important and why they should relicense the deceased’s copyrights. In either case you can be stuck rewriting pieces of code and spending a lot of time sorting out logistics.
I think there’s already a lot of sentiment against making these kinds of grants, but I think a lot of that is a knee jerk reaction to wanting to avoid proprietarization of the code base. I think that an appropriate solution can be more nuanced – give these grants, but only to a nonprofit organization with good governance. Good governance should include a promise as to how the relicense grant will be used. There should be an explicit contractual restriction on proprietary licensing. There should also be safeguards in place regarding the nonprofit governance itself. In my view, a good way to do this is to make sure that the nonprofit has some kind of check on its decision making power. A nonprofit with members, say composed of the the contributors, that can veto action by the board or impose restrictions as to organizational activities is more likely to be trusted over time. Unlike a for-profit entity, a nonprofit structured in this way would be beholden to the very people who have granted their rights to it. This can also be accomplished by ensuring that the organization has a tightly written mission statement and recognized nonprofit purpose specifically for free and open source software or through a board that is somehow especially trusted for some other reason.
The FSF has pioneered this effort by using an assignment agreement that implements a contractual restriction on relicensing and by encouraging developers to license their code under a certain version of the GPL “or later”, giving FSF the ability to fix licenses over time. For some, however, the FSF is not their preferred organization to do this but I don’t think that means that the idea of relicensing and enforcement grants should be rejected categorically. We need to create safe stewardship for our software going forward and we need to be ready for whatever lies ahead. Developing nonprofit homes for these grants that have the kind of governance I describe above could be the answer.