Open Source Comes to Campus/Curriculum/Licensing
Nature of copyright
In the free software world, we have to be very exact about copyright. Most people just coming into the community are a little confused by this concept, which is understandable, but nevertheless, understanding the copyright issues surrounding free software can be one of your most valuable tools in support of the free software movement, and in ensuring your projects are used widely. As such, people who have very specific goals tend to have very specific ideas about copyright.
In the US, and in many other jurisdictions, copyright automatically takes effect the second you put pen to paper (or finger to keyboard) and create a work. You don't need to declare that the work is copyrighted, you just need to make it. And when something is copyrighted, basically, it means that only you have the right to copy the work.
In the digital world, practically everything we do involves copying. Downloads are copies. Forks of projects are copies. Even loading a program into memory could theoretically be considered copying it. Copyright, therefore, plays a huge part in our digital lives too. And considering that, once you write a program, copyright takes effect, unless you do something, nobody will be able to use it! Oh no!
To understand free licensing, it's probably useful to contrast, briefly, with non-free licensing. You're probably familiar with End User License Agreements, or EULAs. Most non-free programs will include them. They spell out very specifically which rights you have, and which rights you do not have. Most of them restrict how you use the program, whether you can share copies of it with others, and whether you can attempt to reverse-engineer it. These clauses have different successes and failures being upheld in local courts, but usually it's safest to adhere to the license in full. Most of the time, non-free licenses restrict you from doing almost anything but using the program, and makes it abundantly clear that you're only being allowed to use the program, you do not own it.
Permissive free licenses
Now, to the other end of the spectrum: Permissive free licenses. This family of licenses includes such stars as the MIT license, the BSD license family, more joking selections like the WTFPL, and even public domain releases like Creative Commons Zero tool. These licenses put very few, or no, restrictions on people who receive copies under their terms. Many of them include a disclaimer that the program has no warranty, to help protect the distributor (or the programmers), but some do not. Others release the program into the public domain if possible, but some jurisdictions make that nearly impossible, so most of them have a backup clause that makes it practically public domain anyway.
The Free Software Foundation publishes guidelines on licensing for free projects to help programmers understand the risks and benefits of each. They suggest that if you must use a permissive license, you should use the Apache 2.0 license. FSF recommends this license for permissively-licensed projects because it includes a patent grant and other patent-related clauses—so that contributors to the project are contributing any rights they have, allowing downstream reusers to know that contributors are not withholding these rights and they intend for the software to be truly free to use. (It doesn't eliminate the possibility of third-party patents, but no license does.)
However, the Free Software Foundation, and many others, highly suggest using a copyleft license instead. This family of licenses includes the GPL line (which in turn includes three GPL versions, the LGPL, and the AGPL), the CDDL, and the Creative Commons Attribution-ShareAlike license. They have one thing in common: If you receive a copy of a work under their terms, you may only distribute copies of it, and copies of any derivative works, under the exact same terms.
Many people think that this family of licenses is inherently flawed. The nature of copyleft licenses makes it impossible to use projects licensed that way in non-free works, which is legally possible with projects with permissive licenses. To that end, many modern programmers, especially in the open source movement, have eschewed the copyleft family and licensed all of their work under MIT or BSD licenses. While the cause may not be immediately obvious, there has also been a rise in re-use of free projects in commercial projects.
However, many programmers continue to use the GPL and similar licenses to protect their code. It ensures that code given to the community stays in the community, and is not used in non-free software packages. The AGPL even ensures that code given to the community is not used in non-free web services. The latest version of the GPL, version 3, also protects code from being included in embedded code without also providing the user the (potentially modified) source code (referred to as "Tivoization"). These protections still appeal to many programmers, and they are powerful tools for the movement - very useful libraries licensed under copyleft licenses can sometimes convince programmers to release their code under the same license.
Still a bit confused? That's OK. Here are a few easy-to-remember guidelines that may help.
- If you're not 100% sure you have the right to do something, you don't. Don't assume you can copy and modify a program unless you've found specific permission to do so, somewhere. This could be a personal message from the distributor, or a COPYING file in the git repo, or a license statement in a specific file. Just make sure it applies to what you're copying or changing.
- If you aren't exasperated by the verbosity of a license to do something, you probably still can't do that thing. Lawyers get paid well for a reason: They spend their days sitting in an office thinking up ways to screw with their own work. That's why the GPL and licenses like it are so very, insanely, mind-numbingly long. If the license you're reading just says "Do whatever you'd like" or "This project is free for everyone", there's probably some subtle thing in copyright law that the authour didn't think of. Even if you don't think there is, it doesn't hurt to be absolutely certain. Suggest that they use an existing license, probably a permissive license - not just to protect you, but to protect them, too.
- Always include a license in your projects. If you have ever run across a project without a license file, you know how frustrating it is, and you should try not to inflict that frustration on others. This is a huge problem on the popular code hosting site, GitHub, where many people simply upload code and assume that's enough. Sharing freely requires a bit more thought.
- FSF guide to licensing your projects (biased towards strong copyleft)
- GitHub's license chooser (seems biased towards permissive licenses, obfuscates GPLv3 and the AGPL)
- Creative Commons license chooser (very little bias towards either end of the spectrum, but includes non-free licenses!)
- List of approved Open Source licenses (from the OSI, who has no horse in the race as far as I can tell)