Why is the usage of a CDN an improvement?

[tedstriker]

I'm struggeling to understand, why the usage of CDNs to load external program parts is considered an improvement?
How does the dependency on an external service and an available internet connection make things better?
Maybe one of you can shed some light on this.

[alam00000]

The reason BentoPDF loads these modules from CDN rather than bundling them directly now comes down to licensing clarity for our commercial dual licensing.

BentoPDF is available under both AGPL-3.0 and a commercial license. PyMuPDF, Ghostscript, and CoherentPDF are also AGPL-licensed, and while AGPL-to-AGPL is technically compatible, bundling third-party AGPL code into a product that's also sold under a commercial (non-AGPL) license creates a legal grey area. By not bundling them, we keep a clean separation. BentoPDF's own code can be commercially licensed without any ambiguity about the AGPL obligations of these third-party libraries.

As for the practical concern about CDN dependency, the WASM files are only fetched once. After the first load, they're cached by the service worker, so every subsequent visit serves them instantly from the local cache with zero network requests. It effectively works offline after the first visit.

If you prefer no external dependency at all from the get go, you can self-host the WASM files on your own infrastructure and point BentoPDF to your internal URLs.

[Viable8237]

I was about to ask the same question.

The reason BentoPDF loads these modules from CDN rather than bundling them directly now comes down to licensing clarity for our commercial dual licensing.

@alam00000 wouldn't it be possible to bundle the modules for those who want to use the non-commercial licence and keep the commercial version without them?

As for the practical concern about CDN dependency, the WASM files are only fetched once. After the first load, they're cached by the service worker, so every subsequent visit serves them instantly from the local cache with zero network requests. It effectively works offline after the first visit.

Running BentoPDF offline and knowing that it cannot connect to the internet even if it wanted to still provides a better peace of mind though (especially when dealing with sensitive data).

If you prefer no external dependency at all from the get go, you can self-host the WASM files on your own infrastructure and point BentoPDF to your internal URLs.

If you mean this then that's quite a lot of work compared to deploying a simple container. I can imagine keeping everything up to date would be pretty cumbersome too. Would it even be possible to use automatic updates or would I have to repeat the process after every BentoPDF/module update?

[tedstriker]

Thanks for the explanation 🙏

[Viable8237]

@alam00000 would you please look at my comment and let me know what you think?

[alam00000]

@Viable8237 sorry I didn't get notified. Please let me go through it. I'll get back to you on this

[alam00000]

@Viable8237 What you said falls in a grey area and even though maintaining two different versions is a good idea, but as a solo dev, it'll be very hard for me to maintain it. Currently, I've provided a helper script which automates the process.

However, I've put that in the roadmap and it'll be certainly implemented in the future

[Viable8237]

What you said falls in a grey area...

I thought that you would be in a legal grey area only if you had one version and bundled the modules even if you also sold BentoPDF under a commercial licence. However if you had two different versions:

1. An AGPL version with the modules bundled
2. A commercial version without the modules

It would not be a grey area, would it? You may also consider hiring a lawyer to let you know what options you have.

...as a solo dev, it'll be very hard for me to maintain it. Currently, I've provided a helper script which automates the process.

I understand that it might be hard to maintain and thank you for the script. It still makes the air-gapped updates more complex (since I suppose it requires either manually running the script every update or setting up a cron job) but I appreciate your effort to simplify the process.

However, I've put that in the roadmap and it'll be certainly implemented in the future

Awesome, I'm looking forward to it! Thank you once again.