Monthly Archives: February 2021

Proprietary (definition) – 02

I’ve had some good conversations about this attempt to define proprietary software. In many of these conversations, people focused on explicitly what I’m trying to not do (i.e. define “proprietary” by saying it’s not FOSS). Some people helped me clarify that I’m looking to do really, which is have a pithy way to explain proprietary to people who are never going to look at source code or pay someone to write new code for them. How do you explain to people who don’t care about technical matters nor have the language to discuss them? How do you talk about licenses to people who may not have the language for it? (In a past life I explained Creative Commons licenses to academics and educators.)

Talking about licensing seemed very important to people, as licenses are what define freedoms, restrictions, and restrictions that protect freedoms. With these points in mind, I present the following:

Proprietary software is software that comes with restrictions that retain control of how software can be used, shared, and changed through the use of copyright and licensing.

I worry that this is “too technical” and then I worry that I’m worrying too much about that. In this I added a truncated version of a common explanation of the Four Freedoms (typically use, study, modify, share). This is in part because I believe “study” is included in “modify.”

I included “copyright and licensing” in hopes that a reader would understand at least one of them. I also wanted to take into account that communities may have other policies (e.g. community guidelines) that might in some way restrict how software is used, shared, and changed. I don’t like “retain control” as a phrase, but it was suggested to me (thanks! If you want credit, just ping me). I think it’s pretty clear about the intention and consequence of proprietary licensing.

A potential criticism I see is that it’s not clear enough that you must be able to do all three (use, share, and change) in order for software to be FOSS and that restrictions on any of them renders software proprietary.

Proprietary (definition)

I recently had the occasion to try and find a definition of “proprietary” in terms of software that is not on Wikipedia. Most of the discussion on the issue I found was focused on what free and open source software is, and that anything that isn’t FOSS is proprietary. I don’t think the debate is as simple as this, especially if you want to get into conversations about nuance around things like Open Core.

The problem with defining proprietary software by what it isn’t, or at least that it isn’t FOSS, means that we cannot concisely communicate what makes something proprietary. Instead, we leave it up to the people we’re trying to communicate with to dig through a history of rhetoric, copyright law, and licensing in order to understand what it actually means for something to be FOSS, and what it means for something to be anything else. It is also just less satisfying, in my opinion, to define something by what it lacks rather than by what it is.

I’ll start by proposing the following definition:

Proprietary software is software that comes with restrictions on what users can do with the software and the source code that constitutes said software.

I think the most controversial part of this sentence is the wording “software that comes with restrictions.” In earlier attempts of this I wrote “software that restricts.” This sort of active wording, which I used for years in my capacity at work, is misleading. In the case of proprietary software, it is the licensing and laws around it that restrict what you can do. For software to restrict you, it must be that the way the software is being implemented or used restricts you.

To be clear, this is my first proposal. I look forward to discussing this further!