In this fifth article of the “System insights with command-line tools” series we explore free and vmstat, two small utilities that reveal a surprising amount about your Linux system’s health. free gives you an instant snapshot of how RAM and swap are being used. vmstat (the virtual memory statistics reporter) reports a real-time view of memory, CPU, and I/O activity.

By the end of this article you will be able to translate buffers and cache into “breathing room”, read the mysterious available column with confidence, and spot memory leaks or I/O saturation.

A quick tour of free

Basic usage

$ free -h
       total    used    free   shared  buff/cache  available
Mem:    23Gi    14Gi   575Mi    3,3Gi        12Gi      8,8Gi
Swap:  8,0Gi   6,6Gi   1,4Gi

free parses /proc/meminfo and prints totals for physical memory and swap, along with kernel buffers and cache. Use -h for human-readable units, -s 1 to refresh every second, and -c N to stop after N samples which is handy to get a trend when doing something in parallel. For example, free -s 60 -c 1440 gives a 24-hour CSV-friendly record without installing extra monitoring daemons.

Free memory refers to RAM that is entirely unoccupied. It isn’t being used by any process or for caching. On server systems, I tend to view this as wasted since unused memory isn’t contributing to performance. Ideally, after a system has been running for some time, this number should remain low.

Available memory, on the other hand, represents an estimate of how much memory can be used by new or running processes without resorting to swap. It includes free memory plus parts of the cache and buffers that the system can reclaim quickly if needed.

In essence, the distinction in Linux lies here: free memory is idle and unused, while available memory includes both truly free space and memory that can be readily freed up to keep the system responsive without swapping. It is not a problem to have a low free memory, available memory is usually what to be concerned about.

A healthy system might even show used ≈ total yet available remains large; that mostly reflects cache at work. Your Linux kernel will automatically drop clean cache pages whenever an application needs the space, so cached memory is not wasted. Think of it as a working set that just hasn’t been reassigned yet.

Spotting problems with free

• Rapidly shrinking available combined with rising swap used indicates real memory pressure.
• Large swap-in/out spikes point to thrashing workloads or runaway memory consumers.

vmstat – Report virtual memory statistics

vmstat (virtual memory statistics) displays processes, memory, paging, block-I/O, interrupts, context switches, and CPU utilization in a single line. Run it with an interval and count to watch trends (output shown below has been split into three sections for better readability):

$ vmstat 1 3
procs -----------memory----------
 r  b   swpd   free   buff  cache
 2  0 7102404 1392528     36 12335148
 0  0 7102404 1392560     36 12335188
 0  0 7102404 1373640     36 12349928

 ---swap-- -----io----
  si   so    bi    bo
   8   21   130   724
   0    0     0     0
   0    0     8    48

 -system-- -------cpu-------
 in     cs us sy id wa st gu
 2851   19 15  7 77  0  0  0
 5779 7246 14 10 77  0  0  0
 5141 6525 12  9 79  0  0  0

Anatomy of the output

From the vmstat(8) manpage:

Procs
    r: The number of runnable processes (running or waiting
       for run time).
    b: The number of processes blocked waiting for I/O to
       complete.

Memory
    These are affected by the --unit option.
    swpd: the amount of swap memory used.
    free: the amount of idle memory.
    buff: the amount of memory used as buffers.
    cache: the amount of memory used as cache.
    inact: the amount of inactive memory.  (-a option)
    active: the amount of active memory.  (-a option)

Swap
    These are affected by the --unit option.
    si: Amount of memory swapped in from disk (/s).
    so: Amount of memory swapped to disk (/s).

IO
    bi: Kibibyte received from a block device (KiB/s).
    bo: Kibibyte sent to a block device (KiB/s).

System
    in: The number of interrupts per second, including
        the clock.
    cs: The number of context switches per second.

CPU
    These are percentages of total CPU time.
    us: Time spent running non-kernel code.  (user time,
        including nice time)
    sy: Time spent running kernel code.  (system time)
    id: Time spent idle.  Prior to Linux 2.5.41, this
        includes IO-wait time.
    wa: Time spent waiting for IO.  Prior to Linux 2.5.41,
        included in idle.
    st: Time stolen from a virtual machine.  Prior to
        Linux 2.6.11, unknown.
    gu: Time spent running KVM guest code (guest time,
        including guest nice).

Practical diagnostics

Catching a memory leak

Run vmstat 500 in one terminal while your suspect application runs in another. If free keeps falling and si/so climb over successive samples, physical RAM is being exhausted and the kernel starts swapping, which is classic leak behavior.

Finding I/O saturation

When wa (CPU wait) and bo (blocks out) soar while r remains modest, the CPU is idle but stuck waiting for the disk. Consider adding faster storage or tuning I/O scheduler parameters.

Detecting CPU over-commit

A sustained r that is double the number of logical cores with low wa and plenty of free means CPU is the bottleneck, not memory or I/O. Use top or htop to locate the busiest processes to scale out workloads accordingly.

Conclusion

Mastering free and vmstat gives you a lens into memory usage, swap activity, I/O latency, and CPU load. For everyday debugging: start with free to check if your system is truly out of memory, then use vmstat to reveal the reason, whether it’s memory leaks, disk bottlenecks, or CPU saturation.

Stay tuned for the next piece in our “System insights with command-line tools” series and happy Linux troubleshooting!

Among the many details developers juggle, software licensing is often treated as an afterthought. We know we need it. However, faced with choosing the right license, tracking inherited code, and keeping things consistent, license management can feel like a bureaucratic burden.

Licensing is what makes the REUSE project, maintained by the Free Software Foundation Europe (FSFE), such an interesting and important effort. It does not try to replace the legal work involved in choosing a license or deciphering obligations. Instead, REUSE focuses on the mechanics of software licensing. It addresses how we communicate licensing clearly, unambiguously, and reliably in the code itself. REUSE has been adopted by a lot of projects already. These include SAP, Nextcloud and numerous Ansible community roles and collections.

I recently went down the licensing and supply chain rabbit hole myself. I had to figure out how to apply it to open source projects we work on and explain it to others. Thus, I had the unique experience of learning it from scratch while also teaching it. That process gave me insight into what makes REUSE helpful. I learned where the roadblocks are, and how you can start using it in your own open source work. So this article aims to give additional reasoning and insights for every day usage beyond the scope of a quick start tutorial.

