Hi Richard, There's a lot of confustion over the OpenSSL license but in actually it's quite a simple license.
Answers to your questions in-line: ----- Original Message ----- From: "Ryan Shon" <[EMAIL PROTECTED]> To: <openssl-users@openssl.org> Sent: Tuesday, August 22, 2006 9:06 AM Subject: Re: license question > Richard Koenning wrote: > > Ryan Shon wrote: > > > >> In particular, we are unclear as to what redistribution rights > >> the OpenSSL license would grant to customers who purchase > >> our OpenSSL variant. Would they be allowed to redistribute > >> our optimized library? > > It depends on how YOU distribute it. > > The license enumerates the conditions which have to be met for > > redistribution. I think the discussion can be shortened when you explain > > which point of the license is unclear to you. > > Ciao, > > Richard > > My boss hopes to sell this OpenSSL variant as a product. Because > of this, he would not want customers who buy this product to be > free to redistribute it on their own. If we were only to modify > existing OpenSSL, then I assume our entire product would be subject > to free redistribution by customers under the license. Is this correct? > This is correct. At the point that you compile OpenSSL with all your modifications, the resultant binary falls under the OpenSSL license terms. See the language in the license: "...The OpenSSL toolkit stays under a dual license..." At the point of linkage, the resultant whole is considered "the OpenSSL toolkit" and is subject to OpenSSL license. (this is obviously arguable, but why even go into that legal quagmire to begin with) You CAN write your own license and put the resultant binary under it. BUT the catch is that you cannot modify the copyright or redistribution terms. Those terms are unlimited, unrestricted. Since you want to limit distribution, writing your own license is a pointless exercise since you cannot use licensing to change the terms to limit distribution. > However, if the cryptographic library in our OpenSSL variant > were written from scratch, using no OpenSSL code (while the SSL library > still used OpenSSL code), would we have the right to forbid > redistribution of our cryptographic library and its source? > Yes, and No. If you distribute a compiled version of OpenSSL with your library compiled into it, your library is in the OpenSSL toolkit, and under it's license. What you have to do is distribute them as separate modules that the end-user must compile and link together. Note that this usually requires the end-user to own a compiler, unless your doing a dynamic runtime link thing. If your doing a dynamic link, it's rediculously easy. Give away copies of the modified OpenSSL sans your library. Sell your library. The end user puts both together. If the end user must statically link it to use it, then it becomes a bit more trickly. (which is probably the case here) The usual practice in the industry is to post the modified OpenSSL, sans your crypto library, onto your website, under the terms of the OpenSSL license, for anybody and their dog to download. You write an installer that goes with this, that also is under the terms of the OpenSSL license. When the end user goes to install OpenSSL, the installer looks for your library on the hard disk, or fetches it from the Internet. The user must have separately bought the library, either by submitting a credit card on a website and getting a key that they give to the installer, or getting the files on disk, or some such. When the installer finds it, the installer runs the compiler, and binds the two together. During the purchase process of your library, the end user must agree to licensing terms that make it illegal for them to modify the copyright and licensing terms on the module that you supply, and illegal to redistribute it. For the best example of this, see how ports work in FreeBSD. For example, under FreeBSD when you install a GPL program, the ports installer quite often HEAVILY patches the GPL program. However, the patches themselves are NOT under the GPL license, EVEN THOUGH the GPL license requires that any modifications to GPL programs MUST FALL UNDER THE GPL IF REDISTRIBUTED. This is because the loophole is that the end user is NOT redistributing the program, they are simply using it. > I hope that clarifies my question. > Note the following in the license: "...Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:.." "...The licence and distribution terms for any publically available version or * derivative of this code cannot be changed...." What is actually going on when the end-user runs OpenSSL and it dynamically links in your restricted library, or the end user compiles the unrestricted OpenSSL into your restricted library, is that they are committing a license violation of the OpenSSL license when they start using the resultant unified whole, because your license is going to require them to accept your license terms for the result of of whatever they link into. This is a violation of the OpenSSL terms on changing the OpenSSL license. HOWEVER in order for Eric Young or any of the OpenSSL team to have legal grounds to sue the end user, damages must occur. If the end user does NOT redistribute, then first of all, how does the OpenSSL team or Eric Young, suffer damages? Second of all, how is the OpenSSL team and Eric Young even going to know who any of the people are who are linking together your restricted module and thus violating the OpenSSL license, to even find them to sue them in the first place? You could even put language in your license that would prohibit the end user from informing the copyright holders of OpenSSL if they created and used a version of OpenSSL with your library in it. Ted Mittelstaedt Author, The FreeBSD Corporate Networker's Guide. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
