How to Cite Open-Source Tools in a Roundup Fairly

A roundup of open-source tools is only as good as its citations. A roundup that lists a tool's name, links to its homepage, and says "this is great" is not a roundup; it is a list. A real roundup verifies each tool against a minimum bar and cites what it found. This guide is for writers, researchers, and students who want to cite open-source tools fairly — in a blog post, a comparison page, a school paper, or a recommendation to a colleague. The bar proposed here is low enough to be practical and high enough to be useful. For related reading, see competing with Ditto without pretending to be Ditto, donations, stores, and keeping a free app alive, what local-first software means for clipboard apps, and why some clipboard apps will never sync.

The minimum bar

Three checks, done before a tool is cited:

1. Last commit. When was the last meaningful change to the source? A tool with a commit in the last 90 days is alive. A tool with no commits in a year is quiet, and the citation should say so.
2. License. Is the source under an OSI-approved license? A tool with no license is "all rights reserved" by default and is not open-source, regardless of where the code lives. A tool with a custom license should be read carefully.
3. Working install. Does the tool actually install and run on a current OS? A tool whose latest release fails to install is a tool that cannot be recommended, no matter how good the source looks.

Each check takes five minutes. Together they take fifteen, which is the minimum time worth spending on a tool before recommending it to others.

Check 1: last commit

The "last commit" check answers the question "is this project alive?" The check is not "is the maintainer active on social media" or "does the project have a website." The check is the source repository's commit history.

How to check

• GitHub. Open the repository. The commit list is on the main page. Look at the date of the most recent commit on the default branch.
• GitLab, Codeberg, Bitbucket. Same pattern. Open the repository, look at the commit list.
• Self-hosted. Find the repository URL in the project's README, then look at the commit list.

What to write

Cite the date and the commit. Example:

Ditto's most recent commit on the default branch is from <date>, as of <access date>.

Do not write "active" or "inactive" without a date. The date is the citation; the adjective is the interpretation.

What "last commit" does not tell you

A recent commit does not mean the project is healthy. A maintainer can push a one-line README fix every 89 days to make the project look alive. The complement is to look at the project's releases: a project with a release in the last 6 months is healthier than a project with a commit but no release in 2 years.

For a deeper health check, look at:

• Issue tracker activity. Are issues being responded to? Are PRs being reviewed?
• Contributor count. A project with one contributor is a bus-factor risk. See bus factor: what if a solo app goes quiet.
• Release cadence. Regular releases (monthly, quarterly) are healthier than irregular ones.

For a roundup, the minimum is the last commit date and the last release date. The deeper checks are for tools the roundup recommends highly.

Check 2: license

The "license" check answers the question "is this actually open-source?" The check is the LICENSE file in the repository root, cross-referenced against the OSI list of approved licenses.

How to check

• Look for a LICENSE file. GitHub, GitLab, and Codeberg all show this on the repository page.
• Look for a license header in the README. Some projects state the license in the README rather than a separate file.
• Look for an SPDX identifier. Modern projects often include an SPDX-License-Identifier: line in source files.
• Cross-reference against the OSI list. The Open Source Initiative maintains the canonical list of approved licenses.

What to write

Cite the license and the source. Example:

Ditto is licensed under GPL-3.0, per the LICENSE file in its repository at <URL>, accessed <date>.

If the license is unusual or custom, say so:

EcoPaste is licensed under MulanPSL-2.0, per the LICENSE file. MulanPSL-2.0 is OSI-approved but unusual outside Chinese-origin projects; verify compatibility before forking.

What "license" does not tell you

A license does not tell you whether the code is any good, whether the maintainer is responsive, or whether the tool will still exist in five years. It tells you whether you have the legal right to use, modify, and distribute the code, and on what terms. That is the only question the license answers, but it is a necessary question.

For tools with no license file, the citation should be direct:

The repository at <URL> has no LICENSE file. Under default copyright, the code is "all rights reserved" and is not open-source, regardless of public availability.

This is uncomfortable to write, but it is honest. Citing a tool as "open-source" when it has no license is a factual error.