For those who prefer video, I also gave a REUSE presentation on this topic at GPN23 in German (it contains essentially the same content as the text):

Why licensing still feels broken

If you’ve ever tried to make sense of licensing in a codebase with contributions from half a dozen sources, or tried to package software only to find ambiguous or conflicting license declarations, you’ve seen the brokenness first hand. It’s a common pain point.

You start coding. A LICENSE file goes in the root. Maybe it’s MIT, maybe Apache 2.0, maybe GPLv3-or-later. We figure that’s enough. For the most part, tools like Licensee (which Github uses) will scan that file and report the project as single-licensed under whatever it finds.

But that is only part of the picture.

Real-world projects grow messy over time. Files come in from various places. Pull requests, upstream forks, old backups. Someone pastes in a script from Stack Overflow. Someone else uploads a code generator output. Over time, the repository becomes a tangle of files with unclear origins. The top-level LICENSE file can’t speak for all of it any more. But the tools like licensee don’t know that, and often neither do the maintainers.

If you provide code without clear licensing information, you make it hard for the open source ecosystem to collaborate with or consume your work. Unfortunately, approaches to automatic license detection can’t deliver the needed certainty. They rely on fuzzy matching, heuristics, and assumptions (like there is “one license for the project”). This just does not cut it when legal clarity is required. Automatic license heuristics are complicated and will never deliver reliable results for all the possible use cases.

FSFE REUSE to the rescue

Rather than trying to detect or infer licensing, REUSE asks developers to be explicit in a machine-readable, auditable way:

1. There has to be a text copy of every used license below a LICENSES/ directory¹ in the root of the project.
2. Each file in your project must have machine-readable copyright and licensing information associated with it.

Again: This matters. It means anyone—an auditor, a packager, a contributor, or a compliance team—can look at any file in your repository and immediately understand its legal status. There is no guessing, no cross-referencing, no “well maybe this falls under the MIT license because the rest of the project does.” It’s explicit. It’s standardized. And it is quickly lintable which is great for teams with Continuous Integration.

Following REUSE, adding machine-readable copyright and licensing information can be done in the following ways:

• Comment headers or <filename>.license for uncommentable files.
• REUSE.toml, a machine-readable copyright file to address file and directory names. This is especially handy to define:
  • a default license for your project.
  • deviant licenses for third party artefacts residing in a sub-directory.

REUSE backs up its specification with a simple, focused, reuse command-line tool. This makes adoption relatively painless (even though all can also be done manually). REUSE fits nicely into the ecosystem, especially by relying on Software Package Data Exchange (SPDX) and SPDX license identifiers.

Usage

The official REUSE tutorial and the tool usage section is really good so I will just reproduce a quick start here:

1. Put your licenses in the LICENSES/ directory.
2. Add a comment header to each file that says something like

   SPDX-License-Identifier: GPL-3.0-or-later
   SPDX-FileCopyrightText: $YEAR $NAME
   

   You can be flexible with the format, just make sure that the line starts with SPDX-License-Identifier: and/or SPDX-FileCopyrightText:

Comment headers

REUSE, and many organizations like GNU, recommend including license header comments in source files as it helps to prevent confusion or errors. So even if the REUSE.toml copyright file exists as the central place for licensing information, sometimes files get copied or forked into new projects and third parties might not have a well organized repository bureaucracy. Without a statement about what their license is, moving single files into another context might eliminate all trace of that information.

Example of a header comment:

# SPDX-FileCopyrightText: Andreas Haerter, ACME Corp (https://example.com)
# SPDX-License-Identifier: CC-BY-SA-4.0

One with dual-licensing:

/*
  SPDX-FileCopyrightText: Jane Doe <j.doe@example.com>
  SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later
*/

REUSE.toml

You might come to the conclusion that to skip adding headers to every file and only using a REUSE.toml is better for your project … fair enough and that will still be compliant. It is also possible to bulk-license whole directories using this technique. The file format is specified, but a simple example helps to get started:

version = 1
SPDX-PackageName = "Foo bar project"
SPDX-PackageDownloadLocation = "https://git.example.com/foobar"
SPDX-PackageSupplier = "ACME Inc. (https://example.com)"

[[annotations]]
path = "**"
precedence = "closest"
SPDX-FileCopyrightText = "ACME Inc."
SPDX-License-Identifier = "LGPL-2.1-or-later"

Verification

Now verify your work using reuse lint:

$ reuse lint
[...]
Congratulations! Your project is compliant with version 3.4 of the REUSE Specification :-)

Demo

The FSFE created a small screencast², which follows the tutorial, making the REUSE example repository compliant:

Tips and tricks

Needed vocabulary when you start learning or teaching

To follow documentation and communication in the licensing space, it is important to know about the meaning of:

• Software Package Data Exchange (SPDX) and SPDX license identifiers: A standard for identifying licenses using short, consistent identifiers (like MIT or GPL-3.0-only). It simplifies license tracking and automation.
• Software Bill of Materials (SBOM): A structured list of all software components and their licenses in a project. It helps with transparency, security audits, and legal compliance.
• Copyleft (license): A type of open source license that ensures derivative works remain under the same license. It protects user freedoms by requiring shared modifications. The GPL is a well-known example.
• Permissive (license): A license that allows code to be reused with minimal conditions, including in proprietary software, without giving back modifications. Common examples include MIT, BSD, and Apache 2.0.
• TOML: A configuration file format. REUSE.toml (a machine-readable file in your project’s root directory) uses it to declare licensing information based on filename patterns.
• DEP5: A machine-readable debian/copyright file which was used before REUSE.toml. DEP5, while still supported, has been deprecated since the introduction of REUSE.toml. This is important to know when hitting older documentation or tutorials.

My personal killer feature: Additional comments in REUSE.toml

It might sound trivial, but it was always cumbersome for me to keep track of the originally used download URLs and other common data around simple third-party files, like “this small icon there”. From my point of view, the RESUE.toml file is the ideal place to keep additional data on third party files by using SPDX-FileComment without cluttering the repository or the end-user documentation. If there is at least one example, in my experience, maintaining source information and reasoning for third-party files is quickly adopted even in teams without many regulations:

