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.

Copyright and Derivative Works

In order to motivate the creation of content, various 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?

Source code is a work much like a book, written by one or more
people. The source code is copyrighted by the authors (whether or not
they register this copyright, it's automatic).

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.

So what's the GPL?

The GPL, the GNU General Public License, is a means of implementing a
concept called Copyleft. Copyleft attempts to negate
copyright for the purposes of collaborative software development.

When an author releases a piece of code under the GPL license, she is
granting recipients of the source code the following rights:

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.

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.

What about the other open-source licenses?

Other open-source licenses like the BSD and Mozilla License also allow
redistribution, but make less requirements on the conditions of this
redistribution. The BSD license, for example, allows anyone to
redistribute the work or any derivative without any source, if such is
the desired path. Some people believe that these licenses grant users
more freedom, since they include a "superset" of the rights granted by the
GPL. Other people believe that only the GPL truly respects users'
freedoms by guaranteeing that no one can coopt their original
work. Choose your side, because this document won't!

The Open-Source Initiative has a precise definition of what it takes
to be a valid open-source license.

So what should I be worried about?

We don't know for sure what constitutes a derivative work in
software. No one has truly tested this definition. The GPL implies
that a derivative work is one that is linked, statically or
dynamically, with the original work. Yet this might change with GPL
v3.

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.

So if I release something under the GPL, I can never take it
back?

If you own the copyright on a piece of code, and you release it under
the GPL, then you can never revoke this right you gave to others. You
can choose to stop distributing the source code, but if someone
obtained it from you, they can then choose to continue distribution
without your ongoing permission. In that sense, you can't take it
back.

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.