I feel like I should drill in on one aspect of copyleft and GPL licenses that @ianopolous points out that I missed out on.
Let’s say another company wanted to come along and build their own version of Peergos called “Neargos”, where they took ~10 years of work of @ianopolous and the other co-authors work, added a feature (or not) and just slap the new “Neargos” labels on it and profit $$.
As @ianopolous suggests, this is possible in the copyleft code today. Provided Neargos’ only plan is to take whatever GPL code is created by the hard work of Peergos team members and community, and run the service, then they are legally fine.
Generally though, a community would see right through this and realize that there’s no incentive to use Neargos as they are taking advantage of the community’s hard work and would likely have those most knowledgeable working on the service they pay for.
So Neargos decides they are going to hire two software engineers and a product specialist to build new features to attract customers to their service. So Neargos does this and are ready to deploy NeargosX which is literally just an Elon Musk version of Peergos that adds useless AI features. However, since Peergos is licensed under AGPL, Neargos realizes they must license their AI features under AGPL and publish the source code for all to see!!
This has a lot of positive effects as NeargosX can’t just copy a bunch of hard work from Peergos, add a small feature, then capitalize off work they didn’t do. In theory, this makes it to where the community much less likely to have one single company monopolizing the market since everyone can study and even modify the features of any modification of the code.
Permissive licenses on the other hand don’t have this requirement. Assuming Peergos was licensed under Apache 2.0, then Neargos would be able to make NeargosX a proprietary feature, keep the small sliver of code for themselves, and profit!
So why would anyone ever choose to make their code permissive and not copyleft then?
The details vary from community to community and project to project, but the best summary I’ve seen was adapted from here:
permissive licences aim for maximum adoption which leads to higher innovation of code, while copyleft aim for maximum openness of code.
- Company’s want to avoid lawsuits so adopting code with GPL libraries is a last resort and will choose a less valuable permissive library over copyleft
- Company’s definitely want to reserve the right to build a feature and profit off of it, even if it’s not currently in their wheelhouse
- Fewer companies adopting the copyleft projects can lead to smaller ecosystem unless the copyleft one just crushes any remote desire to use the alternatives
- Smaller ecosystem if they do occur, will lead to stagnation of adoption and other tools moving faster
So permissive licenses generally encourage a faster flow of adoption and innovation while copyleft ensures the original developers keep the software and the incentives in check through legal guarantees.
I think there are ways to split up software either by making shared standards where core libraries are permissively licensed (this ensures the ecosystem can flourish and be interoperable), while the specific implementations are licensed under GPL.
One example of this is the Matrix specification while the primary innovators of Matrix who founded the chat server/clients called Element, license their synapse server implementation under AGPL, along with Android and ios phone apps.
Anyone could in theory take the code that Element publishes and make their own version which copies the entire Element codebase, and their changes, licenses them under the GPL, and makes those avialable as well, however, they can also just make their own servers or clients on their own and license them how they see fit.
This to me is one of my favorite middle ground strategies to enable a more free flow of ideas, while keeping the implementation details somewhat protected from the unfortunate capitalistic opportunists we live with today.
I hope this more accurately answers your question @ianopolous and sheds light on how I think having Hubzilla and Peergos share some sort of permissive licensed protocol together.
This provides consumers with peace of mind that they will be buying into a much more open market of ideas rather than entirely betting on your team, although it’s a fine bet, this is a radically early space for your ideas despite you being even further ahead than the rest of us.
Adding a bridge between you and Hubzilla also enables some cross pollination to Fediverse protocols like ActivityPub and Nomadic Identity.