Example 1: REUSE.toml with sections tracking the original download URLs or notes

[...]
[[annotations]]
path = "assets/images/window.svg"
precedence = "closest"
SPDX-FileCopyrightText = "2022 Refactoring UI Inc."
SPDX-License-Identifier = "MIT"
SPDX-FileComment = "https://github.com/tailwindlabs/heroicons/blob/master/optimized/24/outline/window.svg"

[[annotations]]
path = ["extensions/Find-WindowHandle.ps1", "extensions/Helper.ps1"]
precedence = "closest"
SPDX-FileCopyrightText = "2018 Grégoire Geis (https://github.com/71/Focus-Window/)"
SPDX-License-Identifier = "MIT"
SPDX-FileComment = "Slightly adapted for this project by foundata GmbH (https://foundata.com)"
[...]

Example 2: The REUSE.toml from SAP/openui5 which uses the file patterns and comments to keep track of single files copied from other projects:

[...]
[[annotations]]
path = "src/sap.ui.integration/test/sap/ui/integration/demokit/cardExplorer/webapp/thirdparty/CfWorkerJsonSchemaValidator.js"
precedence = "aggregate"
SPDX-FileCopyrightText = "2020 Jeremy Danyow"
SPDX-License-Identifier = "MIT"
SPDX-FileComment = "these files belong to: @cfworker/json-schema"

# Library: sap.ui.webc.common:
[[annotations]]
path = [
    "src/sap.ui.webc.common/src/sap/ui/webc/common/thirdparty/base/**",
    "src/sap.ui.webc.common/src/sap/ui/webc/common/thirdparty/theming/**",
    "src/sap.ui.webc.common/src/sap/ui/webc/common/thirdparty/localization/**",
    "src/sap.ui.webc.common/src/sap/ui/webc/common/thirdparty/icons/**",
    "src/sap.ui.webc.common/src/sap/ui/webc/common/thirdparty/icons-tnt/**",
    "src/sap.ui.webc.common/src/sap/ui/webc/common/thirdparty/icons-business-suite/**"
]
precedence = "aggregate"
SPDX-FileCopyrightText = "SAP"
SPDX-License-Identifier = "Apache-2.0"
SPDX-FileComment = "these files belong to: UI5 Web Components"
[...]

README section template about licensing and copyright for humans

I find it useful to have a generic, easy to adapt text snippet for the README.md or a comparable central place which is easy for humans to notice and read. I created and use the following template, taking advantage of the existing REUSE information to make the section basically maintenance free without being useless:

## Licensing, copyright

<!--REUSE-IgnoreStart-->
Copyright (c) YYYY, ACME Inc.

This project is licensed under the GNU General Public License v3.0 or later (SPDX-License-Identifier: `GPL-3.0-or-later`), see [`LICENSES/GPL-3.0-or-later.txt`](LICENSES/GPL-3.0-or-later.txt) for the full text.

