Yes, but the loophole I was mentioning allows companies to not release the code even when it's GPL, that's why I was mentioning the AGPL (which is different from the LGPL).
Ferk
Nice! It also seems to be under discussion on lemmy's github here: https://github.com/LemmyNet/lemmy/issues/818
I think many hobby developers also see "hobby" developing as part of their career, so they would happily try and have their hobby align with future employment possibilities. Since companies avoid GPL, those devs will rather choose a license that is more attractive to those potential employers when they see their portfolio.
It does not have to be something mandatory...
I mean, there could be some form of "metacommunities", something like being able to group multiple communities together in a "view" that shows them to you visually as if they were a single community despite being separated. Bonus points if everyone can make their own custom groupings (but others can subscribe to them.. so there can be some community-managed groupings).
In theory you could have multiple "metacommunities" for the same topic still.. but at least they could be sharing the same posts if they share communities. I feel grouping like this would be helpful because small communities feel even smaller when they are split.
I think reddit has something similar to that, multireddits or something I think they are called.
That's the problem: the protocol pretty much requires explicit relationships between instances since they are forced to proxy/cache each other's content. I think there's too much responsibility on the instance... I feel it would be a moderation nightmare to host an instance with truly open federation (potentially even result in legal trouble!). So I totally understand why so many instances want to be conservative on who they federate with..
The ideal situation would be to be to be able to interact with third party instances directly (at least when the 2 instances don't wanna agree on caching each other's content), instead of having to use your home instance as proxy/cache.. so the home instance would not need to have the burden (both legally and in terms of hosting resources) and it would just act as a way to identify the user, not necessarily as the primary content provider.
To me, the problem is not really so much about "locking people in" (it's also unclear what you mean by that, if they were already using that ecosystem before using uutils aren't they already locked in?)
To me, the problem is how the MIT removes legal protections when it comes to ensuring accountability to changes in the source.. how can I be sure that the version of uutils shipped with "X Corp OS" has not had some special sauce added-in for increased tracking, AI magic, backdoor or "security" reasons? They are perfectly free to make changes without any public audit or having to tell their users what their own machine is doing anymore.
If you are using a GPL library that is statically linked to code with a different license the result is one binary that has inside both GPL and other license code, which would not be allowed under the GPL terms, because it requires that the binaries that use the source code must have their source code available in full (including other source and modifications that are part of the same binary).
The only case in which you don't need to provide the source for GPL software is if you don't actually distribute the binary to customers.. private binaries do not have to be published with their source, as long as you never made the binaries public and never gave it to anyone else. Only when you give it to someone you need to provide the code.
This allows for a loophole in which if you are providing a service, then you can run the software privately in your private server without sharing the source code to the clients using the service, since they do not really run the server program although they indirectly benefit from its results. This is why the AGPL was created, since it has a clause to force also those offering services to make the source of the server available to the users of the service.
But, whichever command I put in
autostart.sh
will run as if I run in terminal with the&
sign. E.g:dunst &
to run in the background.
Well, only if it's one single command, if you have multiple commands inside of the script, they will still run sequentially (the next command will only run after the previous one completely closes) unless you add &
to them as well.
The difference is that dwm itself will not have to wait for the autostart.sh
to complete before launching itself (thanks to it being run in the background with &
)
However, autostart_blocking.sh
(which isn't run with a &
) will stop dwm from fully launching until the script completes.. I guess this is useful if you need certain things to be set up before dwm actually starts.. but it would potentially add a delay on dwm startup.
Potentially, using some sort of predictable hashing to get the same id across instances might also help in the detection of duplicate links so that they can be aggregated in a single place (sort of what was suggested at point 2 here).
I fear this could be too much of a breaking change though.
Is that really what people mean by it being easier?
In Bluesky you are asked to choose a "Hosting provider" when you sign up.. it;'s just that it's set by default to Bluesky and actually trying to set something else makes the experience of signing in much harder.... so actually I feel Bluesky is the one for which the process is harder, if anything.
I can't even get a direct url to the sign up page of https://bsky.app/ ..but I can link https://lemmy.ml/signup
Nobody is being forced to seek an alternative Lemmy instance to whichever they found first. In the same way that nobody in Bluesky has to use Bluesky as their hosting provider or even choose to self host their PDS.