Licensing and “open source”
You’ve created a software product. Now you want to open source it in the safest way, so that you, your product, and its users are protected.
You’re puzzled: do you need a license at all?
If you plan to use the code yourself, then you don’t need a license. But the copyright law works in such a way that if you release your code publicly without a license, it belongs to its author anyway – protected under copyright. This means it would be unsafe for anyone to use your unlicensed code. Because theoretically, you could sue your users for royalties if they are generating income from it.
In short, your project won’t be open source if it doesn’t have a license.
But what license should you use?
Permissive and copyleft licenses, “copyleft” concept
There are literally hundreds of open-source licenses. They are broken down into two main types: permissive and copyleft.
Permissive licenses allow users to do almost anything with the code but still offer copyright protections. These include the MIT license, Apache License 2.0, and the BSD 3 Clause License.
Developers modifying the code will only have to give attribution to the original author in the form of a short statement in the code. They don’t have to release their modified code as open source.
Copyleft licenses require that anyone who changes code open sources modified code, too. Popular copyleft licenses include the GNU General Public License v2 and v3, and the Mozilla Public License 2.0.
As you have seen, copyleft is a way to make your program and its modified versions free for everyone (as in “free to use”). While the simplest way to make software free is to release it in the public domain, uncopyrighted, this may lead to some people using the program to make proprietary software and thus restrict freedom to use your code by anyone.
Copyleft guarantees that anyone who redistributes the software passes along the freedom to all users who can further freely copy or change it.
As GNU project puts it:
“Copyleft is a way of using the copyright on the program. It doesn’t mean abandoning the copyright; in fact, doing so would make copyleft impossible.”
OSI-approved and non-OSI-approved, your own license
The Open Source Initiative (OSI) maintains a list of approved open source licenses. OSI is a recognized authority in the licensing world, so by picking one of the OSI-approved licenses your product will be in good hands.
Similarly, there are hundreds of non-OSI-approved licenses – for example, Unlicense, CC0—The Creative Commons Zero, and WTFPL – but using one is a risky proposition.
OSI-approved licenses are tried and proved in thousands of projects, while non-approved ones may require hours of consultations with a lawyer, potential legal troubles, etc. At the same time, it’s better to use a non-OSI-approved license than no license at all!
There’s even an OSI-approved public-domain-equivalent license: BSD 0-clause license.
What licenses are suitable for what kinds of software?
To determine a suitable license, we advise you to follow a decision tree.
First, determine whether you need OSI-approved or not.
Then, choose between permissive or copyleft.
Finally, select a certain variation of the license type you have chosen.
When selecting a license be mindful of your target audience and consider what the license says about patents, litigation, and legal jurisdiction.
Much of this decision-making will depend on the type of your product.
If these questions are too hard for you to answer yourself, use built-in licensing from such SaaS tools like GitHub and GitLab. It will give you many options for applying for an open-source license when you start a new project.
Contributing to an existing project
If you are a contributor to an existing project, as a rule of thumb, release such modified software under the same license as the original code. A different license can be justified only when you make major changes to a work that result in a considerably more useful product than the original one.
For most programs, the strongest copyleft license is best – like the most recent GNU General Public License (GPL). It is appropriate for all kinds of software and includes numerous protections for users’ freedom. At the same time, for most small programs, using copyleft is not worth the work. GNU uses 300 lines as a benchmark and recommends the Apache License 2.0.
If you think that modified versions of your program will be run solely on servers and won’t be distributed to anyone, GNU recommends using the GNU Affero General Public License (AGPL).
There is a strong copyleft GNU Free Documentation License (GFDL) that has been created specifically for tutorials, reference manuals, and other types of longer documentation. For shorter, secondary documentation, for example, a reference card, there is GNU all-permissive license.
Icons, graphics, fonts
If you created icons and other graphics, fonts, and geographic data specifically for your project, release them under the same license as the main software. All licenses – Apache, GPLv3, LGPLv3, AGPLv3, and GPLv2 – are suitable for any kind of work, not just software.
The “language” projects
Perl, PHP, Python – each programming language has its own license: Artistic License 2.0, PHP License 3.0, and Python License 2.0 respectively. If your project is largely based on a specific open-source programming language and its community, then stick to that community’s license.
There are many edges and nuances to licensing digital work. As a rule, we advise opting for a popular OSI-approved license that is used by products similar to yours.
But this process can never be properly “automated,” as there are as many legal cases as there are pieces of work. That’s why we recommend following the tips above, and when in doubt, seek professional legal advice to avoid any trouble or frustration in the future.
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.