For more on the audit angle, see Apache-2.0 clipboard tools you can actually audit and open source vs closed clipboard apps.

Check 3: working install

The "working install" check answers the question "does this tool actually run?" The check is to install it on a current OS and confirm it works.

How to check

• Download the latest release. Use the official release channel (GitHub Releases, the project's website, the Microsoft Store, etc.).
• Install on a current OS. For Windows tools, install on Windows 11. For cross-platform tools, install on at least one platform.
• Run the basic workflow. For a clipboard manager: copy something, open the manager, confirm the item is there.
• Note any failures. If the install fails, the tool does not run, or the basic workflow does not work, note it.

What to write

Cite the version, the OS, and the result. Example:

Installed Ditto version <X> on Windows 11 <build>, accessed <date>. Install completed without errors. Basic copy-and-view workflow functioned as expected.

If the install failed:

Installed <tool> version <X> on Windows 11 <build>, accessed <date>. Install failed with error <message>. The tool was not evaluated further.

What "working install" does not tell you

A working install does not tell you whether the tool is secure, whether it has telemetry, or whether it handles edge cases. It tells you the tool runs. The deeper checks — telemetry, security, edge cases — are for tools the roundup recommends. See telemetry-free desktop utilities: how to check for the telemetry check, and reading an Electron app's IPC surface as a user for the security check.

Citing features honestly

Beyond the minimum bar, a roundup should cite features honestly. The pattern:

• State the feature as the project documents it. "Ditto's README states that it supports <feature>."
• Verify the feature if you can. "Verified on Windows 11: the feature works as documented."
• Note gaps between marketing and reality. "The README mentions <feature>, but the settings UI for it was not present in version <X>."

This is slower than copying the project's feature list, but it is the difference between a roundup and a reblog.

A worked example

A fair citation for Ditto in a 2026 roundup:

Ditto is a Windows clipboard manager, GPL-3.0, written in C++ against the Win32 API and MFC. As of <access date>, the most recent commit on the default branch is from <commit date>, and the most recent release is version <X> from <release date>. Installed on Windows 11 <build>; basic copy-and-view workflow functioned as documented. Ditto's data store is a SQLite file in %APPDATA%\Ditto\, per the project's documentation.

This citation tells the reader:

• What the tool is.
• What license it is under.
• When it was last updated.
• Whether the latest release installs and runs.
• Where the data lives.

That is the minimum a reader needs to evaluate the citation. Anything less is a name and a link.

What to do when you cannot verify

If a check fails — the repository is gone, the install fails, the license is unclear — the honest response is to say so, not to skip the check. A roundup that says "we could not verify X" is more useful than a roundup that pretends X was verified.

For tools that are widely cited but whose source has moved or been deleted, the citation should note the current state:

<Tool>'s source repository at <URL> returned 404 as of <access date>. The tool's last known release is version <X> from <date>, available at <mirror URL>. The project's current status is unclear.

This is uncomfortable to write, especially for a tool the roundup wants to recommend. It is also the only honest citation.

The minimum bar, restated

For each tool in a roundup:

1. Last commit date, cited with the repository URL and access date.
2. License, cited with the LICENSE file URL and the OSI status.
3. Working install, cited with the version, OS, and result.

Three checks, fifteen minutes per tool. Anything less is a list, not a roundup. For more on the broader evaluation question, see how to evaluate a public-beta desktop app and questions to ask before installing a clipboard app.

Related reading

• Donations, Stores, and Keeping a Free App Alive
• Translating a Desktop Utility Into 30 Languages
• What Local-First Software Means for Clipboard Apps
• How to Enable Clipboard History in Windows 11

Sources

• Open Source Initiative — Licenses by name — canonical list of OSI-approved licenses, for verifying a project's license is real
• GitHub Docs — Viewing repository activity — official documentation for checking a repository's commit history and release cadence
• SPDX — License list — canonical list of SPDX license identifiers, for verifying license headers in source files
• Choose a License — How to choose — community reference for picking and reading open-source licenses
• CHAOSS — Open-source project health metrics — community reference for the deeper health metrics (issue response, contributor count, release cadence) beyond the minimum bar

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support