> On Sep 7, 2026, at 5:49 PM, [email protected] wrote:
> 
> 
> Am 08.09.2026 um 02:43 schrieb Dave Fisher:
>> 
>>> On Sep 7, 2026, at 5:27 PM, [email protected] wrote:
>>> 
>>> 
>>> Am 08.09.2026 um 02:20 schrieb Dave Fisher:
>>>>> On Sep 7, 2026, at 4:21 PM, [email protected] wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I am on a modernization for our pdf importer.
>>>>> 
>>>>> I would like to replace poppler becouse its gpl v2 and the license is 
>>>>> just difficult to digest for our code.
>>>>> 
>>>>> We have 2 other options where to move to.
>>>>> 
>>>>> 1)  Apache PDFBox, with the price of needing java. But our own project. 
>>>>> maybe we could have a collab there.
>>>> I worked with PDFBox years ago. It is in general a lower level object 
>>>> level (COS) layer api. My team built a PDF to Powerpoint converter. It 
>>>> still runs, but I don’t have access to the code base. The lesson though is 
>>>> it is significant work to take PDF a print file format back into the 
>>>> component parts. We did the work over many years on the side.
>>> the conversion from PDF into components we have the code already and we can 
>>> reuse it.
>>>>> 2) PDFium, with the price of beeing class b BSD license, but native 
>>>>> implementation.
>>>> Being C++ this is likely a better fit.
>>> Can we simply use it? or is there some review process necessary?
>> I’m looking at 
>> https://pdfium.googlesource.com/pdfium/+/refs/heads/main/LICENSE and see 
>> ALv2. Where do you see BSD? And what number of clauses?
> https://github.com/documentcloud/pdfium/blob/master/LICENSE 
> <https://github.com/documentcloud/pdfium/blob/master/LICENSE> says BSD 
> 3-clause

This license is acceptable as it is category A - 
https://www.apache.org/legal/resolved.html#category-a

Best,
Dave

>> 
>> 
>>>>> I try our own food first. Then we still can decide to move on.
>>>>> ---
>>>>> 
>>>>> A second thing.
>>>>> 
>>>>> Import yes or no, we maintain an own pdfparser. It reads pdf, identifies 
>>>>> passwords encrypts and so on.
>>>>> 
>>>>> It is not the full import, just enough to identify and open the file in a 
>>>>> special case of hybrid pdf.
>>>>> 
>>>>> We could replace that code with qpdf. It would serve the same purpose, 
>>>>> same license.  But less maintenace for us.
>>>> From https://gpdf.dev
>>>> 
>>>> gpdf is an open-source, MIT-licensed PDF generation library for Go
>>>> 
>>>> That’s not a parser.
>>> I am proposing QPDF https://github.com/qpdf/qpdf
>>>>> Is that something we should go for?
>>>>> 
>>>>> 
>>>> Best of luck,
>>>> Dave
>>>> 
>>>>> All the best
>>>>> 
>>>>> Peter
>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected] 
> <mailto:[email protected]>
> For additional commands, e-mail: [email protected] 
> <mailto:[email protected]>

Reply via email to