home *** CD-ROM | disk | FTP | other *** search
/ PC Welt 2006 November (DVD) / PCWELT_11_2006.ISO / casper / filesystem.squashfs / usr / share / doc / libxmlsec1-nss / README.Debian < prev    next >
Encoding:
Text File  |  2006-07-11  |  2.1 KB  |  43 lines
  1. xmlsec and libxmlsec for Debian
  2. -------------------------------
  3.  
  4. The upstream documentation is included with the libxmlsec1-dev package and
  5. located at /usr/share/doc/libxmlsec1-dev.
  6.  
  7. When developing with the xmlsec library, you have a choice of openssl,
  8. gnutls, or nss crypto engines.  By using "pkg-config xmlsec1-<engine>" or
  9. "xmlsec1-config --crypto=<engine>", you can get the necessary compiler
  10. command-line switches for enabling a certain engine.
  11.  
  12. If you want to license your application that uses the xmlsec library under
  13. the GNU GPL, or want your library that uses the xmlsec library to be GPL-
  14. compatible, I suggest using the gnutls engine.  Use of the nss crypto engine
  15. may also be compatible with the GPL, but see bugs #207024 and #207026.
  16. Regarding openssl, there is a bit of controversy about whether it can be
  17. considered part of the OS and therefore make use of a loophole in the GPL.
  18. (See the xmlsec FAQ in the documentation.)  More specifically, debian-legal
  19. takes a hard line and does not allow GPL'd packages that link to openssl to
  20. exist in main.  In the future, support for PGP key types may be added, which
  21. would become another reason to go with the gnutls engine.
  22.  
  23. Note that the library has a dynamic crypto engine loading feature, but I
  24. have not yet enabled it.
  25.  
  26. Regarding nss crypto engine support, beware that there are a number of
  27. packaging issues with depending on libnss and libnspr (part of the mozilla
  28. source package) which may cause trouble down the road (see bugs #200877,
  29. #200878, #207008, #207009, and #48208).
  30.  
  31. Note that a number of the examples included with the -dev package will
  32. not compile successfuly under the gnutls engine (due to lack of features
  33. compared to openssl), and will fail under both the gnutls and nss engines
  34. (due to lack of pem file support, etc.).
  35.  
  36. Upstream has promised that they will increment the number in the library name
  37. name (for example, xmlsec1 -> xmlsec2) whenever a binary incompatibility is
  38. introduced, and that it will always match the soname number.  For this
  39. reason I chose to omit the soname number from package names.
  40.  
  41.  
  42.  -- John V. Belmonte <jbelmonte@debian.org>
  43.