11–20 of 29 posts
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.
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: https://github.com/LibrePDF/OpenPDF
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 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: https://github.com/LibrePDF/OpenPDF
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.
Earlier quoted context omitted.
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
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.
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.
Earlier quoted context omitted.
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 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…
> 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.
“ 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.
Most previous users of pdftk have probably migrated to qpdf by now.
Earlier quoted context omitted.
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.
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.
Imagine if Bic said you had to write their name on every page you used one of their pens on.