Few Things You Need To Know About Open-source Licenses
I love open source. It’s the greatest thing that happened to the world after the Internet. The reason I became a software developer is open-source software. The global community of developers is working together to create the most sophisticated projects without any formal management and guidance. When I tell my friends from other industries about this, all I typically hear is awe and wishes that their industry was the same.
Open-source is the the future
We, the developers, don’t realize how lucky we are. We can peek at how every piece of Linux system is working, or how Apache and Nginx web servers were built. We can learn from the most advanced software projects and create our own derivative work. We can also freely include code that others wrote into our own projects without the need to reinvent the same things again and again. Because of this, the tech industry is moving at the speed of light, with more and more sophisticated frameworks being created every few years.
Just think about it, to write a single-page web app, you had to use plain JS fifteen years ago. Then jQuery and its myriad of plugins came along and made client-side JS and rich apps a common thing. Now you have React, Vue, and other client-side libraries that do all the heavy lifting, while developers can focus on business logic and optimization.
The other side of open-source
Unfortunately, with great power comes great responsibility. Open-source software gives you a head start, but you can run into severe problems if you are not mindful of the licensing. If the project you are working on reaches a point when you get traction, those licenses begin to matter, because as any license, they have restrictions.
Most popular licenses that include Apache, MIT, BSD, and Mozilla licenses are relatively relaxed. All you have to do is, for example, include the notice about the original author of the library, like MIT license states. Most of the licenses permit you to do anything you want with the code — use, modify and distribute the code or derivative works.
The license can also grant you commercial use of the code, meaning that you can sell the software. But there’s one caveat — the fact that you can sell it doesn’t mean that you can make it proprietary, which a lot of founders of tech companies want. Some licenses, on the other hand, require you to provide the code of your software for the broad public even if you sell the software itself.
Copyleft licenses
From my perspective, the most overlooked license is GPL. You might not know it, but it’s a copyleft license, which means that any software that includes a GPL-licensed library should also be open-source. It can be a disaster for a proprietary software product, especially if you’re in the process of signing a contract with a client, and the contract has a clause that you shouldn’t use any copylefted source code.
I’m not a copyright expert, and, obviously, this is not legal advice, but from what I understand, a GPL license requires you to distribute your software as open-source. The question is what exactly distribution is. Is sending the javascript code to the browser considered its distribution? From what I can read online — yes, it does. But does it mean that since you distribute your javascript source code to the browser, your software is also open-sourced? Most likely not, because open-source means that you specifically state the license your software is distributed under.
SaaS products seem to be an interesting beast from a licensing perspective because the software isn’t distributed traditionally. However, the client-side code is sent to the client’s browser over HTTP. There’s a particular version of GPL called AGPL that was designed specifically for distributed software — if any of your packages is using it, you should make even your backend source code available to the broader public.
Licenses are no joke
Both developers and entrepreneurs often don’t pay attention to the licenses of the libraries that are used when building a product. At the same time, almost any basic contract for software development contains a clause that all OSS software should be approved by the client and that there should be no restrictions or obligations in terms of licensing. In practice, no one really reviews the libraries that are used, which is a recipe for disaster.
It’s an excellent example of why it’s crucial to work with professional developers if you’re an entrepreneur or work in a team guided by an expert team lead. These little details are what makes a difference between professionals who have had their fair load of bad experiences, and those who never ran a production application before. Sure, it makes perfect sense to save the budget when you’re just starting out. But once you get traction, you will have to review your code and fix a lot of things, from security issues to OSS software that has licenses that might be incompatible with your product. And you better do the review before someone would decide to sue you.
What to do about it
The easiest way to sort out the OSS licenses on your project is to use Pivotal’s license analyzer. It works with all of the most popular package managers and will give you the output listing all of the libraries and their licenses. You can then approve licenses that work for you and figure out what to do with the rest.
If a license analyzer doesn’t work for you, the only way to sort things out is to check the licenses hand by hand, which can be a tedious process. A decent app might have thousands of libraries that depend on each other that have to be reviewed.
It’s essential to keep the licensing issue in mind when you’re starting a new project. It’s easier to keep track of package licenses by adding them one by one while you’re building the product than reviewing all licenses in a huge project. If you never thought about this issue and your product already has traction, it might be a good time to start reviewing your OSS licenses. Otherwise, the consequences may be disastrous.
DISCLAIMER: This blog post (document) and discussions contained herein, as well as any data and information provided are for informational purposes only. It is not legal advice nor should it be relied on as legal advice
