So you have a project that you want to use open source tools to create—well, I tip my hat off to you as a developer. But do you know the questions you need to answer before you get started?
What stage of development is your project in right now? Have you finished the planning phase? Are you going to work with a team? Will the project be split up into different modules? And so on.
The principle of DRY (Don’t Repeat Yourself) has become an unwritten rule for developers. Instead of always starting from scratch on each new project, find ways to build upon previous work. This will save you time and other resources. In other words, do not reinvent the wheel; put to use the great work that others have perfected and made “freely” available for you to build upon.
This principle of DRY can also be applied to open source works. When starting a new project, most developers first search carefully for frameworks, libraries, and packages that they can build on or modify to fit their needs.
Best of all, there are thousands upon thousands of open source projects (OSes, frameworks, IDEs, libraries, database management systems, and so on) available for you to choose from.
But wait just a minute!
Imagine your project becomes a huge hit, only to get knocked flat by licensing issues required by the works you built it with. Do you really understand what it means to use open source work in your project?
As the adoption of open source keeps increasing, so does the risk of non-compliance with licensing terms—which in turn leads to an increase in the number of litigations involving open source works.
One of the most recent examples involves Hancom and Artifex, the developer of Ghostscript. The case is ongoing, but the direction seems to be clear from the following:
To use Ghostscript for free, Hancom would have to adhere to its open-source license, the GNU General Public License (GPL). The GNU GPL requires that when you use GPL-licensed software to make some other software, the resulting software also has to be open-sourced with the same license if it’s released to the public. That means Hancom would have to open-source its entire suite of apps.
Or, Hancom must pay a licensing fee to Artifex.
Now you get a bit of the picture, right?
Note: Nothing I say in this article is legal advice; if you’re unclear about the explanations or terms you find in a license, it’s a good idea to get qualified legal counsel. These are just a few things I’ve come across and want to point out to my fellow developers.
Evaluating open source options#section2
Before you settle on an open source project to use or include in your own project, go back to your big idea (that is, the project that you are developing) and answer the following questions.
- What is the vision behind your project? Specifically, are you developing another open source project or will you be selling your project for profit?
- How will you make your project available to others? Will they be able to read the source code or will you make it off-limits?
- What redistribution rights will you allow? Will others be allowed to repackage your work and sell for profit, or will they be able to redistribute it for free?
- How should you handle embedding? Will others be able to embed your work into their own work, then sell or distribute for profit, or can they embed your work, but prevent access to the source so it’s unavailable to others?
- How will you handle attribution? What will you do to give credit to the original creators of included tools?
Once you have answered the above questions, what’s next? It’s time to answer another question.
What does open source mean?#section3
What comes to your mind when you come across a work categorized as open source—free to use as you deem fit? Learn what open source really means here from the Open Source Initiative.
After reading that, do you still want to include open source work in your project? Will it derail your purpose and goal?
Why are open source projects licensed?#section4
One reason why projects are licensed with an open source license is convenience.
Open source licenses tell developers how to use your work and the limitations and restrictions that they must observe. You wouldn’t want a constant stream of emails from everyone interested in using your work—these could run into thousands of people.
At the same time, open source licenses make it easy for others to contribute to a project, as opposed to a closed system. Just imagine the talents that will be able to contribute to an open source project in contrast to an in-house project. You will be able to pull in far more resources toward achieving the goal of your project; yes, you will agree that much more can be achieved this way.
Licensing serves as a protection for the creator of a work or body of works; others won’t go about claiming your work as their own. It makes sure that you get the credit you deserve as the author of a project.
Read every license, every time#section5
Not all open source licenses are the same. Take a look at the table in Fig. 1 to see the types of differences you might encounter.
Image Source: https://choosealicense.com/appendix/
Introduction to popular licenses#section6
Below are a few of the most popular open source licenses, with details of what power or limits they impose on you regarding usage and redistribution.
MIT License#section7
A project with this open source license allows you “to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the software is furnished to do so.” This means that you can use this work for your project as you deem fit (even sell derivative works) with the only conditions being that you 1) leave the MIT license intact and 2) include a copyright notice.
What they mean is that you must include a notice similar to this in the license file of your work:
“[name of your project] includes code from [original creator of included work] and it is licensed under the MIT License” followed by the full MIT license text.
One other thing to note before using a work with this license is that “MIT licensed software can be integrated into GPL software, but not the other way around.” Think about a situation where you have to include works with both the MIT and GPL licenses in your project. At the end, this combination will carry the GPL license, excluding the MIT license. (You can read about the GPL license below.)
Apache License#section8
This license is somewhat similar to the MIT license. You can use works with this license in your project provided that you take note of the fact that it “requires preservation of the copyright notice and disclaimer.”
The Apache License term is very strict about modifications. You are required to explicitly state that the original work has been modified and to include the following in your license notice:
The Free Software Foundation considers all versions of the Apache License to be incompatible with the previous GPL versions 1 and 2 and, furthermore, considers Apache License versions before v2.0 incompatible with GPLv3. Because of version 2.0’s patent license requirements, the Free Software Foundation recommends it over other non-copyleft licenses, specifically recommending it either for small programs or for developers who wish to use a permissive license for other reasons.
GNU General Public License (GPL) 3#section9
This license isn’t particularly permissive when compared to, say, the MIT license. But it does foster community effort greatly and it’s one of the most popular open source licenses out there.
When you use work with GPL that you will be releasing to the public (or redistributing), this license requires that you make the modifications available (including how-to documentation for installation and building) under the GPL license.
BSD 3-Clause License#section10
This is also very similar to the MIT license; it allows you to use it for commercial projects, to redistribute, and to modify, but the copyright notice and the BSD license itself must be included.
Your decision between MIT and BSD now depends on what is suitable for your project. MIT and BSD licenses differ in terms of compatibility with other open source licenses—while MIT licensed work will allow you to include other work with different license terms, BSD licensed work won’t. More on that on license compatibility below.
There are several other open source licenses that are not covered here. They require careful reading and understanding before delving into using works they are licensed with.
Ignoring the terms of an open source license#section11
Considering suitable open source licenses all boils down to avoiding lawsuits in the future. Problems foreseen are problems half-solved. But what happens if you ignore the terms of a license?
Will you be prosecuted when this is uncovered? The Free Software Foundation is an organization that volunteers their resources to ensure open source license compliance—kind of an open source license police. The following is a quote from their compliance page:
Once we have established that a violation has occurred, we explain to the violator what they must do to come into compliance. They’ll make some appropriate changes — to their software, their product, their website, or whatever’s affected — and let us know. We check those changes, tell them about any new or outstanding issues we find, and ask them to make more changes. This back and forth goes on as long as necessary.
License compatibility#section12
What about using works with different open source licenses? Will there be any implications? In other words, if you’re thinking of “mixing” work of different license terms in a project, this is where you have to start thinking of compatibility.
If code components that were licensed under different license conditions are compiled to form a new work, a question arises: Is the common use of the code permissible under license law? If for example code A under license X is linked with code B under license Y to form a new program, licenses X and Y must permit this. If this is the case, license compatibility exists.
Perhaps you’ve found an open source work that will perfectly fit your project … But. The. License. Is. Not. Compatible! What can you do about it?
First, consider the license of the open source work you are planning to use in your project.
Obviously, license issues will be easier to manage when you use open source works with the same license, and one way to avoid license incompatibility is to read beyond the list of features—after reading the features section, be sure to scan down to the requirements section.
As you investigate open source tools to use in your project, make “compatibility” your companion. Keep it close.
In terms of compatibility, the MIT license is fairly generous; as of the time this article was written, this license only prevents you from suing the author of the work. So in general, a work licensed with an MIT license is great for most purposes. (Remember that this is not legal advice.)
License infringement#section13
If a licensing case does affect you or your project, note that some legal cases pertaining to license infringement are settled out of court. You may be able to negotiate and reach a personal agreement with the author—an agreement that would allow you to use the work without infringement. Simply put, contact the author of the open source work to discuss the situation and possible compromises or alternatives they might consider. Negotiation done before embarking on your project could help clarify the license, ensure you and the author are on the same page, and avoid a legal situation entirely.
Bringing it home#section14
Consideration of open source licenses should be part of the early planning phase of your project, not after development.
To significantly reduce the risk of violations, ensure that you take open source license violations seriously and that appropriate open source policies are in place to guide your development team. Do not forget that your project will also need a license after you finish development (and production). What license will you be using? The license(s) included in the open source work used in your project will determine your own license.
Most of all, as an individual developer or business entity that develops, distributes, or uses open source, you should make time to read and understand the terms and conditions of open source licenses you are using.
Thanks for the great article, I especially liked the graph of the differing licenses.
Thank you. Glad that you like it.
Very good article. I’m certainly no expert, but I’m glad there’s this good unopinionated overview which doesn’t fall into the normal misunderstandings/FUD around the GPL.
Also I do think it’s worth mentioning from my time at an open source loving consulting company, that they’ve found that (despite the aforementioned FUD) the GPL is the best license to use for distributing code to clients. It rarely interferes with their business plans and their lawyers are likely already familiar with it.