Section 3 of GPLv3 is titled, "Protecting Users' Legal Rights From Anti-Circumvention Law." That's a little verbose for a section title, but it's actually the most succinct name we could come up with that was still accurate. Section 3 performs a very specific job: it ensures that people who are merely exercising the rights that the GPL gives them won't be threatened by laws like the DMCA. So, if you get some GPLed software that implements DRM, you can take that part out, and the license will protect you.

I bring this up because we still hear people claiming that GPLv3 limits how you can use the software. I'm not sure how else we can respond to this charge; it simply isn't true. We've long believed that it should be possible to use software for any purpose; we said the Hacktivismo Enhanced-Source Software License was non-free because it limited this freedom. GPLv3 has no such limits. You can use GPLed software to implement DRM, guide nuclear missiles, or run your own organized crime syndicate—just as you can use it to administer a court, run an animal shelter, or organize your community.

Let's work through one example I saw recently: cell phones. As far as GPLv3 is concerned, a cell phone is treated just the same as any other hardware that includes GPLed software. You'll need to provide recipients with the source code to the software, using one of the methods offered by sections 6(a) and 6(b). If the software on the phone can be updated, you'll also need to provide recipients with Installation Information as well, to prevent tivoization. And of course, the cellular network provider can't deny you access merely because you modified the software—but they can shut you down if your modifications turn out to be malicious and hurt the network. It's all pretty straightforward.

Perhaps I shouldn't be surprised that people are still spreading these misconceptions, however: a lot of the old confusion about GPLv2 is starting to come around again, too. For example, some people have been wondering what the rules are when you link to some GPLv3-covered code. They're the same as they were under GPLv2: the combined work you create needs to be GPLed as well. In fact, most of what you learned about GPLv2 can be applied to GPLv3; changes are the exception, rather than the rule.

Now that GPLv3 has been released and a lot of people are looking at the license with new eyes, this is a great opportunity to clear up a lot of this confusion. If there's something in the license you're not sure about, check our FAQ, and if you don't find your answer there, e-mail us; we'll be happy to help you out. And if you see these sorts of mistakes in the press or community, let us know and we'll respond to it appropriately.

Work on the GNU Affero General Public License version 3 is starting to wrap up. The feedback we've received has helped us understand which issues in the license are confusing for readers. I don't think the license itself is going to see much change as a result—it would be impossible to hammer down every single one of these issues, and it's generally counterproductive to try—but we are going to try to address those concerns through other means, such as our FAQ.

As part of that process, last Thursday night the FSF Compliance Lab held an IRC meeting to discuss all things related to the GNU AGPLv3. We discussed various different issues surrounding the upcoming license—in addition to clearing up some of that confusion and answering specific questions about what the license requires, we also talked about how various groups have reacted to it, possible business models, and more. Here are a couple of excerpts:

<bcs> fjl asked: <fjl> One of the comments/questions on the posted draft was why does the AGPL not take the approach of requiring source if the program is "Performed" for the public. That seems the obvious approach to both the writer and myself. Is it because that would somehow turn it into a contract and not copyright issue?
<bcs> The issue with talking about Performance is, quite simply, that nobody has any idea what it means to "perform" a piece of software.
<bcs> I'm not sure, but I doubt that even Eben would venture a guess.
<bcs> It is appealing, because it does provide a clean solution. But it's tough to conclude that it's legally sound. We'd rather go with something that's a little more complicated, that we know works, than something that's clean but functionally ambiguous.
<thd> Eben has also said in the past that performance has little conformity of treatment in copyright law internationally.
<bcs> I'd forgotten about that, but you're right, yes, thanks.
<fjl> I had assumed it was running it, analagously to performing music from a script or libretto or whatever it's called. I thought this was somewhat legally established interpretation (IANAL, of course)
<bcs> fjl: That interpretation would make sense to me -- but I've been told that there is no legally established interpretation.

