Based on our current understanding of current US law, any package that implements cryptographic methods must be in the "crypto" section. As an extension of this policy, any package that Depends (or BuildDepends) on such a package must also be in crypto, even if it does not implement cryptographic methods itself.
- Debian's solution for the crypto/US-export restriction is simply to distribute from a non-US site. (Which we can do if we move everything off to finch which is in the Netherlands.)
Packages that do not require crypto packages when they are compiled but instead automatically load them at runtime if they are present and as such could still run (albeit with reduced capabilities or features), need not be in crypto because scrapping crypto is not fatal to them. Similarly, packages that link to the system's crypto libraries need not be in crypto/ because fink presumes a standard system installation is present.
- Eventually move this to the Packaging Manual once content gets ironed out.
- Do we need a system-ssl virtual package?
- [a] What about GPL software that links to OpenSSL that has a clause explicitly allowing linking OpenSSL?
- That could mean License:GPL, but does OpenSSL also have to give explicit permission here, since they're the ones who say "use us but don't redistribute", which is what causes us to say License:Restrictive?.
[b] Note that Debian, in about the same situation, has resolved this: http://www.debian.org/legal/
[a] and maybe [b] are conflating licensing/redistribution, which has a policy already (which is why I removed its discussion from this page, since I had nothing to add at the time), with section:crypto which just seems to be part of Fink's oral tradition.