If you work in IT, purchase software, sign contracts related to software services, create software, or provide software related services: you should have a basic understanding of software licensing. If you spend time working with Open Source software this is even more important to understand licensing.

99% of the time 99% of people do not need to care about any of this. But for those of us who do, it really matters. You should always understand the terms of agreements you enter into, particularly if it’s part of your work.

Please note: software licensing can be a very emotional topic for some folks who create software. I am not looking to participate in any debates about what type of arrangements are better. My goal is to explain to folks who need to understand their options what those options are. I’m happy to discuss, but not debate, the pros and cons of license types in another setting.

Ownership vs Licensing

When we buy something, we assume we own it. If I buy a book, that copy of the book is mine. When we buy software we don’t buy the “thing” we buy a license to use the thing. Software is, by and large, owned by the copyright owner of the source code. The easy way to think of it is as the person or company who wrote the software.

Microsoft owns Windows because they paid a bunch of people to write it and therefore they own the copyright on the source code. They also own a mountain of patents, trademarks, and other intellectual property related to Windows. For them to “sell” Windows to someone else would be a massive legal undertaking.

When I write software for my side projects, I own the copyright, and therefore I own the software. When I write software for my employers usually they have owned the software or their clients have owned the software depending on the contract terms.

When you buy a new computer, no matter the operating system, you are not “buying” Windows, MacOS, or Linux. You’re buying a machine that has that software installed, and getting (or buying) a license to use that software. You own the hardware, you have the right to use the software within the terms of that license. Just to make life complicated that hardware likely has other software embedded in it that you do not own, and has it’s own license.

Types of Licenses

In super sweeping broad categories there are two groups of licenses: proprietary and open source.

Proprietary Licenses

Proprietary licenses typically are the kind you buy from companies like Apple, Microsoft, Salesforce, and others. These licenses are designed to keep you from sharing the software with others or make changes to the code. These are the most common licenses you will see on stuff you buy. They are usually long, complicated, and boring. Almost no one reads them in their detail, and even fewer people understand them. A proprietary license isn’t meant to be understood; they protect the legal and financial interests of the software owner.

When you buy licenses like this, you need to understand a few things. The most important are the scope and duration. By scope I mean how can the software be used and by how many people. By duration I mean how long can you use it.

Scope

Scope can have a huge range, and depends on the type of software and the owner’s expected use cases. Salesforce license scope includes the number of people who can log in, the features they have access to, the amount of data you can store, and so on. In the Salesforce world each add-on you buy a license for can impact the scope of other licenses. It gets complicated really fast. But that makes sense for Salesforce. On iOS from Apple of iPhones, the scope is much simpler you get to use your phone on one line at a time, connected to one Apple account, and any given version has a fixed set of features.

In both cases you can buy license additional software to run onto of Salesforce or iOS created by a 3rd party. Which brings you back to the beginning where they get to set another layer of rules.

Duration

Software licenses can either last a fixed period or be perpetual.

  • When I buy a Salesforce license I’m buying a subscription for a fixed number of years of service.
  • When I buy an iPhone I’m getting a license to use the software on that phone perpetually (at least until the phone dies).

It’s really important to understand which type you bought. Adobe, Microsoft, and others have moved from perpetual licensing of packaged software, to annual subscriptions. Sometimes, you get to pick which. Sometimes you’re just stuck.

Once upon a time, you went to a store, bought Adobe Photoshop (in an actual box) installed it and used it for several years – generally until that version was so old it stopped working. Now, you log into an App store, subscribe to Photoshop for a year, and the next year you have to give Adobe more money to keep using it. Microsoft (last I knew) offers office in both models: buy a version now and use it until it breaks or buy a subscription and it’ll keep working as long as you keep paying.

Open Source Licenses

