This one is something that were brought up a lot by developers including me who are very weary about corporations profiting off of our work for free and this basically put us off from contributing to open source in general.
We get a bunch of dialogues about this such as:
Developers like me: “Many of us who create are concerned about our work being exploited. The possibility of corporations profiting from our open-source contributions without giving back to the community disincentivizes us from participating in such endeavors.”
Open-Source Advocates: “The AGPL exists to mitigate such concerns. It requires derivative works to also be open-source.”
Developers like me: “While I appreciate the intention behind AGPL, there is a loophole - a ‘condom code’ if you will. Even though Linux Kernel prevents such strategies by refusing to merge these changes and that it’s difficult for a singular corporation to force an adoption of a forked version of Linux Kernel, a corporation can fork our much smaller project however and introduce such legal bypass to the copyleft restrictions. This bypass can be justified by them under the guise of extending the software’s capabilities with a plugin interface or an interprocess communication protocol layer, similar to how PostgreSQL allows User Defined Functions. However, I must caution that I’m not well-versed in the legal intricacies.”
When bringing up on non-commercial clause for licensing
Open-Source Advocates: “Disallowing commercial use of your project contradicts the principles of open-source.”
Developers like me: “Well, then perhaps we need a new term, something like ‘Open Code Project’. We can create projects that encourage collaboration and openness while also restricting commercial exploitation.”
So I created this post, because we do need to discuss on a path forward for Open Source in general knowing that corporation can shirk around this restriction and discourage developers like me from participating in open source or open code projects.
MongoDB has a modified version of the AGPL that they call Server Side Public License that might interest you. Specifically the change in section 13:
By my reading, it closes that loophole you mention by specifically calling out interfaces and APIs as also requiring the source to be available. At the top of the page I linked there is also a PDF showing the removals and additions they made to the AGPL to end up with their SSPL.
That a pretty interesting license, I distinctly remember that there were an argument on the internet over that license. So I took the time to review what happened, there were few criticisms for it:
Conflict over “Open Source” Definition - Open source license must allow the software to be freely used, modified, and shared. The SSPL adds additional restrictions, particularly the requirement to open source not just the software itself but also the software used to offer the program as a service.
Restricts Freedom to Use the Software - It requires that anyone who makes the software available as a service must release the source code for their entire stack.
But none the less, this license is an interesting one and an inspiration could be drawn from it to not go to that extreme stipulated by SSPL, but to have some lines drawn to address some of the concerns around AGPL loopholes.