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.
”
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.
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.
3 replies →
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.
4 replies →
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 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
I have used their RUPS tool for a while, and it's been great for inspecting the underlying PDF structure.
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.