GNOME 3.2 released!

GNOME has just announced the release of GNOME 3.2. Check out the release notes to see what’s been added. Kudos to the release team and the rest of the GNOME community who pulled together to make this happen.

Bradley and I held the release of this week’s Free as in Freedom episode a day to match the release date and you can hear us talk a bit about that as well as Matthew Garrett’s post about the UEFI issue. Since we’re often a little behind the times in reporting back about the conferences we’ve attended, we also include a brief interview from the Desktop Summit with Jos Poortvliet.

Some of the things I’ve worked on recently

It’s been a fun past two weeks, other than being sick (which was a good time to think about copyright assignment – that’s what people do when they’re sick, right?) Anyway, some of the things I’ve worked on:

  • got started on the press release for GNOME 3.2 – it’s very exciting, I can’t wait for the release next week!
  • called and emailed a couple of advisory board members, which resulted in some great brainstorming about GNOME
  • emailed new GNOME Foundation members to congratulate and welcome them. To be a Foundation member requires prior contribution to GNOME, so almost everyone I emailed has been actively engaged in the GNOME community well before I became Executive Director. Still, participation in the nonprofit as an actual member is a special thing. Since the members elect the board of directors, it’s the members that truly set the direction of the Foundation.
  • helped answer questions about the proper use of GNOME’s logo under our trademark guidelines for third parties. There’s more work to be done here, as good questions were raised about GNOME’s trademarks in response to a proposal I made on foundation-list to improve the guidelines.
  • helped with some of the logistics regarding the Montreal Summit (and made a few last efforts at organizing it in Boston). I also helped with the logistics of a couple of not-organized-yet events
  • helped SFLC work on a couple of issues that may affect all free software nonprofits, including GNOME. SFLC also helped GNOME with issues it had outstanding this week (it’s great when free software nonprofits work together!)
  • worked on a few press opportunities – more coming on those soon!

copyright assignment

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.