It absolutely could have happened when the ecosystem norm is `curl https://third.party/installer|sudo sh`. That was the normal method for third parties to ship software before snaps came along.
We have Flatpaks to solve this problem too now, but AFAICT while Flatpaks do support sandboxing the UX for that is such that most Flatpak non-power-users aren't enforcing sandboxing on Flatpaks they install, so in practice the feature isn't present where it's most needed.
Whether they are derivative works in the context of copyright law (which the GPL relies upon) has not yet been decided by the courts AFAICT. So your assertion may be your personal opinion but we don't know if the law agrees or not yet. From some quick searches it seems that the answer isn't a slam dunk one way or another and is still working its way through the courts.
There is well established case law on the contract that forms when you buy something from a store (say with cash). There is a contract, on implied terms . I think what we’re talking about here is entering into a contract (or not) on explicit terms dictated by one party where the other party has not explicitly considered them and barely given the opportunity to do so if at all. I don’t think anybody is denying the ability of contracts coming into existence on implied terms.
I think that this is the issue then, not pulling dependencies from the internet directly.
> meaningful review
No that I think about it, maybe for the first time in history it's actually feasible to review all the code in the repos using LLMs. Before LLMs were a thing, for any big project that would be way too much work to realistically do it.
Also, someone can provide code review of publicly available dependencies as a service, to avoid wasting tokens of reviewing same code again and again by each dev locally on their machine.
U wonder if anyone is already working on such service...
Most (all?) of the solutions offered are not providing a "code review service" but rather a "curated registry" one: download from us and we guarantee some things.
It's definitely more widely known/used for container images than individual software packages.
clevis and tang do currently work seamlessly on Debian and Ubuntu using initramfs-tools. So while the initramfs-tools/dracut discussion is valid, it seems mostly orthogonal to this topic.
I was unaware that they no longer depended on Dracut and now support initramfs-tools, which also seem to be the earliest clevis version that got packaged in Debian. That makes the initramfs-tools/dracut distinction a historical aspect of the project.
Anybody can become an Ubuntu developer. This is one such Ubuntu developer discussing possible implementation of a law that affects them across multiple distributions in good faith while trying to respect privacy and maintaining users' ultimate control of their Free Software based operating systems.
Ubuntu has made no decision here. This is essentially one contributor seeking consensus on what sort of contribution in relation to this law might be acceptable to multiple projects. It is very far from "Ubuntu Planning <X>" and exactly how community driven projects are supposed to work.
Comments disparaging Ubuntu have fallen for Lunduke's clickbait in their ignorance.
Oh yeah, by the way! How much time left until people are allowed to develop software without KYC? Before you laugh off, this was unimaginable just a year ago and here we are: Google won't bend anymore. ID yourself or never develop for Android.
> have fallen for Lunduke's clickbait in their ignorance.
This is indeed clickbait, but surely you realize that the merit is here.
We have Flatpaks to solve this problem too now, but AFAICT while Flatpaks do support sandboxing the UX for that is such that most Flatpak non-power-users aren't enforcing sandboxing on Flatpaks they install, so in practice the feature isn't present where it's most needed.
reply