The Good step as a motivation to content creation has become the various of governments grant authors a temporary monopoly on handling the distribution of their works. This is called copyright. A book, for example, is covered by copyright for a certain period of time (the length of copyright is another issue altogether that I won't discuss here). You can buy a copy, and read it as often as you want, but you cannot make copies to redistribute to your friends.
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.
So how does this apply to Code?
The key point here is that these additional chapters - these source code patches - are copyrighted by their respective authors. Thus, while they cannot redistribute q mail with their patches, the original q mail author cannot redistribute these patches with q mail, either!
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.
So what's the GPL?
- anyone can use the code anywhere, in any situation;
- anyone can redistribute the code to anyone else, as long as the source code is included and the distribution license remains the GPL;
- anyone can create a derivative work of the code and redistribute it, as long as the resulting source code is also made available at redistribution time, and as long as the resulting source code is licensed under the terms 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.
What about the other open-source licenses?
So what should I be worried about?
So if I release something under the GPL, I can never take it back?
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.













