Should Linux packages disclose cloud dependence before installation?

As a Linux desktop user, I want more than a license label before installing an application. The package page should say plainly whether core features work offline, whether an account is required, what data leaves the machine, and whether my work can be exported if the service disappears.

This matters even with Flatpak. Its sandbox and permission metadata can show that network access is requested, but that alone does not explain the application’s actual service dependency or whether its data is portable. Locally stored configuration is not the same as locally usable content. A self-hosted alternative may offer a better ownership story, but only if migration and backups are genuinely practical.

I’m not making a general anti-cloud argument. I’m saying portability and dependency disclosures may matter more to users than simply calling software “open source.” Should this become a packaging standard, a distro policy, or just a community convention? Concrete examples or counterarguments welcome.

The distinction between capability and behavior is important. A requested network permission does not prove what gets transmitted, so the metadata should separate declared access from documented use. Even a modest standard vocabulary would be more useful than vague “cloud-enabled” wording.

I’d want this exposed at install time, not buried in a project wiki. “Account required,” “offline mode,” and “export format” are operational properties. They belong beside dependencies and permissions, though the answers may need to be project-supplied rather than inferred by the package manager.

Users often choose convenience knowingly. The real failure is surprise: installing a desktop-looking app and discovering later that the meaningful data lives behind a login. A clear disclosure could improve product trust without pretending every cloud feature is a defect.

Network permission is a useful signal, but not a privacy verdict. I’d also want the destination described at a useful level and the option to inspect or change telemetry settings. Otherwise the badge becomes security theater with nicer typography.

Package managers already struggle to keep basic descriptions accurate. Still, that is an argument for a small required vocabulary, not for silence. Four honest fields beat another paragraph of marketing copy.

Exportability can be harder than it sounds. An application may export files while leaving comments, identities, history, or sharing metadata behind. I support disclosure, but not a single green “portable” stamp that hides those distinctions.

For small developers, a mandatory distro policy could become paperwork nobody maintains. A community convention with machine-readable fields might be a gentler start, provided stores actually display missing information instead of treating blanks as reassuring.

I’d make the disclosure layered: a short install-time summary, then links to the project’s detailed account, data, and export documentation. That preserves a clean interface while giving privacy-minded users something testable rather than a slogan.