Defining Acceptable Proprietary Software
As technology companies we are both consumers as well as creators of software.
In both positions sticking to free and open-source products would be the sublime choice but as we are not quite there yet, we are bound to think through our relation to proprietary software.
The aim of this article is to establish some guiding principles for choosing which software to use and how to license your own creations given that for some reason a fully free and open-source possibility is not an option.
The aim of this article is not to blame those who do not adhere to these principles nor to fire your employees for having a proprietary word processor installed to their device.
We herein make a bold statement by saying that proprietary software in not a priori evil, but only as long as it adhere to the following four principles:
- Its uses open-source input and output formats
- It is at least partially open-source and usable for at least non-commercial purposes
- It does not function as malware
- Its creators are committed to giving something back to the community who’s shoulders they are standing on
To illustrate the four requirements we have picked three proprietary projects which in our opinion adhere to the acceptable proprietary software criteria: a real-time collaborative LaTeX editor Overleaf, a Python IDE PyCharm, and a project management system GitLab, all of them having an important place in our own toolkit as well.
Principle 1: Using an Open-Source Input and Output Format
Most pieces of software are using a complicated data model internally but have the capability to serialize it into some file format for long-term storage and transportation.
It would be preferable if a widely understood syntax would be used for this purpose, something like JSON, CSV or LaTeX.
Most programming languages have parsers for such file types which makes it easy for anybody to write a script for creating and modifying these datasets.
In case of a more complex software such common standards might not be sufficient and a need for custom file types emerges.
This is often the case for open-source as well as proprietary projects alike.
There is nothing wrong with it as long as the file type’s specifications are available for the general public.
This requirement is not fulfilled if the only supported public output formats are PDFs or other files which are not machine-readable.
A lack of machine-readable output and input formats introduces a vendor lock-in problem and limits the possibilities for integration with other software.
Principle 2: Being At Least Partially Open-Source and Usable At Least Non-Commercially
A common, and in our opinion not bad, business strategy is open-sourcing a limited yet usable version of your product, sometimes restricting its usage for educational or non-commercial purposes while providing an enterprise subscription with a more permissive license and additional features.
Both Overleaf¹ and PyCharm² have chosen that strategy.
Beside the commonly known licenses such as MIT and GPL we think that the Creative Commons Attribution-NonCommercial 3.0 license is also a fair option.
If even this seems to be too unaffordable, as a bare minimum one should refactor some utilities and other reusable logic into publicly distributed packages.
Principle 3: Not Functioning as Malware
If the software does something beside directly serving the interests of the user, it should be clearly communicated and done in a transparent way. Even open-source projects collect telemetric statistics to better understand how the user interacts with the product. Being a developer I know how valuable such data can be and thus I usually agree to share my usage statistics. However, if the software starts to do its own thing behind the back of the user, it undermines trust within the entire society.
Principle 4: Giving Back to the Community
It almost never happens that a software project is built completely from scratch in your custom language using a custom compiler for your custom processor completely detached from the heritage of the bright masters of the past.
We are constantly making use of concepts, languages and frameworks which are freely offered to us by the generous communities of past and present.
From that viewpoint the wish to pay back the kindness of others who are supporting us should arise naturally.
There are multiple ways a tech projects can benefit the community.
The list provided here is certainly not complete nor is it ordered in any way:
- Sharing the knowledge. GitLab has a nice tech blog while Overleaf provides the most user-friendly LaTeX tutorials available in the web.
- Sharing the tools. Using the resources obtained from selling PyCharm its founders at JetBrains have introduced Kotlin a state-of-the-art language to emancipate the developers from the boundaries set by the previous strictly-typed languages.
- Sharing the resources. Many open-source frameworks and applications can flourish only because of the generous enterprise donations.
- Contributing to charities and social projects. Some software projects like Vim are directly contributing to a charity. Many projects have also decided to use their websites to support social movements: after the social unrest in the United States it was hard to find a framework without the #BlackLivesMatter statement. Many gigantic enterprises like Microsoft and Google are now taking the environmental concerns more seriously than the local laws would insist.
So, while free and open-source software should definitely be preferred both when choosing software for your toolkit as well as licensing your own artworks, proprietary software is not evil on its own as long as its creators are committed to actively working for the benefit of the multitude and establishing a better world for one and all.
