I didn't see your reply until just now, but the AGPL does not require you to redistribute source code to network users if it is not modified. The following stack exchange question has quotes from the fsf
> 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.
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?
When you start with gRPC and connect to localhost, usually the worst that can happen with a RPC call is that the process crashes, and your RPC call eventually times out.
But other than that everything else seems to work as a local function call.
Now when you move the server into another computer, maybe it didn't crash, it was just a network hiccup and now you are getting a message back that the calling process is no longer waiting, or you do two asynchronous calls, but due to the network latency and packet distribution, they get processed out of order.
Or eventually one server is not enough for the load, and you decide to add another one, so you get some kind of load mechanism in place, but also need to take care for unprocessed messages that one of the nodes took responsibility over, and so forth.
There is a reason why there are so many CS books and papers on distributed systems.
Using them as mitigation for teams that don't understand how to write modular code, only escalates the problem, you move from spaghetti calls in process, to spaghetti RPC calls and having to handle network failures in the process.
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.
Luckily for you this is exactly how it works in these instances. Those who do right action suffer punishment. While those who did wrong get a free pass to continue doing such.
And I do believe this is inconsistent if you believe that justice has anything to do with right and wrong actions.
Your argument is:
1. There are right and wrong actions.
2. Justice does not decide or even attempt at determining right and wrong.
3. Therefore doing something right or wrong has no bearing on the outcome of our justice system.
As an individual, what your are saying is important and I agree. We have to call upon ourselves to do the right thing in spite of the consequences. But often times civil disobedience seeks to change the injustice of the current system and if that system never changes or adapts as a result then the outcome will always be the same. This may have happened in the case with Snowden (though we can still correct it) but it has not been the same throughout history. I’m very glad that we did not simply exile all our civil rights leaders with no thought given toward bringing a greater sense of fairness to our judicial systems.
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]).
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.
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.
With the two licenses incompatibility, the GPL is the one that would be violated, not the CDDL. So any Linux contributor would have the right to sue, including Oracle who presumably have committed to Linux. However, Oracle owning ZFS gives them no extra grounds to sue over OpenZFS.
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.