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:
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.
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.
Once you have answered the above questions, what’s next? It’s time to answer another question.
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?
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.
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.
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.
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:
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.)
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:
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.
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.
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:
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.
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.)
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.
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.
Source: A List Apart
Considering Open Source Licenses