Re: Writing PDF files

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Tue, 18 Oct 2011 13:46:10 +0200, Jeffrey Creem <jeff@thecreems.com> a  
écrit:
> The idea behind the LGPL language there is that it must be technically  
> possible to re-create the program in question and update/replace/bug  
> fix/modify the portion that is covered by LGPL.
OK! That's simply GPL with no contamination so. LGPL, is still GPL  
(internally) for what is licensed with it, and to fulfill the requirement  
of the GPL only on that part, you need some kind access to it. That's  
rather clever finally, kind of bridge between two worlds.

> The license language is not asking you to warranty that there
> exists an continuing stream of LGPL library updates that will
> always link against the .o files of  your application,but providing them  
> does allow users at least the freedom to fix bugs in the LGPL portion  
> and create a new application.
Technically speaking, for that kind of maintenance, dynamic linking is the  
better way to go. However, the case of an API change is still a challenge  
even if wrappers may be an option. If this ever occur, the best is to ask  
the provider of the proprietary application, to build a release compatible  
with the new API, what he/she would probably be glad to do, if he/she  
cares to its users (and reputation). If not an available service, I anyway  
believe this is unlikely someone could safely play with binary objects  
files to fix something --- too much an unsafe hack --- better play on  
something you have access to source and possibly design a wrapper or a  
custom version of the shared library. So, I still vote Shared Library  
(unless I've still not understood).

Thanks for clarifications Jeffrey :) (was clearer than the Wikipedia prose)

-- 
“Syntactic sugar causes cancer of the semi-colons.”  [Epigrams on  
Programming — Alan J. — P. Yale University]
“Structured Programming supports the law of the excluded muddle.” [Idem]
Java: Write once, Never revisit