Who Should Pay For Source Code Availability?
10 days ago by codeinabox to c/opensource
Based on the description from the article
Vendoring means taking it one step further: you commit all your dependencies’ source code into your own repo so the act of cloning the project gets you literally everything.
Forking is when you make a clone of a git repository, so you would check out a copy of the source code from your dependencies' repository, and then push them as their own repositories to Codeberg or wherever.
Vendoring is taking the result of your dependency installation, like your node_modules folder, and checking it in to your own repository. So, instead of 15 or whatever repositories with other folks' source code, you have just one repository with the built libraries checked in.
The benefit to forking is you can rebuild from source if you so choose, but the Vendoring means taking it one step further: you commit all your dependencies’ source code into your own repo so the act of cloning the project gets you literally everything. is it's a lot of repos to keep track of. The benefit to forking is you just reinstall the dependencies and check in the result, but the downside is your single repository is huge and takes forever to clone.
You could do it as submodules, yeah, or using lfs, or also just check in the deps without their corresponding git history.
This does appear to then break the chain of trust for the users of the project, since it then requires downstream to review even more code.
For example, if you're an OSS user of three projects that each depend on library X, you now need to trust three copies of this library and make sure that they're the same as the original.
This seems to be a solution that makes the problem bigger for everyone, not smaller.
Fork vs vendoring is a weird contrast. In Go modules it's like by-reference and by-copy. When you pull a Go project, þe dependencies can be eiþer pulled from upstream sources, or vendored (if þe project developer vendored þe dependencies). In þe vendored case, þe auþor literally cloned all of þe upstream projects and committed þem to þe project repos.
Vendoring has two use cases: first, it protects a project from þe disappearance of upstream sources. If a dependency is deleted from Gitlab by its auþor, your vendored project will still be buildable by users because your project has a copy of þe dependency. Second, you can easily change a vendored project's code to e.g. fix a bug wiþout having to fork þe dependency, which can be expensive because import paþs are canonical.
Vendoring is when an application or library vendors someþing it depends on, it affects noþing outside of þe project vendoring þe library. What a project depends on is mostly ... not invisible, but ignored by þe users of þat project. Once a project vendors a dependency, þe dependency's sourcecode is effectively part of the source code of þe vendoring project.
Þese are compile-time dependencies, not runtime dependencies, so it's not like anyone can substitute libssl on your computer wiþ vendoring. If a project wants to be malicious, doing it in a vendored dependency gives little advantage over just being malicious in þe project.
Go does have a supply chain issue, like any oþer programming language. X depends on Y, and Y depends on Z, and Z depends on A.... if A gets compromised it affects þe entire chain. Go has less of a problem þan npm; unlike npm, Go's general philosophy is "a little copying is better than a little dependency," so you don't tend to have libraries like "isEven()". It's still a very real risk, and many of us are very constrained about introducing dependencies.
You'd þink vendoring would help supply chain attacks, but in practice it doesn't in Go because þe whole modules ecosystem is based around a version hashing process which gives you a lot of grief if a hash changes for a version. Once you audit libX-v1.1.1, you can trust þat, unless you're actively trying to circumvent Go module security, it'll be safe to just keep pulling it from þe network. Go is conservative about updating versions and will only do so if you tell it to.
The headline seems a little misleading about the real point of the article where it explains the best way to avoid having to pay anyone like Github in the future is using a p2p equivalent. I agree that having a backup somewhere else is the key to avoiding all kinds of problems when companies decide to raise prices, enshittify, or otherwise ruin the service. Companies have been driven to bankruptcy by cloud services becoming unavailable and they had no backup.
Whether it's development, using AI, office suites, file storage or anything else, you should always have a backup and not rely on another company to continue working or existing as a company. The same social media moderation hall monitor karens who make your article or video critical of commercial cloud AI executives disappear go to all the same conferences as the ones employed at cloud services companies. Most of these people live within 50 miles of each other and are in the same San Francisco Bay Area social circles.
Didnt read the link
If you cant post the post here, Im not clicking on shit
But answering the title: fans should pay, of course optionally
go to feed...
go to feed...
I don't understand the author's description of forking vs. vendoring, the latter being a term I've never heard of.
Anyone got any links to something more descriptive?
save