Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
What's the latest on Forgejo's Windows builds? Last I checked there was no Windows build due to no volunteers for build/test - Gitea's old build stuff should still be good.
Which is a mild shame because Gitea's Windows version was an insanely simple way to run it if you are a solo dev on Windows and need a private Git site. Drop the binary on an USB hard drive, run it on terminal, boom, done.
(Currently contemplating just setting up a Raspberry Pi server.)
It's just as easy to run in a Docker container and I would recommend this anyway.
Heh, your comment actually made me finally go and resolve a problem I've had since I got this laptop in 2020. I didn't have SVM virtualisation acceleration enabled because that made Windows unable to boot somehow. A bit of twiddling after, it finally did! VirtualBox runs! Docker runs!
...but why would I use Docker for something like this. Might as well blow the dust off of my FreeBSD virtual machine and run Forgejo there!
Docker is lighter and easier to manage than a VM. I run a collection of services as docker compose services inside a NixOS host VM. It's easy to start, stop, monitor, update etc. even from a different computer (via ssh or docker contexts). It's great.
Yeah, I just tried upgrading my Gitea Windows instance to Forgejo via Docker, and it actually works pretty much as easily as it did before. Fantastic! Might just leave it here instead of shoving it all in the VM - I can always do that later if it's necessary. Having a full VM does have upsides, but in this particular instance this is definitely good enough.
So, why Forgejo over Gitea? I've been pretty happy with Gitea.
afaik they are planning on adding federation support eventually, which would be really neat for collaboration
Because gitea is fully the victim of corporate capture. Any PRs that make gitea better in a way that would reduce the main corporate “sponsor” profit are rejected.
The company has a conflict of interest with the community and it shows. Forgejo is sponsored by a non profit open source cooperative.
Any examples of this? PRs that are good overall but not for corporate sponsor?
https://codeberg.org/forgejo/discussions/issues/67
The biggest issue is they require your to give them your rights as they pertain to copyrights.
That means even if you submit MIT or GPL licensed code they can just instantly say “we relicense this code as proprietary” and there is nothing anyone can do.
They rejected a bunch of valid PRs. Including the one linked here because the author refused to assigned their copyrights to the Gitea corporation.
Thanks for the link. But is this really unseen in FOSS? My understanding is some FOSS projects do this so that it is easy to make major decisions without having to bring every person that has ever contributed to the project, kinda like how ZFS is stuck with license issues because they can't bring all contributors together to approve a license change.
There are some advantages but generally it's better for everyone to keep their copyright to prevent a company being able to take over and then deny users the software freedoms intended by the original license.
But everyone does keep their license. A company can not really take over in the sense that you lose your old code. They can stop developing in public but keep using your code, but so can you keep using the last public version and keep developing it. Or you can take your contribution and apply it elsewhere.
You're right that the former license can't be taken away from other instances.
Some projects chooses a license specifically to stop people taking code without sharing code back upon redistribution via copyleft (ShareAlike). Getting around that by changing the license defeats the purpose (projecting users software freedom).
I'm not one to fight for software taken over by a corporate that is against FOSS. If you like Gitea, stick with it till you have a problem
My concern is that this hard fork means "till you have a problem" might be too late for a smooth switch.
I'm not going to be able to convince people to move. I'm sticking with Forjego until something goes wrong.
I'm not trying to start an argument, just looking for that balance between "gitea hasn't done anything wrong yet" and "what if forgejo runs out of steam and the project stalls"
No, it can happen when the organization that owns the product decides to change the license, to include making a product closed-source. Redis just changed from BSD to dual-license SSPL and a custom license, for example.
Because Gitea is MIT-licensed, Gitea Ltd. is well within their rights to change the license on Gitea to any license they please, including the "fuck you all rights reserved" license. However, unless specified in the license, you cannot revoke a previous license. So even if it's closed going forward, you can still continue to use the last MIT version under that license.
You cannot do this with GPL code, however, because the GPL states that any work derived from something under the GPL must also be licensed under the GPL ("copyleft"). The person you are replying to seems to not know that the MIT license has no such requirement.
Well yeah, that's how licenses and copyright work - licenses can change. And sure on an adversary take-over (or corporate overloads taking control), that's problematic. However the beauty is, it's still MIT code: It can be forked (see what's happening with redis). However a project copyright (and DCO) is not in place to enable just that, it's in place to enable any license change by the project. Say a license is updated and there are good reasons for the project to move to the updated license - I think it's pretty reasonable that the project would like to be able to do that and therefore retain copyright. Of course you are also free not to contribute such a project. However claiming it's a license violation or unheard of is pretty disingenuous (formerly ingenious, thanks :) ).
This has nothing to do with GPL or MIT: If you own copyright of a GPL licensed code-base, you can change that license at any time. Of course that only applies to new code. And that's the same for GPL or MIT or any other license.
That last bit isn't quite true. When contributions themselves are MIT-licensed, they can be relicensed. When the contributions are GPL-licensed, they can't be relicensed by the product owner, because that right was not granted to them by the contributor. That's where contributor agreements and copyright assignments come in.
(Also I'm pretty sure you wanted "disingenuous", not "ingenuous".)
Right. I was focusing on the point that what matters is the copyright notice. While your pointing out that you can relicense MIT code because MIT is so permissive, while you can relicense GPL to almost nothing, as it's not compatible with most other licenses. However that's kinda moot, you couldn't include GPL code into an MIT licensed project anyway due to the copyleft.
(Thanks for the "ingenuous" correction, I did indeed - to my non-natively speaking brain the "in" acted as a negation to the default "genuous", which yeah, just isn't a thing of course)
Interesting. Is there a migration path?
If you deployed with docker composr you just change the image and hit redeploy. Super simple.
Appreciate that, sounds super easy
It is. Did that when this was first announced
Huh, using their instructions for docker compose, I use docker pull codeberg.org/forgejo/forgejo:7.0.0 and it errors for manifest unknown. Removing the version tag so it default to latest doesn't help.
Do I need to make an account and docker login? That seems like it should be unnecessary for a simple pull.
Login isn't necessary, but there is no :latest tag published so you need to pull a version that exists. The current version is at codeberg.org/forgejo/forgejo:1.21.8-0 or at :1.21 if you want one that tracks patch updates (as found in the container registry).
Ah, the docs reference V.7.0.0 so that's what I was trying with.
TY, that got her transitioned. The config actually pops a notice that 1.21.9 is available but I don't see that it's in the registry yet. I do like the :latest tag because then I can use watchtower, but I can understand why some people would want to specify the version.
Right now Forgejo is a drop in replacement. This article is them announcing that Forgejo will eventually not be one.