Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

https://docs.flathub.org/docs/for-app-authors/requirements says,

> Windows application submissions that are using Wine or any submissions that aren't native to Linux desktop and is using some emulation or translation layer will only be accepted if they are submitted officially by upstream with the intention of maintaining it in official capacity.

Although, I am curious why; they don't seem to have a general problem with unofficial packages, so I'm not sure why a translation layer makes any difference. It doesn't seem different than happening to use any other runtime (ex. nothing is said about Java or .net).

View on HN

Probably because it's implicitly pirated. No one is sharing windows freeware this way, because there's no demand for it. It'll be MS Office, Photoshop, CAD, etc. -- stuff for which there's still no good OSS alternative, and for which the barrier to entry is high.

It would take a large organization with enough connections to cut through this. You'd probably need to cut a deal so you could distribute their software, and you'd need to provide a mechanism for users to be able to make purchases. Even then, there are various licensing challenges, because you would be distributing the same install, so thousands (or millions) of "installs" would effectively have the same serial or license number.

It's nontrivial, but the basic idea is straightforward and doable. The challenge is how windows software is distributed and licensed, not anything technical.

I am just thinking out loud. Wouldn't it be better then to just share the reproducible recipes similar to sharing Dockerfiles? For wine, specifically, it could be similar to just using FROM wine-1.23. As long as we keep the recipes maintained and "pinned" to their old dependencies.

I think this could work as a translation layer because containers already abstract away everything on syscall level.

There must be just a GUI for that, which can create multiple sandboxes easily, per application, and remember what you configured and installed there (and add it to the Winefile).

In regards to the sharing serials problem: You can easily diff the .reg file that wine adds there and if anything pops out in \\software, you can assume this is a custom field and offer it as an environment variable for the container?

This is similar to what Bottles [1] does, it uses a YAML file to describe the installation instructions for a Windows app here's an example: [2].

[1] https://usebottles.com [2] https://github.com/bottlesdevs/programs/blob/main/Games%2Fit...

> Probably because it's implicitly pirated.

It doesn't have to be. Old software is cheap, even shrink wrapped ("new old stock")

They do cover that in https://docs.flathub.org/docs/for-app-authors/requirements#l... , but I don't buy it in the general case because Windows isn't synonymous with proprietary isn't synonymous with non-redistributable licenses. Sure, I doubt there's a legal way to ship Microsoft Office on flathub, but there are plenty of shareware programs that I think would be fine (though IANAL, ofc) right up to FOSS that happens to target Windows. For instance, Notepad++ is GPLv3[0] and WINE platinum rating[1]; why shouldn't it be on flathub?

[0] https://github.com/notepad-plus-plus/notepad-plus-plus/blob/... [1] https://appdb.winehq.org/objectManager.php?sClass=applicatio...

I don’t think it’s necessarily that either. They probably just want some guarantees that the app will keep working, instead of someone submitting 100s of wine apps and having them break eventually.

They're just trying to prioritize linux applications, without preventing developers who want to support linux through wine from doing so.

The key difference is that applications ran under wine will always have some subtle quirks and misbehaviors that break the usability, that can be worked around by the dev when given the chance to.

Reply on news.ycombinator.com