Hacker News Reader

Comment by atweiden | Hacker News Reader

It’s notable how prevalent AGPLv3 licensing is all throughout the Fediverse. This, and the fact user accounts are decoupled from the federated frontends present a radically different incentive structure for providers compared to the traditional model of social media.

You can feel the impact this has when browsing PeerTube: eclectic videos — a good sign of a burgeoning ecosystem — but with video buffering rates seemingly decades behind YT.

I’m actually a huge fan of the fediverse. But if PeerTube in particular wants to hit it big, there are some serious scalability issues which need to be addressed, despite fediverse development being largely antithetical to profit.

View on HN

Mastodon was very nearly not AGPL. I asked them to fix it very early on. Issue 1 or 2 on the GitHub tracker.

Edit: 49. https://github.com/tootsuite/mastodon/issues/49

for someone who doesn't know better, what is the benefit to AGPL and what license were they using originally?

found the issue btw: https://github.com/tootsuite/mastodon/issues/49

Software that isn't executed on a user's machine is out of the user's control. The GNU AGPL redefines distribution to include serving over a network so that software served over a network must disclose source code as well (unminified JS, server-side code, etc). It's also copyleft, which is good: the purpose of permissive licenses is to enable proprietary derivatives, which is against the spirit of the Fediverse.

One interesting consequence of Mastodon's AGPL licensing is that Gab, the right-wing twitter clone that runs a Mastodon fork, also has to disclose its source. That was how people found a vulnerability in Gab that allowed the recent "hack".

As a service operator, why would I want to choose software licensed this way?

As an operator you're always making a tradeoff between the "negatives" of a license and the "positives" enabled by the actual software.

So for one example, the recent (bait and) switch of Elasticsearch to SSPL effectively means that for many actual real-world users of Elasticsearch, the benefits of staying on the official Elastic branch has ceased to be worth the costs of the license when your alternative is running FOSS Elasticsearch/Opensearch.

So to answer your actual question - presumably as an operator you want to use the AGPL-licensed code more than you want to avoid those same negatives of AGPL.

That's exactly why I license everything I open-source MIT/Apache.

Because what you're offering is a service, and not someone else's software. Your added value is not actually in the code or the cute pictures; it's being available, having a low latency, allowing people with no tech knowledge to take part in the discussion, building a relation based on mutual trust rathet than serfdom. It's fundamentally the difference between a user and a consumer.

I find that issue very confusing. How is a GPL-2 license not acceptable for being listed on a website of GNU projects?

I note they went along with the relicense but the site only currently lists "GNU FM" and "GNU Social". Is there an actual compelling argument for a project to choose a license just to be listed alongside those?

GNU FM and GNU social are both AGPL projects. The gnu.io site was for GNU projects that were AGPL.

With the convergence of technologies, AGPL should maybe be everyone's default (if they consider GPL, go for AGPL).

This is something I've never heard about, but are there any projects who license AGPL but offer paid relicensing to GPLv2? With customers paying for permission to keep private their modifications to a hosted service?

Reply on news.ycombinator.com