jblwps's comments

> I like the AGPL, but I would like an extra step that forces you to distribute code even you have not modified it.

This is...already the case. The distributor is the one who is bound to supply the source code--"upstream" isn't implicated in the license.

Nitpick: SQLite is public domain[0], which is not open source[1].

[0] https://sqlite.org/purchase/license

[1] https://opensource.org/node/878

> What I don't like about changes like this is that it makes it impossible to reuse any Grafana/Loki/Tempo pieces or libraries in any more permissively-licensed code

They're not making everything AGPL and seem to be aware of the kind of thing you're talking about. From TFA (emphasis mine):

> Going forward, we will be relicensing our core open source projects (Grafana, Grafana Loki, and Grafana Tempo) from the Apache License 2.0 to the Affero General Public License (AGPL) v3. Plugins, agents, and certain libraries will remain Apache-licensed. You can find information in GitHub about what is being relicensed for Grafana, Loki, and Tempo.

Doesn't a "service" handle a domain?

Aren't you just describing traditional RPC calls? Many tools for this: DBus on Linux, Microsoft RCP on Windows, and more that I'm not aware of.

If you've only got a basic IPC system (say, Unix domain sockets), then you could stream a standard seriaization format across them (MessagePack, Protobuf, etc.).

To your idea of gracefully moving to network-distributed system: If nothing else, couldn't you just actually start with gRPC and connect to localhost?

Is there something I'm missing?

Ah, gotcha. There are hosted Nextcloud solutions out there if you can't run your own instance. I've never used them and can't speak to how non-technical the overall process is (I'd guess it varies by provider).

Nextcloud's website does have a page on getting ("free"?) accounts from providers. It took me a hot second to find the "change provider" link, but that allows you to see a bunch of options.

https://nextcloud.com/signup/

Civil disobedience isn't about avoiding the consequences of that disobedience; it's about doing the right thing even though it's illegal and requires punishment. If your concept of justice can account for civil disobedience like that, that is.

That is to say, if e.g. Snowden's actions were civil disobedience, it's not incoherent to say both that:

1. He was right to leak the info, and

2. He need not be pardoned in the name of justice.

If ES is the sole copyright holder, they can license it to whomever they wish under whatever license they wish. IANAL, but it seems perfectly coherent to me that they can say "If you build the software this way, we release it to you under X license. If you build it that way, we release it under Y license."

What do you need in a calendar service that you can't find elsewhere?

I use the Calendar app with NextCloud[0] for a CalDAV server + calendar web interface. It's fully-featured as far as I can tell. I use its CalDAV functionality to sync to my Android phone using DAVx^5[1], which integrates the calendars natively so that you can use whatever calendar app you want on your phone (I use Etar[2]).

[0] https://apps.nextcloud.com/apps/calendar

[1] https://www.davx5.com/

[2] https://github.com/Etar-Group/Etar-Calendar

IIRC, The GPL incompatibility prohibits distribution of linked binaries. Since the CDDL-licensed ZFS kernel modules have to be linked against the kernel, those compiled modules can't be distributed.

Hence, Canonical (or anyone else trying to re-release under the CDDL) cannot distribute binaries of the kernel modules.

However, you are fully allowed to compile and link the two on your own. This is why the alternative to binary distribution is compiling yourself with the help of DKMS.

Graphiti always seemed like a cool project in this vein.

https://www.graphiti.dev/guides/

You don't send the whole pool--you send the datasets (ZFS filesystems) that you're concerned with.

What net benefits would you see that having? If I'm allowed to assume that you wouldn't use TLS because of PKI management concerns, I have a hard time seeing how using WireGuard in the large wouldn't have the same problems--you still have to build some kind of management platform on top that verifies host authenticity (ultimately including revocations and more). That is to say, WireGuard in the large will surely (right?) need supporting PKI.

> tank mass scales with a lower exponent than tank volume

I'm confused here. How are they not both cubic?

So aside from the additional cost, is there any catch in using it instead of palm oil or tallow, provided you balance it out with a moisturizer like olive oil?

Because you can reproduce that binary bit-for-bit to confirm its corresponding source code. That's the point of a reproducible build.

https://en.wikipedia.org/wiki/Reproducible_builds

As greysonp points out, yes; Signal has had reproducible builds since March 2016. So we can prove that those published binaries do not have backdoors insofar as we can prove that the corresponding source code does not have backdoors.

In what sense would it be a gateway? Because of the possibility of data exfiltration?

> What incentive do doctors and patients have to keep vending the data to Google at that point?

Inertia, if nothing else. Moving platforms, especially in a highly-regulated industry, is no small thing.

I'm running Fedora 31 on my C710 too as my daily driver. It's a surprisingly good experience! You've definitely got to manage your CPU expectations.