When you're just starting out in software development, the last thing you want to do is worry about licensing. This is a subject fraught with legal and political battles that have been going on for decades. Some people think you should only use "free" or "copyleft" licenses like the GPL, while others feel the best route is to stick with "permissive" licenses like MIT or BSD.
Licensing is something you need to be aware of not only when developing your code--which inevitably requires you to use code developed and licensed by others--but also when deciding how to release your own software. Many developers treat licensing as an afterthought and that can get them into trouble if they select a license that is deemed "incompatible" with some other license.
While licensing is a very detailed and complex subject--far beyond the scope of a single article--here are a few basic principles to understand as you wander into this proverbial minefield.
How Long Does Copyright Last?
Let's start with a basic question: Why do we need licensing at all? The simple answer is copyright. Any code that you write is protected by copyright in the United States, the United Kingdom, the European Union, and indeed most countries around the world. Copyright means that you, as the author of an original work, have the exclusive right to decide how others may use, copy, or distribute that work.
Historically, copyright was something that required an author to register their work with a government agency, such as the U.S. Copyright Office. This registration then guaranteed copyright protection for a fixed number of years and might need to be renewed at a later date. But today, copyright is generally considered "automatic" from the moment the work is created. In other words, if you just write some original code and save it to your computer--or push it to a remote repository like GitHub--it is now protected by copyright without you having to take any further action. While it is customary to affix a copyright notice, e.g. "Copyright 2022 Jane Smith," even that is not technically required anymore.
And unlike the old days, copyright today lasts a very long time. Most nations are parties to a treaty known as the Berne Convention, which sets certain minimum standards for copyright protection. Under the Convention, copyright for written works like software code must last at least for the lifetime of the author plus another 50 years after their death. But this is just a minimum. The United States, the European Union, and many other Berne signatories have actually increased the term to 70 years after the author's death.
Now, those are the rules that apply to individual authors. A "work-for-hire," such as code written by a corporation's employees, are subject to different copyright terms. In the United States, such copyrights last 95 years from the date of first publication or 120 years after creation, whichever is shorter.
In practice, these rules mean that code written for some of the first microcomputers in the early 1980s can remain under copyright well into the 22nd century! And given how even a simple program today may depend on dozens--if not hundreds--of previously written pieces of code, it would be impractical for you, as a developer, to seek out and get permission from each original author to reuse their work. This is where licensing comes into play.
Setting Conditions for Using Your Code
A software license sets the conditions by which someone can use your code to create "derivative works," i.e., a new work that incorporates your copyrighted material. As a developer, you also rely on such licenses to create your own code using software developed by others. A license is effectively a contract between the copyright holder and the person who wishes to take advantage of the license.
Many developers--especially those who want to sell their software--offer different types of licenses for their code. For example, Riverbank Computing, Ltd., the company that publishes PyQt, does so under a "dual" license. One license is for use of PyQt in proprietary applications, i.e., software where the developer does not release their source code to the end user. The other license is the GNU General Public License v. 3.0 (GPLv3), which can be used with non-proprietary applications.
Licenses like the GPLv3 are sometimes called copyleft licenses. The word "copyleft" is a term of art that has no legal significance. Copyleft is basically a preferred outcome under copyright--i.e., preserving the ability of both the original author and any subsequent users to freely modify and redistribute source code. But this is all still rooted in the principles of copyright law. If you violate the terms of a software license, even a relatively permissive one, you are also violating the copyright of the developer who released their software under that license.
One way that you can violate copyright, perhaps without realizing it, is to release your own code under a license that is incompatible with the license of other code used in your project. Indeed, you may read that certain licenses are considered "open source" yet are not compatible with the GPLv3. Does this mean you must always use the same license? Not necessarily. For example, PySide is released under the Lesser GPL or LGPL license. The terms of this license differs from the GPLv3 but the two are still considered compatible in most cases. In the next article, we'll examine these differences in more detail.