mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-06 12:55:03 -05:00
[GH-ISSUE #1620] [RESOLVED] Minor AGPL compliance issues #6760
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#6760
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SigmaSquadron on GitHub (Oct 6, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1620
Describe the Bug
Hi team,
Now that you have received your VC funding (congratulations on becoming a successful startup!), it appears that all further development of Pangolin will include mixed AGPL/proprietary software indicated by the comment below:
c2c907852d/server/auth/sessions/privateRemoteExitNode.ts (L1-L12)While it is great that Pangolin SaaS is receiving a lot of development, this spells concerning news for the "100% open-source" self-hosted solution. As it stands, Linux distributions like NixOS cannot redistribute Pangolin without marking it as
unfree, and more strict distributions like Fedora cannot distribute it at all, since removing the proprietary files would both break Pangolin's build process, and would be illegal, given that deleting files is still an unauthorized modification.We, (myself and @jackrosenberg) the Nixpkgs maintenance team for Pangolin, urge you to reverse course when it comes to mixing AGPL and proprietary software on the same repo. We would highly recommend doing one of the following:
license.tsand other files after community backlash. You've gained a lot of goodwill in the open source community thus far, and abandoning that would be senseless.Environment
To Reproduce
Clone
https://github.com/fosrl/pangolin. There are proprietary files that prevent redistribution of the software as a whole.Expected Behavior
No proprietary software found in the public, open-source version of Pangolin.
@oschwartz10612 commented on GitHub (Oct 6, 2025):
Thanks for the notes and concerns and thanks for the kind remarks on the funding. As we touch on in the article, to continue to push Pangolin forward at the rate we want to, we needed some funding to both pay ourselves and to expand the team. We hope this will allow us to move much quicker on creating features.
It is disappointing to hear that these platforms have such restrictions. We would like to resolve these if possible, but this is a tough one!
On #1
While we could AGPL license these files, we do still need a way to maintain a separate saas base, so I don’t think we can purse this. If anyone could just copy and run our saas that would make it a bit hard for us to build a successful business and keep pushing this software forward.
On #2
We were previously maintaining the cloud platform as a fork, this was extremely painful development-wise. There are endless merge conflicts on every change and an overhead of needing to think about if you need to add something upstream in the main repo and then bring it downstream. The overhead for this was slowing us down and breaking things in the cloud and it became unsustainable.
If we were to ensure that when using the build flag, proprietary code is not included in the build output would this allow it to remain “open source” in the eyes of these platforms? I am not familiar with the restrictions!
@SigmaSquadron commented on GitHub (Oct 6, 2025):
If this was a compiled software project, these restrictions would not apply, but adding any file marked as
privateto theindex.tsfile of a directory would include their code in the final JavaScript output, even if their logic makes them a no-op. Because of this inclusion, the final output becomes proprietary, even though no proprietary code actually runs.It's true, the AGPL license would technically allow anyone to run a copy of Pangolin SaaS, but in practice, this won't happen for two reasons:
Several companies in a similar situation as Pangolin have successfully used the AGPL to make it unattractive for competitors to use their software, while still allowing FOSS usage by individuals. On the posts below, the usual turnout is that the open source community is respected, and all corporations using their software were forced to buy a commercial license because AGPL is incompatible with their software.
As of 2025, there are zero competitor projects using the AGPL code of these companies. All competitors were forced to build their own system from scratch, as AGPL made it impossible for them to innovate competitively without publishing their changes.
I understand if this still seems like a bad option - many companies are still afraid of competition, despite the protections of the AGPL. Another option would be to clearly segregate the proprietary code in a separate directory, and adding a provision to the Commercial License that deleting those files is allowed for building the 100% AGPL self-hosted version of Pangolin. This would mean not including their code at all in the self-hosted version, and Pangolin would still need to function if those files are not included. This does seem like a worse option than just trusting in the provisions of the AGPL and their unsavoriness to competitors, which is proven to work given the policies companies like Google have implemented when it comes to AGPL: https://opensource.google/documentation/reference/using/agpl-policy
This is not necessarily true, as the license only requires one to publish the code publicly if the software is being hosted publicly. This means that corporations using Pangolin internally don't actually have to publish anything, but as soon as Pangolin is running on the open Internet and proxying to the public, the requirement to publish the sources publicly is in effect. This makes it extremely unattractive for anyone building a SaaS competitor. ↩︎
@disinclination commented on GitHub (Oct 8, 2025):
Concerns around this was raised 8 September (https://github.com/fosrl/pangolin/issues/1187#issuecomment-3265768874) - quite sad to Pangolin go this route.
@slimshizn commented on GitHub (Oct 8, 2025):
It would probably be to the developers benefit to hire some talent for a couple different purposes.
First would be to hire someone to help them navigate the proper ways to profit from their work. Obviously we can see that this has become a difficulty with the constant battle between the open source community and the devs slipping in proprietary aspects behind a paywall or "managed" self-hosting option, while also promising to make sure both are in parity with another.
Secondly would be hiring someone who could reply to these types of issues with the public. Claiming you don't know or aren't familiar with the restrictions is a bad look, and at least to me speaks that they are instead doing this with purpose.
Either way I have to agree with @disinclination that it is sad to see this go on.
@slimshizn commented on GitHub (Oct 8, 2025):
In before "pulling a Emby"...and
@oschwartz10612 commented on GitHub (Oct 8, 2025):
@SigmaSquadron appreciate the thoughtful response. I really do. We dont disagree that the AGPL route might work. I think you are right it makes it functionally impossible for a competitor to use the code and with the tech overhead I think its also unlikely. We could explore this. Our concern given the self-hostable nature of the project that by using AGPL larger companies using it for the indented purpose would have no reason to come to us to pay for the product because they can just build as "SAAS" and use it themselves and get the multi tenancy or ease of use features we are offering in EE and SAAS. Not sure the best way to handle this one. A project doing it with a "special" license is https://github.com/Infisical/infisical
I will talk about this more with Milo and we can come back with our thoughts.
On the tech side Pangolin is a "compiled" javascript project using esbuild. The front end is a separate thing (and we could probable just AGPL that). But wondering if there is some work we could do here along your thinking of just simply making sure no FC licensed code makes it into the final server.mjs esbuild compiled object. I feel like that could get us to where we need to be.
@slimshizn Plan is to expand the team now that we have some funding to do so to bring on expertise. While I understand your point, I think engaging in a healthy discussion about something you dont know in public to find the best way to do things is a healthy way to work with a community and shows maturity.
@disinclination geoblocking and health checks are now open source and will be available in 1.11.0. Thanks.
@disinclination commented on GitHub (Oct 8, 2025):
@oschwartz10612 - I wasn't making reference to the feature disparity. It was reference to the fact that Pangolin is being inconsistent when it comes to the way it is treating it's open source community alongside the paid version of the product.
If you read the comment you would've seen that it was a worry that at some stage Pangolin would pull the rug on it's open source community. Splitting the licenses like mentioned above doesn't help that concern.
@oschwartz10612 commented on GitHub (Oct 8, 2025):
@disinclination gotcha. I think you have to just take my word for it that this is not the plan. I understand that might not be good enough. We are sticking with our statement that the OSS version of Pangolin will be fully featured and competitive. I think Grafana is a good model for this where they have some things in their "open cloud" but really self hosted Grafana itself is almost fully featured. This is where we are headed. We are not shy about engaging with the community about things that need to be in parity and we are OSSing health checks and geoblocking for this reason!
@anon79678 commented on GitHub (Oct 8, 2025):
I am having a hard time understanding what you are trying to achieve here. As a "large company", why would we choose to go with Pangolin over Cloudflare? I still need to self host the node, which has absolutely 0 effect on potential DDoS attacks and also means there is additional costs or maintenance required from our end, along with paying the fee for the cloud service. Not really seeing the financial incentive as the consumer here. If the idea is to keep it, "internal" there are countless enterprise solutions for that already and Cloudflare also offers a better option.
I understand that you want to earn money from this project but, this seems to be very ill conceived and a rushed idea.
@slimshizn commented on GitHub (Oct 8, 2025):
@oschwartz10612 I'm trying to understand what this means, on one sentence you are saying that Pangolin will be fully featured, then in another you are referring to using the Grafana model which is almost fully featured. So is it fully or almost fully?
@SigmaSquadron commented on GitHub (Oct 8, 2025):
In practice, this will never happen, as it's simply not how the corporate world works. As a company, you aren't self-hosting things willy-nilly regardless of their license and compliance requirements. If a company needs Pangolin's features, they will buy an EE license if they think it's fairly priced, because if and when Pangolin breaks or isn't compliant with some regulatory requirement, they will want a support team with a decent SLA to scream at. In all my years in the industry, I have never witnessed or heard about a company self-hosting infrastructure software, especially AGPL software, so this feels like a knee-jerk reaction to something that was a non-issue to begin with.
Myself, and probably a lot of people in the community see the value of a fully open source Cloudflare alternative. If Pangolin continued to include proprietary software, then there'd be no reason to not use Cloudflare - the greatest strength of a startup is differentiation and innovation, so making another proprietary solution is a step backwards, as if you're no different than Cloudflare, no one will care about Pangolin.
I must say I agree. Although some of the actions taken by you and Milo have been questionable, it's clear that they were not taken out malice, but were in fact misrepresented technical shortcomings.
It's important to take this (and past) discussions to heart, and be mindful of implemening more features in the Managed/SaaS/EE versions of Pangolin while ensuring the Self-hosted version gets them as well, when reasonable. Obviously the self-hosted edition will never need Stripe payments or Redis caching for user limits, but features like geoblocking and white-labeling should be added, especially since the latter is usually considered a staple of the freedom of FOSS software. For example, here's Kanidm's customisation documentation: you can white-label the server, but their brand identity is still present via a "Powered by" label, and the overall UI causing it to be unmistakably a Kanidm server. On the other hand, software that restricts branding changes, like
open-webui, a LLM web interface, is usually viewed with distrust, as the proprietary branding restrictions turned them into proprietary software.Working with the open source community is both a question of trust (we trust you to not turn your software proprietary, and you trust us to not misuse your FOSS software) and a question of licensing, and turning features proprietary breaches that trust. I should also note that goodwill decreases over time. If you're just open-sourcing the geoblocking and healthchecks because of this backlash, you'll be viewed more negatively than if you were proactive about OSS feature parity. Fortunately, Pangolin is still in its infancy, so this will all be water under the bridge soon enough, given you play your cards right.
I'm hoping this is the last time a discussion like this must be held, as if after a legal and industry consultation you're still unsure about a fully AGPL license, then you'll be happy to know that all you need to do is follow Infisical's lead. Put all proprietary files inside a single
private/directory in the root of the repository, and then set up GitHub releases to publish the source code sans that directory. This means that downstream can fetch the fully FOSS code of Pangolin without the proprietary bits, and there's no chance of cross-contamination during the build.@anon79678 commented on GitHub (Oct 9, 2025):
100% agree with everything @SigmaSquadron stated above.
I think many of us are in the same boat and that's why there has been fairly vocal concerns around this over the past month. From a hobbyist perspective Pangolin is a great alternative to Cloudflare but from a business viewpoint, (especially a larger company) it makes very little sense to use Pangolin as opposed to Cloudflare or another established competitor. As you stated, "
In practice, this will never happen, as it's simply not how the corporate world works" which is the truth. I really hope this sparks proper discussions around the subject and leads to meaningful changes.@oschwartz10612 commented on GitHub (Oct 9, 2025):
I have to say we are leaning toward the Infisical method. I think we can make that happen fairly easily. Things are fairly separated already into private directories and I can work on breaking the imports at build time or something like that - ill do some experimentation to see if this can be done well.
Appreciate the discussion on the features. Things are going to be as open source and free as they can be while we drive something for business to pay for. IDK what that will be yet but I would appreciate some latitude from the community while we figure that out. We want to work with you to figure out what that is and if we can't find something Pangolin is going to go away. We can sell support - Grafana did this - but had to grow out of it to build a business around their product.
Thanks everyone. Let us take some time to do a legal and industry consultation and figure this out. I think we have covered things. I am going to lock this and come back with a plan in a bit. Please give us some time to plan.
@oschwartz10612 commented on GitHub (Oct 10, 2025):
Alright we are back with an update. We have gone the Infisical route. I understand that might not be what everyone is hoping for but I think it will be best for how we want to manage the project.
So what I did:
In
chungus 2.0 d92b87b7c8984e56b2ee03f8afe4958a1a0bd983I have moved all FC license code into server/private. Anything outside of this directory is AGPL only. Any AGPL only code that needs to import any private code does so with a#dynamicimport.There are three esbuild plugins. The first makes sure the AGPL code does not import anything from the
#privatedirectory directly. The second makes sure that theprivatedirectory code does not import using#dynamicas it would not resolve. And the third rewrites#dynamicimports depending on the build version. So with a-b saasit will import dynamic fromserver/private, with a-b ossit will import fromserveronly. This should ensure that no FC code is built into the community version.The frontend is fully AGPL licensed. There are
#privateimports in the frontend but these are only for typescript types and are therefore not included at build time.Feedback about this build process is appreciated.
Lets keep this discussion on topic around the AGPL build process for the community version and not about features. Expect to see a published update in the next few days with how we are going to handle features. I think we have found a way to keep as many people happy as possible. We also expect to start building and publishing the EE version.
@SigmaSquadron commented on GitHub (Oct 11, 2025):
Hi team,
I have reviewed the changes in
d92b87b7c8984e56b2ee03f8afe4958a1a0bd983and built Pangolin from source on that HEAD. It's a step in the right direction, and theossbuild is very close to 100% AGPL. However, buildingserver.mjsresulted in the code from the following files being present in the build, which turned it proprietary:server/private/lib/billing/createCustomer.ts: imported inserver/lib/createUserAccountOrg.ts. This also importsserver/private/lib/stripe.ts,server/private/lib/config.tsandserver/private/lib/readConfigFile.ts, so removing the call increateUserAccountOrg.tswill remove all files from the build.And there is one big licensing issue with the type checks as well:
Unfortunately, this is not compliant with the AGPL, as the build fails if the proprietary files are deleted.
This means that in order to comply with the AGPL, these files must be optional. Downstreams must be allowed to remove these files in order to get a 100% AGPL repository that can build a 100% AGPL work. Please note that as it stands, AGPL is actually overwriting the proprietary license: anyone is allowed to modify the proprietary files because they are required for the build.
To remedy this, the following needs to be done:
One may remove all FCL-licensed files from the repository. (which would obviously make asass/enterprisebuild impossible, but allow for a 100% AGPLossbuild, as we can fetch just the AGPL code)AND
private. Take your pick.) The frontend cannot depend on the proprietary code at all, otherwise the proprietary license becomes invalid and theprivatefolder is licensed under the AGPL due to its viral nature as a copyleft license.Additionally (and unrelated), the
server/private/cleanup.tsfile needs the proprietary license header to avoid license ambiguity.@oschwartz10612 commented on GitHub (Oct 11, 2025):
Thanks for the though review! I really appreciate it!
I will separate the types tomorrow into an AGPL file.
I don't think I see a problem including that language in the FCL. We will be compiling and publishing the FCL in the next couple of days and open to comments. This will also make clear the plan on the EE.
I think the billing file was a mistake probably imported without the
#privatedue to a move. Should be an easy fix.@jackrosenberg commented on GitHub (Oct 11, 2025):
Hey guys,
I just want to say thank you for working with us on this. It makes me happy to see Pangolin continue as a fully FOSS project. I understand that keeping Pangolin profitable is hard, and that things will need to change so Pangolin can grow. That said, I urge you to keep communicating with the community, as you have been. They are your greatest asset, and largest stakeholder. Open and honest communication goes a long way in situations like this.
Also, huge thank you @SigmaSquadron for your sound advice and licensing expertise.
@oschwartz10612 commented on GitHub (Oct 12, 2025):
Thanks @jackrosenberg appreciate the response and the work you and @SigmaSquadron do!
In
2c63851130I have I think fixed the type problem and the#privateimport for certs that was a mistake. I think we are probably good to go now - at least as it is on dev? LMK.We will be publishing a first version of the FCL shortly and can do a little RFC. The required language will be in there. We are going to try something to allow anyone who wants to run it and does not need AGPL to be able to do so for free if they are "not a business". Definition TBD.
@SigmaSquadron commented on GitHub (Oct 12, 2025):
Ran the build again, and we're almost there! The "compiled" (optimised?)
server.mjsfile for Pangolin is free of proprietary sources, but the build process still requires the private folder to exist and contain the proprietary code. The AGPL requires the entire build process to contain AGPL code only, so the build needs to succeed even if that directory does not exist.I thought just moving the types would fix that, but apparently not. I'm not very familiar with Typescript's dynamic imports and NextJS' type checking, but the test for whether or not the build complies with the AGPL is simply to remove the
private/directory and runnpm run build:<db>. If the build suceeds, it's AGPL. Otherwise, the proprietary code is being turned into AGPL code by virtue of being required by (and requiring) AGPL code to build.@oschwartz10612 commented on GitHub (Oct 12, 2025):
My bad should have done that test deleting the directory. I did so now after a few last tweaks. And it appears to build.
@SigmaSquadron commented on GitHub (Oct 12, 2025):
Build succeeds, Pangolin is once again compliant with the AGPL!
@oschwartz10612 commented on GitHub (Oct 12, 2025):
👏 thanks for the help on this!
@disinclination commented on GitHub (Oct 12, 2025):
I know this is closed but just want to say thanks to @oschwartz10612 for the effort put in and restoring the license to what it should be.
@ssddanbrown commented on GitHub (Oct 13, 2025):
Just to add to the conversation here, it's generally best to completely separate AGPLv3 and non-AGPLv3 version codebases (and build versions) so they're distributed separately. You can dual license with the AGPLv3 (where/if you have the rights) but distributing with a mixed license causes issues. Under section 7 of the AGPL a user could just ignore any extra (non-compliant) terms you're setting on related elements within the distribution that are part of the application:
I have a little extra context on my site here: https://isitreallyfoss.com/concerns/agplv3-mixed/
It would be ideal to state this in the LICENSE file, since the current wording leaves users needing to check the headers of every file to fully understand the licensing. Although, as said above, it's best not to share those non-AGPLv3 files at all with the AGPLv3 codebase.
From a search, it looks like it's still a little complex though since the private directories are in multiple different subfolders of the server directory.
Lastly, from a glance (unless I've missed something), it's not currently easy to understand the license of the provided binaries (GitHub releases) or the docker images. Do/will these contain any of the non-AGPL code or are they AGPLv3 only?
@SigmaSquadron commented on GitHub (Oct 14, 2025):
I agree, but the Fossorial team mentioned that it is technically infeasible to maintain two separate distributions of Pangolin, and separating all of the proprietary code to the
server/privatedirectory means that can easily be removed by distributions and users, which is frankly good enough.Two things that could be added for more clarity:
server/private/.LICENSEfile in the root of the repository explaining that all code is AGPL except for everything inserver/private/. For an AGPL build, delete the folder.This is misleading. Take a look at the
devbranch; all proprietary code has been moved to one single folder.To reiterate this to the Pangolin team and everyone else: if you are publishing pre-compiled images or binaries on GitHub or Docker, DELETE THE
private/DIRECTORY BEFORE BUILDING! The AGPL release of Pangolin can only be AGPL if the resultingserver.mjsfile is built from a fully AGPL repository.