Open Source is a huge deep rabbit hole that I’m not diving down. You can learn more from the (Open Source Initiative (OSI))[https://opensource.org] and other similar organizations. This is meant to be a summary about the parts that matter day-to-day to people who buy software and handle software contracts as non-lawyers.

Open Source licensed software, also called Free/Libre Open Source Software (FLOSS), allows the user a lot more rights to the code of the software. This isn’t directly useful to people who don’t know how to write and compile code, or even to people who can but don’t wanna update source code of their photo editing tool.

But it does have really important advantages even if you don’t edit the code.

First, because the source code can be freely shared most of this software is free to acquire and run. You license scope and duration are essentially unlimited. Your ongoing costs are around hardware and the team needed to support the tool. A lack of per-user license costs can save a lot of money.

There are also examples of times and places where an open source project was discontinued by it’s original creator, or just neglected terribly, and someone else created a new version from that code. The best of example of this is Open Office (a free set of tools like Microsoft Office), whose owners stopped releasing updates for a couple years. A new group took it and created Libre Office and made sure all existing users could keep going. This was great for the companies that didn’t want to pay Microsoft for their office suite, but needed updates and new features.

I’ve seen this happen with web site creation tools, games, Salesforce add-on packages, and more. The ability for anyone with the skills to keep a project afloat can save you. If a proprietary product is discontinued, you’re out of luck. Most of the time, you have no choice but to replace it entirely.

Open Source has Strengths and Weaknesses

Open Source supporters are known for being passionate about why their approach and software is better. And sometimes it is. The entire internet, all major operating systems, and a huge variety of tools most people don’t know exist (but are critical to their daily lives) all rely on Open Source software. That said, Open Source software has trade-offs, flaws, and failures. Nothing is perfect.

A few years ago there was a huge dust up when a developer of two mostly unknown software projects created trouble for all kinds of big companies. The two projects were small, but popular. The guy who was writing them wasn’t getting paid by anyone to work on them. Thousands of other larger projects – some of which are important to very large companies with large deep pockets – used those two projects as critical elements. The developer became frustrated with the lack of financial support he was getting and released a version that intentionally broke all downstream projects. Over the next few days there was lots of yelling online, and debate about the ethics of malicious changes vs free-loading off a project maintained by one unpaid person.

Because they were open source and released under a very permissive license, the projects were replaced with new copies maintained by other people. The nature of open source allowed this to happen and undid one developer’s efforts to undermine other people’s work.

It generated news and caused worry, but in the end it didn’t matter much outside a few small nitch communities.

Some Notes for Developers

One of the issues made clear in those debates was the lack of understanding by far too many developers of what the various open source licenses mean. When I was first starting out in Open Source more than 20 years ago everyone in the community was expected to have a working understanding of licensing. There was an active debate between GPL vs BSD-style licenses on all the forums for open source developers. Freedom vs Openness was argued over on endless email threads. Debates about the (definition of the concepts)[https://opensource.org/osd] raged. It was a passionate and active argument filled with good insights, vitriol, dogma, and religious fervor. In short, it was a mess. But one important thing was happening: we were all learning to understand software licensing.

Slowly people who were interested in writing code, and not fighting, started to ignore the question and settled into one of a few camps:

  1. Ignore it all, publish stuff to public repos (Github didn’t exist until 2008, but most people I know in this camp switched there from SourceForge (https://en.wikipedia.org/wiki/SourceForge)[https://en.wikipedia.org/wiki/SourceForge] when it became possible – or just started their project on Github) without any license, and assume it doesn’t matter. This camp is always tempting but not good for people who actually want to re-use code and places like Github actively discourage it these days.
  2. Ignore most of it, and just use whatever’s normal for their language/community. In the JavaScript world that means the MIT license, PHP that means a flavor of GPL license, in OSes that means GPL if you work on Linux and BSD-style if you use anything else, and so on. Most people I talk to in this camp have no idea what the license means unless they work on a big project. They just know that they are supposed to have a license and pick the default in front of them. It is a pretty reasonable way to go (largely is how I license my projects) but leads to misunderstandings when people get annoyed that a large company is using their code in critical ways without giving any direct credit or payment back – even when the license explicitly says that’s not expected like the BSD and MIT-style licenses do.
  3. Dig in like crazy behind their beliefs and accept no alternatives. This is the smallest but loudest camp. These folks would love to engage you in an energetic debate about the (four essential freedoms)[https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms], the purity of BSD-style licenses, and why you’re oversimplifying the situation and therefore wrong about your views on all this (and may offer up a few insults to your mother along the way).

What developers should do with their code

If you find yourself in camp 1 or 2, or if you have no idea why you care about software licensing but have read this far anyway, here are my suggestions about the minimum understanding you should have for your project (if you are in camp 3, I probably heard the argument you want to have with me 15-20 years ago and am uninterested in revisiting it).

License your work

That means understanding that you own a copyright on the material, and you should give other people permission to use it not just toss it into the world. I don’t actually care what you pick, but pick something. All of my repos have a license file (not the same one – which depends on the project), and even my blog has a (Creative Commons License)[https://creativecommons.org/]. If you want people to use your work, give them permission through a license. If you want them to have to pay you – that’s an option. If you want them to just do their thing – fine.

Understand the terms of your license

Again, I don’t care which you pick, and I’m not saying read and understand every clause of every option out there. Read and understand the one you use with your project(s). As a publisher of a copyrighted work (which all open source contributors are – at least in the US and EU) you should understand the terms you extend to others who want to use or republish your work. Nearly all Open Source licenses are written to be read and understood by developers and other non-experts. Take a few minutes and give it a try.

Understand When And How You Can Change The License

When you are the sole contributor to a project this is easy: any time for future releases. Once you have multiple contributors it gets a little messier, but generally that’s still possible. And remember just because you let anyone who wants to use a work do so under one set of terms, doesn’t mean you can’t let someone use that same work under other terms. The Creative Commons block you see below this says no commercial use, so if you want to earn money off my blog content you don’t have permission – but if you ask me for permission we can talk about a deal.