As the author of that post, please allow me to clarify:
My comment there starts with a conditional expression ("if"), regarding the suggestion that a compiled component might be a work derived from GPL-governed source.
If that were the case, the component would inherit the distribution rights and responsibilities of the work it was derived from.
That would seem unlikely, however, because LC was dual-licenced, so even during the period in which they also distributed an open source edition of LiveCode, they had to maintain a proprietary edition as well.
Though like most modern software they make extensive use of open source packages, they've shown good diligence in choosing only those with licenses like MIT which are well suited for both open source and proprietary distribution.
Two posts later the original producer of the component clarified that the LC external is based on PDFium, which is distributed under MIT license:
http://lists.runrev.com/pipermail/use-l ... 66435.html
So the "If" in my reply evaluates to false: since the component was not derived from to the GPL'd xPDFReader, GPL license terms are not relevant to the component LC ships.
Moreover, the use case presented was one for an in-house tool, not anticipated to be distributed to others.
Since the GPL is a distribution license, any personal use of GPL-governed works carries no inherited rights and responsibilities from that license. The software is not being shared, so there is no obligation to provide source to a recipient.
This is useful in appreciating the value of Stam's solution he linked to. While it does make use of the GPL-governed xPDFReader, that use would not appear to require sharing source, because the use case is not part of a derivative work, as would be the case if LC had distributed a derivative work in the form of an external.
If all this seems complex, wait till you see what PDF does to the format of the text it contains as evidenced through extraction.
