spacelord

Yeah, you don’t sacrifice any convenience here, in my opinion:

Feker Alice98

I’m… Reborn and in love with mech keyboards. 😃

Doesn’t seem to be present on my keyboard. 😁

That’s inacurrate. Licensing representation matters. If the cloud service is genuinely presented as AGPL-licensed, Section 13 obligations apply regardless of copyright ownership. However, copyright owners remain free to maintain truly separate proprietary versions under dual licensing.

That’s misleading. While copyright owners aren’t bound by their own license, AGPL Section 13 requires that when they run AGPL software as a network service, they must make the complete source available to users.

The AGPL was specifically designed to close the “SaaS loophole.” Being the copyright owner doesn’t exempt you from AGPL’s network service requirements if you’re distributing under that license.

@Goldflag

I appreciate the intent behind Rybbit, but I have to respectfully disagree with the “only very slightly so” characterization. Looking at your official comparison table, the self-hosted version is missing:

• Pages View
• Web Vitals
• Email reports
• Google Search Console integration
• VPN/Crawler/ASN tracking
• Google/GitHub OAuth
• Email support

That’s 7 significant features—which seems more than “very slightly” different.

More importantly, this raises AGPL compliance questions. Under AGPLv3 Section 13, if users interact with modified AGPL software over a network (your cloud version), you’re required to make the complete corresponding source code available to those users. If these cloud-only features are integrated into the same AGPL-licensed codebase, withholding them from the public repo while running them as a network service appears to conflict with the license terms.

There are really only two compliant scenarios here:

1. These features exist in the public repo but are just marketed as “cloud-only” (in which case the comparison table’s misleading)
2. These features are truly separate proprietary code that interfaces with Rybbit without being part of the AGPL-licensed work (which would require careful architectural separation)

If it’s neither—if these are AGPL-covered features running in your cloud service but withheld from the repo—that’s exactly the “loophole” the AGPL was designed to close. The irony is that you criticized Plausible and Fathom for having “much inferior self-hosted versions,” yet this appears to be a similar approach.

Could you clarify the licensing status of these cloud-only features? Are they in the public repo but disabled by default, or are they proprietary additions that don’t derive from the AGPL codebase?

I wouldn’t say it’s only for the extra paranoid, but rather for everyone.

After reading the whole discussion, it’s clear that the repo transfer was handled in an extremely unorthodox way, at least by usual standards for repo handovers that I’m familiar/experienced with.

Communication from Catfriend1 was absolutely nonexistent, and there was only minimal info from the person who took over using a GitHub account created just two days ago.

Trust is something that must be earned, not given to someone you’ve never seen or heard of before.

Didn’t get to contributing to Tempus yet, but since I use it & like the layout approach, I forked Feishin and made it more Tempus-like. Decades, starred albums and tracks sections etc. Have a look if you like it. Linux only since it’s my primary driver.