I've been pondering proprietary software for the past couple decades. Ever since I discovered Free Software (and, later, "open source" software), I've intuitively felt that proprietary software (closed source software, proprietary to its copyright holders) was somehow wrong, but I've never taken the time to get more specific until now.
Here's my considered position:
Proprietary software, though not inherently unethical, creates undesirable incentives and conditions ripe for exploitation.
"What?" you say. "But most software developers write and people use in the world today is proprietary, right? You're saying that most software today is one step away from being unethical?" Yes. It's a bit awkward, but that is exactly what I'm saying. The purpose of this post is to explain why - that even if you're building proprietary software with the best of intentions... you are nonetheless setting your users up for exploitation - either by future you or someone else.
Us and them
The code of proprietary software is controlled by its developers and usually owned by a company or corporation employing or engaging the developers (I refer to the developers and whoever owns the code as "developers" here).
The code is carefully protected by its owners - who are also its copyright holders - and copyright (a "government granted monopoly") is backed by governments, the courts, and legislation. People using proprietary software generally are neither able to see nor alter the code of that software. At best, they accept a Copyright License (an End User License Agreement or EULA) which defines the terms under which the user may use the proprietary software. These are very restrictive and require that the user indemnify the developer against most forms of legal or consumer obligation.
The user can pore over these terms (which, I've been amused to find, even lawyers for proprietary software developers, who literally write EULA terms for a living, seldom read on the software they themselves use)... or they can ignore the terms, and blithely click I ACCEPT - consequences, indemnifications, and caveats be damned! - because they really really want (or need) to use the software.
Proprietary software companies have learned that they can put literally anything into their terms, and no one will ever read them. Moreover, they cover every eventuality by reserving the right to change the terms at their discretion (they may even proactively alert their users to the updates, but they can be confident in the knowledge that, in practice, everyone ignores them completely).
I would argue that "informed consent" for software EULAs is a farce, with almost unbounded scope for abuse, but that's not the main point of this post.
Power and Leverage
Through this EULA, the software's developers have complete control of something on which they hope the users will become dependent. This set of proprietary software properties creates a power imbalance substantially favouring the interests of developers over those of users.
One of the ways that power usually manifests itself is with regard to a user's digital artefacts created and stored by proprietary software - be it company accounts, digital images, sound files, data sets, presentations, documents, spreadsheets, and even other software. Most proprietary software rapidly evolves around a conceptual model known only to the developers, and that includes the way in which data - digital artefacts - are rendered for persistence, in other words: data schema and file formats. The former is for storing data in memory or in databases, the latter for storing them in a self-contained portable form. These persistence mechanisms evolve along with the software and are generally ad hoc - new bits are invented by the developers as the digital artefacts the software creates - and needs to save - requires them.
That ad hocracy means the data files or schema are almost always unique to the software around whom they are created and for any even slightly capable piece of software, these schema and formats can become extraordinarily complex. A new release of the same software often creates files incompatible with data created by previous versions. In this case, the developers have an interest in building in compatibility mechanisms to allow older files to be read properly by newer versions - and, critically, they have the institutional knowledge to achieve that.
If left to chance, any two independently developed proprietary software applications, even if they have largely overlapping (and perhaps competing) capabilities, like for example, two independently developed word processors, are guaranteed to have incompatible schema and file formats.
In practice this means that a user working for days, months, or even years with a particular software package creates tens, hundreds, thousands, or more digital artefacts with the software. In many case, those artefacts can only be read, displayed, or edited reliably by the version of the proprietary software that created them or (in most cases, but not always) by future versions of that supplier's proprietary software.
The software is usually (although this is not universally true) updated frequently, sometimes every few days, and the user is encouraged to apply the updates, usually with the threat of being "insecure" if they don't. In many cases, today, software automatically updates "invisibly" in the background, sometimes without the user's knowledge. The updates, controlled by the developer, may or may not improve the software from the user's perspective.
The user seldom has more than a sanitised overview of changes included, and it is common to include changes that are not listed, as they're not deemed to be of interest to the user. In any case, the user is generally helpless to either control the updates or understand what they contain and what utility the changes they bring might have. In many cases, the updates are what are sometimes called "antifeatures" - features built into the software for the benefit of the developer rather than the user, and often working to the detriment of the user and their privacy.
As proprietary software developers are well aware, users generally accept the antifeatures and this general lack of control over the software they're using. That is because of the often ponderous corpus of dependent digital artefacts a user has, or their perception that this particular software is "market leader" and therefore the best they can get, or because they need to use this software's proprietary formats to submit an artefact (e.g. for government compliance or for a school assignment)... The user, perversely, might even develop a fondness for this "black box" of capabilities which magically turns their creativity or industry into semi-tangible 1s and 0s.
The relationship between the user and the developer actually eventually starts to resemble the relationship between a hostage and the hostage taker... This is especially true for computer users who have never used or even seen any comparable software in a given context. They cannot chafe in their situation because they have never experienced any alternative. The affection (or at least acceptance) they feel towards the proprietary software on which they've developed a dependence can best be described as a kind of Stockholm Syndrome.
I feel strongly that, no matter the original intentions, incentives ultimately determine behaviour. The combination of a substantial power gradient between the user and the developer, and the fact that most proprietary software developers are part of a corporate apparatus whose single motivation is to "maximise shareholder value"... means that there is a substantial incentive for developers to exploit the power they hold over users to their (and/or their shareholders') advantage.
I would argue that the exploitation, though often small and relatively painless, at least compared to the perceived alternatives (in many cases people are entirely unaware of any alternatives, or of their relative capabilities) can, en masse, add up to huge value for proprietary software corporate shareholders.
Today, it's common to see the "Big 5" referenced in the media. The Big 5 are Google, Amazon, Microsoft, Apple, and Facebook. These multinational, publicly listed technology corporations sell (and made their fortunes from) almost entirely proprietary software, each have more financial might than most sovereign nations. What is clear is that they did not achieve their sizes by refusing to exploit their proprietary advantages.
Most other proprietary software firms are somewhat less dominant (SAP, Oracle, PeopleSoft, IBM, Hewlett Packard, Dell, etc.) but all aspire to find their own place among the "Big 5" or more... Sure, most start out aiming to create great software... but with pressure from venture capitalists and the industry "wisdom" that eventually seeps through even the most idealistic do-gooder's skin... they work to create a software context in which they, though their proprietary advantage, have a monopoly over their users that they can exploit.
This is why, I believe, proprietary software, with its inherent power imbalance favouring developers over users, leads to unethical behaviour and exploitation of users.
Adding further evidence to the exploitative nature of proprietary is the very existence of Free and Open Source Software (FOSS). This software, now the dominant form of software on the planet, is the antithesis of proprietary software. Its brilliance is that it uses the flawed concepts of copyright in the digital age, not to protect the interests of the software's developers, but to ensure that the software cannot be made proprietary. FOSS, typified by the concept of "copyleft", rejects the idea of developer control of software that others use, and it explicitly creates a relationship between the software and its users that both allows and encourages the user to be a developer. This is a profound difference. Perversely, it is precisely because of this different dynamic that few people in the non-technical world have heard of FOSS... Most people use it every day, often thousands of times, and yet they're unaware of it. Why? Marketing and promotion.
Those commercial entities who have complete proprietary control over their software are able to collect tariffs from users - their interest in doing so, and in increasing their "share of the pie" and perhaps even "increasing the size of the pie" is clear - they profit from people using their software. They therefore have both a motive to market their software, and the means to do so, by committing a portion of their profits to that end.
FOSS is often commercially crucial, and often developed for commercial purposes and by commercial entities, but it is seldom the product that commercial entities are profiting from. Usually, FOSS exists as infrastructure that allows their commercial services... the same way that a trucking company depends on the roading infrastructure for their commercial services. Very seldom do commercial entities have both the motivation and the means to market and promote FOSS. Nonetheless, people who are technically minded tend to know about it (it's easily discoverable - I understand (can't find the source at the moment) the term "Linux" is second only to the term "sex" in number of searches on the market-leading proprietary search systems - Linux is the most widely used computer operating system on the planet, exceeding the use of Microsoft Windows and Apple's MacOS and iOS by far, and it is fully FOSS).
Treatment for proprietary malaise
So there is a grass-roots effort, by communities of developers - many of them self-taught former users - some with commercial aspirations, others without - to create an alternative universe to the imbalanced proprietary software world. Almost every context in which people use proprietary software has a FOSS alternative, but in most cases, few software users are aware of it... they are usually so overwhelmed by the complexity and blistering rate of change of proprietary software - about which they are bombarded in every advertising context - that absorbing information that requires a wee bit of digging is beyond what all but the most technically inclined will undertake.
Software has only really been relevant in most people's lives for, at most, 40 years. It's a discipline still in its infancy, but never before has such a new domain gained such ubiquity with such breathtaking speed. I can only hope that users will start to question their relationship with their software, find essays like this one, find it resonates for them, and be moved to make that bit of extra effort to extricate themselves from their current co-dependent relationship with their primary means of production...