Now on to reply to @ianopolous’s related question on a separate thread.
What limitations do you think come from AGPL? Anyone is free to take, modify and run it, and build companies on it as long as they release their source modifications to the public.
For checks and balances I think there are several effective options.
- Peergos LTD doesn’t own the copyright on the current peergos code, it is owned by the individual contributors. this defends against re-licensing against the communities interests, which is common.
- Independent implementations
Background
As mentioned above, I’m still not a lawyer and these are pragmatic developer vibes to dig at the heart of how my brain summarizes these licenses…not legal advice.
AGPL 3.0 falls under the copyleft licenses mentioned above. Similar to GPL 3.0, anyone who is not the copyright owners of the code (typically the authors and subsequent maintainers) aren’t able to sublicense the software. Which disables some big company from grabbing the open sourced code that a community (and likely a core of maintainers like Peergos) work hard to develop and maintain, and sticks it behind a bit of code, their logos, and recompiles the code!
AGPL is more or less an adaption that needed to be made to adapt the terminology to SaaS applications as stated here:
Why AGPL?
The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.
An older license, called the Affero General Public License and published by Affero, was designed to accomplish similar goals. This is a different license, not a version of the Affero GPL, but Affero has released a new version of the Affero GPL which permits relicensing under this license.
Example
Although this wasn’t for a sublicense issue, a recent newsworthy violation of the AGPLv3 occurred when Truth social copied and modified Mastodon’s code without distributing the original source code or attribution. This didn’t violate the sublicensing clause, which is the more impactful clause, but still didn’t offer credit to the original project.
For sake of example, assume you did have to pay to use Truth Social and it was being done for profit, Mastodon and Software Freedom conservancy would have had a stronger case.
Why do I prefer having my foot in a permissive and copyleft project communty?
Using the AGPL licensing and any copyleft licensing has plenty of valid uses, but also leaves a power gap open that could potentially be exploited. I mention this in detail in the previous post.
Unfortunately, this means the community has less leverage if the authors do something unplanned and outside of what the community signed on for. This has value, but requires more trust that the authors won’t just use this license to stonewall public contributions and simply use this as a sales pipeline rather than a community to share ideas as we’ll discuss in the next bucket of licensing.
It can also avoid healthy competition and choice.
As @ianopolous mentions:
Peergos LTD doesn’t own the copyright on the current peergos code
This is very healthy setup of course, and vests the decision making power with the authors.
The question is, where do the authors currently work and what might their biases be? From the contributors code, there are four authors that have made more than a single commit contribution and 11 contributors total. Those four authors all work for Peergos LTD based on looking at the profile names and this team page.
I am btw no stranger to the BDFL model. It is quite an effective model provided you call a spade a spade. In that instance, a lot of people trusted the BDFL maintainers as they had the clearest and most inclusive vision for the community despite all three of them working for the same venture capital funded company I worked for.
Now you state there’s currently no financial incentive (also good to know), and you and Kevin have been working on this project for a long time so that alone tells me this isn’t some VC get-rich-quick scheme and something you believe in. But there’s no crystal ball to this formation of power vested in four humans when it comes to providing future optionality and enabling choice to the community regardless of how pure and benevolent your intentions are.
I am curious what you mean by “Independent implementations”. To me this would be something like Hubzilla, which is under a permissive license, and enables anyone to not only copy the code, but fork it and make a version of their own that can provide features or a competitive product to Peergos. It also provides an overlap with the Fediverse protocols which may be incentivizing to many.
So all around I like just having that there to provide options and leverage to this very interesting market.
What I think would be the most ideal option, would be cross compatible protocols that make migration between or use of both Hubzilla and Peergos possible without a lot of lockin to users. That’s likely getting ahead of ourselves.
So yeah, curious to hear your thoughts and anyone else’s thoughts and critiques on the my licensing and open source political takes.