Do I have to use a free/open source license?

Article originally published in the March 2018 issue of Linux Journal

Man thinking at a deskA few weeks ago I ran into a neighbor, whom I’ll call Leo, while he was out taking his dogs to the park. Leo stopped me to ask about some software he’s developing.

“Hey, you do open source stuff for companies, right?” Leo asked.

“Yeah, that’s my freelance business. Do you need some help with something?”

“Well,” he said, “I’m getting ready to release my software and it’s time to start thinking about a license. Which open source license should I use if I want people to know it’s OK to use my software but if they make money from it they have to pay me?”

I blinked, stared at Leo for a moment, then answered, “None of them. No open source licenses allow for that.”

“No, you see,” he continued, “this guy told me that there must be plenty of licenses that will let me do this with my software.”

“Plenty of proprietary licenses, maybe,” I explained, “but no open source ones. According to Item 6 in the Open Source Definition, no open source license may prevent someone from making money from software released under it. That’s what you’re suggesting, and it’s not possible to do with an open source license.”

Leo did not seem pleased with this answer. “So what you’re saying,” he fretted, “is that I can’t release my software at all!”

“No, no!” I assured him, “You definitely can release and distribute your software. You’ll just have to get an intellectual property lawyer to help you write the proprietary license you want, and maybe to help you release it under a dual license (one open source and one proprietary).”

He nodded (not altogether happily), and headed off to the park with his now very impatient dogs. I continued my walk, pondering what I’d just experienced.

The thing is, Leo was not the first person I’ve spoken to who assumed that software had to be released under an open source license. I’ve had multiple conversations with different people, all of whom had mentally equated “software license” with “open source license.”

It’s easy to understand why. Of all software pursuits, only free and open source software is defined purely in terms of its licenses. Without that license, a piece of software cannot be either free or open. This leads to a greater focus on licensing than for other types of software, which then itself gains a lot of mindshare. The larger intellectual property concept of “licensing” becomes so closely associated with “open source,” and is often the only context in which someone hears of licensing, that people understandably start to assume that all licenses must therefore be open source.

That, as we all probably already know, is not the case. The only licenses that can be called “open source” are those that are reviewed and approved as such by the Open Source Initiative (aka OSI). Its list of OSI-Approved licenses allows developers to choose and apply a license without having to hire a lawyer. It also means that companies no longer need to have their own lawyers review every single license in every piece of software they use. Can you imagine how expensive it would be if every company needed to do this? Aside from the legal costs, the duplication of effort alone would lead to millions of dollars in lost productivity. While the OSI’s other outreach and advocacy efforts are important, there’s no doubt that their license approval process is a service that provides an outsized amount of value for developers and companies alike.

OSI approves or rejects licenses as qualifying as “open source” by comparing them to the Open Source Definition. A license must not violate any of the sections of the definition in order to be added to the list of approved (and therefore open source) licenses. Aside from the, “you can’t prevent people from making money from it” precept mentioned above, other requirements contained in the Open Source Definition include non-descrimination (you may not prevent certain people or groups from using your software), that the license be technology neutral, and of course the requirements of the Four Freedoms as originally defined by the Free Software Foundation. If you haven’t read the Open Source Definition before (or not for many years), I encourage you to do it again now. It’s an important and powerful work that is the foundation for much of how many of us spend our days.

It’s worth stressing again that no license can be called an “open source” license if it does not adhere to the Open Source Definition. Full stop. No exceptions. It’s illogical to think that something that doesn’t meet the official definition of open source could ever legitimately be called open source. Yet people try it every day mostly because they, like Leo, don’t know any better. Thankfully, there’s an easy way to fix this. It’s called Education.

Basically, you only have to choose from two different types of licenses:

  1. Free and open source: If you agree that the software you want to release should obey the Open Source Definition, then you should select one of the OSI-approved open source licenses from the list they provide. You may still need an IP lawyer to help you make the correct license selection, but you’ll need considerably less of their time than if you weren’t to use one of those licenses.
  2. Proprietary (and likely custom): If there are any parts of the Open Source Definition that you don’t want to apply to the software you want to release, then you’ll still need a license but it will have to be a proprietary one likely custom-written for your purposes. This absolutely requires an IP lawyer. Where licenses are concerned, you should never roll your own. Copyright and licensing are very complex legal issues that you should in no way undertake on your own without professional assistance. Doing so puts yourself, your software, and your organisation at risk of large legal problems.

To be clear here: There is nothing wrong with using a proprietary license for the software that keeps the lights on at your company (figuratively speaking). While I, personally, would prefer everything be free and open, I also prefer that companies remain solvent. To do that, it’s usually necessary for some software to remain proprietary, if only for a while. It’s bordering on business malpractice to release the “secret sauce” of your company’s product offering without a business model that will allow the company to remain or become profitable. Once your company has established itself and is secure in its market, only then should it consider releasing its mission-critical software under an open source license (and I do hope it does do so).

