***********************************

Before I start with the questions, I'd like to take a quick moment to thank PJ for helping to organize this, and the many people who submitted their thoughts. The FSF Compliance Lab deals with the GNU licenses in many different ways—we investigate violations, help people come into compliance, and educate users and developers about their terms. Hearing your thoughts on GPLv3 has helped me understand what needs to be done as we finalize the license.

If you'd like to learn more about the Compliance Lab, please stop by our web site. A team of volunteers actually help me answer questions like this all the time; if you think you'd be interested in pitching in, don't hesitate to drop us a line. You can also support our work by joining the FSF.

A lot of your comments seemed to be suggestions for the draft itself, rather than questions per se. I do appreciate those, and while I would have loved to provide some sort of response to each of them, I'm afraid I simply don't have the time. Please do submit those to our comments page—we do read and consider everything there, and the feedback will help inform the last call draft we publish next.

Answers

I've roughly organized the questions by topic: they start out discussing the drafting process, move on to the more significant changes in draft 3 such as lockdown and patent terms, and then more specific, nitty-gritty questions. I've also done some slight editing to the questions to help clarify them in the new context; I strove not to lose any substance, and I've provided links to the original comments so you can double-check me on that. I hope my answers are as helpful to you as your comments were to me.

Hawk wrote:

• Is it really necessary to reference any specific (and therefore fragile) law?
• Are we really incapable of bluntly stating our intent from basic near-universal principles alone? (Examples are "copyright" and patents".)
• Is the concept of "free software" not basic enough to be expressed in a legally binding way without these references?
• Are we willing to initiate an arms-race with lawyers and lobbyists paid to subvert our work?
• How long do you hope GPLv3 will be able to protect our software unmodified? 15 years (like GPL2)? 15 months?
• Does the FSF think we could "win"? (I use "win" in the sense that software would be "effectively free" as long as the authors kept applying the license patches from the FSF, say, every Tuesday.)

Free software is dirt-simple to express in a license. Here you go:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so.

I just took the main paragraph of the Expat license and trimmed it slightly. This is a complete free software license: it gives the recipient all the four freedoms. I wouldn't want to use it as a developer, but as a user there's absolutely no problem with it. It even sounds like legalese.

That's 61 words. By contrast, just the legal terms of GPLv2—not counting the preamble and appendix—weigh in at 2021 words. That's more than 30 times bigger! Why is the GPL so much longer? Can't we make it simpler?

Writing a free software license is easy. Writing a good free software license, that does a good job of addressing the needs of both users and developers, is hard. And writing a copyleft is where the rubber hits the road. Copyleft is where we have to consider the environment that software exists in today, how users' freedoms are threatened, and how best to counter those threats. When you write a copyleft, you don't get the high-minded language of freedom; you get compromising text like "a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code."

That's so complicated! What if someone tries to give you punch cards? Those are machine-readable if your machine was bought in the fifties. And how do we know what their cost of physically performing distribution is? What if they lie? And what's this business about "any third party?" Plus, why does it say three years? Shouldn't we be able to get source after four years too?

Despite all these questions—all questions that people have legitimately asked at one time or another—this language has served us well in GPLv2 for over fifteen years now. I still explain it to lawyers and engineers inside companies big and small, and they all usually provide written offers that are reasonable for users.

I won't deny that GPLv3 is more complex than GPLv2. That's because we live in a more complex world now, where people interact with software in lots of ways besides sitting down in front of a box that runs their code, and some developers want to have all the advantages of freedom with none of the obligations. You can use simple language if all the participants have shared understanding. Unfortunately, not everybody groks freedom yet.

I understand why some people are averse to referring to specific laws in GPLv3, but I have yet to hear an alternative that's actually better. We want to say: "Judge, the law creates a special class of software that has special rights, and we want you to know that this software is not in that class and has no special rights." We could describe that class in plain English, but then the judge may not make the connection. He might think our definition is different somehow. Calling out the law directly eliminates that risk.

And avoiding that risk is important, because we do want GPLv3 to last. I don't think it's going to make it quite as long as GPLv2; probably somewhere between five and ten years instead. Of course, we'll update the license whenever the integrity of the GPL is threatened, but this sort of timeframe is the goal we're working towards.

When I first started coming into the free software movement, the complaint du jour was journaled filesystems. Free software will never have a journaled filesystem, they said; it's too boring, nobody working on their own time wants to make that sort of thing. These days, I have to double-check and make sure that I don't use a journaled filesystem when I format a USB drive. In between then and now, they also said that we'd never develop an office suite, or a "real" relational database, or enterprise software. Every day, the list of things you can't do with free software shrinks, and each time that happens, more people start using GNU/Linux. As time goes on, more of the world runs on free software. We have to stand our ground and be smart moving forward, but if we're successful in that, I think success for the movement will follow.

EJN wrote:

The object of revising GPLv2 was ostensibly to improve and clarify it. With respect, this latest draft of GPLv3 is hardly clear; to the contrary, there's a lot more ambiguity. For instance:

[snip suggestions]

I've heard Eben Moglen speak on several occasions, and he's acknowledged that he's intentionally included ambiguous terms in the license.

We did include nebulous language in previous drafts so as to generate discussion and figure out where certain lines should be drawn. That process should be finished at this point, however, and there shouldn't be any more language that's intentionally difficult to understand. If you have suggestions for how we can help clarify the specific points you brought up, I would encourage you to submit them to our comment page, if you haven't already.

tce wrote:

1. Should this comment period lead to serious work for the v3 team, is the self-imposed deadline flexible? The implied point of view is that real improvements will benefit thousands for years, while hitting the date might be more of a pointy-haired-boss thing...

Right now I have no reason to believe that we'll be delayed. The process has gone very smoothly so far. Except for compatibility with the Apache Software License, I haven't yet heard of any issues that might require much of our time. But we do agree that getting this right is more important than getting it on time—we already extended our deadline once, after all, to address the new threat presented by the Microsoft-Novell patent deal.

2. Our justice system has been based on accepting that a few false negatives (crooks) will go free to protect citizens from government false positives (good guys going to jail).

Should the authors of GPLv3 reconsider the balance between the goal of worldwide acceptance of the GPL versus dealing with specific risks, if dealing with the risk either complicates the GPL and creates legal interpretation risks or complicates the GPL and makes developer-readability risks and barriers to use?

This balance is something we keep in mind as we revise the license. We are trying to keep the complexity as low as we can. For instance, when we changed the anti-tivoization terms in the latest draft from something in the definition of source code to a condition in section 6, one of our motivations was to make it easier to understand. We've received some feedback telling us we made the right judgment in that, which I was glad to see. The change actually added more text, but I think it's simpler overall.

From our perspective right now, GPLv3 addresses very real and serious threats. We recognize the high cost of doing this, but we think the costs of inaction are even greater. People have already envisioned a world where all hardware is locked down, and are trying to figure out how to force it on an unwilling public. Microsoft is already trying to force every free software user to pay them royalties. These are not abstract issues. Other organizations are fighting to take away your freedom.

Sesostris III wrote:

What considerations have been given by the FSF regarding international and pan-global law?

I ask because things like the sections on patents, and references to things like the "Magnuson-Moss Warranty Act" (whatever that is) seem very U.S.-specific.

Could the addition of these sections—although tightening the GPLv3 in the U.S.—actually weaken it (as unenforceable) in the place most of us reside—i.e., "abroad"?

We are doing everything we can to make the license work uniformly in as many jurisdictions as possible. This is why we have defined new terms such as "propagate" and "convey," instead of using U.S.-centric language like "distribute." In the latest draft, we also replaced a reference to the DMCA with one to the corresponding WIPO treaty.

I don't see anything in the patent section that would be particular to the U.S.; if you do, please let us know. As for the reference to the Magnuson-Moss Warranty Act, we recognize that it has some costs outside the U.S. We think it would still be enforceable because the text makes very clear that this reference is not supposed to supplant any local laws; we're only incorporating a definition into the license. Even then, we're still considering this balance, which is why the reference is in brackets. We only propose it because it has exactly the kind of interpretation we would like the GPL itself to have.

steve wrote:

This is a topic that nobody has picked up on yet, but it is quite explicit in the FSF drafts: GPLv3 is incompatible with the Apache Software Foundation 2.0 license.

Now, GPL2 has been incompatible with ASF2 because the Apache license said "sue for patent infringement and your rights to this app go away". GPLv3 has a similar clause, and everyone—including the Apache people working with the FSF—thought all would be well. But come the next draft, no, the FSF came up with some other argument against the Apache license that they did not even bring up with the Apache folk.

Now, this may seem minor, but in the Java world it is not. Sun's JVM uses Apache code for XML support, so Sun cannot release the JDK under the GPL—as promised—until the two are compatible.

What game is the FSF trying to play here?

The indemnification provision of the Apache Software License was brought up as a potential compatibility problem in discussion committee. Once it came to our attention, our thinking evolved the way we described in the rationale document. At first we couldn't determine the exact scope of the requirements, and so assumed it was no problem. We then came around to the idea that, despite that, we should still act as though there were some requirement there, which would make the two licenses incompatible.

This wasn't a proposition we were really eager to consider. In fact, saying we were reluctant would be putting it mildly. Both interpretations of the language are reasonable. However, the community places a lot of trust in the FSF's judgment on licensing matters like this, and we must honor that trust by considering these issues from all possible angles—even the ones we don't like.

We wanted to be forthright about our concerns in the rationale document; I think that's a better policy than trying to sweep the problem under the rug. But you're absolutely right that we should've discussed this issue with the ASF before releasing the last draft, and you have my apologies for that. I hope we can make it up to you. In the weeks between then and now, the FSF and ASF have had the discussion we should've had back then, with a goal towards finding a solution that will provide compatibility between the two licenses again. I can't promise anything yet, but I'm optimistic that we're going to find that solution.

The Apache Software License is a good license. We still want compatibility between the GPL and ASL, and continue to work towards that. We keep getting tripped up on the legal nitty-gritty, but we're going to get through it.

Wardo wrote:

Why is the GPL being forked to deal with a loophole? If it's worth closing the loophole for ASP, why not include the fix in the main GPL? Why is this one named and the other potential combination licenses are not? So what happens when I link to BSD code, or public domain code, or ...?

Not everybody agrees that this issue constitutes a loophole. And when I say that, it's not just big business on the other side of that debate; there were developers here on Groklaw disagreeing about this issue. There are reasonable arguments on both sides, and the GPL is not the place to close debate.

In the previous drafts of GPLv3, we tried writing a provision that would provide for compatibility with any license that required network-interactive applications to provide their source in particular ways. But nobody was really satisfied with it. Large companies said the risk of having that requirement present would cause them to avoid using or endorsing software under GPLv3. At the same time, developers who are interested in tackling this issue felt the provisions were too technically-oriented and allowed certain kinds of requirements that would've been too burdensome.

The new provision allows us to provide for compatibility with a license that addresses this issue, while taking all this criticism into account. It doesn't seem like a major loss, either; the only free software licenses we may have lost compatibility with (compared to the previous draft) are the Affero GPL v1, and the Honest Public License. Both of those are GPL-based, and I think their users will be very interested in moving to AGPLv2. We're certainly looking forward to hearing their feedback once we publish the first draft of that.

You'll still be able to link to code under other GPL-compatible licenses just as you do with GPLv2. Section 7 in the current draft helps make this clearer.

nb wrote:

Is it OK to distribute a program in which some components are GPLv2-licensed and some components are GPLv3-licensed?

That depends on some more details. I've prepared a matrix that lays out a lot of the common options, and posted it to the GPLv3 FAQ.

Note that this only covers cases when you're combining code into a single program through usual methods, such as actually copying the code from one project into another, or using a library.

Anonymous wrote:

Given the nature of [free software] projects, and the large number of contributors to most of them, how can any large project move from GPLv2 to GPLv3?

If the project is released under GPLv2 or any later version—as most projects are—upgrading to GPLv3 should be a relatively straightforward process for any team that wants to do so. They effectively gave themselves permission to upgrade, after all. Beyond that, I can't really talk much in general about how projects should migrate to GPLv3—because every project is run differently and will be willing to take different steps to reach this goal, the process will be different as well.

It definitely should be possible, however. There are lots of good reasons to upgrade to GPLv3, and we'll be happy to do what we can to help projects that are interested in making the switch. Licenses aren't designed to be permanent, so it's important to have some kind of structure to make upgrades easy. The FSF has collected copyright assignments to do this for GNU programs, and the SFLC has been helping developers establish other ways to achieve this goal. Unfortunately for hackers, this is the kind of thing that requires some legal advice, but hopefully the release of GPLv3 will provide a good opportunity for lots of projects to hammer this out.

Illiander wrote:

Why do you feel the need to draw lines between different locations of licensee?

If a buisness doesn't want control of their hardware, they should rent that hardware. And I seriously doubt that any business really wants manufacturers to have control over their hardware. Manufacturers who are worried about modifications to their software causing them liabilities should put it bluntly (at point of sale) that they are not responsible if the thing they sell is modified in any way.

We don't want to draw a line based on whether you rent or own the device that houses the software, because if we do, every device manufacturer will find a way to "rent" their device as a way to get around the GPL's requirements. We've already seen some distributors try to make this very argument with GPLv2, particularly in the ISP business where it's common to lease modems to customers—even though rental qualifies as distribution in pretty much every jurisdiction.

Moreover, the companies that have the sort of "managed IT" that we're trying to allow—where they don't have the keys to modify the software and actively don't want them—are already renting that hardware. Nonetheless, they were still concerned that it would not be possible to use GPLv3 software in these programs.

stephen pollei wrote:

I've been trying to learn more about what would and what wouldn't be considered a consumer product. One thing I found said it's a case-by-case issue. Are there any bright-line rules to categorize a tangible product into a household as opposed to say maybe a industrial, or professional product? Do you have a list of electronic products that you consider to be consumer products? Do you have a list of electronic products you don't consider to be consumer products? Do you have a list of border-line products? For this list of border-line products could you provide a couple walk-through case-studies showing what method you would use to make a determination of its categorization?

Corbet from LWN has said

What it comes down to, though, is that gadgets intended to be sold to businesses will be exempt from the "installation instructions" requirements. This seems strange; it may well be businesses which would have the most use for the ability to change the code running in devices they purchase. ... This exemption could prove to be a big loophole. ... The exemption for devices which are not "user products" looks similar; with this language, the FSF may well be setting us up for a flood of "business use" gadgets which happen to available at the local big-box technology store.

Does your user product definition protect individuals against this type of gamesmanship? Does it protect people whose hobbies approach professional type quality?

We took the definition of Consumer Product from the Magnuson-Moss Warranty Act, and we have proposed that the license refer to its interpretation, precisely because it has been very resistant to exactly the kind of gamesmanship you describe. If you'll excuse some oversimplification, when courts have been asked to determine whether or not something is a Consumer Product under the Magnuson-Moss Warranty Act, they have generally asked one question: do people buy it for their personal use? If so, then yes, it's a Consumer Product.

Like I said, that's oversimplifying the issue, but it is accurate in that those courts have not considered how the product is named, marketed, priced, or otherwise described by its manufacturer. The main thing that matters is who generally buys it, and for what purpose.

Any device you can buy at an electronics store should qualify as a Consumer Product. This includes the overwhelming majority of desktop and laptop computers, portable media players, all kinds of mobile phones, DVRs, plenty of digital cameras, wireless routers, and other dedicated hardware.

Devices that probably don't count are the kind of very-high-end computing equipment you would expect: Blade servers, huge rackmount Gigabit Ethernet switches, that sort of thing.

The line between these two extremes is blurry. I don't know exactly where we're going to settle on a cut-off point. None of these devices should be locked down; we say that in the preamble of the draft. But the people distributing these devices aren't locking them down just to take away users' freedom, and right now there's no reason to believe that's going to change—quite the opposite, actually. Meanwhile, the devices where this is a problem are all very safely tucked under the Consumer Products umbrella. So even if the definition of Consumer Product isn't perfect, we think it's still a good compromise to help us achieve our goals.

songmaster wrote:

The obvious hole to me [in section 6] is that there are no limits given on what a conveyor can require the user to do in following the installation procedure. A TiVo-like distributor could specify a procedure in its Installation Information whereby all binaries to be installed on the device have to be sent to it to be digitally signed by their private key before they will run. Their procedure could work perfectly well, and providing it does I don't see how this requirement would break the terms of the GPLv3 at all, although it seems to be breaking its spirit.

If I have to send my binaries to them for signing, they'd also be entitled to get my source changes since I'm now propagating a copy of code that is licensed under the GPLv3. Could they require me to sign over any additional rights to my modifications as part of that installation procedure?

When we wrote this language, we didn't intend for "procedures" to include all kinds of interaction between the person conveying the software and the recipient. All we had in mind were relatively straightforward technical instructions—press this button, upload that file, and so on. This is something we've gotten a lot of feedback on and we'll consider clarifying it to better reflect what we had in mind.

Illiander wrote:

Would re-wording the "Installation Information" section to apply to all users (i.e., removing the "User Product" definition) be a additional permission, or an additional restriction?

That would be an additional restriction. Think of it this way: suppose you add some sort of terms to the GPL. If a licensee didn't realize those terms existed, and just followed the plain GPL, would they also be in compliance with your additional terms? If so, then it's an additional permission; otherwise, it's an additional restriction.

So, in your particular case, if someone distributed your software in something that wasn't a User Product, and just followed the terms of GPLv3, they'd run afoul of your additional terms. So it's a restriction.

Illiander wrote:

So I can add any additional permissions, but anything restrictive can only be something from the list?

And if I recive something which claims to be licenced under the GPL, the GPL itself removes the restrictions which shouldn't have been allowed to have been placed there in the first place?

That right?

That's correct.

Anonymous wrote:

If I understand the phones/medical devices situation correctly, it's possible to avoid making such devices unmodifiable by putting the unmodifiable code in ROM rather than using tivoization to ensure that it's unmodified. But wouldn't making code unmodifiable this way have all the same disadvantages to the user of making it unmodifiable by tivoization? What does the user gain by having things unmodifiable in one way rather than in another?

You're absolutely right that, from a user's perspective, having software in ROM is no better than having locked down software. However, manufacturers don't put software in ROM solely to restrict people's freedom. There are often technical reasons for this decision. It might, for example, be simpler or cheaper.

When we think about this issue, we're primarily concerned with hardware that looks a lot like a general purpose computer. Despite the continued march of progress, your microwave is not going to be a useful GNU/Linux box for the foreseeable future, and that doesn't really bother us. Even if the manufacturer does burn some GPLed software to its ROM, what could you really do if you had some ability to modify that? Maybe I could build a better user interface, and that would definitely be nice. But a locked down microwave isn't nearly as threatening to society as a locked down general-purpose computer.

And your DVR, for all intents and purposes, is a general-purpose computer. It's capable of all sorts of interesting work, and you should be able to put it to use as you see fit. We don't really see firmware for those devices going into ROM; it doesn't make technical or economic sense.

Even in portable devices where using ROM could make sense, like smart phones and media players, the trend has been moving away from that for some time already and that's only going to continue. Given all this, I think the lines we've drawn work well: really limited hardware isn't unnecessarily included, and everything else is.

Anonymous wrote:

Company A makes a consumer product (vacuum cleaner, personal video recorder, coffeepot, whatever) that uses GPLv3 software. They do not sell directly to the consumer, but rather to distributors. With each shipment, they include Corresponding Source and Installation Instructions, to stay in compliance.

Distributor B takes possession of thousands of products from A, and puts the box with the Corresponding Source and Installation Instructions in a cabinet somewhere, and proceeds to sell the products without including those things. Net result: the consumer gets an appliance with GPLv3-covered software, without source code or installation instructions. (To add to the problem, if I as a consumer copy the software as it exists in the device to give to a friend to analyze, I'm in violation.)

After all, A has done what is required of it. B is not in the business of doing anything it needs a license for, but is rather just reselling things provided by A. If I have legitimate copies of a book, or song, I can sell those as I wish with regard to copyright. I just can't make any more copies without some sort of license. Therefore, B need not accept the GPLv3 to operate, and is not bound by its restrictions. B is free to distribute source and instructions (and A cannot forbid it in an agreement), but it may well not be in B's interest, as B may think it will add to support costs and possible complaints.

It's not clear that "B is not in the business of doing anything it needs a license for." It would at least be reasonable to argue that B is conveying the software just the same as company A is, and so is bound to the same terms. Certainly, if you're opening the box to remove those materials, you should be aware of what's on the device, and the fact that a license came with it. In the United States, the first sale doctrine which is most likely provide B with an out is especially murky when it comes to software.

Even if they do have no license obligations, however, this scenario does feel a little implausible. Company B would need to have some reason to want to undermine the GPL—enough of one that they're willing to stick their neck out on this case. Most resellers simply don't have a dog in the fight either way. And if B was a subsidiary or had some other relationship to A, it could very well be possible to convince a court to see these as the orchestrated actions of the single parent company.

iabervon wrote:

[Company X] produces two hardware devices with identical processor and peripherals, each of which stores its code in flash. Both of them take in new firmware images from the user, but one of them additionally takes a signature which only [Company X] can create, and only installs the image if the signature verifes. Neither device, as constructed, uses anybody else's copyrighted work.

[Company X] writes some lousy firmware for these that doesn't do anything useful, but doesn't use anybody else's code. All this firmware does is let people fetch firmware images (and signatures), and provide them to the hardware for upgrade.

[Company X] releases enough documentation that people get Linux working on the unlocked hardware. Other people turn this into a great system. Everybody able to get the unlocked hardware (which is not everybody who might want it) is happy, and can customize it to do what they want.

[Company X] downloads some images and the corresponding sources from other people and finds images that don't do anything [Company X] wants to prevent. [Company X] doesn't accept the GPL, because, since they do not intend to modify, copy, or distribute the covered work, they don't have to. [Company X] releases signatures for the firmware images they like. It points customers at these signatures and at their author's sites (since it can't legally distribute the images itself).

(This situation is even more likely if the locked and unlocked hardware are by different companies, and the locked hardware is expensive, while the unlocked hardware is provided to end users free with some service.)

Now, the only people who are bound by the terms of the GPL are the people writing firmware images, and they're releasing everything they have. Also, their firmware is designed for unlocked hardware, which is what they're developing on, and what they probably expect users to have. [Company X] doesn't need a license to hyperlink to firmware images other people publish, and Freedom 0 means they can read the source, test it, and produce signatures. [Company X] owns the hardware designs, including the signature checking device, outright.

So I don't see how any possible GPL which follows Freedom 0 is going to affect what is probably the laziest strategy for getting locked hardware running specific versions of GPL software. It seems to me like anything that could be prohibited by the license is actually less objectionable than the behavior that doesn't involve the license at all.

I hope you don't mind that I changed the name of the company in your example. This is a hypothetical situation with a pretty nasty player at the center of it, and I don't want to suggest that anyone's quite this mean. I get a lot of compliance by being nice to companies, after all.

I think it would be possible to bring a contributory infringement case against the company in this situation. From what you've written, it's pretty clear that they mean to convey the software—they produced signatures for it, after all—and they're just using hyperlinking to try to work around the license's requirements. That's not fooling anybody; certainly not a judge.

But I'll go ahead and pretend for a moment that nobody wants to try to bring that case for some reason. The thing is, I don't think that product is going to sell. If the product doesn't even pretend to do anything out of the box, and the first thing you have to do is download some firmware and a signature from a web site—well, that sounds an awful lot like a computer without an operating system, and retailers haven't exactly been clamoring to offer that product to their customers.

So I think Company X is going to have to write some real firmware, on their own. It won't be very good, and it drives up their development costs, but it at least has to look nice enough that people want to pick it up off the shelf. And then some hackers will buy it because they know they can install free software on it, too.

When that happens, I'll have to consider starting my own company, Company Y, because the business opportunity in this situation is just too good to pass up. Company Y is going to build a box that looks a lot like Company X's, except it's not going to have signature checks on the firmware. Instead of developing my own firmware, the box will ship with some of the firmware that other people have already written. I'll go ahead and tell people how to build and install their own firmware, too, because what's it matter to me? My costs are lower, so I can sell the hardware for less than Company X's product and still make more profit on each device. On top of that, I'm going to sell more of them, because my device has more features out of the box, and Company Y will have a reputation of being friendly to the free software community. I even have a cool Web 2.0-style slogan that'll drive the point home: Y for You. And so through the superiority of my product and my slick marketing campaign, freedom wins.

Right now, under GPLv2, I can take a piece of software, modify it, and then charge ten billion dollars before I give anyone my modifications. That's horrible from an abstract freedom perspective; my software's not really free because nobody's going to pay that much. And that's exactly why we don't worry about it: because nobody will pay that much, nobody will charge that much, so there's no real threat to freedom. Because the GPL doesn't really place any limits on commercial distribution of the software, the market tends to correct towards freedom. This effect is so strong that even the distributors who were doing everything right, who were putting together a good package of free software with nice printed manuals and all that, never really spent too much effort trying to charge for their work. They decided they'd rather sell support contracts.

I think this sort of thing is another situation where there's an abstract threat that's going to have a hard time materializing. If you're trying to convey GPLed software without leaving your fingerprints on it, either you're going to get too close to the copyright line, or someone else is going to pick up the software and run with it.

Anonymous wrote:

Let's say that I create medical device, and I want to use some GPL v3 licensed code as part of it. Let's also say that this medical device has the potential to kill someone if something goes wrong. Needless to say, I don't want just anyone putting software on the device, but I want to be able to issue code patches to be applied to existing devices.

I'll want to follow the terms of the license, but allowing some arbitrary person to install new software on the device just isn't an option. Is there a way to make this work within the terms of GPL v3?

Someone working in the medical industry recently mailed me with this same question, except the software was under LGPLv2.1 instead of GPLv3. After I explained the requirements of the license to her, I asked her a question of my own: if her company was very careful to disclaim responsibility for modifications to the device, and someone did it anyway and caused a problem, what would happen? She answered without hesitation: "Oh, it'd kill us."

FDA regulations on medical devices are very strict, mostly for good reason. Right now, letting users modify the software on their devices is forbidden. That's something we want to change, but it would be premature to address this directly in the license; we need to campaign for some regulatory change first.

abraxus wrote:

I don't see how this wording in any way affects a covenant provided by a third party to users. It clearly refers to a license but I am sure I read somewhere that the way they got around GPL2 was by avoiding a license and creating a "covenant to customers" instead. I don't see how this is addressed in any way here.

Using a covenant is not really the way the Microsoft-Novell deal tries to step around GPLv2. The license says that if you have any conditions imposed on you that prevent you from fulfilling the terms of the license, you cannot distribute the software at all. This is true whether the conditions come from a patent license, a covenant not to sue, or anywhere else.

We still have you covered, though. See the second paragraph of section 11, which says:

For purposes of the following three paragraphs, a "patent license" means a patent license, a covenant not to bring suit for patent infringement, or any other express agreement or commitment, however denominated, not to enforce a patent.

Anonymous wrote:

Why would you have a phrase like "with a third party that is in the business of distributing software" in paragraph five of Section 11?

If I'm MS, wouldn't I just license a few critical patents to a patent troll and let them do the the dirty work?

... and Anonymous wrote:

I've heard it eluded to that Microsoft already has in place patent agreements with businesses over the use of Linux and other opensource software already. How do you protect against that? If you're in business and a company like Microsoft approaches you and says your use of that software infringes our IP. Pay us and as a stipulation, keep it a secret. How do you respond to that or as a community, protect against that?

The reason the Microsoft-Novell patent deal is so nefarious is because it puts pressure on all free software users to pay a fee to Microsoft. That only works because a few things are true about the company. First, it has a large patent portfolio, and other companies are concerned that a typical GNU/Linux installation may infringe those patents. Second, Microsoft sees free software as a competitor, and so we know it's going to do everything it can to make life hard for free software users. If one of those weren't true, the same pressure wouldn't materialize.

A standard-issue troll doesn't create this effect because it doesn't see free software as a competitor. In fact, it doesn't have any competitors at all; it's just a leech. They'll threaten anybody who has enough money to be a worthwhile target that they think they can win against, and once they have their money they'll go away until they get another patent to use. They would never sue me personally because it doesn't gain them anything.

In fact, other companies distributing free software have already made patent deals with trolls similar to the Microsoft-Novell agreement. We don't want to penalize them for this; it doesn't hurt the community, and it's sometimes the most economical way to deal with the problem. That's why this limitation is there.

GPLv3 is going to provide free software developers with more protection against patent aggression than any other license. It's one of the best reasons to adopt the license. But it's not going to solve all of our problems with patents; it never could. If Microsoft decided to wage full-scale war and start suing all free software users for patent infringement, consequences be damned, no license could stop them. The only way to solve that problem once and for all is to abolish software patents. In the meantime, the whole community needs to cooperate to make Microsoft's war more expensive. The new terms in GPLv3 are part of that. Patent pools like OIN are another part. We have been making progress on this, though I do wish it were a little sooner coming.

swmcd wrote:

It isn't quite obvious to me that Microsoft has "propagate[d] by procuring conveyance of" Linux in the Microsoft/Novell deal. My understanding of the deal is that Novell distributes Linux and Microsoft agrees not to assert its patents against Novell's customers. How exactly does this constitute an act by Microsoft of procuring conveyance?

The deal between Microsoft and Novell also includes some marketing cooperation. Microsoft provides coupons for SUSE to companies, who then go to Novell to redeem the coupons and get their copy of the software. Those coupons procure the conveyance of lots of free software.

Our lawyers have seen the terms of the deal under NDA—unfortunately, they're still secret—but they're confident that Microsoft is already conveying GPLed software under this agreement. The coupons are the most direct proof; there is some other evidence to support that idea as well.

Anonymous wrote:

I parse section 11 paragraph 3 as: IF ( rely-on-patent-license AND source-not-available ) THEN...

But the source is required to be available (by section 6). What is the difference between this and the section 6 requirement (other than "free of charge")?

Paragraph three of section 11 is concerned with whether or not the source is publicly available to everyone. Section 6 only requires distributors to provide source to their recipients.

As to option (1), how does having the source help with patents?

When someone is relying on a patent license in order to convey a GPLed work, it creates a number of problems. For starters, the people who get the software may be afraid to convey it to other people. In that scenario, everybody would effectively pay a royalty to the licensee, and there won't be any competition pressuring them to bring the price down, either. When the source is publicly available, it's harder for them to set up that toll booth.

What can the user do with the source they download? Depending on what patents are involved, and how the software is written, it might be possible to modify the software so that it no longer infringes them. For instance, if the software is a video playback program using licensed codecs, you could modify it to use Ogg Theora instead, and still benefit from interface code and other generic features that were in the original program.

Depending on your jurisdiction, you may also have some protection from patent infringement claims, depending on exactly who you got the software from and how they're related to the licensee. It seems likely that you have at least some sort of implied license to exercise your rights under the GPL. There's still some legal risk here, but not as much as there has been in the past. As always, each user will have to decide for themselves how much risk they can handle.

As long as noncommercial developers can get the code, we think patent licensees will have a hard time breaking the development and distribution cycles for free software. This option, along with public availability requirement earlier in the paragraph, keeps the code flowing.

As to options (2) and (3), if you don't hold the patent yourself, then how can you disclaim or extend the patent license, for yourself or for others?

I'm not sure I understand what would prevent you from disclaiming your own license. All we require in option 2 is that you make it clear that you are not relying on your patent license when you distribute the software. If the patent holder wants to sue someone for patent infringement, they'll be pressured to go after the distributor who disclaimed the license first. Other users can see how that case develops to inform their own decisions about how much risk is involved when they use the software.

Option 3 acknowledges that you must "arrange... to extend the patent license." In other words, we realize that you can't do this unilaterally; you'll have to discuss it with the licensor.

PolR wrote:

Question number one: if GPLv3 is incompatible with non-problematic patent agreements, could this be misused to make it harder for corporations to join the community? Imagine corporation A does not distribute Free Software today. Some unfriendly organisations may trick corporation A (after the date limit) into patent cross-license agreements that are incompatible with the GPLv3. Then corporation A is unable to change its mind at a later time and distribute Free Software. This could be the basis of an attempt to limit the community growth.

Yes, this is a very real concern. That's why we've attempted to draft those particular terms as narrowly as possible.

Question number two: What if someone structured his organisations into separate parts where the owners of the patents that sign cross-licensing deals is a different legal entity than the parts of the organisations that depend of GPLv3 software? For example, you could have a holding where there is a patent troll outfit and a software development outfit and all software patents on the development outfit products are transfered to the troll outfit before they are licensed to third parties. The software development can use GPLv3 software a lot, but the troll outfit never uses any. This is an example among other possible scenarios.

I ask because I think you have to be a GPLv3 licensee for this section 11 to be applicable to you. If the patent licensing outfit is a seperate legal entity, it will not hold a GPLv3 license and will not be bound by its terms. In this case couldn't the patent arm get to sign cute patent agreements with third parties?

We are considering adding terms to the license so if an organization distributes GPLed software, its patent obligations would be extended to organizations it controls as well. That would help address this case specifically.

That said, this seems like a remote possibility; I have to question what the overlord organization gets out of this arrangement. Very few companies have such incentive to try to undermine the GPL, and even if they went through this sort of kabuki dance I think it would be self-thwarting, as I described earlier.

Question number three: If it is OK to let Novell/Microsoft get away with paragraph 5 before the cutoff date because paragraph 4 is good enough, why isn't it OK to also let them get away after the cutoff deal? I ask because depending on the answer to first two questions paragraph 5 may hurt Free Software friends more than it hinders those getting cute with the GPL.

Novell did a lot of damage to the community's patent defenses when it made its deal with Microsoft. We need to discourage other distributors from making similar arrangements, and paragraph 5 serves that purpose much more effectively than any other part of the license.

While we were drafting this language, we worked extensively with the friends of free software you're talking about, and we continue to do so, to ensure that this language will not cause undue problems for them. These conversations have been productive and it's quite possible that we'll make a couple of adjustments based on what we hear.

Sesostris III wrote:

Could I ask for a clarification? It seems to me on reading the relevant bits of the GPLv3 that the GPLv3 patent provisions only cover GPLv3 code. Is this right?

With one caveat, that's correct. We could've written them more broadly, but that would've been asking too much of the large patent holders who distribute free software.

I guess that could lead you to the question: why don't Microsoft and Novell make a patent agreement which explicitly excludes all GPLv3-covered software from its scope? That leads us to the caveat: paragraph 5 of section 11 kicks in if the patent license or covenant not to sue covers a product or compilation of software that includes some portions under GPLv3. So, if you create a distribution that includes any software under GPLv3, you can't arrange to provide discriminatory patent protection for that distribution, even if you try to carve the GPLv3ed parts from the deal.

swmcd wrote:

Section 0 paragraph 6 excludes private modification from the definition of "propagate". This seems to create an anomaly: making a verbatim copy is propagation, but if I make a trivial change to the work (say, copy all but one byte), then I have a modification, and it escapes from the definition of "propagate".

I've grep'd the text of the license, and I can't find any place where this would make a difference, but I'm curious why it was done.

Under copyright law, you need to have permission if you want to modify a work, even privately. So, if people are going to release their work under the GNU GPL, the license has to provide permission to do that. However, we're not particularly interested in placing restrictions on private modification, so we carve that out of the definition of propagate, and make it clear that you have permission to do this in section 2.

Of course, if you give a copy of the modified work to someone else, that's something else entirely, and falls under the definition of convey. That's the main goal of these new terms: to draw a clear line between the acts that we've historically considered distribution—the kind that provide other people with a copy of the work—and those that don't. So, we want to define propagation to include any activities that involve making a copy. Then we define conveying as the subset of those acts that involve giving the copy to another party. Excluding private modification from the definition of propagate should help make that line even clearer.

grouch wrote:

What does "occasionally" mean, there [in section 6(c)]?

We don't have any secret, precise legal meaning in mind. It means the same thing it does in everyday English. Yes, different people will have slightly different ideas about what exactly counts as occasional. That's okay by us; we're comfortable with any of the possibilities a judge is likely to accept.

Anonymous wrote:

Removing automatic termination from the GPL seems to be a serious error given the breadth of people who contribute to GPL licensed software (many of whom don't have the resources to identify and notify violators) and the difficulty of determining if a proprietary package contains GPL code in violation of the copyright.

What then is the rationale for removing automatic termination, and why should we wish to license code under the GPLv3 if it fails to include an automatic termination clause?

Dealing with license violations is a major part of my job. When I determine that someone's violating the license on some piece of software where the FSF holds the copyright, like GCC or coreutils, I send them a letter. It tells them everything they need to know up front. I explain what the license requires, and how they failed to meet those obligations. I inform them that they've lost their rights to continue distributing the software, and we'll restore those rights if they work with us and take appropriate steps to cure the violation.

This hasn't happened to me personally yet, but occasionally a violator will think to ask: what about our rights for all the other software we were distributing? How do we get those back?

That's a very tough question to answer. We do have an answer for it, but it's not exactly satisfying to some of these companies. Everyone involved, including me, could breathe a lot easier if there were a clear way to get all your rights back, and the new termination clause provides that.

As long as enforcers of the GPL are primarily concerned with bringing about compliance, I don't think the new provisions will undermine their work. While the violation is ongoing, a copyright holder can always put the violator on notice, and once that happens they have all the time in the world to pursue the matter however they want. And if the violator already brought themselves into compliance, then we've reached our goal.

swmcd wrote, in reference to "Any attempt otherwise to propagate or modify it is void" in section 8:

What does that mean? Can you give an example of a situation where the outcome would be different if this sentence were omitted from the GPL?

No, this sentence doesn't actually change anything. It's only meant to remind you of what copyright law already says: you're not allowed to change or share the work unless the copyright holder or the law itself gives you permission to do so.

Anonymous wrote:

Shouldn't distribution in any country be limited by patent laws in that country? What happens if Congress passes laws to limit exports to Iran of patented technology which is available under an unrestricted royalty free license acceptable to GPLv3? Can Microsoft or someone else use this clause in GPLv3 to block the use of programs in the US on the basis that it doesn't comply with the GPLv3 requirement that it must be distributable to everyone including individuals in Iran? Of course distributing in Iran won't be a problem because US law doesn't run in Iran, but what is worrying is whether it may be used to block use of the GPLv3 program in the US.

This is a good question. In fact, it might not be as hypothetical as you think. After all, there's a piece of free software you're not allowed to develop or distribute in the United States already; it's called DeCSS.

A license can't give you permission to break the law. As long as the law doesn't expressly prohibit you from fulfilling your obligations under the GPL, we don't think it can be used as an argument under section 12 to cease conveying the program. So, in your example, I can convey a copy of GPLed software to someone in the U.S., and also pass along the source and a copy of the license, and I've done everything I'm required to do. I'm not the one who insists that my recipient not convey the software to Iran; the government does. I shouldn't be held responsible for that.

It's also unlikely that Microsoft would be able to even try this sort of action. If anyone were going to do it, it would be the copyright holder.

Reven wrote:

I myself have a couple projects that I release under the GPL. Something that I would like to add as a limitation to my license is to have it automatically expire when a new version of the GPL is released, with the option that the person may then relicense it under the new version of the GPL.

I was thinking that this could be an allowed limitation in section 7. It would be completely voluntary on the part of the developer, so I can't see that it would be a hard sell either.

Just thinking of this possibility with respect to the Novell deal makes for a lovely fantasy. It allows me as a developer to not have to worry about a future loophole, because if something comes up strong enough to warrant a license change, my software is retroactively covered. The day after GPL v4 is released, whomever is misusing an unforeseen loophole in GPL v3 is cut off.

In these days where software is often "patched" to retroactively fix a bug, wouldn't it be nice if a license could be too?

I appreciate your enthusiasm for GPLv3, and definitely understand your concerns. However, adding a feature like you describe isn't really feasible. One big reason is that it's not clear to us how to have it work effectively. How do users find out about new versions of the GNU GPL? What if they don't have Internet access? What if the web is superseded by another system? And so on.

Another reason is that this sort of language in general has the potential to grant rights to users initially, and then take them away at a later date. While there are specific circumstances where this seems like a good idea, we must make a principled stand against this. A license that can be changed from under you is a license that can take away your freedom. While the GNU GPL would never do that—it will always be a free software copyleft license—we must not encourage other license authors to adopt such language.

Winter wrote:

A highly politicized area where copyright like restrictions and patents are indeed harming people is the field of Plant Breeder's Rights which give a plant breeder a copyright like monopoly on plant varieties. It has been no exception that farmers and plant breeders in the developing world have developed new pest and stress resistant varieties of important crop plants, only to find them being hijacked by a commercial breeder who starts enforcing Plant Breeder's Rights against the original breeders. Patents on genetically modified plants are a dime a dozen. Many large companies also produce Tivo like restrictions on seed. For instance, by manipulating the plants to be sterile when raised from their seeds.

While reading the rationale document, I was wondering whether the GPL could be used to cover new plant varieties? And whether it would need adaptations?

I'm afraid I can't answer your questions authoritatively; unfortunately, I don't know enough about this particular issue. In the latest draft, we did introduce some small changes so the license works more effectively with laws similar to copyright, such as semiconductor masks. I imagine that might help. The idea of copylefting plants certainly sounds intriguing, but it's a little out of our field—we are the Free Software Foundation, after all.

Anonymous wrote:

Also, what are we going to do about the FUD that Microsoft will put up over the MS-Novell deal? I think it's already clear that they paint the GPL as "anti-business" but here, they'll probably try to sell it as a risk that the GPL can be amended to punish you if you use it. Never mind that that's largely ridiculous, only applies to new code, and would only ever happen if you were trying to do something to extort free software users, I don't doubt that they're already preparing a media blitz over it.

Is any PR machinery in place, yet, to handle this?

In the past few weeks, we've gotten a good sample of the tactics Microsoft is going to use against GPLv3. The so-called Association for Competitive Technology has been on the warpath. GPLv3 is an unenforceable contract, they say. You can't negotiate it. It's going to send us back to the bad old days of technology when different pieces of software couldn't talk to each other. Apparently, their plan is to say anything they can think of that sounds scary, and then see what sticks.

Nothing good ever came of underestimating Microsoft's power, but I think this is a pretty good sign for us. I don't think they're fooling anybody who honestly has an open mind about this subject. And once you see other big companies releasing software under GPLv3, I think that'll do a lot to dispel the FUD right there.

Of course, we are keeping an eye on what they say, and we do have ways to react if things get nasty. We've put too much work into the substance of this license to let it be defeated by marketing. Like I said at the beginning of this, we do need to be smart in how we move forward. Drafting the license has been the focus of much of our efforts lately. A lot of talking and listening and careful consideration has gone into the language we have today, and I think it represents a great step forward for software freedom. Given that almost all the harsh criticism has come from Microsoft, I'm hopeful that you all—the community—agree.

And with that, I think I've addressed all the concerns that were raised. Thanks again for all your feedback—GPLv3 is a better license because of your support.