Open-Source software relies on the concept of content licensing. Licensing is the domain of the law, which means it quickly becomes relatively complex. I am not a lawyer, nor do I play one on TV, but I do spend time with a few of them. This document is a summary of the main issues involved.
Interestingly enough, the author has very little control over how the content is used. For example, an author can sell you a book, but would have a hard time enforcing that you can only read this book in your bedroom, but not in the bathroom. In fact, most legal experts note that copyright was never meant to regulate use, only distribution (thus the term copy-right). In practice, there are exceptions, such as in the case of home videos which are sanctioned for home use but not for public viewing.
Now, if you take the book and add a new chapter, you are creating a derivative work of the original book. Much like for the original work, you can't decide on your own to distribute this new work. You can technically purchase the rights from the original copyright holder to distribute this derivative work.
The complicated issues, of course, relate to the specific definition of derivative work. Copying a book word for word and adding a chapter clearly creates a derivative work. But what about writing a book that closely resembles another, but doesn't use the same words? This is usually decided on a case-by-case basis.
An author can thus decide to distribute source code if she wants to. This distribution does not give the recipients of the source code any rights other than to make use of it. Some developers use this simple distribution method: Qmail was previously distributed this way. Users could freely download it and use it, but they could not create derivative works and redistribute them. This is why qmail developers would distribute their work as patches to the original source code, which is the equivalent of distributing an additional chapter to a book without the original content: the end-user is responsible for assembling the pieces in a way that makes sense.
The key point here is that these additional chapters - these source code patches - are copyrighted by their respective authors. Thus, while they could not redistribute qmail with their patches, the original qmail author could not redistribute these patches with qmail, either! In part because of these problems, the author of qmail released it to the public domain.
In general, copyright is a serious obstacle to creating works in a collaborative fashion, because each author owns the copyright and thus controls the distribution policies on their individual pieces. If all authors fully cooperate and agree on the resulting licensing terms, all is well. If not, it's a mess.
An open-source license is thus a set of redistribution policies that a set of developers can agree on before contributing to a common project. Each developer must agree to the terms before contributing to the project, and all developers would technically need to be involved if the license were ever to be changed.
When an author releases a piece of code under the GPL license, she is granting recipients of the source code the following rights:
Thus, the GPL allows authors to effectively use copyright law as a bootstrap to negate the powers of copyright and allow everyone and anyone to participate in a collaborative development effort. As soon as two authors combine their code under the GPL, the resulting source code exists only in "GPL land" where everyone and anyone can contribute to the project within the limits of the GPL.
The GPL is a very interesting hack on top of the Copyright system. While it attempts to negate copyright, only the copyright holder of a work can use Copyright Law to truly enforce the GPL. Thus, the Free Software Foundation recommends that authors voluntarily choose to assign copyright of their works to them in order to create a strong legal entity in defense of the GPL. Not everyone believes this is a good idea.
The Open-Source Initiative has a precise definition of what it takes to be a valid open-source license.
The issue is that it's conceivable that someone would claim that writing code for a specific purpose after having seen other source code having the same purpose is in fact creating a derivative work. Thus, it's conceivable that seeing a particular piece of source code written by someone else would effectively "contaminate" you with that source code's license. This is why people worried so much about the Sun Community License, and why many are currently very worried about Microsoft's new Shared Source licensing strategy.
However, if you are still the copyright holder, you can certainly choose to distribute the source code under a different license. No one else can do that on your behalf! Only you, the copyright holder, can. This is how certain developers choose to release source code under a "double-license."
Double licenses are difficult, however, the moment you begin to involve the community in your development. Each author individually owns the copyright on their pieces of the code, and if you want to redistribute under multiple licenses, you must get all authors to cooperate first.