[HN Gopher] iText PDF Library turns 25
___________________________________________________________________
iText PDF Library turns 25
Author : alemos
Score : 52 points
Date : 2025-02-18 08:10 UTC (2 days ago)
(HTM) web link (itextpdf.com)
(TXT) w3m dump (itextpdf.com)
| _JamesA_ wrote:
| 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?
| bklyn11201 wrote:
| The classname "lowagie" will live forever in the memory of Java
| developers, but we've all abandoned itext for the fork:
| https://github.com/LibrePDF/OpenPDF
| whizzx wrote:
| Does it support tagged documents and PDF2.0 as well?
| btown wrote:
| 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.
| nogridbag wrote:
| 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.
| cess11 wrote:
| 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.
| nogridbag wrote:
| 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!
| propter_hoc wrote:
| 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.
| DannyB2 wrote:
| JasperReports library used that library, and forked it at it's
| last LGPL version.
| Tomte wrote:
| > 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.
| swsieber wrote:
| 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.
| Tomte wrote:
| 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.
| fweimer wrote:
| 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.
| dec0dedab0de wrote:
| 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.
| weinzierl wrote:
| The output can contain code that itself is under GPL.
| Basically the bison case.
| weinzierl wrote:
| 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.
| weinzierl wrote:
| Not a lawyer but these could be valid additional terms under
| section 7 (likely 7b) of the AGPL.
| swsieber wrote:
| I have used their RUPS tool for a while, and it's been great for
| inspecting the underlying PDF structure.
| angst_ridden wrote:
| 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.
| miahi wrote:
| 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.
| crabl wrote:
| 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.
| roschdal wrote:
| OpenPDF is a fork of iText with Lgpl and Mpl license:
| https://github.com/LibrePDF/OpenPDF
| fweimer wrote:
| 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.
___________________________________________________________________
(page generated 2025-02-20 23:01 UTC)