I would like to add a project to GitHub for a WinBox Flatpak, but would not until I understand any licensing arrangements associated with WinBox.

I've wonder this myself. They have https://mikrotik.com/downloadterms.html . Not a lawyer but comes down to if winbox is encompassed by the "MIKROTIK ROUTEROS SOFTWARE ROUTER SYSTEM" since they do say:

You may not:
permit other individuals to use the SOFTWARE except under the terms listed in Article 1 "Grant of License" above;
modify, translate, reverse engineer, decompile, disassemble (except to the extent applicable laws specifically prohibit such restriction), or create derivative works based on the Software;
copy the Software; or
remove any proprietary notices or labels on the Software.

And, I do know @normis chastises people for using "third-party packages", but they seem to allow the brew package with winbox for Mac on GitHub.

Personally, the better way would be if the snap package were to have the needed wine bits BUT then downloaded winbox from Mikrotik as part of some post-install task. So winbox itself wouldn't be in a package repo. This is a safer approach since theoretically the post-install could verify Mikrotik's SSL cert when downloading winbox. The brew package for winbox just includes winbox, which works but I'd actually prefer if it downloaded it from Mikrotik not GitHub.

Why Mikrotik didn't long ago just package wine with winbox for Linux and Mac (via MacPort and/or brew) themselves I have no idea. Instead, rumors are there is some future multi-platform client coming. So they let Linux and Mac users suffer with which version of wine works in the meanwhile. While wine being bundle in a distro package (e.g. like the brew one) would solve 80+% of the need for some "Multiplatform" client IMO.

Thanks,

The approach I was planning does not include any binaries, only scripts and manifest to build the actual flatpak yourself. I find the included Tahoe font from WineHQ does not exhibit proper kerning so the build script removes it (the file system is R/O at runtime). I spent time going through traces and WinBox seems to exclusively select Tahoe with 2 specific geometries.

After you build the flatpak the first execution downloads and installs WinBox, checks the available replacement fonts and provides a dialog box to choose one. The build script allows you to add your own fonts e.g. a GitHub repo where the Segoe font has been uploaded etc..

Not sure if this fits in with the established policy.

IANAL and don't work for Mikrotik. But I'm 100% supportive of your efforts. If a package/snap cause a download from mikrotik.com when end-user installs, that's not redistribution. And it's redistribution where things get tricky legally.

No policy AFAIK, but various packaging schemes of winbox+wine has come up before, mainly on Mac-side. I know @normis from Mikrotik is NOT a "fan" of folks using packages in general e.g. "dangerous", "unsafe", etc. And to some extend that's right – a lot people "just guess" at Linux commands to get things working e.g. cut-and-paste from here/reddit/google/etc. that sound similar. And downloads with intermediate steps make it's hard to know if something isn't nefarious in the chain.

Problem is there is a narrow, but generally known paths, to get wine to work on Linux – like fonts. And while it better & safer if Mikrotik did this. Googling how to fix wine's font for a particular distro could end in same "unsafe guessing" at commands problem anyway.

Perhaps email support@mikrotik.com if you're concerned.

Why not use the RouterOS API and build something custom that way?
Linux will soon have a native "Winbox", so no need to spend time on that, but for a custom tool, use the API.

OP asks/wants to create a flatpak for winbox. OP does not want to build some completely custom software application from scratch - using the ROS API.

Linux will soon have a native "Winbox"

Some folks use packaging system to install ALL their software from repos & want their distro-specific "Application" icon for it. I doubt the manual download part is going to change with some "native Winbox". We'll see, soon.

Indeed, I refuse to install anything manually. So I use AUR to install Winbox as well. The PKG build downloads winbox.exe so I see no problem with doing alike for flatpak. See https://aur.archlinux.org/packages/winbox

I am not familiar with Flatpak, but it seems it is a distrbution mechanism. Winbox can be distributed in any way you please, if there is no internal modification needed. But I guess it would be smarter to wait until native Linux Winbox and then set it up for this distribution method, it will be much easier, since there will be no wine involved

+1

Easter is around the corner...

native Linux Winbox

Does this also mean a new Windows Winbox application?

Will there be a native version for macOS as well?

OT - Btw, please add support to
- detach child windows from the MDI parent area
- move the "Windows" menu (the one with all active windows) to the title bar, or make the location configurable.

Easter is around the corner...

... and easter monday seems like the perfect date for the official announcement ...

indeed.

Linux will soon have a native "Winbox"

Linbox?

After futzing on and off for the last 2 weeks sorting out various issues, I pushed the code to GitHub (https://github.com/hfxdanc/winbox.git). I have tested and solved the issues that bothered me, plus put up some documentation etc. to remind me. It's all in standard shell script, nothing fancy.

Perhaps someone will find it useful.