Be a Savvy Consumer: Software Licenses Explained
Be a Savvy Consumer: Software Licenses Explained
In the proprietary or open-source world, knowing what licenses are applicable is important. The legal department can guide you, but what if you don't have one?
Join the DZone community and get the full member experience.Join For Free
Are your API program basics covered? Read the 5 Pillars of Full Lifecycle API Management eBook
If you share my worldview, the subject of software licenses will bore you to the very fiber of your being. Seriously. I got into the world of software because I like to build stuff. So, when the building finishes and the time comes to argue about who is allowed to copy what, when, and where, I prefer to let the bureaucrats sort it out.
Unfortunately, however, I can’t always do that. From time to time it matters to me in a business context, advising clients. Likewise, if I start slapping things on Github (or selling them), at some point, I have to think about licensing. But today, I want to talk about arguably the most common way to encounter licensing: as a consumer.
Software seems to run on pretty much everything these days, so the question of who owns what can get murky. You might find yourself in possession of a piece of software that you shouldn’t have, whether you realize it or not. Or, you might download something free to use, as a developer, only to smack into legalese preventing you from redistributing it. As you consume software, it behooves you to understand a bit about it.
Now, I cannot possibly explain every licensing model in a single post. That topic presents such complexity that folks built an entire website dedicated to helping you sort it out. What I’ll do instead is offer a quick primer. I’m going to give you a breakdown of software licenses in terms of copyright implications. Copyright governs a content producer’s rights to reproduce, publish, and sell that content. In our case, we’re talking about source code and the resultant software.
First up, let’s start with the most permissive form of software licensing. You might think of this as an un-license of sorts. I say this because software in the public domain is software without copyright. GNU offers the following description of public domain licensing: "Sometimes people use the term 'public domain' in a loose fashion to mean 'free' or 'available gratis.' However, 'public domain' is a legal term and means, precisely, 'not copyrighted.' For clarity, we recommend using 'public domain' for that meaning only, and using other terms to convey the other meanings."
I offer this extensive explanation so that you do not confuse the price of the software with licensing rights to it. Theoretically, I could take a freely available piece of public domain software, modify it, and charge you for it. Depending on the licensing particulars, this public domain software might have a cost. But what it won’t have is any copyright particulars attached to it. You can sell, reproduce, and publish it to your heart’s content.
Next, let’s consider non-protective FOSS, also known as permissive FOSS. Oh, and FOSS stands for “Free, Open Source Software.” According to opensource.org, you can think of a non-protective FOSS in the following terms: "A 'permissive' license is simply a non-copyleft open source license — one that guarantees the freedoms to use, modify, and redistribute, but that permits proprietary derivative works. See the copyleft entry for more information."
Alright, so they use yet another term that we need to unpack. To understand that one, ask yourself what would distinguish this from the last model of licensing: public domain? Public domain says, “do whatever you want with this,” whereas non-protective FOSS says, “do whatever you want with this, and don’t prevent proprietary derivative works.”
The phrasing of this gets a little dense with an implied double negative. But suffice it to say, non-protective FOSS establishes copyright, but leaves you free to do as you will with the code, including modifying it. The only gotcha has to do with redistributing; if you want to redistribute, you must use the same license.
Now, let’s consider protective FOSS licenses. Protective FOSS licenses come with the aforementioned copyleft restriction. To dive into that a bit, let’s now consider more carefully the definition of copyleft. Wikipedia offers this: "Copyleft (a play on the word copyright) is the practice of offering people the right to freely distribute copies and modified versions of a work with the stipulation that the same rights be preserved in derivative works down the line. Copyleft software licenses are considered protective, as contrasted with permissive free software licenses."
That stipulation that they mention carries a great deal of import. With a protective FOSS license, you can still do as you please, but you must attach the same license to whatever results. In other words, you cannot go making the result proprietary, or selling it, should the license prevent selling it.
If you find yourself dealing with protective FOSS, you definitely want to dive into the license in detail, because that license will govern everything you later do with it and anything derived from it.
Here, we get into fairly familiar territory, particularly for us grizzled veterans of the industry. Proprietary software spent a lot of time as the default means of distribution. Simply put, someone owns it as property. Here is a more formal definition: "Proprietary software is software that is owned by an individual or a company (usually the one that developed it). There are almost always major restrictions on its use, and its source code is almost always kept secret."
When companies write proprietary software, they generally do so to keep it close to the vest. The source code represents their intellectual property and they probably don’t choose to share it. You can find this pretty much anywhere you look, from operating systems to box software to many SaaS products. Video games usually fall under this umbrella as well.
Last up, we get into the realm of the super-restrictive: the trade secret. You can read more about the particulars of a trade secret here, at Wikipedia. You’ll find too much nuance there for me to quote easily.
Instead, I’ll summarize for the purposes of our licensing discussion. Trade secrets fall into the realm of proprietary software, but with an additional kicker. With trade secrets, the protected software in question presents a substantial, economic/competitive advantage to the secret holder. To put a bit blithely, here we have the stuff someone will really sue you for.
For instance, let’s say that you developed a SaaS offering that cracked the mathematical problem of fast factoring in revolutionary runtime. If you built a website to show people just how fast, you could divide it into conceptual sections. The framework and plumbing code on the server side might count as proprietary, but you would only consider the algorithm itself a trade secret.
Know Where You Stand
Hopefully, I succeeded in offering a quick primer without bogging you down in details. As a savvy consumer, user, writer, or distributor of software, you should have a basic understanding of software licensing. At the very least, you should learn these paradigms well enough to develop a sense for when you need to dig in and do further research.
Published at DZone with permission of Erik Dietrich , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.