Nuclear war is a really bad thing.

It's so bad that we want to work really hard to avoid it. As the copyright holders of a whole bunch of free software, FSF has a lot of power. So, why do we permit the use of free software in nuclear weapons?

The GPL represents a truce between mutually hostile powers. Gigantic companies, who compete relentlessly in other areas, cooperate to improve the GNU C Compiler and other free software. And individuals from rival political movements, from communists to libertarians to radical anarchists hack on Free Software. I've met Free Software hackers who are evangelical vegans, and Free Software hackers who drive SUVs.

So, let's say we decided that version 3 of the GPL would contain a clause which would forbid you from using GPL software in nuclear weapons. The anti-nuclear activists would be very happy. But what about the anti-torture activists? Or people who oppose genetically modified foods, or the free biotech people? They would all be understandably upset that their pet cause is being neglected. And the nuclear engineers wouldn't be real happy about it either. Eugene Volokh makes the same point about free speech in general:

" Think of it as "censorship envy" -- if my neighbor gets to ban symbols he dislikes, why shouldn't I get to do the same? "

So, we reject restrictions on who can use free software, or what it can be used for. By keeping everyone on a level playing field, we get the widest possible participation in the free software movement. And the anti-nuclear activists are still free to use free software to organize and spread their ideas.

Read this article auf Deutsch]]> No publisher root 2010-05-17T20:43:38Z Web Page http://www.fsf.org/blogs/licensing/20050324tedt.html An example of why we need to know the reach of our intellectual interests. An example of why we need to know the reach of our intellectual interests.By Ted Teah

Recently, the "Big Dig" construction project here in Boston ran into some big trouble over software. It seems that the Massachusetts Turnpike Authority (MTA) the agency in charge of the Big Dig, failed to stipulate all their rights to the Integrated Project Control System (IPCS) program of Transdyn Inc. It is clear that they had the right to execute the program, but when it came time to hand the project off to the next lowest bidder, there was no source code to be found.

At the end of the “early-build” contract, the final development of IPCS was to be done by the winning bidder of the “full-build” contract. Honeywell, a bidder on the “early-build” contract, was the lowest bidder on the “full-build” contract. Transdyn argued that the software in question was off-the-shelf so they did not need to provide the source, while the MTA contended that the numerous changes to tailor the software to the circumstances make it a custom work, which would entitle the state to the source code.

After an out-of-court settlement by the State, in the amount of $350,000, Honeywell, was able to use Transdyn's work. The total cost of this incident, according to the state auditor, exceeds $10 million. This causes a smirk to flit across the faces of all those who have ever looked over their employment contracts and seen words to the effect of, "anything you say, see, think, or do which is in anyway related to our current business and or planned business is OURS!" Agreed, there are differences between contractors and employees which affect the legal analysis of the situation. But you would have thought that by 1994 even the government would have realized that you don't truly have the program until you have the source. Too bad they didn't talk to the Government Open Code Collaborative, to which Massachusetts belongs.

If nothing else this serves as a poignant example of the importance of securing an employer disclaimer. That is, if you want the peace of mind that your piece of mind is yours, get a disclaimer.


Source: NO.2003-0510-3C3 Independent State Auditor's Report on Certain Activities of the Massachusetts Turnpike Authority's Central Artery/Third Harbor Tunnel Contract C22A1 January 1994 Through December 2004]]> No publisher tedt 2010-05-17T20:43:39Z Web Page http://www.fsf.org/blogs/licensing/20050325novalis.html The basics about copyright and licensing The basics about copyright and licensingI get a lot of questions about licensing which seem easy to me. I've just realized that the cause is probably that people don't understand all the pieces of the Free Software licensing system. I say "system" because the GPL really is like a piece of software that runs on top of LegalOS XP (home edition). Even though there are many legal systems in the world, most countries have agreed to the Berne Convention. So, copyright laws are quite similar around the world.

So, here's a primer:

1. Copyright law grants to copyright holders some exclusive rights.

   a. These rights include copying, modification (what copyright law calls "preparing a derivative work"), and redistribution.

   b. If you write software, you're probably the copyright holder, unless you are at the time working for some company as an employee. You don't have to do anything special to obtain a copyright. As soon as you save the document, pixies sneak into your computer and deposit the copyrights directly onto the document. But it's still a good idea to use copyright notices.

2. Exclusive means that the copyright holder gets to decide who can exercise these rights.

   a. In order to let someone else exercise these rights, the copyright holder issues a license.

3. If someone exercises the rights outside the terms of the license, they're infringing the copyright.

   a. We speak of these as "license violations".

   b. Because the copyright holder is the only one whose legal rights have been infringed, they're the only one who can enforce the license.

4. Sometimes, a copyright holder wants something very close to, but not exactly, standard terms. In this case, they can issue an exception to the license permitting this. That's effectively a modification of the license which makes it strictly more permissive.

   The copyright holder can do this because of (2) above.

   There are at two common cases of this:

   a. The standard terms don't permit linking to a library which the copyright holder wants to permit linking to. FSF has written exceptions for this case.

   b. Someone has convinced the copyright holder that they should be treated specially and have rights above the standard terms. Perhaps this is because they have paid the copyright holder. Because the terms for this can vary wildly, and can sometimes support proprietary software, FSF doesn't have standard text for this.

5. You can also assign your copyright. By way of analogy, licensing software to someone is like inviting them to visit your house; assigning copyright to someone is like selling them your house.

   a. You might want to assign your copyright to someone else if they promise to do the work of enforcing the license, or they otherwise won't take your patches.

