I ended up in a conversation related to software licensing over the last 12 hours (I did sleep for some of it) with someone doing some pretty nice work. And they hated the GPL license, which began a conversation.

Where once I was a strong Free Software Foundation (FSF) proponent, I am not anymore – mainly because there is a Right to choose how your code will be used in certain circumstances, and I’ve found in putting food on my table it has been necessary to compromise for the good of customer, as the customer sees it, and also for my own good, as I see it. And after a few decades of writing code to pay the bills – which I don’t do anymore – I can be a bit more grounded in all of this.

#Define

Readers looking at this will be at different points in their careers, with different levels of experience, with a lot of different perspectives and political philosophies. I’m not going to argue about any of that because all it does is keep geeks from doing what they’re good at, wastes electricity, and keeps t-shirt companies exploiting things.

I’m just giving a perspective, having used Free Software, Open Source and proprietary licensing as I needed to while feeding my keyboard addictions for a few decades¹.

A Brief Look At The Future

Code is already writing commercial code. The implications of that are writ large for those that are simply code monkeys. Time for everyone to evolve beyond syntax wars (my apologies to those who suffered my own syntax nukes over the years).

Software Engineering is more than writing code, though, so that should be in good stead. This is going to be a weird time for HR departments who are still going to hire based on antiquated requirements, but it’s a 2 paragraph nudge to code monkeys out there to broaden their skillset beyond complex evolutions of “Hello World!”.

The Software Life Cycle

Code is only loved when it is used, it is only used when it does something people want and costs less to maintain than the ‘profit’ from it. In commercial coding, this is a necessary pragmatic.

Everyone has their own reasons to write code and release it in the wild, not everyone does it for money alone or money at all.

In voluntary coding, that still stands except the ‘cost’ and ‘profit’ are not monetary. This will confuse people who don’t do things simply for fun, or to prove that they are awesome to others.

So, when interest in the code for the coder is less than what the coder gets from it, you get code cul-de-sacs unless someone else decided to continue it.

Eventually, the code dies².

A Few Words About ‘Commercial’ Code

Some uninformed people still use ‘commercial’ as a synonym for ‘proprietary’ when it comes to licensing. Code can be commercial under any licensing.

Now they’re informed, and you can call them idiots if they muck that up. You’re welcome.

Proprietary Licensing (Ye Olde Black Box License)

Probably the oldest model around, we have Bill Gates to thank for a lot of that. Despite his dumpster diving escapades to learn how to code, old Bill decided to write a letter to hobbyists that was pretty much the start of proprietary licensing for software – and, to be fair, it launched an industry that paid code monkeys and software engineers so well that to this day they’re willing to work in a place that rains so much.

Proprietary licensing, while the software models have evolved way beyond the waterfall model (which is still useful in special cases) has a definite life cycle where whoever owns the copyright decides whether or not that code lives from moment to moment. It’s always brass tacks or companies go bankrupt. This hasn’t happened to Microsoft to date, so we know that the licensing works for them quite well.

However, for the licensing to be good for them, they have to follow business practices that arguably limit the code based on the business model itself. Microsoft knows that now, which is why they’ve been plunging more and more into open source licensing (but remain leery of Free Software Licensing).

It is what it is. Working for different companies over the years, I decreasingly had this sort of licensing to pay the bills, but my last full time position was proprietarily licensed. My last contract was a hybrid.

Proprietary code is a closed system from an engineering perspective. All your problems are your own.

Open Source Licensing

There’s overlap between Open Source and Free Software licensing, but not the other way around. ‘Open Source’ can apply to both Free Software Licensing and Open Source licensing, so I tend to call something a Free Software License if it is compatible with the GPL, and I call everything else ‘Open Source’ licensing.

With the Open Source licensing (non-GPL compatible), you don’t have to release source code – which means it’s compatible for proprietary code projects. This means that code re-use hits new levels since code someone has never written can be pulled into projects at little cost for a company (or individual, or…). These are hybrid licensing projects and come with pain.

Pure open source projects are really projects that people decide that they will allow people the option to write proprietary code with. You don’t have to, you have a choice, and that’s nice in it’s own way.

Pure Open Source projects are limited open systems in that they’re not compatible with the GPL. If you’re going to argue that and take all the GPL code out of your options, do so wisely.

Hybrid Open Source/Proprietary Licensing

This has been pretty popular over the last decade, mainly because it allows ‘code re-use’ without actually bearing the cost of writing some of the code. Code re-use has it’s own problems.

• Code being used for what it was not intended for gets buggy by design. Think about it³.
• Dependency Hell: when you have multiple projects embedded in your code, you have to track all the dependencies – which costs in maintenance. An update in one piece of code can break things. That’s also a product of software complexity, but if you can’t control your source it’s an issue – particularly when an open source project is fixing bugs you coded around rather than contributed to the project to get done.This can also lead to getting locked into an antique version of an open source project – I’ve seen it before – where you’ve got so much code around it you *can’t* upgrade. It’s like having Dr. Who show up, shoot you in the foot, and keep shooting you in the foot every day afterward.
• Documentation is a pain. It’s not as if many people actually write documentation – a pet peeve of mine – but if you’re going to follow the gold standard of someone new coming into a project and being able to be productive quickly, you’re in a world of hurt.

Free Software Licensing

I could get into what Free Software Licensing is, but the FSF has a good guide for licensing that they endorse here. In the context of this article, what you need to know is that it’s compatible for use with proprietary services, but not proprietary products. There is an exception in the AGPL – be advised (read the article linked).

Basically, if you have no problems releasing your source code with a product, you have no issues here. This is ok if you’re not coding proprietary business trade secrets and patents. I’m not a big fan of software patents, but they do exist – but not all patents related to software are software patents, either. It’s weird how things can get all mixed up with lawyers and software engineering.

If you’re willing to pass along the right to modify the source code provided to your end users, you’re golden here. An interested customer base with access to source code is a resource – and threatens to breed competition if people are willing to invest in it. If you do a good enough job, you won’t have that problem. Business is risk, right?

My personal argument for using the GPL is that I shouldn’t write a piece of code and think it’s the only code I will ever write or profit from. Artists don’t make one painting, they make many. Authors write a lot more than a single book. In my mind, as ‘businesses’, coders are ‘subscription model services’, so I like the Free Software Licensing. It can generate more paying work. It has for me more than once.

Hybrid Free Software/Open Source Licensing

These are more common, but the licensing hybrids can be wonky and occupies software philosophy geeks well past the time when they get bored with the conversation. They are a fact of life.

This model only works if the code is following the GPL or compatible licensing, where end users get the code. Linux, while not a simple software project, is a smorgasbord of licensing in this regard and has worked and continues to work.

What to choose?

Every one has pros and cons. I’m not your Dad⁴. Figure out what’s best for you and don’t complain if it bites you in the posterior somewhere along the way – they all do in one way or the other.

Footnotes

¹Keyboard addictions include the basics – food, shelter and clothing – as well as feeding the curiosity. When it comes to food, it was usually flat, but after a few decades I’ve found that all food shouldn’t be flat. It affects Geek Longevity. 
² Personally, I think the difference between a Junior Software Engineer and a Software Engineer is having seen some of their code die. And a Senior Software Engineer has not only had more than one project die, but has also marked them for death. A real Software Engineer Manager has evolved through these paths, in my experience, but it’s just an opinion.
³ When you get the ‘by design’ response from an open source project, or from someone else, it’s time to suck it up, cupcake.
⁴ Open to negotiation, though. If you want me to be your Dad, make a good case and send it to me.