[OpenAFS-devel] crypto backend and integration for rxgk

[Troy Benjegerdes]

On Thu, May 02, 2013 at 11:07:34AM -0400, Derek Atkins wrote:
> Benjamin Kaduk <kaduk@MIT.EDU> 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.