>} 	we may need a professional legal advice on it - once code goes into
>} 	openssl repository, it is unclear if Sun changes are all inside #ifdef,
>} 	or not.  so i'm not sure if we can avoid Sun license by doing #define
>} 	NO_SUN_CODE.  as a matter of fact, if you see the latest openssl
>} 	repository, license boilerplate is outside of #ifdef OPENSSL_NO_EC. 
>} 
>} 	if the code fork is the only solution, we'll need to do the same
>} 	(or import open-openssl from openbsd).
>     Didn't this issue come up with the idea patent?  How was that
>solved?  Couldn't this problem be solved the same way?

	idea/rc5 patent were easier to deal with.  it is under a single
	directory (openssl/crypto/{idea,rc5}), and conditions are like below.

	idea:
	"non-commercial use of this algorithm is free"
	http://www.mediacrypt.com/engl/Content/patent_info.htm

	rc5:
	"cannot be used commercially in the US without a license"
	http://www.massconfusion.com/ssh/ssh_patent_issues.html

	so our current situation is like this:
	- idea/rc5 source code is in the tree, under src/crypto/dist/openssl.
	- they are not compiled by default (so that binary tarballs does not
	  contain these binaries)
	- there's make variable to enable build of separate library
	  (libcrypto_{idea,rc5}).  so if you need to use them (and are allowed
	  to use these), it's possible

	i'm not totally sure if it is a safe approachh - if we want to be
	totally safe, we should remove idea/rc5 from the tree entirely.


	on the contrary, Sun code is everywhere in openssl tree (including
	bignum code!) as my first message have shown, so we can't do the
	similar thing.

itojun