Companies like Amazon and Google can release critical infrastructure as open source because they no longer really compete on product, they compete by having scaled to a point that no newcomer to their product spaces could possibly replicate. If tomorrow Amazon were to release the software for S3 under the GPLv3, it’s unlikely it would at all impact their profitability. The number of companies that could take this code and spin up and scale their own product offering with it and do so in a way that could compete with Amazon’s existing dominance and scale? Vanishingly small, and those that could do it are unlikely to be interested in doing such a thing anyway (or already have their own solutions).

With open source as with all technical and business decisions: Do not do something simply because the big players do it. Unless your company has the advantages of scale of an Amazon or a Google, please be very careful about open sourcing the technology that pays the bills. Instead, hire a good intellectual property lawyer and have them write you a proprietary license for the critical software that you distribute.

Changing the language

The other day I tweeted this:

Tweet by @vmbrasseur: "If you help to create software (design, prodman, QA, docs, code), you ARE a software developer. All roles are vital, not just programmers."
Tweet by @vmbrasseur: “If you help to create software (design, prodman, QA, docs, code), you ARE a software developer. All roles are vital, not just programmers.”

This tweet is a necessarily brief exclamation of something which has been on my mind a lot lately and warrants a larger post. In summary: The words we use matter.

It’s probably safe to assume that nearly everyone reading this is involved with creating software. Even if you’re not, you’re undoubtedly aware that software development is a complex process composed of many moving parts. While it’s possible to create software on your own, it usually works much better when we collaborate to build each of the parts.

Despite recent “full stack” trends, none of us can be specialists in every facet of the software development and creation process (nor should we try). Many different skills are required for the process to work smoothly:

  • Before writing a single line of code, product management, user experience, and user interface design are necessary to make sure you’re creating software which is valuable and useful to the end user.
  • The crafting of the deliverable software product involves front end coders, back end coders, security analysts, database administrators, and documentarians. It may also require more specialised roles such as mobile coder or data scientist.
  • Before the software can be delivered, quality assurance and product management must confirm that the software not only meets the needs of the end user but also that it works as expected (or at all).
  • The actual delivery of the software is the responsibility of system administrators, operations, and devops. They, along with DBAs and customer service representatives, also help to ensure the software remains available.
  • As the software progresses through its life cycle, customer service receives additional support and outreach assistance from marketing, sales, and community management.

This is the software development process. This is what it requires. A true “full stack” software developer would be skilled in all of these roles (which is why the very concept of “full stack” is laughable). Yet lately when we speak of software developer we mean only those who create the code. As we see above, programming is only a portion of the process, just one of those many moving parts. The term as currently used disregards the myriad other roles required to develop a successful piece of software.

It’s unclear what nudged our language to shift such that “software developer” has come to exclude the majority of roles responsible for successful software development. It’s not as though there is any shame in the title of “programmer.” It’s a descriptive title but more importantly it’s one with decades of rich history behind it. By using “software developer” instead we’re not only excluding people, we’re turning our back on this history and everything which it affords us.

Why is this important?

Words matter. How you talk about things affects how you think about them. To discuss “software development” as though it were a purely programmatic act excludes a large percentage of the people who participate in the process and encourages a “cult of the coder” mentality such that programmers are lifted up to near aristocratic levels.

This programming-centric view does software development no favours. By excluding other roles from the language we use, we also exclude them from how we think about the process. The piles of startup corpses strewn along the road to business success are a testiment to how ignoring things like user needs, market fit, and usability will scuttle even the best coded piece of software. Recent findings by GitHub show that excluding documentation from the process has negative effects on the adoption of and contributions to free and open source software projects, no matter how well architected their APIs.

The biggest loser in this “cult of the coder,” though, is the end user. The poor unfortunate souls who struggle to use a UI created by someone inexperienced in the skill, who growl in frustration as yet again a software service updates without a much requested feature, who are astounded by Internet of Things products with no concept of security, who puzzle out and reverse engineer undocumented installation steps. So much productivity, opportunity, and customer good will lost because software companies often focus more on programming than on the entire software development process.

Don’t get me wrong: I love programmers. I’ve spent most of the last ten years of my life leading programming teams and departments. Programming is a highly specialised and ever changing part of the industry. It’s populated by some of the most clever, most inspiring, and kindest people with whom I have ever had the honour to work. It is not the fault of programmers that the language shifted around them. It is the fault of our industry, our community, and our culture.

We can do better. We can do better for the end user, for programmers, and for everyone involved with or impacted by software development. It all starts with changing our perceptions through language.

Let’s start to shift the language back and reclaim the term “developer” for all who participate in this complex process rather than just the programmers. Let’s evolve the mindset back toward one where we recognise the contributions of all of the roles which contribute to delivering and supporting a successful software project. Let’s call a programmer a programmer and just get back to work creating software which changes peoples’ lives in valuable ways.