Seems related to size and/or maturity if anything. I haven't seen any startups less than five year old doing anything like that, but I also haven't seen any huge enterprise not doing that, YMMV.
If it really is fully open-source please make that more visible on your landing page.
It is a huge deal if I can start investigating and deploying such a solution as a techie right away, compared to having to go through all the internal hoops for a software purchase.
How hard is it to go to the GitHub repository and open the LICENSE file that is in almost every repository? Would have taken you less time than writing that comment, and showed you it's under MIT.
It's not entirely uncommon to only have parts of the solution open. So a license on one repo might not be the whole story and looking further would take more time than giving a good suggestion to the author.
Agreed. For all the people arguing "just click the link and the license is there!!", I have been burned several times before where a technical solution has a prominent open permissive license github repo (MIT or similar etc) based component as its primary home, only to discover later on that essential parts of the system are in other less permissive or private repos behind subscriptions or fees.
The rest of us get around that particular issue by going through the source code and all the tradeoffs before we download, include and adopt a dependency, not after.
Good for you! This of course doesn't help in the situation where a dependency author retroactively changes the licensing state of a component, or reconfigures the project to rely on a new external dependency with differing license states (experienced both of these too!).
Having the landing page explain the motivations of the authors vis-a-vis open source goes a long way to providing the context for whatever licensing is appearing in the source repos, and helps understand what the future steer for the project is likely to be.
There are loads of ostensibly open source projects out there whose real goal is to drive sales of associated software and services, often without which the value of the opensource components is reduced, especially in the developer tooling space.
> Good for you! This of course doesn't help in the situation where a dependency author retroactively changes the licensing state of a component, or reconfigures the project to rely on a new external dependency with differing license states (experienced both of these too!).
No, but I also don't see why that matters a lot. Once you adopted a third party project as a dependency, you also implicitly sign up to whatever changes they do, or you get prepared for staying on a static version with only security fixes you apply yourself. This isn't exactly new problems nor rocket science, we've been dealing with these sort of things for decades already.
> There are loads of ostensibly open source projects out there whose real goal is to drive sales of associated software and services, often without which the value of the opensource components is reduced, especially in the developer tooling space.
Yeah, which is kind of terrible, but also kind of great. But in the end, ends up being fairly easy to detect one way or another, with the biggest and reddest signal being VC funded with no public pricing.
If I have to dig through your website/documentation to find basic information we’re not getting off to a great start. It’s pretty common for open source projects to proudly proclaim they are open source from the get-go. “____ is an open source tool for ______.” Simple as that
Seriously all the nitpicking I see of any project people post here but “tell us you’re open source at the top when you’re open source” means we’re lazy? Being open source is an important decision and you should tell people! It’s a good thing!
Isn’t a big part of getting a project out there actually letting people know what it is? Especially if you’re trying to give a tool to the open source-valuing community. That’s a high priority for them. That’s like having a vegan menu and not saying you’re a vegan restaurant anywhere public facing.
I agree it's a good thing, but I'd also agree it's not something you need/have to shove in people's faces, especially when it's literally one click away to find out (The GitHub icon in the top right takes you to the repository, and you don't even have to scroll or click anything, the sidebar shows "MIT License" for you).
There is a GitHub icon fairly prominent on the top right. Choosing to spend precious text for a fleeting would be user on it is a choice and not everyone wants to market that fact very prominently. Should everyone who writes their project in rust include that prominently as well? It seemingly markets very well and a lot of people seem to care about that as well.
It's been a while since I looked at kuik, but I would say the main difference is that Spegel doesn't do any of the pulling or storage of images. Instead it relies on Containerd to do it for you. This also means that Spegel does not have to manage garbage collection. The nice thing with this is that it doesn't change how images are initially pulled from upstream and is able to serve images that exist on the node before Spegel runs.
Also it looks kuik uses CRDs to store information about where images are cached, while Spegel uses its own p2p solution to do the routing of traffic between nodes.
If you are running k3s in your homelab you can enable Spegel with a flag as it is an embedded feature.
There is a couple of alternatives that mirrors more than just Docker Hub too, most of them pretty bloated and enterprisey, but they do what they say on the tin and saved me more than once. Artifactory, Nexus Repository, Cloudsmith and ProGet are some of them.
Spegel does not only mirror Docker Hub, and works a lot differently than the alternatives you suggested. Instead of being yet another failure point closer to your production environment, it runs a distributed stateless registry inside of your Kubernetes cluster. By piggy backing off of Containerds image store it will distribute already pulled images inside of the cluster.
I'll be honest and say I hadn't heard of Spegel before, and just read the landing page which says "Speed up container pulls and minimize downtime with a stateless peer-to-peer OCI registry mirror for efficient image distribution", so it isn't exactly clear you can use it for more things than container images.
Spegel itself does not manage state as a normal registry would. Maybe ephemeral would be a better word to describe it. A normal registry would require some stateful storage solution along with a database to store image that clients push to it. Spegel exploits the fact that images used by containers will be stored on disk by Containerd for its benefit. Any image currently being used by a pod in a cluster will be available for all other nodes in the cluster to pull.
Gotcha. That's definitely an important point and seems difficult to communicate in a single word or quick blurb. I can see why you went with stateless. It's just a little confusing in this context (for me at least).
I am having some discussions about getting things working on GKE but I can't give an ETA as it really depends on how things align with deployment schedules. I am positive however that this will soon be resolved.
I initially built Spegel to deal with a series of GHCR outages along with rate limit changes in Docker Hub. I am a bit biased but it is a no brainier to run Spegel to mitigate these types of issues.
Thank you. Question, how large of clusters have you deployed spegel to? I run clusters which are well beyond the defined k8s limits and sometimes when we put stuff in there it blows up as it wasn’t ever tested at those scales (for example Cilium) https://kubernetes.io/docs/setup/best-practices/cluster-larg...
I am not to familiar with Kamal but it seems possible to integrate it with my project Spegel to remove some of the load from upstream. Especially if they are running clusters of servers physically located close to each other they could avoid some of the replication complexity with multiple Harbor instances.
And just to be really clear -- it's not actually a solution to cloud providers not reusing the code for profit (which I assume is the context you're implying, could be wrong here), because AGPL is free software, so people are free to reuse your code for commercial purposes. AGPL at least prevents making private improvements to open source networked code without contributing back.
I think in this situation it might have convinced Microsoft to contribute rather than fork... But then again, it's Microsoft. Also, they're well under their right to fork and keep the changes as long as the license stays the same, etc.
I think another important point might be that "free software" aims to protect the users of free software, not necessarily the profit-maximizing (I mean to use that phrase neutrally) ability of software developers.
The AGPL doesn't require them to contribute back. It only requires them to provide the code to end users upon request. No license as far as I know requires people to contribute back.
In many cases, project maintainers would not want the changed code anyway because it does not align with their vision for how things should be done. Linus Torvalds and his subsystem maintainers, for example, do not want people to send them code dumps containing the hacks people have done to private Linux source trees. They want proper commits that are done well and have been modified to comply with any feedback that they provide.
What the project maintainer here wanted were collaborators who would work with him as a team (which is not much different than what most OSS developers what), but no license requires that and it is rare to get that.
It is in a roundabout way also about collaboration with upstream, since the users (or those working for them) are fully empowered to be developers if they so choose.
And the upstream and buy the product and get the same rights as a user.
The biggest thing that GPL et al. enable is that customers are not locked in to their provider.
It's not as much about the collaboration by the vendor per se, though users would likely prefer it, and are themselves able to collaborate on equal footing.
The problem is that it scares away also others. Personally I avoid such projects for any purpose, they simply don't exist for me.
I also don't understand the cloud hosting argument, when we had a great whole era of Apache/PHP/MySQL stack based on exactly this idea of commercial hosting.
> The problem is that it scares away also others. Personally I avoid such projects for any purpose, they simply don't exist for me.
I think this isn’t a problem — not everyone has to contribute to any project! People sometimes struggle with the choice between GPL and MIT for similar reasons of popularity.
People who want the widest possible usage/corporate adoption can pick licenses that reflect that and embrace the tradeoff
The anger over cloud hosting came from a specific set of Open Source companies that produced cloud software with the intention of earning money by selling hosting. Mongo, Elastic, and Hashicorp were the big ones. These companies failed to realize that the licenses they chose were incompatible with the business model they chose and then blamed the resellers for their own failure to plan.
It was particularly problematic for the FOSS companies because each of these players' plans was to resell the Big Three clouds and live off of the margin, so the instant that the cloud providers decided to just directly compete in the hosting space the original company physically couldn't compete on price.
The moral of the story is that if you're releasing cloud software as FOSS you can't plan your business around the idea that you'll be the only hoster.
Any copies of the code should include the notice according to the MIT license. I do agree that I could have used a less permissive license, and it is something that I am now considering to change.
The reality is that licenses do not mean anything unless you are actually able to enforce it. So I really do not think the license would have mattered in this case.
Licenses absolutely matter, that’s the whole point of using them! Big corps will absolutely not risk being sued over infringement, it’s not worth it to them. For the litigation cost they’ll throw a couple engineers and redo your project from scratch.
Sorry it happened to you but it seems like you just picked the wrong license.
I agree, after this happened to me I learned of a few other situations where the same thing happened to other friends.
On my end if was a mix of naivete and flattery which made me want to take the meeting. I suspect it is the same case for others. I will not make the same mistake the next time it happens.
Well your license is only as good as you are able to enforce it. Even with the law there is no guarantees.
I grew up thinking that people would follow the spirit of open source rather than the specific letter of the law. This is obviously not true, and probably never has been.
No license stops someone from spinning off an OSS project into their closed-sourced enterprise offering. It's just sad that most corps see nothing wrong with this
The GPL (and AGPL) are easy to comply with for a corporation, or anyone else really. Just redistribute your modifications under the same license, and ensure users can run modified versions on devices you distribute and you are done.
Were folks under the impression there were other options for license violations? Your comment implies that a lawsuit being the only recourse to enforce a license renders that license moot.
Some people just hoped that picking a corporate-unfriendly license would be enough of a deterrent by itself, because most folks can't actually afford to sue. But infringers, big and small, are increasingly realising that these licenses are toothless by themselves, they need to be backed by money.
I don’t disagree with any of that, I think the challenge is certainly the costs of enforcement. For GPL licenses anyway (I realize the OP used the more permissive MIT license) I think their is (or there should be) a non-profit foundation established to collectivize the funding and legal actions necessary to support open source projects in these kinds of scenarios. Certainly, pursuing license violations in a manner that maximizes awareness and makes examples out of violators should prompt others to reconsider their actions.
> I think the challenge is certainly the costs of enforcement.
IMO, this is fundamentally a mismatch between how software is developed in practice and how copyright works.
If software was like a book, where it's finished and published once, then simply registering it with the copyright office would be all anyone needs to do: up to $10k/copy statutory damages is a stiff enough deterrent that few large companies would want to take the risk. And even if they did, it'd be easy to find a lawyer to take the case on contingency.
As a non-lawyer, that doesn't seem to match nearly as well with software as a constantly evolving work. But I'm not an expert - maybe periodically submitting versions is enough.
Software Freedom Conservancy are the most visible GPL enforcers these days. The FSF probably does some enforcement too, but doesn't seem to talk about it as much.
> For GPL licenses anyway...I think their[sic] is (or there should be) a non-profit foundation established to collectivize the funding and legal actions
Hence my thinking there is. I kept thinking EFF for some reason, but I knew that wasn't right. EFF are the ones who consistently predict which anti-privacy/anti-consumer laws will definitely get passed.
Interesting idea to use the file path layout as a way to control the endpoints.
I do wonder though how you would deal with the Docker-Content-Digest header. While not required it is suggested that responses should include it as many clients expect it and will reject layers without the header.
Another thing to consider is that you will miss out on some feature from the OCI 1.1 spec like the referrers API as that would be a bit tricky to implement.
Kraken is sadly a dead project, with little work being done. For example support for Containerd is non-existent or just not documented.
I created Spegel to fill the gap but focus on the P2P registry component without the overhead of running a stateful application.
https://github.com/spegel-org/spegel