<johnsu01> NZHeretic asked, Is part of the problem that the Business sector recognize the business model usage for GPL/LGPL but not for the AGPL. Might it not be a good idea to produce some study to show where the AGPL would be truly useful to Businesses ( Keeping a commons open )?
<bcs> I doubt we need to do that. I think a few companies are going to do that for us.
<_ivan> <--
<bcs> For all we were slagging on companies earlier, there are a few who are very interested in the AGPL. Like all the companies who sell SaaS to other companies.
<_ivan> that's me :)
<bcs> Like _ivan's company, yes. :)
<bcs> And companies like SugarCRM, and Alfresco, and Zimbra. I'm not saying they're all going to adopt AGPLv3, or have even noticed it, but they are looking at this issue.
<bcs> And they have a lot of voice in today's Web 2.0 bubble. So when they start talking about how important the AGPL, or something like it, is to them, others will take notice.

Thanks to everybody who came by and participated. It went so well that we're going to go ahead and do it again, this time at 18:00 UTC on Wednesday, October 24, in #gplv3-meeting on freenode. This will be a general question and answer session; feel free to drop by and ask any question about any GNU license, past, present, or future. We hope to see you there.

There's been a whitepaper making the rounds recently which discusses how a vendor can use virtualization to comply with GPLv3's anti-tivoization requirements, while keeping separate proprietary software locked down. Unfortunately, the headlines have had their usual sensationalist slant: "Can hypervisors circumvent GPLv3's 'anti-tivoization' clause?" they ask.

That's a pretty easy question. The answer is no.

GPLv3's anti-tivoization terms aren't quite as broad as some people apparently think they are. The license doesn't require that users have permission to modify all the software on the device; they only need to be able to modify the code covered by GPLv3 or LGPLv3. It wouldn't have made much sense for us to require anything else: even if we said that you should be allowed to modify all the software on the device, that doesn't help you much when you can't get the source for the proprietary programs.

So, the fact that GPLv3 allows you to tivoize proprietary software on devices isn't really news. Virtualization is one way you could do it, but it's not the only way. Anybody pushing a particular solution is probably trying to sell something.

Recently we've been seeing a lot of questions about the FDL's requirements for different kinds of multimedia work. People will ask what they have to do when they use an FDLed image to illustrate an article, for example, or an FDLed song as part of a movie.

In cases like these where the materials complement each other, we believe that the end result is a derivative work. So, in the examples above, this means that you would need to follow the FDL's terms for creating modifications when you release your article or film. Just because the components can be separated doesn't necessarily mean that they're not derivative. For a long time we've held a similar position about copyright for software: just because a program only optionally makes use of GNU readline, for example, doesn't suddenly excuse the author from the GPL's requirements.

If you have a particular scenario along these lines you'd like to ask about, please feel free to e-mail us. We're always happy to answer those sorts of questions.

The blogosphere has started buzzing with the suggestion that GPLv3 isn't going to address the so-called "ASP loophole," where users interact with software over a network but never see source. I think Bryan Richard started the ball rolling.

In the second draft, this was addressed in section 7(b)4, which would've allowed licensors to optionally add a requirement to their code so that source would remain available even when the software was running as a network service. The language we proposed got the job done, but it was not an elegant solution. Proponents of the requirement—and I include myself among them—supported the goal but were unsatisfied with the execution. The wording in draft two left open a lot of bothersome questions. For example, it required that you maintain certain source delivery mechanisms that were in the code. But what if you modified the code to talk over a different protocol? Something like DNS that doesn't really support delivering files? I'm not sure it's always a horrible thing to dictate technology to accomplish your policy, but it's definitely less than ideal, and 7(b)4 was a shining example of it. Even worse, the clause had the potential to make GPLv3 compatible with onerous licenses, with obnoxious terms akin to the BSD advertising clause.

So we've come up with a better solution. We're going to write a new license, version 2 of the Affero GPL, that solves this problem in a more general way and doesn't dictate technology. GPLv3 is going to be compatible with AGPLv2; you can see the this in section 13 of the latest draft. This provides everyone with much the same benefits that 7(b)4 did: people who want their source to be available over a network will use the Affero GPL—not much different than using an optional requirement—and will still be able to build on top of all the GPLed code that's out there. And then this approach has additional advantages over 7(b)4: it'll be less of a technology hack, and people who want to avoid code with this requirement can just blacklist the AGPL, and not have to worry about a list of additional requirements.

We're going to draft AGPLv2 just as publicly as our other licenses. Initial language is circulating among the first stakeholders, and once we have something ready to publish, we will. For those of you who have been writing about this, I think you're really going to like what you see. Just please have a little more patience.