--- Comment #3 from Orcan Ogetbil <oget.fedora(a)gmail.com> 2009-01-26 20:20:26 ---
(In reply to comment #2)
> The way itext and its dependencies (bouncycastle, pdf-renderer,
> packaged by their upstreams, one has to do some rigorous work to provide JNI
> subpackages for each of them, so that pdftk can link to itext-jni (which will
> link to bouncycastle-jni, ...) dynamically.
Pdftk doesn't use JNI. It uses GCJ's CNI. That's how it can statically link
Java libs into a C++ app. The Java libs are natively compiled and then linked
into the C++ program to form a single executable (with a dependency on
Yes. Thanks for the correction.
> Additionally, itext saw big modifications since pdftk
"borrowed" this old
> version. Therefore it is quite possible that even if someone steps up and
> builds these JNI subpackages, one will have to patch pdftk to make it
> compatible with them.
Indeed it will have to be patched, and we have to hope that they didn't remove
some of the stuff which pdftk uses to sort out the licensing.
Afaict pdftk didn't remove that code. The header of that piece of code was
changed to reflect the fact that it is freed.
Yet there are other parts of pdftk where there might be some API breakage.
> Hence I think this package is suitable for rpmfusion-free for
the time being.
No, it's not. There are licensing issues, so it has to go to nonfree.
You may be right, but on a second thought I realized a subtlety here. The code
is freed after it was taken by pdftk. Therefore the headers in the pdftk
package do not reflect this fact. I am not 100% sure whether that piece of code
should be regarded as nonfree.
But then again, FE-Legal isn't happy enough to put this package in Fedora so we
might as well stick to their opinion and label this package as nonfree.
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.