marcoheisig
AGPL License
I just finished watching the ELS 2024 and Petalisp looks very interesting.
I completely respect your choice of license, but unfortunately it prevents any commercial use of Petalisp in hosted customer facing applications. If this is the intention that is all good. If not would you consider relicensing under for instance Apache v2?
This is a topic I thought long and hard about, and where I have still no perfect solutions.
On the one hand, the picture is incredibly clear to me. Non-free software is a centralization of power, and that power is going to be exploited eventually. To protect my users, they need both the software and the means to read, edit, and redistribute it. Now that software is creeping into more and more sensitive areas (smart watches, insulin pumps, autonomous cars, voting machines), I think it is madness not to demand the ultimate transparency that is provided by free and open-source software. So in a way, anyone not using something like AGPL is either naive or malicious.
On the other hand, the power imbalance created by non-free software is how a lot of software companies make their money, and users are typically not educated enough to consider the long-term cost of running software they have no control over. So the business case for non-free software is, unfortunately, still strong. I cannot expect developers or software companies to forego profits to do the right thing (although one can always hope).
From the pure engineering perspective, non-free software is just a disaster. It prevents people from repairing stuff, it leads to regressions, and it hampers collaboration. A product that is non-free is therefore inherently flawed.
Here is an idea:
-
I can put the API and reference implementation of Petalisp under Apache v2, while leaving all the fast backends under AGPL. This way, even commercial projects can include Petalisp, albeit with mediocre performance.
-
Developers of commercial projects can then apply for a copy of the faster backends under a proprietary license, and I will happily grant them that if the conditions are fair.
How does that sound?
Marco,
Thank you for your thoughtful and thorough response.
I think your suggested approach sounds feasible, although the commercial license terms would ideally be known up front, so users can evaluated whether it is worth evaluating Petalisp,
As an aside I agree with the a lot of your analysis, certainly from a technical/security POV. The challenge is of course how to build a business model that is compatible with releasing all your license code. In that connection I think many proponents of the AGPL (not you) fail to realize how expansive GNUs interpretation of derivative work is. In many instances it will result in enough uncertainty for, for instance a SAAS vendor, as to how much of their codebase will be encompassed by the APGL, that they will avoid it all together. This is the approach Google has adopted for instance, and that organization has a fairly sophisticated and non-defensive approach to open source. Any way, just my two cents.
Thanks again for creating Petalisp and demonstrating that CL is as viable as it ever was.
Cheers,
Martin
On Sat, 22 Feb 2025 at 19:10, Marco Heisig @.***> wrote:
This is a topic I thought long and hard about, and where I have still no perfect solutions.
On the one hand, the picture is incredibly clear to me. Non-free software is a centralization of power, and that power is going to be exploited eventually. To protect my users, they need both the software and the means to read, edit, and redistribute it. Now that software is creeping into more and more sensitive areas (smart watches, insulin pumps, autonomous cars, voting machines), I think it is madness not to demand the ultimate transparency that is provided by free and open-source software. So in a way, anyone not using something like AGPL is either naive or malicious.
On the other hand, the power imbalance created by non-free software is how a lot of software companies make their money, and users are typically not educated enough to consider the long-term cost of running software they have no control over. So the business case for non-free software is, unfortunately, still strong. I cannot expect developers or software companies to forego profits to do the right thing (although one can always hope).
From the pure engineering perspective, non-free software is just a disaster. It prevents people from repairing stuff, it leads to regressions, and it hampers collaboration. A product that is non-free is therefore inherently flawed.
Here is an idea:
I can put the API and reference implementation of Petalisp under Apache v2, while leaving all the fast backends under AGPL. This way, even commercial projects can include Petalisp, albeit with mediocre performance. 2.
Developers of commercial projects can then apply for a copy of the faster backends under a proprietary license, and I will happily grant them that if the conditions are fair.
How does that sound?
— Reply to this email directly, view it on GitHub https://github.com/marcoheisig/Petalisp/issues/27#issuecomment-2676333283, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAPUXCW5A3KAFNFNPYUSZ32RC4QHAVCNFSM6AAAAABXH2ZNWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZWGMZTGMRYGM . You are receiving this because you authored the thread.Message ID: @.***> [image: marcoheisig]marcoheisig left a comment (marcoheisig/Petalisp#27) https://github.com/marcoheisig/Petalisp/issues/27#issuecomment-2676333283
This is a topic I thought long and hard about, and where I have still no perfect solutions.
On the one hand, the picture is incredibly clear to me. Non-free software is a centralization of power, and that power is going to be exploited eventually. To protect my users, they need both the software and the means to read, edit, and redistribute it. Now that software is creeping into more and more sensitive areas (smart watches, insulin pumps, autonomous cars, voting machines), I think it is madness not to demand the ultimate transparency that is provided by free and open-source software. So in a way, anyone not using something like AGPL is either naive or malicious.
On the other hand, the power imbalance created by non-free software is how a lot of software companies make their money, and users are typically not educated enough to consider the long-term cost of running software they have no control over. So the business case for non-free software is, unfortunately, still strong. I cannot expect developers or software companies to forego profits to do the right thing (although one can always hope).
From the pure engineering perspective, non-free software is just a disaster. It prevents people from repairing stuff, it leads to regressions, and it hampers collaboration. A product that is non-free is therefore inherently flawed.
Here is an idea:
I can put the API and reference implementation of Petalisp under Apache v2, while leaving all the fast backends under AGPL. This way, even commercial projects can include Petalisp, albeit with mediocre performance. 2.
Developers of commercial projects can then apply for a copy of the faster backends under a proprietary license, and I will happily grant them that if the conditions are fair.
How does that sound?
— Reply to this email directly, view it on GitHub https://github.com/marcoheisig/Petalisp/issues/27#issuecomment-2676333283, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAPUXCW5A3KAFNFNPYUSZ32RC4QHAVCNFSM6AAAAABXH2ZNWSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZWGMZTGMRYGM . You are receiving this because you authored the thread.Message ID: @.***>
@maacl Just for clarification, is the issue with using AGPL licensed components in commercial hosted consumer facing applications explicit (i.e. the license expressly prohibits this, just using some legal language that I was unfamilliar with), or is this just an issue with companies not wanting to provide license the service they host under AGPL? Or is it some conflict between licensing of different parts, or is it something else entirely?
@yuki-tsubaki It is "just an issue with companies not wanting to provide license the service they host under AGPL" - which for most organizations is not "just" an issue, but a complete dealbreaker. Even if no commercial interests cause this, many orgs will - however misguidedly - object to releasing source code with reference to security and other concerns.
