by Ben Adida, part of Licensing in OpenACS Community.

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.

I'm confused! I need to ask some questions

This is complex stuff! You can always email me and I will do my best to help, but your best bet is to contact the Free Software Foundation directly.