On Fri, May 11, 2001 at 09:03:48PM -0400, Brian Ristuccia wrote: > > > > > > > > > > 2) Do the binary .debs go in non-US? > > > > > > Yes. Policy currently requires it. > > > > OK, I understand that this is a quirk of Debian policy, and not US law. > > > > It wouldn't make sense for .deb's to go in a place different than their > source code. Otherwise, you wouldn't be able to rebuild from source without > specifying additional places to get source tarballs and diffs from.
I don't understand this (but am willing to believe it). Please elaborate, if you would. > There are legitimate reasons why non-crypto .deb's might need to go in > non-US/main. For example if the source and diffs must go in non-us, you > can't put the .deb's built from them anywhere else. In this case, it's > probably silly to even bother distributing them since anyone who was using > non-US could just use the ssl versions. What if they are living in France, where private use of cryptography is illegal? They might be using non-US to get things that are excluded from the US mirrors due to patent rather than cryptography reasons, and so they might still find use for a non-crypto version of my package, which they would be able to get from non-US/main rather than main (for the reason stated in your quoted bit above) if I distribute such a thing. > > > Good luck :) > > > > Thank you! I may also download the source of some package that comes in ssl > > and non-ssl flavors and see how they do it. Can you suggest one? I'm > > thinking > > of lynx, myself. > > > > lynx has seperate and distinct sources for the crypto and non-crypto > versions. Based on size alone, I suspect the non-ssl version has all the > crypto stuff ripped out (or the ssl version has it patched in). Since the only difference here is a few lines in the makefile, I could easily generate a crypto and a non-crypto version from the same source packge with some simple fileutils magic in debian/rules. BTW can anyone on -mentors explain how I set up a debian/rules file that generates multiple binary packages? Also, this makes me realize, the following entry was listed in the SourceForge release notes for version 0.4.3 (an old release) of my package: -- This version adds a bit of "security." Rather than storeing the user's password in plain text in a world readable config file, it saves it scrambled (though easily decryptable with the algorithm included in the source) in a file which is not world readable. -- This doesn't seem like real strong cryptography, and it may not qualify as any cryptography at all, just simple encoding (as opposed to encrypting). Is this legal to use in countries such as France? Also, is France's prohibition on cryptography limited to strong cryptography or not? If this would count as crypto then even the non-ssl version would have crypto. (There is no apparent way to disable compilation of this feature without hacking of the source - which could be done with sufficient justification, I guess.) - Jimmy Kaplowitz [EMAIL PROTECTED]
