I've written a brief FAQ about some of the changes in the latest draft of GPLv3. It addresses some of the big questions that have come up in the recent discussions about the license, and I'll add more answers as I see them. If you think I'm missing something, please send me an e-mail and let me know.

We released the third discussion draft of GPLv3 this morning, and already we're seeing a lot of interest in the changes we've made. We're definitely looking forward to discussing these issues with you all to help us write the best free software license we can.

Until now, the drafting process has been relatively quiet—we've heard your comments, and addressed them as best we can in the changes we make and rationale documents. As we start to finalize the license, we want to make this process even more public, so I'll be writing pretty regularly about the issues that have come up. Hopefully this will help people better understand our thinking, and generate even better discussion.

One point in particular that's drawing a lot of attention already is the bracketed clause in section 11. We've proposed language that would prohibit distributors from entering discriminatory patent deals like the one between Microsoft and Novell; the text in brackets is still under consideration, and would make that effective only against deals that were made starting today. If the text is removed, the draft would be "retroactive" because it would prohibit companies from distributing GPLv3ed software if they've already entered such a deal. That's as far back as it can go—we don't have a magic trick to retroactively stop those companies from distributing software under GPLv2.

So, if the text in brackets is adopted for the final version of the license, it is true that this would grandfather in Novell. That's not the reason we're considering it, though. After all, that deal would still be affected by the previous paragraph, forcing Microsoft to offer its patent protection to everyone instead of just Novell's customers. At the same time, a number of other companies who distribute free software are worried that our language will affect other kinds of patent agreements they've made that aren't harmful to the community, like patent cross-licenses. If you want to learn more about this, the rationale document has details.

We're still considering the issue, and want to hear more about it. We would also like to know how you feel about this grandfather clause in general; perhaps you can suggest alternatives that would help us better accomplish our goals. Please comment on the draft and let us know. And make sure you subscribe to our RSS feed to hear more about other issues surrounding GPLv3.

In the few months I've been working at the FSF, I've been dealing with about twenty license violations on GNU software. When it comes to the embedded devices, I've noticed an upsetting trend: a lot of them are locked down. The products range from wireless routers to personal media players. They take different strategies, too; some of them won't provide you with the tools necessary to build your own firmware, and other times the hardware checks the software for authorized signatures. The result is the same either way -- they'll give you the source, but you can't actually modify the software you're running.

This is a real problem that affects free software users today, and it's only going to get worse if we don't fight it every way we can. Right now, if you don't like the firmware the manufacturer provides, you can often install an alternative, like Rockbox or DD-WRT. But there are products on the shelves right now that will prevent that, and more on the way.

This is the reason the GPLv3 drafts require that these distributors make it possible for you to modify the software it includes and install those changes. We didn't add that just to stop TiVo, and we're not looking to force our will on the Linux kernel. This issue affects the entire free software community, and all the devices we use. We need to turn the tide.

The Compliance Lab does do one job which is very public: we answer licensing questions from the free software community. When people want to learn how they can mix code under different terms, or what license would be best for their program, we try to help them so they can spend less time worrying about legal nitty-gritty and more time hacking. It's not the most glamorous job, but it's a unique way to help out.

With the recent staff changes, though, we've had a hard time answering all the questions we get, so we're looking for new volunteers. Your help could make a huge difference, even with just a few hours a week. If you'd like to contribute, try your hand at our license quiz, and let us know how you do at licensing@fsf.org.

Last year, I applied to join the JET Program, which would have sent me to Japan to help teach English in a public school for a year or two. The organizers give the participants a little mantra: Every Situation Is Different. What works well in one school, or one town, or one apartment search, may not carry over to another. If people are giving you advice that seems bad, they say, there's probably a good reason for that -- something unique about your situation.

I wasn't accepted for the JET Program, but that's okay, because now I'm FSF's new compliance engineer, which is even better. Even though I've been in this job for less than two months, people are already asking me how the compliance process works. This is a hard question to answer, because like the JET people say, every situation is different.

Every compliance case starts with some kind of report about a violation. Even these come from all over: some people follow our reporting instructions and mail us, others post to mailing lists or forums, sometimes we hear about a problem through the press. Then we have to confirm the violation. How do we do that? It depends on what kind of violation it is. If the violator is distributing GPLed software on a web page without a copy of the license, we can simply download it and take a look for ourselves. If a router manufacturer includes GPLed software in their hardware without providing the source or an appropriate written offer, we have to use various tools to figure out exactly what code they're shipping.

After the violation has been confirmed, we contact the violator to start bringing them into compliance. Our approach to these negotiations varies a lot depending on whether the violator is a small team of hackers or a corporation, what kind of violation it is, how friendly they are to free software, any cases we've had with them in the past -- I could go on and on. Things don't always go the way I expect, either. I've dealt with corporations who were very friendly and fixed problems promptly, and individuals who dragged their feet and made a huge stink about the process. It all depends.

I know we don't talk much about FSF's compliance work; this is just one of many reasons why. But it's important work: the many developers who have assigned their contributions to us expect it, and there aren't a lot of other organizations enforcing free software licenses. So expect to start hearing more about the Compliance Lab, here and elsewhere. And in the meantime, if you have any questions about what we do, please feel free to send us an e-mail.