JoeyJoeJoeJr

Yeah, gadgetbtidge was my first thought as well. I've never used it, but in theory it would allow you to control devices without the proprietary app. See the link below for supported devices:

https://gadgetbridge.org/

This is not true. The GPL does not force anyone to give up their code, unless they distribute it. From the "Definitions" section:

A “covered work” means either the unmodified Program or a work based on the Program.

And

To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

And from the "Basic Permissions" section:

You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.

Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.

Under the terms of the GPL, the owner can revoke your access for any violation of the license, and at their discretion, they can make that revocation permanent. The GPL does not guarantee equal treatment - an author can punish one person harshly, and another not at all. It still comes down to the author. Yes, there is a small barrier in that you have to find a violation, but if you look hard enough, you can probably find a violation - especially in large projects using libraries distributed under multiple different licenses.

the FUTO license can revoke the license just because Rossmann says so. It is a mechanism to keep Rossmann the owner of everything that spawns from the code of the app and being the only one who can make money from it. If Rossmann doesn’t like someone who wants to redistributes the app, he can immediately revoke their license.

Quoting from my comment here:

They’re just trying to prevent a company from making money off the free labor of the authors. It’s the same issue that has plagued other projects, such as Elastic Search, which ultimately led it to change licenses. And it’s why MariaDB created the BSL, which they and other companies have adopted (very similar terms here - source free to use for non-commercial purposes).

If the hangup is specifically that they can change the terms, or revoke rights altogether, the other licenses also allow for that - that’s how these projects are changing licenses at all, and it happens quite a bit. I have personally contributed to projects that were GPL, and then went Apache.

only one who can make money from it

This is not true. You can make and sell plugins, you could offer support, you could sell your services as a code auditor/security expert... anything other than selling the code you didn't write. On top of that, in practice, this isn't different from anything else - most contributors to open source projects don't profit from them, unless they work for the organization that owns the project. When the non-owners do profit, it's usually big companies and results in the license changes I've described above.

A user that doesn't care about licensing is typically called a pirate.

The license literally does not govern the usage of the app. Here's the first line:

This license grants you the rights, and only the rights, set out below in respect of the source code provided.

Read the entire license (it's only 32 lines), and you won't find anything related to using the product, only the code.

This license should only be scary to developers, who might build on the project, and then have it taken away. As a user, your concerns are different, and this license vs the GPL, or any other FOSS, or even source available license, are more-or-less the same. As a user, your primary concerns are probably going to be related to the security and privacy related aspects, and as long as you have access to the source, you can audit it and ensure it meets your standards. If they choose to revoke access to the code, as a user, you're in the same boat you described - don't take new versions because you can't audit them, but you can stay on the old version. They can't revoke that access with this license, because again, this license literally does not govern usage of the product.

repackaging is a fundamental software freedom

Re-packaging is fine. You just can't sell it.

They're just trying to prevent a company from making money off the free labor of the authors. It's the same issue that has plagued other projects, such as Elastic Search, which ultimately led it to change licenses. And it's why MariaDB created the BSL, which they and other companies have adopted (very similar terms here - source free to use for non-commercial purposes).

If the hangup is specifically that they can change the terms, or revoke rights altogether, the other licenses also allow for that - that's how these projects are changing licenses at all, and it happens quite a bit. I have personally contributed to projects that were GPL, and then went Apache.

As a developer, I could certainly see not wanting to build on the project while the license is what it is, but as a user, I don't think this license is bad. I also think this is likely temporary (hence the name - "FUTO Temporary License"), and the tight grip on the rights are probably just so they can re-license later (hopefully to something a little more permissive). I could definitely be wrong, but given Louis's track record of fighting for things like right-to-repair, I'd give him the benefit of the doubt here. He could certainly prove me wrong though, if they do anything shady. Feel free to rub it in my face if he ever does.

Edit:

Just for proof, here's the specific line that says you can re-package and redistribute, from section 2, line 2:

2. You may provide the code to anyone else and publish excerpts of it for the purposes of review, compilation and non-commercial distribution, provided that when you do so you make any recipient of the code aware of the terms of this license, they must agree to be bound by the terms of this license and you must attribute the code to the provider.

As a user, or a developer? As a user, I don't think it matters. As a developer, I think other licenses have similar carve outs, e.g. the GPLv3 section 8 is a whole section on "termination" - the copyright holder can revoke your rights for any ticky-tack violation of the license, and at their discretion, the revocation can be permanent.

Additionally, even with other FOSS licenses, the copyright holder can re-license the project. If I had to guess, this ability to re-license is probably why it is written as it is - the license is called the "FUTO Temporary License." I would assume it's written as is so they can re-license later, and they just want to cover their bases now. It's entirely possible that's incorrect, and they'll clamp down. I'm personally willing to give them the benefit of the doubt (though having said that, I have no intention of buying, using, or contributing to this project).

According to the license, it is better than source available. You can modify and redistribute, you just can't sell it. Other than that caveat, as far as I can tell, your rights are basically the same as with other open source licenses. (Feel free to correct me if I've missed something.)

