Author & Lead Researcher:
Francisco Javier Jiménez Gómez
Independent Intellectual Property Owner
Presented under the institutional umbrella of:
BRISECOM S.L.
A specialized research and thinking laboratory dedicated to algorithmic ethics, AI governance, and human-centric technology intelligence.
October 2026
There is an important distinction that is often lost in discussions about software freedom.
We usually ask:
Is this software free? Is it open source? Is its license permissive? Can I inspect the source code?
These are important questions. But they are not the only questions that matter.
I would like to propose another one:
Is this software clean?
By clean software, I mean software that does not unnecessarily contaminate its environment with dependencies on a particular vendor, platform, account, cloud service, store, or commercial ecosystem.
This is not a new software license. It is not an alternative to Free Software or Open Source. It is a different dimension.
Free does not necessarily mean independent
Software can be completely free and open source while being strongly associated with a particular ecosystem.
The source code may be available. The license may grant the traditional freedoms. The software may even be perfectly usable locally.
But the surrounding ecosystem can progressively become more important.
A typical evolution looks like this:
Software
|
initially local
|
v
optional services
|
v
integrated services
|
v
preferred distribution
|
v
ecosystem dependency
At some point, the user may discover that the easiest, best-supported, or officially recommended way of doing something requires an external service.
The software itself may still be free.
The ecosystem around it is what has changed.
Clean software
I use clean software to describe software that preserves the autonomy of its environment.
A clean application should ideally be:
- usable locally;
- installable through independent channels;
- based on open or well-documented formats;
- interoperable with other software;
- usable without a mandatory account;
- usable without a mandatory cloud service;
- replaceable without losing access to your data;
- independent of a particular vendor’s ecosystem.
This does not mean that the software cannot offer online services.
Cloud services can be useful.
The important distinction is whether they are optional or whether they gradually become part of the application’s essential environment.
Clean does not mean Free
This distinction is important.
A proprietary application can be relatively clean.
For example, imagine a commercial application that:
- runs entirely on your computer;
- stores your data in standard formats;
- does not require an account;
- does not require a cloud service;
- does not force you into a particular store;
- can exchange data with other applications.
It may be proprietary, but its environmental footprint is relatively clean.
Conversely, free software can become less clean if its practical use increasingly depends on a particular ecosystem.
Therefore:
SOFTWARE
|
+----------+----------+
| |
FREEDOM CLEAN
| |
Free / Proprietary Independent /
Ecosystem-dependent
These are different axes.
Clean Code and Clean Software
There is already a familiar concept in software engineering: Clean Code.
Clean Code is about keeping the internal structure of software understandable, maintainable and free from unnecessary complexity.
I think the same idea can be extended outward.
Clean Code asks:
Is the code itself clean?
Clean Architecture asks:
Are the internal dependencies well structured?
Clean Software asks:
Is the software’s relationship with its external environment clean?
The concept therefore moves one level outward.
Clean Code
↓
Clean Architecture
↓
Clean Software
↓
Clean Ecosystem
The last level concerns not only the application, but also how the application interacts with the rest of the technological environment.
Ecosystem pollution
This also gives us a useful metaphor.
Software can introduce unnecessary dependencies into an otherwise healthy environment.
A simple local application might become surrounded by:
Application
|
+----------+----------+
| | |
Account Cloud Store
| | |
Vendor Vendor Vendor
| | |
+----------+----------+
|
User dependency
Each individual dependency may appear reasonable.
The problem emerges from the accumulation.
The user is no longer simply using an application.
The user is participating in an ecosystem.
And leaving that ecosystem becomes increasingly difficult.
This is vendor lock-in, but I think the concept of cleanliness describes something slightly earlier in the process: the gradual introduction of unnecessary environmental dependencies.
Standards matter
Clean software should also make use of standards wherever practical.
If I create a document, I should be able to keep that document independently of the application that created it.
If I write a database, I should have a reasonable way to access the data without the original vendor.
If I create a website, I should be able to publish the resulting HTML somewhere else.
This is one reason I value technologies such as Markdown, HTML, PDF, EPUB, XML, JSON and other well-established formats.
The format becomes more important than the application.
That is a powerful form of independence.
Pandoc as an example
This is one reason I find Pandoc particularly interesting.
Pandoc is not a publishing ecosystem that requires me to belong to a particular service.
It is fundamentally a local document conversion engine.
I can take:
Markdown
|
Pandoc
|
+---- HTML
+---- PDF
+---- DOCX
+---- EPUB
+---- RTF
+---- ...
I can add templates.
I can add Lua filters.
I can create transformations.
I can build my own workflow.
And I can keep the whole process on my own computer.
That is what I mean by clean software.
It is not simply about the license.
It is about where the control remains.
Quarto is an interesting case
Quarto is another useful example because it is built on top of Pandoc and provides a much richer publishing environment.
Quarto is open source and can be used locally.
There is nothing inherently unclean about using it.
However, Quarto also exists within a broader ecosystem that includes commercial publishing and cloud services.
That does not make Quarto bad.
It simply means that when choosing a technology, I want to distinguish between:
What the local software requires
and
What the surrounding ecosystem offers or encourages.
An optional service is very different from a mandatory service.
The cleanest systems are those where the user can take advantage of services without becoming dependent on them.
The clean software test
When evaluating a new application, I would therefore ask a few simple questions:
Can I run it locally?
Can I use it without creating an account?
Can I install it without depending on a particular store?
Can I keep using it if the vendor disappears?
Can I export my data?
Are the formats documented?
Can another application read my data?
Can I replace one component without replacing the entire ecosystem?
Does the application work with the Internet, or does it require the Internet?
These questions tell us something that a software license alone cannot tell us.
Clean software is about autonomy
Ultimately, I think the concept is about autonomy.
A clean application does not necessarily reject the cloud.
It does not reject commercial software.
It does not reject companies.
It does not even reject proprietary software.
It simply avoids making unnecessary external dependencies part of the user’s computing environment.
The ideal is quite simple:
The software should serve the user’s environment, rather than turning the user’s environment into an extension of the software vendor’s ecosystem.
That is what I mean by Clean Software.
Free Software gives us important freedoms over software.
Open standards give us interoperability.
Portable applications give us flexibility.
But clean software adds another question:
How much of my computing environment remains mine?
And perhaps that is a question worth asking before installing the next application.