On Wed, Mar 25, 2009 at 12:03 PM, Paul Wise <pabs@xxxxxxxxxx> wrote: > On Thu, Mar 26, 2009 at 3:42 AM, Kel Modderman <kel@xxxxxxxxxx> wrote: > >> The DFSG seems to suggest that the source code to the regulatory database >> should be modifiable and the derived work distributed under the same license. > > It is my understanding that: > > Debian probably won't need to build the regdb from source most of the > time so we can just ship the upstream regulatory.bin file most of the > time. Yes, that is the case. The user who would modify these rules for example would be people doing experiments, research, or maintaining their own db for some sort of custom hardware with specifically licensed regulatory information. > When we do, just adding a second public key to the CRDA pubkeys dir > and using the corresponding private key (from outside the package) > during the build process of wireless-regdb would be just fine. Yes, this is the case. > This > would mean the maintainer of crda would also have to be the > wireless-regdb maintainer. Actually technically it could be a different person. I maintain crda upstream and John maintains wireless-regdb upstream, for example. I just need John's pubkey file which is non-binary. CRDA just reads the regulatory.bin which wireless-regdb provides. > I assume the wireless-regdb is > architecture-independent so this would work because the buildds do not > build such packages. This is correct. You do need a regulatory.bin installed first though so that if crda is built with the RSA digital signature check part of its build process is to ensure the signature checks out against the currently installed regulatory.bin file on your system. But that's just because a sanity check is part of the default target on the Makefile. > It is possible for users to add more public keys to the CRDA pubkeys > dir and build their own wireless-regdb using their own private key. Affirmative. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