Is there a particular aspect of the FUTO license you are concerned with? The code is publicly available, and the license seems to allow you to do anything you want, except sell the code. Other than not allowing you to re-package and sell the code, it seems like your rights are very similar to anything distributed via the GPL.

Am I missing something?

If you're ok with Jitsi, and you already use Brave, note that Jitsi is baked in. See https://brave.com/talk/ and check the "Who provides the Brave Talk service?" question:

The Brave Talk service is provided in partnership with 8x8. And the service is built on the open-source Jitsi platform.

(Note that 8x8 owns Jitsi)

See also the "How are my calls with Brave Talk encrypted?" question:

To start, all video and audio data transferred through Brave Talk is encrypted via transport layer encryption. This is similar to how many websites use HTTPS to ensure your traffic can’t be captured on public networks (e.g. coffee shop WiFi).

The video and audio from your call are transmitted to other participants with the help of a Video Bridge server that’s run by Brave’s partner, 8x8. When you enable Video Bridge Encryption in Security Options, your browser exchanges keys with other call participants, and these keys are used to encrypt the video and audio streams. Only people with keys can see your calls. Assuming honest but curious behavior, neither Brave nor its partner, 8x8, have this key by default.

However, there are some important limits to Video Bridge Encryption. If you want to include a phone participant in your call, have more than 20 participants, or want to include users with incompatible browsers (Safari, most iOS browsers, and browsers based on Chromium version 83 or below), this encryption setting will not work. If you record a call, 8x8’s servers will receive a set of keys to decrypt the video/audio stream in order to process and store that recording. Brave will continue to improve Brave Talk’s encryption properties and work to remove some of these limitations.

Read a more detailed description of Jitsi encryption (the open source basis for Brave Talk).

I noted in another comment that SearXNG can't do anything about the trackers that your browser can't do, and solving this at the browser level is a much better solution, because it protects you everywhere, rather than just on the search engine.

Routing over Tor is similar. Yes, you can route the search from your SearXNG instance to Google (or whatever upstream engine) over Tor, and hide your identity from Google. But then you click a link, and your IP connects to the IP of whatever site the results link to, and your ISP sees that. Knowing where you land can tell your ISP a lot about what you searched for. And the site you connected to knows your IP, so they get even more information - they know every action you took on the site, and everything you viewed. If you want to protect all of that, you should just use Tor on your computer, and protect every connection.

This is the same argument for using Signal vs WhatsApp - yes, in WhatsApp the conversation may be E2E encrypted, but the metadata about who you're chatting with, for how long, etc is all still very valuable to Meta.

To reiterate/clarify what I've said elsewhere, I'm not making the case that people shouldn't use SearXNG at all, only that their privacy claims are overstated, and if your goal is privacy, all the levels of security you would apply to SearXNG should be applied at your device level: Use a browser/extension to block trackers, use Tor to protect all your traffic, etc.

It's possible to hit issues, especially if different distros are using different major versions of desktop environments or applications, but in practice, I don't think it's something that really needs to be worried about.

If you were to upgrade/fresh install, and copy your home folder over, you'd have the same experience - it's not much safer than sharing the home partition, except that you're (hopefully) doing that less. You could still easily go from distro A using version 2 of something, to distro B using version 3, and then decide you don't like it and try to roll back to distro A. If in the process your config was upgraded in place (as opposed to a new, versioned config being made*), you could have problems rolling back.

With configs, you can usually just delete them (or, less destructively, rename them, in case you decide you want them back), and let the application make a new default one for you. With other files (e.g. databases), you might be in more trouble. But a good application will tell you before doing an upgrade like that, and give you a chance to backup the original before upgrading in place. When asked, it's probably a good idea to take a backup (and not just for this distro hoping case).

*For any developers reading this, this is the correct way to upgrade a config. Don't be destructive. Don't upgrade in place. Make a copy, upgrade the copy, and include a version in the file name. You can always tell the user, so they can remove the file if they want, but let them make the choice. If you can't (e.g. the database scenario, which could be large), tell the user before doing anything, so they can choose whether or not to backup.

Can you describe your use case more?

I don't think format matters - if you've got multiple processes writing simultaneously, you'll have a potential for corruption. What you want is a lock file. Basically, you just create a separate file called something like my process.lock. When a process wants to write to the other file, you check if the lock file exists - if yes, wait until it doesn't; if no, create it. In the lock file, store just the process id of the file that has the lock, so you can also add logic to check if the process exists (if it doesn't, it probably died - you may have to check the file you're writing to for corruption/recover). When done writing, delete the file to release the lock.

See https://en.wikipedia.org/wiki/File_locking, and specifically the section on lock files.

This is a common enough pattern there are probably libraries to handle a lot of the logic for you, though it's also simple enough to handle yourself.

You mean with config files stored in your home directory? Or something else?