The [`REUSE.toml`](REUSE.toml) file provides detailed licensing and copyright information in a human- and machine-readable format. This includes parts that may be subject to different licensing or usage terms, such as third-party components. The repository conforms to the [REUSE specification](https://reuse.software/spec/). You can use [`reuse spdx`](https://reuse.readthedocs.io/en/latest/readme.html#cli) to create a [SPDX software bill of materials (SBOM)](https://en.wikipedia.org/wiki/Software_Package_Data_Exchange).
<!--REUSE-IgnoreEnd-->

Replace YYYY with the year of the first release or code contribution and adapt the mentioned license, filenames and links as needed. The HTML comments prevent REUSE linting errors when e.g. listing multiple licenses.

The wording is already pointing to the copyright file (REUSE.toml) and mentions that parts of the project might be subject to different licensing than the main one. If this is not good enough, feel free to adapt the wording of the main “licensed under” sentence to highlight the main licensing rules without the need to maintain every single bit outside of the copyright file. Examples (adapt as needed):

The project is dual-licensed under the

* GNU General Public License v3.0 or later (SPDX-License-Identifier: `GPL-3.0-or-later`), see [`LICENSES/GPL-3.0-or-later.txt`](./LICENSES/GPL-3.0-or-later.txt) for the full text.
* Apache License 2.0 (SPDX-License-Identifier: `Apache-2.0`), see [`LICENSES/Apache-2.0.txt`](./LICENSES/Apache-2.0.txt) for the full text.

[... usual template follows ...]

License detection on Github or Gitlab

If you follow REUSE, you will notice that Github and Gitlab are no longer able to detect licensing information for your repository.

Even if automatic licensing is broken by design for the reasons outlined above, it is understood that it would be nice if all the broken license detection tools spit out something, even unreliable but working, for indexes and searches (for the sole reason of not having a disadvantage if inexperienced users are searching for projects and filter by often broken meta data).

If you need this, put the stated “license with the highest freedom protections” just for search-indexes and GitHub in a LICENSE or COPYING file in the root directory of your project:

1. GitHub uses Licensee to attempt to identify the license of a project and Licensee does not support the REUSE specification.
2. A workaround to fix the automatic license detection of GitHub and others is to place an additional LICENSE or COPYING file in the root directory of your project. This is allowable by REUSE. These files are explicitly ignored by the toolset and do not need an additional .license file or header.
3. If you want to prevent a duplication of License texts, beware of another issue with Licensee: You can place a symlink at LICENSES/<your license>.txt pointing to the LICENSE or COPYING file in the project’s root directory. reuse lint will follow that link. Licensee sadly does not even support symlinks, so a more logical symlink from LICENSE or COPYING pointing to LICENSES/<your license>.txt is not solving the issue. I therefore recommend a real copy instead of a symlink to keep things accessible when using the workaround.

I, for myself, would use this workaround only if a single license is used for all of the project’s files. This would prevent misunderstandings or conflicts and simply ignore GitHub’s limited behavior in all other cases.

Years in copyright texts

This is not exactly a REUSE topic but I noticed it is discussed quite a lot when a project starts adopting REUSE. IANAL, but it is not necessary to update the copyright year since the main legal intention is to state the year of the first public release or code contribution. But it is common to do so anyway, especially since it shows third parties that a project is still alive.

I usually propose the following which might also be a useful technique for your project:

• Update the copyright data but maintain the copyright year only at central places like a project’s README.md reduce the maintenance effort.
• Simply add each year with a release or updates separated by commas. You can use a timespan (yearX-yearY) for multiple subsequent years.
• Example:
  • The first release and copyright statement was Copyright (c) 2013.
  • There were releases or updates in several but not all years afterwards:
    • 2023 → Copyright (c) 2013, 2015, 2018-2021, 2023.
    • 2015 → Copyright (c) 2013, 2015.
    • 2018 → Copyright (c) 2013, 2015, 2018.
    • 2019 → Copyright (c) 2013, 2015, 2018, 2019.
    • 2020 → Copyright (c) 2013, 2015, 2018-2020.
    • 2021 → Copyright (c) 2013, 2015, 2018-2021.

Conclusion

Licensing clarity is needed for sustainable collaboration in open source. The REUSE specification doesn’t try to replace legal frameworks or licensing decisions, but it makes the messy practicalities of license management predictable, explicit, and automatable.

Adopting REUSE can feel like extra effort at first, especially for existing codebases. But once in place, it pays off by making your project easier to understand, maintain, package, and … reuse… 🙂 . REUSE helps you express the legal structure of your project in a way that machines and humans can agree on. And that’s worth a lot.

Continuing our exploration of commands that provide insights into the inner workings of your Linux system, we turn our focus to more simple ones like lslogins and lsmod. These tools offer information about user accounts and kernel modules, respectively.

lslogins: Look into User Accounts

lslogins is a command that extracts and displays detailed information about user accounts on your system. It pulls data from /etc/passwd and /etc/shadow files, along with system logs, to give you a comprehensive overview. It is especially useful to look for login failures and to list group memberships.

Basic Usage

Run the command without arguments to display a summary of all user accounts:

lslogins

This provides an overview including UID (User ID), GID (Group ID), user name, and last login details.

Common options and usage example

• -u: Display only user accounts and root (filtering out system accounts with UIDs below 1000).
• -G: Display information about exiting groups.
• -g <group>: Show users of a specific group (e.g. wheel which usually has sudo-permissions on a Red Hat system).
• -e: Display in an export-able key-value output format, separated by space.
• -L: List last logins and password information (empty, logged, nologin).

Examples, listing the last logins and password information (empty, logged, nologin) of non-system user accounts on my laptop as well as group memberships:

$ lslogins -L -p -u
 UID USER      LAST-TTY LAST-HOSTNAME LAST-LOGIN PWD-EMPTY PWD-LOCK PWD-DENY NOLOGIN HUSHED PWD-METHOD
   0 root                                                                          0
1000 ahaerter  tty2     tty2               01:16                                   0      0

$ lslogins -G -u
 UID USER       GID GROUP     SUPP-GIDS  SUPP-GROUPS
   0 root         0 root
1000 ahaerter  1000 user      971,10,977 docker,wheel

lsmod: Listing Kernel modules for further inspection

The Linux kernel is fundamentally monolithic in design, but it also provides the capability to load and unload modules at runtime. A kernel module is generally understood as a component or an extension of the kernel. For example, hardware drivers (e.g., Wi-Fi cards, sound cards, etc.) are usually implemented as modules. The lsmod command provides a nice overview of all currently loaded kernel modules.

Basic usage

Simply type:

lsmod

This displays a table with three columns:

1. Module: The name of the kernel module.
2. Size: The memory size (in bytes) the module occupies.
3. Used By: Lists the dependent modules or kernel features.

Example output:

$ lsmod
Module                  Size  Used by
overlay               241664  0
tun                    73728  2
snd_usb_audio         614400  0
snd_usbmidi_lib        57344  1 snd_usb_audio
snd_ump                49152  1 snd_usb_audio
snd_rawmidi            57344  2 snd_usbmidi_lib,snd_ump
hid_jabra              16384  0
uinput                 20480  0
rfcomm                102400  16
snd_seq_dummy          12288  0
snd_hrtimer            12288  1
wireguard             122880  0
curve25519_x86_64      36864  1 wireguard
libcurve25519_generic    45056  2 curve25519_x86_64,wireguard
ip6_udp_tunnel         16384  1 wireguard
udp_tunnel             36864  1 wireguard
nf_conntrack_netbios_ns    12288  1
nf_conntrack_broadcast    12288  1 nf_conntrack_netbios_ns
nft_fib_inet           12288  1
nft_fib_ipv4           12288  1 nft_fib_inet
nft_fib_ipv6           12288  1 nft_fib_inet
nft_fib                12288  3 nft_fib_ipv6,nft_fib_ipv4,nft_fib_inet
[...]

Usage examples

While lsmod doesn’t have options, pairing it with other commands enhances its utility:

• Combine with modinfo: Get detailed information about a specific module, including its author, license, and description.
• Debug with dmesg: Correlate kernel log messages with loaded modules to diagnose boot-time issues.

modinfo <module_name>
sudo dmesg | grep <module_name>

Conclusion

Commands like lslogins and lsmod can give you easy insights into user management and kernel behavior. Try them out today, and think about combining their output with other tools to appreciate their capabilities.

In our ongoing series on Linux system insights, we have a look into essential command-line utilities that provide information about the system’s hardware and status. Following our previous discussions on lscpu, lsusb, dmidecode and lspci, we now turn our attention to lsof and lsblk. These tools are particularly useful for investigating open files, active network connections, and mounted block devices on your Fedora Linux system.

Exploring open files with lsof

lsof (list open files) is a powerful command-line tool. Since almost everything in Linux is treated as a file, lsof provides detailed insight into many parts of your system by listing what files are being used, which processes are accessing them, and even which network ports are open (see e.g. Wikipedia on Network socket for more information).

Basic usage

To start with, execute the basic lsof command to get an overview of the system’s open files:

$ sudo lsof

sudo was used for extended privileges. This is needed to get information about files not opened by processes started by your user. The command outputs a lot of information which can be overwhelming. We are going to narrow down the output to specific information about some common use cases in the following examples.

Example 1: Finding open files by user or process

To identify which files a specific user or process has open, lsof can be very helpful.

To list all files opened by a specific user:

$ sudo lsof -u <username>

This will return a list of open files owned by the given user. For example:

$ sudo lsof -u johndoe

You’ll see details such as the process ID (PID), the file descriptor, the type of file, and the file’s path.

To filter by process ID, use the -p flag:

$ lsof -p <PID>

This is particularly useful for troubleshooting issues related to specific processes or when you need to check which files a service is holding open. Use sudo if the process is not owned by your user.

Example output:

$ lsof -p 873648
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
bash    873648 user  cwd    DIR   0,39     8666      257 /home/user
bash    873648 user  rtd    DIR   0,35      158      256 /
bash    873648 user  txt    REG   0,35  1443376 12841259 /usr/bin/bash
bash    873648 user  mem    REG   0,33          12841259 /usr/bin/bash (path dev=0,35)
bash    873648 user  mem    REG   0,33          14055145 /usr/lib/locale/locale-archive (path dev=0,35)
bash    873648 user  mem    REG   0,33          14055914 /usr/lib64/libc.so.6 (path dev=0,35)
bash    873648 user  mem    REG   0,33          13309071 /usr/lib64/libtinfo.so.6.4 (path dev=0,35)
bash    873648 user  mem    REG   0,33          14059926 /usr/lib64/gconv/gconv-modules.cache (path dev=0,35)
bash    873648 user  mem    REG   0,33          14055911 /usr/lib64/ld-linux-x86-64.so.2 (path dev=0,35)
bash    873648 user    0u   CHR  136,3      0t0        6 /dev/pts/3
bash    873648 user    1u   CHR  136,3      0t0        6 /dev/pts/3
bash    873648 user    2u   CHR  136,3      0t0        6 /dev/pts/3
bash    873648 user  255u   CHR  136,3      0t0        6 /dev/pts/3

Example 2: identifying open network connections via sockets

With its ability to list network connections, lsof also becomes a handy tool for diagnosing network-related issues as it is usually even available on hardened, minimal systems.

To display all open network connections (TCP/UDP sockets), run:

$ sudo lsof -i

This will list active network connections along with the associated protocol, port, and process details.

You can filter for specific protocols (like TCP or UDP), include or exclude IPv4 and v6 and combine several values (the example section of man lsof provides a lot of useful information, including negation):

$ sudo lsof -i tcp
$ sudo lsof -i udp
$ sudo lsof -i 4tcp
$ sudo lsof -i 6tcp
$ sudo lsof -i 4tcp@example.com

For connections associated with a particular port:

$ sudo lsof -i :<port_number>

For example, to list connections to port 22 (SSH):

$ sudo lsof -i :22
COMMAND    PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
sshd    904379 root    3u  IPv4 5622530      0t0  TCP *:ssh (LISTEN)
sshd    904379 root    4u  IPv6 5622532      0t0  TCP *:ssh (LISTEN)

This information can be critical for identifying unauthorized connections or simply monitoring network activity on a system for debugging.

Investigating block devices with lsblk

Another useful tool is lsblk, which displays information about all available block devices on your system. Block devices include hard drives, SSDs, and USB storage. This command provides a tree-like view, helping you understand the relationships between partitions, devices, and their mount points.

Basic usage

Running lsblk without any options provides a clean hierarchical structure of the block devices:

$ lsblk

This shows all block devices in a tree structure, including their size, type (disk, partition), and mount point (if applicable).

Examples

For a deeper look into the file systems on your block devices, use the -f flag:

$ lsblk -f

This will display not just the block devices, but also details about the file systems on each partition, including the type (e.g., ext4, vfat, swap), the UUID, and the current mount points.

If you want less information about the devices themselves (without showing partitions or mount points), the -d option is useful:

$ lsblk -d

There is also a -J or –json option. If used, the command outputs the information in JSON format. This provides a structured view that is particularly useful for scripting and automation.

Example outputs from my laptop (some long information like UUIDs stripped for readability):

$ lsblk
NAME                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                        8:0    1     0B  0 disk
sdb                        8:16   1     0B  0 disk
sdc                        8:32   1     0B  0 disk
zram0                    252:0    0     8G  0 disk  [SWAP]
nvme0n1                  259:0    0 931,5G  0 disk
├─nvme0n1p1              259:1    0   600M  0 part  /boot/efi
├─nvme0n1p2              259:2    0     1G  0 part  /boot
└─nvme0n1p3              259:3    0 929,9G  0 part
  └─luks-84257c20[...]   253:0    0 929,9G  0 crypt /home

$ lsblk -d
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda       8:0    1     0B  0 disk
sdb       8:16   1     0B  0 disk
sdc       8:32   1     0B  0 disk
zram0   252:0    0     8G  0 disk [SWAP]
nvme0n1 259:0    0 931,5G  0 disk

$ lsblk -f
NAME                FSTYPE [...]LABEL    UUID           FSAVAIL FSUSE% MOUNTPOINTS
sda
sdb
sdc
zram0                                                                  [SWAP]
nvme0n1
├─nvme0n1p1         vfat                 4C5B-4355      579,7M  3%     /boot/efi
├─nvme0n1p2         ext4                 30eff827[...]  605M    31%    /boot
└─nvme0n1p3         crypto_LUKS          84257c20[...]
  └─luks-84257[...] btrfs       fe[...]  666f9d6f[...]  303,1G  67%    /home
                                                                       /

$ lsblk -f -J
{
   "blockdevices": [
   [...],{
         "name": "nvme0n1",
         "fstype": null,
         "fsver": null,
         "label": null,
         "uuid": null,
         "fsavail": null,
         "fsuse%": null,
         "mountpoints": [
             null
         ],
         "children": [
            {
               "name": "nvme0n1p1",
               "fstype": "vfat",
               "fsver": "FAT32",
               "label": null,
               "uuid": "4C5B-4355",
               "fsavail": "579,7M",
               "fsuse%": "3%",
               "mountpoints": [
                   "/boot/efi"
               ]
            },{
               "name": "nvme0n1p2",
               "fstype": "ext4",
               "fsver": "1.0",
               "label": null,
               "uuid": "30eff827-[...]",
               "fsavail": "605M",
               "fsuse%": "31%",
               "mountpoints": [
                   "/boot"
               ]
            },{
               "name": "nvme0n1p3",
               "fstype": "crypto_LUKS",
               "fsver": "2",
               "label": null,
               "uuid": "84257c20-[...]",
               "fsavail": null,
               "fsuse%": null,
               "mountpoints": [
                   null
               ],
               "children": [
                  {
                     "name": "luks-[...]",
                     "fstype": "btrfs",
                     "fsver": null,
                     "label": "fedora_localhost-live",
                     "uuid": "666f9d6f-[...]",
                     "fsavail": "303,1G",
                     "fsuse%": "67%",
                     "mountpoints": [
                         "/home", "/"
                     ]
                  }
               ]
            }
         ]
      }
   ]
}

Conclusion

The lsof and lsblk commands are providing insights into file usage, network activity, and block device structures. Whether you’re tracking down open file handles, diagnosing network connections, or reviewing storage devices; whether you’re troubleshooting, optimizing, or simply curious; these tools provide valuable data that can help you better understand and manage your Fedora Linux environment. See you next time when we will have a look at more useful listing and information command line tools and how to use them.

Mitigation

If there are old boxes, make sure you apply proper firewalling to mitigate the issue. It seems that a exploit might need a lot of login tries on average to be successful without further optimizations. This might buy you a bit of time to patch everything today, even if the box was exposed to the public internet. Additionally, the exploit was only shown for 32-bit systems yet. There is a high probability that a yet-to-come exploit for 64-bit systems will be slower (=more login attempts needed on average for a successful hack).

If you cannot upgrade your system yet, the FreeBSD security advisory states that setting LoginGraceTime to 0 might help:

If sshd(8) cannot be updated, this signal handler race condition can be mitigated by setting LoginGraceTime to 0 in /etc/ssh/sshd_config and restarting sshd(8). This makes sshd(8) vulnerable to a denial of service (the exhaustion of all MaxStartups connections), but makes it safe from the remote code execution presented in this advisory.

Systems known to be affected

• Red Hat Enterprise Linux (RHEL) 9 (and therefore probably all CentOS 9 versions)
• Debian 12 Bookwork
• Ubuntu 22, 23 and 24
• Potentially all systems with OpenSSH 8.5p1 up to 9.8; the first patched version is OpenSSH 9.8p1.
• Potentially all systems with OpenSSH versions earlier than 4.4p1, as long as their respective distributions have not backported patches for CVE-2006-5051 or CVE-2026-5051.

The list is probably incomplete and will be updated as more confirmations are obtained. Do not forget to restart the sshd service (for example, it seems that there are otherwise issues with key exchange on Arch Linux).

Propably unaffected systems

Even if your systems seem to be not affected in general: Update. Now. There will be a lot of research about this vulnerability and maybe new ways to exploit it will be discovered.

Currently not affected are:

• Red Hat Enterprise Linux (RHEL) 6, 7 und 8¹ (and therefore probably all related CentOS versions)
• Debian 11 Bullseye²
• FreeBSD³
• OpenBSD⁴

Links

Additional links and reports:

• Qualys Security Advisory: regreSSHion: RCE in OpenSSH’s server, on glibc-based Linux systems (CVE-2024-6387)
• Hacker News Thread about (CVE-2024-6387)

Fedora (and other common Linux setups out there) offers you an array of tools for managing, monitoring, and understanding the system. Among these tools are a series of commands that begin with ls (for “list”).

They provide easy insights into various aspects of the system’s hardware and resources. This article series gives you an intro and overview over many of them, starting with the simpler ones. The post will cover lscpu and lsusb.

lscpu – Display CPU information

The lscpu command gathers and displays information about the CPU architecture. It is provided by the util-linux package. The command gathers CPU information from multiple sources like /proc/cpuinfo and architecture-specific libraries (e.g. librtas on PowerPC):

$ lscpu

This command outputs information like the number of CPUs, threads per core, cores per socket, and the CPU family and model.

If asked, it outputs detailed CPU information in JSON format. This provides a structured view that is particularly useful for scripting and automation:

$ lscpu --extended --json

Advanced usage example

With the machine readable JSON output, you can extract information using jq (a powerful command-line tool that allows users to parse, filter, and manipulate JSON data efficiently and worth an article of its own). For example, the following command will extract the current MHz for each CPU:

export LANG=en_US.UTF-8
export LC_ALL="en_US.UTF-8"
lscpu --json --extended \
  | jq '.cpus[] | {cpu: .cpu, mhz: .mhz}'

Let’s look at the single parts of the command:

• export LANG=en_US.UTF-8 and export LC_ALL="en_US.UTF-8" are making sure that the output is not using localized numbers. For example, a German language setting can result in broken JSON output because of the use of commas in place of periods as floating point separators.
• lscpu --json --extended generates the detailed CPU information in JSON format.
• jq '.cpus[] | will iterate over each entry in the cpus array. The {cpu: .cpu, mhz: .mhz}' part constructs a new JSON object for each CPU entry showing the CPU number (cpu) and its current frequency in MHz (mhz).

Example output from a laptop operating in performance mode:

$ lscpu --json --extended \
  | jq '.cpus[] | {cpu: .cpu, mhz: .mhz}'
{
  "cpu": 0,
  "mhz": 3700.0171
}
{
  "cpu": 1,
  "mhz": 3700.2241
}
{
  "cpu": 2,
  "mhz": 3700.1121
}
{
  "cpu": 3,
  "mhz": 3884.2539
}

and later in power saver mode:

$ lscpu --json --extended \
  | jq '.cpus[] | {cpu: .cpu, mhz: .mhz}'
{
  "cpu": 0,
  "mhz": 1200.0580
}
{
  "cpu": 1,
  "mhz": 1200.0070
}
{
  "cpu": 2,
  "mhz": 1200.5450
}
{
  "cpu": 3,
  "mhz": 1200.0010
}

lsusb – Display USB Devices Information

The lsusb command displays detailed information about the USB buses in the system and the devices connected to them. It is provided by the usbutils package and helps users and system administrators easily view the configuration and the devices attached to their USB interfaces:

$ lsusb

This produces a list of all USB buses, devices connected to them, and brief information about each device, such as ID and manufacturer. This is particularly useful for a quick check of what devices are connected to the system and if you need the USB device ID for udev rules or the like.

Usage example and output

For those needing more detailed information about the USB devices, lsusb allows listing more detailed information:

$ lsusb | grep Fibocom
Bus 001 Device 013: ID 2cb7:0210 Fibocom L830-EB-00 LTE WWAN Modem

$ sudo lsusb -d 2cb7:0210 -v
Bus 001 Device 013: ID 2cb7:0210 Fibocom L830-EB-00 LTE WWAN Modem
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 [unknown]
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x2cb7 Fibocom
  idProduct          0x0210 L830-EB-00 LTE WWAN Modem
  bcdDevice            3.33
  iManufacturer           1 FIBOCOM
  iProduct                2 L830-EB-00
  iSerial                 3 004999010640000
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x00a1
    bNumInterfaces          4
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower              100mA
[ more output omitted for readability ]

Using the -v and -t options will tell lsusb to dump the physical USB device hierarchy as a tree including IDs. The following shows a detailed tree of all USB devices (here using a ThinkPad T480S), their types, speeds, and device classes. This is particularly useful for troubleshooting USB device issues:

$ lsusb -t -v
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        ID 046d:c069 Logitech, Inc. M-U0007 [Corded Mouse M500]
    |__ Port 002: Dev 003, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        ID 046a:c098 CHERRY
    |__ Port 002: Dev 003, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
        ID 046a:c098 CHERRY
    |__ Port 003: Dev 004, If 0, Class=Chip/SmartCard, Driver=usbfs, 12M
        ID 058f:9540 Alcor Micro Corp. AU9540 Smartcard Reader
    |__ Port 005: Dev 005, If 0, Class=Video, Driver=uvcvideo, 480M
        ID 5986:2123 Bison Electronics Inc.
    |__ Port 005: Dev 005, If 1, Class=Video, Driver=uvcvideo, 480M
        ID 5986:2123 Bison Electronics Inc.
    |__ Port 006: Dev 013, If 0, Class=Communications, Driver=cdc_mbim, 480M
        ID 2cb7:0210 Fibocom L830-EB-00 LTE WWAN Modem
    |__ Port 006: Dev 013, If 1, Class=CDC Data, Driver=cdc_mbim, 480M
        ID 2cb7:0210 Fibocom L830-EB-00 LTE WWAN Modem
    |__ Port 006: Dev 013, If 2, Class=Communications, Driver=cdc_acm, 480M
        ID 2cb7:0210 Fibocom L830-EB-00 LTE WWAN Modem
    |__ Port 006: Dev 013, If 3, Class=CDC Data, Driver=cdc_acm, 480M
        ID 2cb7:0210 Fibocom L830-EB-00 LTE WWAN Modem
    |__ Port 007: Dev 007, If 0, Class=Wireless, Driver=btusb, 12M
        ID 8087:0a2b Intel Corp. Bluetooth wireless interface
    |__ Port 007: Dev 007, If 1, Class=Wireless, Driver=btusb, 12M
        ID 8087:0a2b Intel Corp. Bluetooth wireless interface
    |__ Port 008: Dev 008, If 0, Class=Video, Driver=uvcvideo, 480M
        ID 5986:2115 Bison Electronics Inc.
    |__ Port 008: Dev 008, If 1, Class=Video, Driver=uvcvideo, 480M
        ID 5986:2115 Bison Electronics Inc.
    |__ Port 009: Dev 009, If 0, Class=Vendor Specific Class, Driver=[none], 12M
        ID 06cb:009a Synaptics, Inc. Metallica MIS Touch Fingerprint Reader
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 003: Dev 002, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
        ID 0bda:0316 Realtek Semiconductor Corp. Card Reader
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/5p, 480M
        ID 0451:8442 Texas Instruments, Inc.
        |__ Port 001: Dev 003, If 0, Class=Hub, Driver=hub/7p, 480M
            ID 0424:2137 Microchip Technology, Inc. (formerly SMSC)
        |__ Port 003: Dev 005, If 0, Class=Hub, Driver=hub/3p, 480M
            ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
            |__ Port 001: Dev 006, If 0, Class=Vendor Specific Class, Driver=r8152, 480M
                ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
        |__ Port 004: Dev 004, If 0, Class=Human Interface Device, Driver=usbhid, 480M
            ID 0451:82ff Texas Instruments, Inc.
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub

Conclusion

Even though they are simple, both commands offer insights into the system’s configuration and status. Whether you’re troubleshooting, optimizing, or simply curious, these tools provide valuable data that can help you better understand and manage your Linux environment. See you next time when we will have a look at more useful listing and information command line tools and how to use them.

Bus 003 Device 002: ID 2c7c:0313 Quectel Wireless Solutions Co., Ltd. Quectel EM05-G

Therefore, the necessary FCC unlock procedure does not get triggered automatically even though an unlock script for the Quectel EM05-G was already added by Leah Oswald. However, the modem works perfectly fine if you unlock it manually after each reboot:

mmcli -L
sudo mbimcli --device-open-proxy --device="/dev/cdc-wdm0" --quectel-set-radio-state=on

We have opened an upstream issue to fix the problem. If you don’t want to wait so long until a new ModemManager version including the fix arrives on your computer, you can help yourself as follows:

sudo mkdir -p "/etc/ModemManager/fcc-unlock.d/"
sudo chown root:root -R "/etc/ModemManager/"
sudo find "/etc/ModemManager/" -type d -exec chmod 0755 {} +
sudo find "/etc/ModemManager/" -type f -exec chmod 0644 {} +
sudo ln -s -f "/usr/share/ModemManager/fcc-unlock.available.d/2c7c" "/etc/ModemManager/fcc-unlock.d/2c7c:0313"

This creates a symlink to the working FCC unlock script 2c7c for the new USB device ID 2c7c:0313 in your local configuration. Hope that helps.

The clause addresses how future versions of the license will be handled and state that the Free Software Foundation (FSF) may publish new versions of the GPL, which will be similar in spirit to the current version but may include changes to address new legal and technological issues. This also ensures the protection of Free Software from potential missteps by the Free Software Foundation (FSF) itself as, for example, no one could state a valid GPLv4 without copyleft. Some argue that the GPLv3 is fundamentally different from the GPLv2, but a detailed examination shows this is not the case–it is indeed similar in spirit. Just read it for yourself. For our part, we therefore strongly recommend choosing the “or later” option for our own projects.

Learn from past mistakes

Using GPL-2.0-only in the past created significant compatibility issues with other licenses, hindering the integration and distribution of combined works. For example, software licensed under GPL-2.0-only is incompatible with the Apache-2.0 license, preventing the combination of many codebases even today. And some projects had to spend a lot of time and work to change licensing to achieve better license compatibility and reduce integration barriers. These issues can lead to fragmentation and reduced flexibility in the open-source ecosystem.

GPLv2 showed that this adaptability might be necessary, as sticking to GPL-2.0-only did not provide any significant benefit and led to compatibility problems. Therefore, it makes sense to adopt the “or later” option whenever possible. This approach not only preserves the spirit of the license but also provides a safeguard against potential future challenges, much like a well-prepared contingency plan.

Conclusion

The “or later” clause of GPL-3.0-or-later is crucial as it allows the evolution of the license to keep up with changing circumstances, ensuring ongoing protection and freedom for software users and developers. This clause is like a safety net that allows us to adapt to future changes in the legal and technological landscape and to enable cooperation from various parties in the future. Use it.

If you connect the adapter, you’ll get a 10 MiB drive mounted with the following contents, containing a Microsoft Windows Client WinClient.exe (basically a Runtime Environment and wrapper) and the real application JavaClient.jar:

$ ll
total 9,1M
drwxr-xr-x. 2 user user  16K  1. Jan 1970  .
drwxr-x---+ 3 root root   60 30. Apr 19:08 ..
-rw-r--r--. 1 user user 3,7M 30. Dez 2019  JavaClient.jar
-rw-r--r--. 1 user user 2,0M 30. Dez 2019  Vplayer.jar
-rwxr-xr-x. 1 user user 3,5M 30. Dez 2019  WinClient.exe

The “login failed” problem

The JavaClient.jar KVM console is mostly the same as ATEN uses for all their IP KVM stuff. They just bind the service to some high port on localhost and use the hardcoded credentials -u administrator -p password to connect (which is obvious in several places):

Sadly, the Java application is not able to run out-of-the-box on a Fedora 40 Linux with OpenJDK / Java SE. The application will start but sometimes does not even list the device. And if there is a device to connect to, the login will fail:

The JavaClient.jar will not be able to connect with any supported OpenJDK or Azul Zulu Java RE:

# incompatible Java version :-(
$ java -version
openjdk version "17.0.9" 2023-10-17

Solution: Oracle JDK 7

For anybody having the same problem, the following should help:

1. Use a copy of the Oracle JDK 7 (the patch level does not matter) and the application will work without flaws.¹
2. Make sure the current working directory is the USB mount point so the .jar files are in ./.

For example, if you just extract jdk-7u80-linux-x64.tar.gz to /tmp, you can use the application as follows:

tar -xvf jdk-7u80-linux-x64.tar.gz -C /tmp
cd /run/media/user/disk # or wherever the ATEN CV211 storage was mounted
sudo /tmp/jdk1.7.0_80/bin/java -jar ./JavaClient.jar

You can download the Oracle JDK 7 from https://www.oracle.com/de/java/technologies/javase/javase7-archive-downloads.html, but keep in mind to check the license conditions, especially if you are operating in a commercial environment.

If the problem persists…

Sometimes, the “login failed” error occurs even when following the procedure described above (i.e., when using Oracle Java and the current working directory is the mount point). I have not yet been able to determine the exact cause of these (rare) cases. However, this behavior has never occurred during operation but only during the first use. In such cases, a reboot of the hardware by unplugging and reconnecting it to the USB port always helped.

Licenses like the General Public License (GPL) are usually better for the open-source ecosystem than permissive ones like Apache 2 or MIT as they require that any modifications or derivative works are shared, promoting a cycle of continuous contributions and improvements. Enhancements are distributed, benefiting the entire community rather than allowing the exploitation of open source code without giving back (looking at you, Amazon Web Services).

Hypergrowth < Community

Licenses like the GNU Affero General Public License (AGPL) might prevent some corporations from using an open-source project because they do not want to release the source code of their own modifications to it. Sadly, corporate compliance often prohibits the usage of copyleft projects altogether, even if nobody plans to modify anything. Especially the legal departments of large “enterprizy” organizations often prefer software with licenses like MIT as they want it simple and “risk”-free.

In light of license changes, the impression comes to mind that many start-ups use open source not because of freedom but as an argument for adoption in the enterprise ecosystem. They avoid choosing (A)GPLv3 licenses to facilitate easier corporate adoption without generating enough revenue, while being funded by venture capital and without getting contributions back by organization who could easily afford giving back something. Then, after being adopted, they complain.

While the open-source contributions from corporations like HashiCorp are impressive, the overall situation is complex. There’s a reason why Linux (GPL licensed) is still around, growing, and making money for so many while companies behind widespread open source projects often fail financially and burning insane amounts of money. It might work out for individuals and owners when getting bought, but it hurts users and ecosystems who relied on something.

Your SaaS will not compete against AWS or internal IT staff

So don’t be surprised if licenses like MIT attract large corporations and users who don’t care about you or the community, making it difficult to find fair cooperation (including financial resources) with them later. Stick with a real, copyleft license that has less adoption by other enterprises and focus on organic growth with people who care about the project.

Alternatively, be prepared for the consequences that Amazon or other hyperscalers will attract a large number of customers using your product without giving anything back—as you stated that’s OK by using e.g the MIT license.

If you still want to go that route, you must establish another source of income right away. One has to be realistic: Competing with your open-source product’s own SaaS against any SaaS by Amazon or other hyperscalers—or even the well-trained on-premises operations team—will not work out if that’s your only way to make money. Services that support users in operating in-house or enabling paid development (e.g., prioritizing features for a fee) are also possible with open source and are the better choice.