Considering Open Source Licenses

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...