On Thu, May 02, 2013 at 11:07:34AM -0400, Derek Atkins wrote: > Benjamin Kaduk <[email protected]> writes: > > > Necessary is debatable. Desirable, well, all the reasons Debian tries > > hard to eliminate bundled libraries. The kernel's crypto library (or > > even an openssl krb5 backend) will offer aesni acceleration, which > > hcrypto does not. > > OpenAFS cannot use the Linux kernel's crypto because last I checked the > Linux KCrypto was GPLONLY, and OpenAFS was not GPL and therefore > couldn't use the API.
I'm perfectly free to build an OpenAFS kernel module that uses Linux Kcrypto. What's murky is what happens if I distribute that resulting binary. I have yet to see a case where anyone besides me has actually 'distributed' an openafs.ko module. ... So 'cannot' is rather misleading, and if you look at crypto/aes_generic.c the *original* code written by a Brian Gladman is licensed under a BSD-style license. I can easily write a GPL/IPL dual-licensed module that re-exports the symbols as 'EXPORT_SYMBOL_DFSG'. I can't see why someone would actually care about this... If you grab any android device there are significantly worse violations of the intent of the linux-kernel GPL than something that allows two clearly Debian free software guidelines compliant software packages to co-exist. All that being said, I think getting linux/net/rxrpc/rxgk written as GPL code would be a far better solution. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
