Yeah, it's basically dying and living on old fame. We had to buy a license a few years ago for a customer who needed support for some things that PDFBox did not support, Of course it's not just a license, you have to buy multiple licenses for production, development and so on. It was okay until we hit a bug, iText could not read some form fields correctly and was basically changing the PDF contents on save. We opened a support ticket with all the details, sample files and code to reproduce. The ticket stayed open for a year. After a year they asked us to pay for more support. We showed them the open ticket and never heard from them again.
> When using iText Core/Community under AGPL, you must prominently mention iText and include the iText copyright and AGPL license in output file metadata, and also retain the producer line in every PDF that is created or manipulated using iText.
Hmmm... they link to the AGPL and state it's under that. In a conflict between the two, the website extras, and the AGPL requirements, which would win?
I personally think the AGPL would win, but it's not something I'd be willing to enter a legal battle over.
Exactly. That’s why I said avoid. Even if you think the AGPL prevails.
You already know that the licensor has his own, idiosyncratic interpretation. He either misunderstands the AGPL (probably clause 7 par 3 b), or he’s trying to deceive you. Both cases can easily lead to hostilities.
Even more confusing is that the AGPL explicitly deals with this scenario:
“
If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.
”
The (A)GPL explicitly allows certain restrictions under section 7 (Additional Terms).
Back in the day FlowPlayer (a JavaScript component to play videos on the web) used additional terms per GPL section 7 to force users of their unpaid version to keep their mark intact in the UI or for modifications keep a "based on FlowPlayer" in.
I followed the discussion on this back then and the consensus seemed to be, that this is in line with what section 7 of the GPL allows. I think there was even a statement of the FSF, but I could not find it anymore.
Of course the iText case is different, but I believe section 7 (especially 7b) allows a way to add terms for attribution.
I stopped using iText back when it changed licensing because the developer wanted his government to pay to use it (or something like that). What ever happened with that fiasco?
As the commenters above note, the "upgrade" to AGPL was both highly profitable to Lowagie and caused many to shift to an open-source fork.
IMO forks are the great leveler; if your brand strength and your ongoing investment in engineering + community make a license shift viable (and if you retain the trust of your contributors) then everybody wins... but if you make a license shift and just rest on your laurels, forks will destroy your value. I don't know enough about the history to know what happened in this case, but based on the successful exit, I imagine it's somewhere between these two extremes.
I thought most were using Apache PDFBox these days. Anyone have any thoughts on how the two libraries compare in 2025? I'm particularly interested in programatic creation of PDFs.
I know historically PDFBox is a bit lower level whereas iText was a bit more user friendly, but that's not too big of a deal for me.
PDFBox is the GOAT of backend pdf libraries. We've built incredible things with it, plus pdfjs on the front-end - full compliant e-signature, templated pdf generation, in-browser pdf editing. Looked deeply at alternatives but very happy with our choice. In particular using itext vs pdfbox feels like using WordPress vs Rails - try to build anything very serious and you will be happier you picked the more capable, lower-level library.
I use PDFBox. There are some FOSS layout libraries you probably want to add one or more of, depending on your needs.
It's disgustingly fast and capable. In one project we crunched out 150k PDF documents in less than forty minutes from roughly 6 GB input data, on a mid laptop, including a fair bit of other file types related to those documents.
Fairly low level but not hard to get started with. You might have to wrap it in a module yourself if you're using those.
Thanks. I'm using it for a side project now and have my own layout library which I may consider open sourcing. I started to question if I made the wrong decision if OpenPDF had more momentum!
It's a fine decision. The degree of control you can have is a life saver sometimes, especially if you find you need to produce documents that adhere to specific PDF standards, or need to invent some customised layout element. Allows both the quick and dirty, and the very sophisticated.
You could use both if you want, I've done it in toy projects when evaluating.
I recently used Okular (KDE linux application) to annotate a PDF, the interface to add text was clunky, not inline. Is there a better app available for linux? It uses the poppler library as its back end:
If I recall correctly, earlier versions of iText lived on in Linux distributions as part of pdftk, until that became unbuildable because it had a hard dependency on GCJ: the command-line parser was written in C++ for some reason.
Most previous users of pdftk have probably migrated to qpdf by now.
pdfbox is just as good for 99.9999% of documents. We used to use iText and in the last renewal, they tried to 10x our yearly license cost to the point it would have been more expensive than our AWS bill. No thanks.
Libraries like iText would be SO good with LLM/vision model integration and vice-versa. Huge opportunity to use these tools to generate more training data based from siloed PDFs.
They're now owned by "copyright trolls".
They hit up a company I know because their web-crawler found a PDF that someone generated using their library over a decade ago.
https://beemanmuchmore.com/software-licensing-trolls-apryse-...
I'd avoid it.
Yeah, it's basically dying and living on old fame. We had to buy a license a few years ago for a customer who needed support for some things that PDFBox did not support, Of course it's not just a license, you have to buy multiple licenses for production, development and so on. It was okay until we hit a bug, iText could not read some form fields correctly and was basically changing the PDF contents on save. We opened a support ticket with all the details, sample files and code to reproduce. The ticket stayed open for a year. After a year they asked us to pay for more support. We showed them the open ticket and never heard from them again.
> When using iText Core/Community under AGPL, you must prominently mention iText and include the iText copyright and AGPL license in output file metadata, and also retain the producer line in every PDF that is created or manipulated using iText.
https://itextpdf.com/how-buy/AGPLv3-license
Not really AGPL, they just advertise AGPL and mean something else. Avoid.
Hmmm... they link to the AGPL and state it's under that. In a conflict between the two, the website extras, and the AGPL requirements, which would win?
I personally think the AGPL would win, but it's not something I'd be willing to enter a legal battle over.
Exactly. That’s why I said avoid. Even if you think the AGPL prevails.
You already know that the licensor has his own, idiosyncratic interpretation. He either misunderstands the AGPL (probably clause 7 par 3 b), or he’s trying to deceive you. Both cases can easily lead to hostilities.
Even more confusing is that the AGPL explicitly deals with this scenario:
“ If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. ”
https://www.gnu.org/licenses/agpl-3.0.en.html
I think the expectation here is that commercial users purchase the AGPL opt-out.
The (A)GPL explicitly allows certain restrictions under section 7 (Additional Terms).
Back in the day FlowPlayer (a JavaScript component to play videos on the web) used additional terms per GPL section 7 to force users of their unpaid version to keep their mark intact in the UI or for modifications keep a "based on FlowPlayer" in.
I followed the discussion on this back then and the consensus seemed to be, that this is in line with what section 7 of the GPL allows. I think there was even a statement of the FSF, but I could not find it anymore.
Of course the iText case is different, but I believe section 7 (especially 7b) allows a way to add terms for attribution.
I don’t think the outputted files count as part of the program, which makes that requirement even more absurd.
Imagine if Bic said you had to write their name on every page you used one of their pens on.
The output can contain code that itself is under GPL. Basically the bison case.
Not a lawyer but these could be valid additional terms under section 7 (likely 7b) of the AGPL.
I stopped using iText back when it changed licensing because the developer wanted his government to pay to use it (or something like that). What ever happened with that fiasco?
The classname "lowagie" will live forever in the memory of Java developers, but we've all abandoned itext for the fork:
For some context on that infamous classname, see https://stackoverflow.com/a/13515403 and https://entreprenerd.lowagie.com/
As the commenters above note, the "upgrade" to AGPL was both highly profitable to Lowagie and caused many to shift to an open-source fork.
IMO forks are the great leveler; if your brand strength and your ongoing investment in engineering + community make a license shift viable (and if you retain the trust of your contributors) then everybody wins... but if you make a license shift and just rest on your laurels, forks will destroy your value. I don't know enough about the history to know what happened in this case, but based on the successful exit, I imagine it's somewhere between these two extremes.
I thought most were using Apache PDFBox these days. Anyone have any thoughts on how the two libraries compare in 2025? I'm particularly interested in programatic creation of PDFs.
I know historically PDFBox is a bit lower level whereas iText was a bit more user friendly, but that's not too big of a deal for me.
PDFBox is the GOAT of backend pdf libraries. We've built incredible things with it, plus pdfjs on the front-end - full compliant e-signature, templated pdf generation, in-browser pdf editing. Looked deeply at alternatives but very happy with our choice. In particular using itext vs pdfbox feels like using WordPress vs Rails - try to build anything very serious and you will be happier you picked the more capable, lower-level library.
I use PDFBox. There are some FOSS layout libraries you probably want to add one or more of, depending on your needs.
It's disgustingly fast and capable. In one project we crunched out 150k PDF documents in less than forty minutes from roughly 6 GB input data, on a mid laptop, including a fair bit of other file types related to those documents.
Fairly low level but not hard to get started with. You might have to wrap it in a module yourself if you're using those.
Thanks. I'm using it for a side project now and have my own layout library which I may consider open sourcing. I started to question if I made the wrong decision if OpenPDF had more momentum!
It's a fine decision. The degree of control you can have is a life saver sometimes, especially if you find you need to produce documents that adhere to specific PDF standards, or need to invent some customised layout element. Allows both the quick and dirty, and the very sophisticated.
You could use both if you want, I've done it in toy projects when evaluating.
Does it support tagged documents and PDF2.0 as well?
JasperReports library used that library, and forked it at it's last LGPL version.
I have used their RUPS tool for a while, and it's been great for inspecting the underlying PDF structure.
I recently used Okular (KDE linux application) to annotate a PDF, the interface to add text was clunky, not inline. Is there a better app available for linux? It uses the poppler library as its back end:
https://poppler.freedesktop.org/
Firefox has a minimal PDF annotation editor which works for me
OpenPDF is a fork of iText with Lgpl and Mpl license: https://github.com/LibrePDF/OpenPDF
If I recall correctly, earlier versions of iText lived on in Linux distributions as part of pdftk, until that became unbuildable because it had a hard dependency on GCJ: the command-line parser was written in C++ for some reason.
Most previous users of pdftk have probably migrated to qpdf by now.
pdfbox is just as good for 99.9999% of documents. We used to use iText and in the last renewal, they tried to 10x our yearly license cost to the point it would have been more expensive than our AWS bill. No thanks.
Libraries like iText would be SO good with LLM/vision model integration and vice-versa. Huge opportunity to use these tools to generate more training data based from siloed PDFs.