6. We maintain a list of free software licenses. A license gets on this list by consensus of our licensing committee. But the committee isn't a bunch of alchemists. They don't even have pointy hats. They just look at the terms of the licenses. Decisions are made based on the Free Software Definition.

   Usually, you can tell if a license is a Free Software license by matching its terms to other licenses in the license list. This is not to say that a license which consists only of terms from other Free licenses is ncessarily a free license. For example, if I took only section 11 of the GPL and called it my license, it would (a) not be a license and (b) not be free. But a license that differs from another only in the name of sponsoring organization will be judged the same.

7. We encourage the use of standard licensing terms.

   a. Writing a new license, rather than using an existing standard license, is a bad idea because it increases the burden on people who want to re-use your software. They have to understand some new set of terms. And then they ask me to tell them if it's a free software license.

First, in the US, the copyright status of fonts is somewhat confused. A font face -- that is, the look of a font, is not copyrightable (see Eltra Corp. v. Ringer, 579 F.2d 294 (4th Cir. 1978)). But font "programs" (truetype fonts, for example) are. Another ruling has extended the definition of "programs" to include certain outline data. Why this outline data is not equivalent to a font face, nobody knows. Helpfully, the copyright office has also issued contradictory statements on this. I don't know how font copyright works in other countries.

What this means is that no font is going to affect the distributability of a printed document in the US. Further, merely referencing the font (as in the CSS font-face: caslon;) does not create a derivative work of that font. So why did we worry about font licensing at all?

The situation we were considering was one where a font was embedded in a document (rather than merely referenced). Embedding allows a document to be viewed as the author intended it even on machines that don't have that font installed. So, the document (a copyrighted work) would be derived from the font program (another work). The text of the document, of course, would be unrestricted when distributed without the font.

This isn't an artifact of the GPL; it's just the way fonts work. Proprietary fonts often explicitly forbid embedding. So, if you want to send your document off to a printing service, the printing service needs to buy another copy of the font.

I was unhappy with even this amount of influence for fonts, because (a) it's rarely what font authors intend and (b) it's possible that some applications do embedding behind the user's back. The situation seemed to me to be similar to the case of the runtime libraries which GCC automatically includes in its output (and which are licensed to permit inclusion in proprietary software). So, I wrote the font exception you see on our web site.

The reason the exception is so limited is that we're worried about someone extracting a font from a document, and redistributing it. Extraction is, in my view, the major issue that a font license must confront. Because I haven't been able to come up with a license which correctly handles embedding and extraction in all cases, I've restricted this exception to unaltered fonts. This means that someone can't use embedding as a way to distribute a modified version of a font under restrictive terms. If you have suggestions for how to write a license which better handles extraction, please let us know. We haven't had time to give this as much thought as we've given some of the other issues involved in free licensing. We're especially interested in hearing from font creators at licensing@gnu.org.

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 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.

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.

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.

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.

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.

Because so much has happened so quickly, some people have speculated that developers' attitudes about GPL enforcement have changed. In reality, I don't think that's the case. To put it simply, filing lawsuits isn't fun. It takes a lot of time and energy that most people would rather spend elsewhere. These are all cases where the developers have tried hard to amicably work with the violators for compliance, and have been met with stonewalling and resistance. Compliance efforts around Freebox have been going on for years, to no avail.

One of the major goals of the GPL, and one of the main reasons so many software authors choose it, is to create a commons of software that everyone can share and build upon. All these developers would be satisfied just to see these companies follow the GPL's rules and contribute to that commons. Unfortunately, when a company fails to do that and won't respond to polite requests, legal action is the only major option left to address the problem. These lawsuits only demonstrate how serious we all are about protecting software freedom.

You can use these logos on your project web page, or even in the software itself if you want. It's an easy and straightforward way to let your users know that the software they use and contribute to is protected by a license that puts software freedom first.

Previous versions of the SGI Free License B were nonfree. Luckily for us, however, they included this clause:

Once Covered Code has been published under a particular version of the License, Recipient may... choose to use such Covered Code under the terms of any subsequent version published by SGI.

So, now that SGI has released a new, free version of the license, users can take advantage of its terms. SGI has just made a large and invaluable contribution to free 3D software, and we're very thankful to them for that.

Unfortunately, today it still isn't be possible for free system distributions like gNewSense to add OpenGL support back to xorg just yet—there are still a few legal loose ends that need to be tied up first. But we're getting right to work on resolving those issues, and we're confident that we're going to be successful.

Here's the deal: all of the code that SGI contributed to Mesa is covered by the SGI Free License B, so that is all free software now. Most of the code that SGI contributed to xorg is available under this license too, but there are a few exceptions. A little bit of the code was released under the GLX Public License. That code can be found in these files:

• proto/glproto/glxint.h
• xserver/GL/glx/glxext.c
• xserver/hw/dmx/glxProxy/glxext.c

Since that code was originally contributed, two things have happened in parallel. First, developers outside of SGI have been changing it to better meet xorg's needs. Second, SGI later released their original code under the SGI Free License B.

Because it has been released under the SGI Free License B, the code in those files that comes directly from SGI is free software. However, we can't make the same assumption about the changes that other developers made—that code is still covered under the GLX Public License, and still nonfree. We need to get permission from those developers to release their contributions under a free license as well.

Right now, it looks like there have been somewhere between ten and twenty people who made changes to code released under the GLX Public License. We plan to work with them and the rest of the xorg team to get their contributions under an appropriate free software license. We hope that this process will take less than a month. And once it's done, a complete, modern OpenGL implementation will be available to the entire free software community.

Check back at this blog for progress updates as we get the rest of this sorted out and ensure freedom for 3D rendering.