Joined 18 years ago
By just using a local application you will avoid all the problems and most probably have a more performant and capable tool at hand.
Even if you distribute your part of the code under the commercial license, the components make - depending on how they are integrated into BentoPDF - the whole project AGPL again. So it might be possible that all your commercial customers are breaking the AGPL of the included components. For example, if your code directly calls code in the components, the integration is tight and AGPL would most certainly apply. If all you do is call the components as external binaries, then it is fine.
Also, doing this extra work and developing the binary is probably more expensive than just buying a commercial license.
For example, the GPL FAQ has the following part in the FAQ item title "What is the difference between an 'aggregate' and other kinds of 'modified versions'?" (https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation):
> If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
A combined work needs to be distributed under the AGPL, an aggregated work does not. Since Ruby is interpreted the code of HexaPDF loaded from the application would run in the same address space and thus it would be a combined work.
The following two links are also relevant: https://opensource.stackexchange.com/questions/5003/agplv3-s... and https://opensource.stackexchange.com/questions/5010/can-i-us...
What the commercial license does is a different thing. You could charge once OR once and for every upgrade to an (arbitrarily defined) new major version OR each year via a subscription OR ... It is really up to you and how you want to handle this.
I agree that laying out PDFs could be made easier by using a declarative mechanism instead of coding. However, I'm still not sure what the best way would be to do that. Using HTML/CSS for this and doing it right would entail implementing something like PrinceXML...
With the current layout model you have the possibility to implement price layouts, like the one needed by Swiss QR bills (see https://x.com/_gettalong/status/1748823670368117154), or just define the general layout and let HexaPDF decide the final position (see https://hexapdf.gettalong.org/examples/pdfa.html).
If you have any ideas, how laying out PDFs could be made simpler, I'm all ears!
Once you have parsing and writing of a simple PDF file going (sections 7.2, 7.3, 7.4, 7.5, 7.7), add in support for encryption (section 7.6). Now you are able to handle to at least parse and write nearly all PDF files.
Then implement all the things you need gradually For example:
* Need support for parsing or creating the contents of a page? -> sections 7.8, 8, and 9. Mind you, start out with only supporting the built-in PDF fonts for creating text and later add support for TrueType (easier) and OpenType (harder if you need to implement the font parser yourself).
* Need support for annotations? -> section 12.5
And so on.
If you just need to store the metadata in the PDF, you only need support for parsing and writing a PDF because this usually also entails that you can modify the PDF object tree which is needed for storing the metadata. However, if you need to store that metadata in a way that is usable for other PDF processors, you would need to store it as an XMP file and creating that is yet another deep dive if you don't have an XMP library available. See section 14.3.2 in the PDF spec for this (btw. the latest PDF spec is available at no cost at https://pdfa.org/resource/iso-32000-2/).
My guess is this all started many years ago when Adobe Reader was the standard PDF reader and it was (and still is) very lenient when it comes to PDFs that aren't exactly following the specification.
So what did everyone else? They followed Adobe's lead because "But, but, ... it works in Adobe Reader!"
