License Question: Including OpenSSL code in Linux kernel
Dear All, The linux kernel is including an AES implementation for ARM which comes from OpenSSL. I refer to the file: arch/arm/crypto/aes-armv4.S The file itself contains information about its license: @ @ Written by Andy Polyakov ap...@fy.chalmers.se for the OpenSSL @ project. The module is, however, dual licensed under OpenSSL and @ CRYPTOGAMS licenses depending on where you obtain it. For further @ details see http://www.openssl.org/~appro/cryptogams/. @ Which might LOOK like dual license... BUT in http://www.openssl.org/~appro/cryptogams/ it is written that If obtained as a part of the OpenSSL Toolkit the modules are covered by the OpenSSL license, while if obtained as a part of the CRYPTOGAMS distribution - by the CRYPTOGAMS License. The latest version of CRYPTOGAMS doesn’t contain any ARM implementations, therefore they should have got it from OpenSSL, therefore it should be licensed with the OpenSSL license, therefore they can't put it in a GPL project such as the linux kernel. At least, this is what I understand, but I'm not sure. I tried to ask them, see http://comments.gmane.org/gmane.linux.kernel.cryptoapi/7513 , but without a great success. Now I ask you, is the inclusion in the linux kernel correct from a license standpoint ? Best Regards, Ruggero PGP.sig Description: PGP signature
License Question
Hi, if OpenSSL is included in hardware e.g. in a PLC, where should the copyright notice go? The hardware has no user interface with an about box or something like that. So the only place that remains would be the PLC manual. Would it be enough to write the following acknowledgement from the OpenSSL license This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/) in the PLC manual? -- mit freundlichen Grüßen / best regards *Gerhard Gappmeier* ascolab GmbH - automation systems communication laboratory Tel.: +49 9131 691 123 Fax: +49 9131 691 128 Web: http://www.ascolab.com GPG-Key: http://www.ascolab.com/gpg/gg.asc -- *ascolab GmbH* Geschäftsführer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrauß Sitz der Gesellschaft: Am Weichselgarten 7 • 91058 Erlangen • Germany Registernummer: HRB 9360 Registergericht: Amtsgericht Fürth signature.asc Description: OpenPGP digital signature
Re: License Question
The manual must include both the OpenSSL license text (what you quoted) and the SSLeay license text (which is also to be found in the LICENSE file). It just needs to be in the printed documentation or, where no printed documentation exists, in a LICENSE file or equivalent. -Kyle H On Mon, Jan 26, 2009 at 7:00 AM, Gerhard Gappmeier gerhard.gappme...@ascolab.com wrote: Hi, if OpenSSL is included in hardware e.g. in a PLC, where should the copyright notice go? The hardware has no user interface with an about box or something like that. So the only place that remains would be the PLC manual. Would it be enough to write the following acknowledgement from the OpenSSL license This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/) in the PLC manual? -- mit freundlichen Grüßen / best regards Gerhard Gappmeier ascolab GmbH - automation systems communication laboratory Tel.: +49 9131 691 123 Fax: +49 9131 691 128 Web: http://www.ascolab.com GPG-Key: http://www.ascolab.com/gpg/gg.asc -- ascolab GmbH Geschäftsführer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrauß Sitz der Gesellschaft: Am Weichselgarten 7 • 91058 Erlangen • Germany Registernummer: HRB 9360 Registergericht: Amtsgericht Fürth __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: license question
Ah, so then your going to retract your statement that: EULAs are agreements, you must actually agree to them to use the work because clearly you can use the work here (the Windows software) without agreeing to the EULA. No, that is the definition of an EULA. To give an analogy, an agreement is something two people have agreed to. I can sell you a piece of software acommpanied by a piece of paper that says agreement on it, but that doesn't make it an agreement until you agree to it. The 'A' in EULA stands for agreement. If it hasn't been agreed to, it's not an agreement. If it's not an agreement, it's not an EULA. An EULA is a type of agreement. To establish that an EULA controls a given situation, it must be established that there exists an EULA that affects that user of that product. The usual way you do this is by showing in some way that the user accepted the EULA. If you can't show that the user accept the EULA, it's not an agreement with that user. There is no distinction between a grant of rights and a license. Licenses grant rights. Agreements that grant rights are licenses. Absolute rubbish. If this were true software would not have software license in it's text, it would have grant of rights Tell me -- why would anyone ever agree to a software license? There is only one answer -- it grants them some right they wouldn't otherwise have. Otherwise, there is no reason they would. You do not license poems, period. I have no idea what definition you are using of license, but you most certainly do. Absent a license from you, the publisher could not distribute your poem. No, you don't. Perhaps you had difficulty reading so I'll say it again. I have my book contract for my published book that the publisher has published, and sold copies of. It does not use the word license in it. You do not license poems, period. If you did not license the publisher to copy your poem, you can sue them for copyright infringement. The only defense that would apply to them is that they have a valid license. You can claim that license means grant of rights but that is just semantic games and is not true. Book publishing is not the same as software publishing. That is why they can print T-shirts with the DeCSS algorithim on them but when people distribute files with the DeCSS source code, they get sued. I can't follow your analogy. I will point out that the common definition of license is formal permission to do something and the relevant legal definition is a private grant of right to use, copy, or distribute some intellectual property. Any copyrighted work can carry a license. Without a license, you cannot copy or distribute a copyrighted work (modulo the statutory exceptions). Tell that to my publisher. They do not have a license from me to publish my book. They have a grant of rights to publish. That grant of rights is a license. The definition of a license (that permits you to do something copyright would ordinarily prohibit) is a grant of rights. I don't see it doing any harm, however, I do agree that it wouldn't be a bad idea to remove it. Who knows, perhaps courts will hold that it's enforceable, though I cannot imagine how. Arrgg!! This is why I told the original poster he couldn't do what you were telling him he could which sent us down this discussion to begin with - and now your backpaddling? You never know what a court will do. Like I said, I'm not offering legal advice and I'm not predicting the future. I cannot see any way to uphold a use restriction in a copyright license that nobody has to agree to. I can point to case law that supports this view. But can I promise that a court won't rule a particular way, of course not. I personally consider it highly distasteful when people claim they have legal rights they do not have in an attempt to intimidate people into not doing things they in fact have the legal right to do. I think the restrictions on use in the OpenSSL license are an example of exactly this, and it distresses me that people who claim to support free software would argue that you need a license to get the right to *use* a piece of software you lawfully acquired. Note that the license does not even say that you must agree to it to use the work. (It says use is allowed if you agree to it, but that is not the same thing -- the default position is that you have the right to use it.) OK, that's an interesting hairsplit, and it is that kind of language why I said that the OpenSSL and SSLeay license was poorly written. It's not a hairsplit, it's critical. The license does not attempt to restrict use, possibly because the authors *knew* they couldn't restrict use. So instead, it's crafted to mislead people into thinking it can restrict use. I think it's calculated rather than poorly written. (Though I'd rather not
Re: license question
David Schwartz wrote: To the extent that there is no affirmative act of agreement to the EULA, Microsoft will have a hard time enforcing it. I have seen laptops that, on first customer boot, require you to accept a Microsoft EULA. I think Microsoft would have hard time enforcing their EULA if there was no positive act of assent to it. In Germany even the click on I agree has no legal consequences when the user was not able to read the EULA *before* the purchase: If the EULA is not printed on the outside of the cardboard box (or the user can read the EULA in any other way before the purchase), the EULA is not applicable. And when the installation process completes only when you click on the I agree button, then you can do this without legal consequences, your rights to use the software are then determined by german copyright law, not by the EULA. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: license question
- Original Message - From: David Schwartz [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Sunday, September 03, 2006 3:39 AM Subject: RE: license question These are EULAs. I'm talking about pure copyright licenses like the OpenSSL, BSD, and GPL licenses. EULAs are agreements, you must actually agree to them to use the work and this is actually enforced in some manner. Incorrect, see the following (I found on a quick scan): http://www.microsoft.com/malaysia/genuine/myths/ ...You can however transfer the entire desktop/notebook with the OEM license to a new user/company. When transferring the PC to the new end user the original software media, manuals (if applicable) and Certificate of Authenticity (COA) must be included. It is also advisable to include the original purchase invoice or receipt. The original end user cannot keep any copies of the software Nothing is said there about requiring the new owner of the old PC and old OEM software to actively accept the EULA Quite obviously since the software is already installed and working, the Windows installer cannot prompt the new owner to accept the EULA. No need, you already accepted the EULA and the EULA says it survives such a transfer. (See below for the case where there never was any affirmative act.) I'm not talking about the first owner. I'm talking about the second owner who never accepted the EULA. Thus, the statement you must actually agree to them to use the work and this is actually enforced isn't correct. At least, not in this instance. To the extent that there is no affirmative act of agreement to the EULA, Microsoft will have a hard time enforcing it. I have seen laptops that, on first customer boot, require you to accept a Microsoft EULA. I think Microsoft would have hard time enforcing their EULA if there was no positive act of assent to it. Ah, so then your going to retract your statement that: EULAs are agreements, you must actually agree to them to use the work because clearly you can use the work here (the Windows software) without agreeing to the EULA. The new owner also could slipstream the existing Windows install and create a installer that didn't ask the EULA acceptance question, I believe an explanation of how to do this was discussed in Ct several years ago. He could then legally install the Windows copy on any machine, not just the OEM one, since he never accepted the EULA. True. I have no idea how courts would rule on this. ProCD v. Zeidenberg, among other cases, indicates that the crux of validity is some positive act of agreement. If you buy a laptop pre-installed, and the EULA click-through is disabled somehow, I don't see how there is that positive act. Speaking as a published author of a book I can assure you that nowhere in my book contract is the word license used. If a copyright holder wants to legally permit a publisher to print his poem, he makes a grant of rights to publish to the publisher, he does not issue a license to the publisher. There is no distinction between a grant of rights and a license. Licenses grant rights. Agreements that grant rights are licenses. Absolute rubbish. If this were true software would not have software license in it's text, it would have grant of rights You do not license poems, period. I have no idea what definition you are using of license, but you most certainly do. Absent a license from you, the publisher could not distribute your poem. No, you don't. Perhaps you had difficulty reading so I'll say it again. I have my book contract for my published book that the publisher has published, and sold copies of. It does not use the word license in it. You do not license poems, period. You can claim that license means grant of rights but that is just semantic games and is not true. Book publishing is not the same as software publishing. That is why they can print T-shirts with the DeCSS algorithim on them but when people distribute files with the DeCSS source code, they get sued. Notice that I do not make the obvious joke about poetic license. Except that OpenSSL is software and carries a license, a poem does not. Any copyrighted work can carry a license. Without a license, you cannot copy or distribute a copyrighted work (modulo the statutory exceptions). Tell that to my publisher. They do not have a license from me to publish my book. They have a grant of rights to publish. If you read copyright law, you will see that the right to *use* a work is *not* one of the rights reserved to the copyright holder. So the OpenSSL license can't restrict the *use* of a work any more than it can restrict breathing. Then why is the use clause in both the SSLeay and OpenSSL license? If it is unenforceable then the OpenSSL project should modify the license. I don't see it doing any harm, however, I do
RE: license question
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ted Mittelstaedt Sent: Saturday, September 02, 2006 5:28 PM To: openssl-users@openssl.org Subject: Re: license question - Original Message - From: David Schwartz [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Saturday, September 02, 2006 5:22 AM Subject: RE: license question Copyright law gives the copyright holder almost unlimited power to control distribution of the copyrighted work - until the copyright expires, that is. Correct, but we're talking about what people who never distributed anything can or cannot do. You are correct that you must comply with the OpenSSL license if you wish to distribute OpenSSL. (There are possible ways one might get around this, but they're so obviously intended to circumvent fair rules that I doubt any court would buy them.) About the only thing a copyright holder can't do is force a user of his work to do something illegal. But, if for example, a songwriter decides that the only way your going to be able to listen to his copyrighted work is to pay him then paint yourself green and stand on your head while he plays it, well then better get the paintbrush. This is true if and only if he doesn't widely distribute the work. The way he could make this work is by not distributing the work to anyone who didn't agree to his terms. This could be done by means of an EULA, click-through, shrink-wrap, or signed agreement. But the OpenSSL license is none of these things -- you do not need to agree to it to lawfully receive the work. And you are not compelled by a license enforcement scheme to agree to the license in order to use the work. This squarely robs the license of the ability to restrict use. I should point out that this is not just my view. This is, for example, the FSF's view as well. Licenses that rely on copyright for their power cannot restrict use. The OpenSSL license is this type of license. If you don't see why, imagine if there were no copyright laws. What would you do if I copied, modified, and distributed OpenSSL willy-nilly? Charge me with violating a license I never agreed to? Adn please, don't waste time quoting fair use, if fair use was really observed then the news organizations wouldn't be chasing after people they interview all the time to get them to sign releases. It is very rare that a court upholds fair use on copyrighted material, at least in the United States. Hell, you can't even put a 1 minute partial section of a song track on a website these days under fair use without the RIAA jumping all over you. I'm not talking about fair use. I'm talking about something much more fundamental -- copyright law just does not give the copyright holder the right to restrict use. Read the law and find the clause that says this is the case, you cannot do it. not by the license itself. The license can only restrict an action that copyright law gives a copyright holder the right to restrict. And since copyright law gives the copyright holder unlimited authority to control use and distribution, what is the point? You repeat this error over and over. Copyright law does *not* give the copyright holder authority to control use. I explained why this must be the case -- if it did, I could drop a million copies of my poem from an airplane and sue everyone who read it. Under United States copyright law, a copyright holder cannot restrict someone who lawfully possesses a copy of the work from using that work. You can only obtain this right from sources other than copyright. For example, if the OpenSSL license said that if you ever downloaded a copy of OpenSSL, you had to pay the authors $1,000,000, this would not be valid. Huh? I think the people that run itunes would beg to disagree. I doubt it. It's obviously correct. It would only be valid if the license were the only way to get the right or ability to download a copy of OpenSSL. not correct. I think you need to rework this example, obviously you have some point buried in there your trying to make. No, that is correct. That is, if iTunes charges you $1 to download a song, then they will not make the copy for you unless you pay them. They can do that. However, if they let you download the song and rely only on copyright, they cannot then charge you for using the song you already downloaded. If they wanted that right, they would have to obtain it from some source other than copyright. (Which they can, since you click-through their terms of service.) Since nobody formally agrees to, clicks on, or otherwise assents to the OpenSSL license, the OpenSSL license only applies to you when you choose to accept it. Of course, should you not choose to accept it and then do something copyright law prohibits you from doing, you are violating copyright law. (Read
Re: license question
- Original Message - From: Richard Salz [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Saturday, September 02, 2006 10:04 PM Subject: Re: license question There are many funny licensing clauses that appear nonsensical to the layman but are perfectly logical. The SSLeay and OpenSSL license is an extremely sloppy and poorly defined document because the people who wrote it were under the misguided assumption that good legal documentation is simple. I don't know about OpenSSL, but for SSLeay you're wrong. A great deal of lawyer time and effort was spent in writing it. Then the lawyer got a lot of money for doing a shitty job, which is par for the course for most lawyers. Have you ever paid money for a lawyer to write or do anything for you? I have. Take a look at any commercial US software license. Take a look for that matter at the GPL license. A child could compare them against the SSLeay license and see that the SSLeay license is too simplistic. In the US, in any contract dispute where a term in a contract is ill-defined, the courts usually rule against the person that wrote the contract, not the person who is being accused of violating it. Ted __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: license question
The other alternative is that you're not very good at reading it. :) /r$ -- SOA Appliances Application Integration Middleware __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: license question
- Original Message - From: David Schwartz [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Saturday, September 02, 2006 11:23 PM Subject: RE: license question You can start out with an OEM license, load that on another piece of hardware, then get the holder to sue you. I'd love to see those ruled invalid. These are EULAs. I'm talking about pure copyright licenses like the OpenSSL, BSD, and GPL licenses. EULAs are agreements, you must actually agree to them to use the work and this is actually enforced in some manner. Incorrect, see the following (I found on a quick scan): http://www.microsoft.com/malaysia/genuine/myths/ ...You can however transfer the entire desktop/notebook with the OEM license to a new user/company. When transferring the PC to the new end user the original software media, manuals (if applicable) and Certificate of Authenticity (COA) must be included. It is also advisable to include the original purchase invoice or receipt. The original end user cannot keep any copies of the software Nothing is said there about requiring the new owner of the old PC and old OEM software to actively accept the EULA Quite obviously since the software is already installed and working, the Windows installer cannot prompt the new owner to accept the EULA. Thus, the statement you must actually agree to them to use the work and this is actually enforced isn't correct. At least, not in this instance. The new owner also could slipstream the existing Windows install and create a installer that didn't ask the EULA acceptance question, I believe an explanation of how to do this was discussed in Ct several years ago. He could then legally install the Windows copy on any machine, not just the OEM one, since he never accepted the EULA. poem from an airplane and then sue anyone who read it without complying with my license terms. You don't license poems so that does not apply. What? Of course you do. How else do you get the rights to copy them, distribute them, perform them publically, create derivative works from them, and do anything else that copyright law restricts to the author? Speaking as a published author of a book I can assure you that nowhere in my book contract is the word license used. If a copyright holder wants to legally permit a publisher to print his poem, he makes a grant of rights to publish to the publisher, he does not issue a license to the publisher. You do not license poems, period. You have also chosen a distribution mechanism - dropping from the plane - that you have an inherent inability to control the use of the material. So, for the first use at least - the initial read of the poem - while you could sue, you wouldn't win. But, you could certainly sue, and win, if someone reprinted the poem. Granted. By dropping the poem from airplanes, you concede the right to restrict ordinary use. This is the law and it makes sense. The same is true by making OpenSSL available for download to anyone who wants it without obtaining any agreement from them. Except that OpenSSL is software and carries a license, a poem does not. I am in agreement with you that the idea that software should be even PERMITTED to be licensed in the first place is fucking stupid, and should never have been permitted in the first place. But the realities of what people are doing today in the industry are that at least in the united states, the industry is arguing that software is considered a device, thus patentable, not an expression. And so far, nobody with money has stood up to fight that all the way to the US Supreme Court, even though there's a lot of bad law, like the DMCA that is institutionalizing it. Software contains a mix of ideas and expression. Theoretically, only the ideas are patentable and only the expression is copyrightable. only the ORIGINAL ideas and original expression... If you read copyright law, you will see that the right to *use* a work is *not* one of the rights reserved to the copyright holder. So the OpenSSL license can't restrict the *use* of a work any more than it can restrict breathing. Then why is the use clause in both the SSLeay and OpenSSL license? If it is unenforceable then the OpenSSL project should modify the license. Thus, the reason that industry is pushing for software licenses to be considered to apply automatically. And they are gradually getting it. It's kind of hard to tell. Most companies take a shotgun approach in the hopes that some legal theory will make their license enforceable. The following things seem to work (with some exceptions for things like unconscionable terms): 1) Making a person actually assent to a license through some positive act before they can lawfully obtain the work. 2) Making a person actually assent to a license in order to physically install or use the work. (For example, an installer that makes you click
RE: license question
These are EULAs. I'm talking about pure copyright licenses like the OpenSSL, BSD, and GPL licenses. EULAs are agreements, you must actually agree to them to use the work and this is actually enforced in some manner. Incorrect, see the following (I found on a quick scan): http://www.microsoft.com/malaysia/genuine/myths/ ...You can however transfer the entire desktop/notebook with the OEM license to a new user/company. When transferring the PC to the new end user the original software media, manuals (if applicable) and Certificate of Authenticity (COA) must be included. It is also advisable to include the original purchase invoice or receipt. The original end user cannot keep any copies of the software Nothing is said there about requiring the new owner of the old PC and old OEM software to actively accept the EULA Quite obviously since the software is already installed and working, the Windows installer cannot prompt the new owner to accept the EULA. No need, you already accepted the EULA and the EULA says it survives such a transfer. (See below for the case where there never was any affirmative act.) Thus, the statement you must actually agree to them to use the work and this is actually enforced isn't correct. At least, not in this instance. To the extent that there is no affirmative act of agreement to the EULA, Microsoft will have a hard time enforcing it. I have seen laptops that, on first customer boot, require you to accept a Microsoft EULA. I think Microsoft would have hard time enforcing their EULA if there was no positive act of assent to it. The new owner also could slipstream the existing Windows install and create a installer that didn't ask the EULA acceptance question, I believe an explanation of how to do this was discussed in Ct several years ago. He could then legally install the Windows copy on any machine, not just the OEM one, since he never accepted the EULA. True. I have no idea how courts would rule on this. ProCD v. Zeidenberg, among other cases, indicates that the crux of validity is some positive act of agreement. If you buy a laptop pre-installed, and the EULA click-through is disabled somehow, I don't see how there is that positive act. Speaking as a published author of a book I can assure you that nowhere in my book contract is the word license used. If a copyright holder wants to legally permit a publisher to print his poem, he makes a grant of rights to publish to the publisher, he does not issue a license to the publisher. There is no distinction between a grant of rights and a license. Licenses grant rights. Agreements that grant rights are licenses. You do not license poems, period. I have no idea what definition you are using of license, but you most certainly do. Absent a license from you, the publisher could not distribute your poem. Notice that I do not make the obvious joke about poetic license. Except that OpenSSL is software and carries a license, a poem does not. Any copyrighted work can carry a license. Without a license, you cannot copy or distribute a copyrighted work (modulo the statutory exceptions). If you read copyright law, you will see that the right to *use* a work is *not* one of the rights reserved to the copyright holder. So the OpenSSL license can't restrict the *use* of a work any more than it can restrict breathing. Then why is the use clause in both the SSLeay and OpenSSL license? If it is unenforceable then the OpenSSL project should modify the license. I don't see it doing any harm, however, I do agree that it wouldn't be a bad idea to remove it. Who knows, perhaps courts will hold that it's enforceable, though I cannot imagine how. Note that the license does not even say that you must agree to it to use the work. (It says use is allowed if you agree to it, but that is not the same thing -- the default position is that you have the right to use it.) That doesen't work if for example, the person buys a computer with Windows installed, and on it there is a program with one of those installers that was installed by the prior owner, and the new buyer decides to stay legal by simply going and buying a copy of the software program and not installing it, and just using the already installed version. I agree, and courts have so held (though AFAIK, only in dicta). See, for example, ProCD v. Zeidenberg and the example of a person who finds a copy of the software on the street, with the shrink-wrap already broken. Do you know of any cases where a license that required no positive act of assent was held to restrict use? Interesting article here: http://www.infoworld.com/article/03/08/08/31FEfair_1.html ...I made the mistake of showing a visiting Cisco rep the 2611 router I'd purchased on eBay for $1,200, says Mark Payton, director of IT at the Vermont
Re: license question
- Original Message - From: David Schwartz [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Tuesday, August 29, 2006 2:17 PM Subject: RE: license question 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. I wholeheartedly disagree. You cannot violate the OpenSSL license by using OpenSSL. The end user is not creating a derivative work because he is not creating a work at all. For copyright purposes, you only create a work when you add creative input. Compiling and linking is not a creative process. This is licensing terms we are talking about here, not copyright terms, which are an entirely separate and different thing. From the license: ...Redistribution AND USE in source... This LIBRARY is free for commercial and non-commercial USE as long as the following conditions... When you link in your own code, it becomes part of the library, thus part of OpenSSL. If you don't apply all the license terms to your code, when you are licensing it to yourself to use for yourself, you are violating the license. Of course, nobody cares because your not redistributing it. There are many funny licensing clauses that appear nonsensical to the layman but are perfectly logical. The SSLeay and OpenSSL license is an extremely sloppy and poorly defined document because the people who wrote it were under the misguided assumption that good legal documentation is simple. This is an assumption that is shared by much of the general public, of course, because most people are stupid and want to believe that the rest of the world is comprised of simpletons, it makes them feel better. In reality, good, defendable legal documentation is very explicit and spells everything out, that is why it's so long, it does not make a bunch of assumptions. IANAL, this is not legal advice. We have a saying here about that: No shit, sherlock Continuing to disclaim your own advice is really rediculous. We all know that the respondents to this thread, including myself, are not lawyers and nobody with brains is going to take postings off a mailing list as legal advice. I also have some distressing news for you as well - if you were to consult a dozen lawyers about this topic, you would get a dozen different interpretations. Legal advice, paid or otherwise, ain't worth shit until a Judge in a courtroom agrees with it, I fail to see why your getting so excited about advice on a license being not legal Ted __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: license question
- Original Message - From: David Schwartz [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Saturday, September 02, 2006 5:22 AM Subject: RE: license question I wholeheartedly disagree. You cannot violate the OpenSSL license by using OpenSSL. The end user is not creating a derivative work because he is not creating a work at all. For copyright purposes, you only create a work when you add creative input. Compiling and linking is not a creative process. This is licensing terms we are talking about here, not copyright terms, which are an entirely separate and different thing. Umm, no. We are talking about whether the license *covers* a particular act or not, not what the license says about that act. The scope of the license is set by copyright law, Copyright law gives the copyright holder almost unlimited power to control distribution of the copyrighted work - until the copyright expires, that is. About the only thing a copyright holder can't do is force a user of his work to do something illegal. But, if for example, a songwriter decides that the only way your going to be able to listen to his copyrighted work is to pay him then paint yourself green and stand on your head while he plays it, well then better get the paintbrush. What kind of relief are you looking for, exactly, from copyright law, for any rediculous or silly requirement that a copyright holder wants to put into a license? Adn please, don't waste time quoting fair use, if fair use was really observed then the news organizations wouldn't be chasing after people they interview all the time to get them to sign releases. It is very rare that a court upholds fair use on copyrighted material, at least in the United States. Hell, you can't even put a 1 minute partial section of a song track on a website these days under fair use without the RIAA jumping all over you. not by the license itself. The license can only restrict an action that copyright law gives a copyright holder the right to restrict. And since copyright law gives the copyright holder unlimited authority to control use and distribution, what is the point? For example, if the OpenSSL license said that if you ever downloaded a copy of OpenSSL, you had to pay the authors $1,000,000, this would not be valid. Huh? I think the people that run itunes would beg to disagree. It would only be valid if the license were the only way to get the right or ability to download a copy of OpenSSL. not correct. I think you need to rework this example, obviously you have some point buried in there your trying to make. Since nobody formally agrees to, clicks on, or otherwise assents to the OpenSSL license, the OpenSSL license only applies to you when you choose to accept it. Of course, should you not choose to accept it and then do something copyright law prohibits you from doing, you are violating copyright law. (Read this over a few times until you get it. This is the crux right here.) Ah, that argument. You aren't the first person to think up that one. As far as whether software licenses apply whether or not someone agrees to the license in writing, or by clicking, or by opening the shrink wrap, well that is still an open question. There's been plenty of infringment lawsuits in the past in the software industry where the accused has made a similar claim. Unfortunately, in the US they all seem to get settled out of court. The software industry really does not want shrink wrap licensing tested in court, and that includes the FSF - who has bent over backwards to prevent it's precious GNU license tested in US court. In other countries where the courts are less sympathetic to the copyright holder, there have been some case law created. Like in Germany for example. But, I invite you to go infringe a software license in the US, get the copyright holder to come after you, then try this argument out in an US court and see how far it gets. You can start out with an OEM license, load that on another piece of hardware, then get the holder to sue you. I'd love to see those ruled invalid. But until someone has the nuts to do this in the US, your not going to find many users with much of value who are vulnerable to being bled dry by legal action in the US, to take this approach. So while it might have merit in a theoretical discussion, it is useless in practicality, at least in corporate America. It is essentially impossible to violate the OpenSSL license. If you disribute OpenSSL in violation of its license, you are violating copyright law. This is because copyright law restricts the distribution of covered works and you have no license. If you are not complying with the terms of the license, you just don't get the *additional* rights the license gives you. But you still have the rights under first sale, fair use, scenes a fair, and so on. Again, just to be 100% clear -- the only way you could violate the OpenSSL
Re: license question
There are many funny licensing clauses that appear nonsensical to the layman but are perfectly logical. The SSLeay and OpenSSL license is an extremely sloppy and poorly defined document because the people who wrote it were under the misguided assumption that good legal documentation is simple. I don't know about OpenSSL, but for SSLeay you're wrong. A great deal of lawyer time and effort was spent in writing it. /r$ -- SOA Appliances Application Integration Middleware __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: related license question
On Mon, 28 Aug 2006, David Schwartz wrote: Certainly. Nothing in the OpenSSL licenses requires you to allow redistribution of any derivative works you create. Wrong. See the following: ...The licence and distribution terms for any publically available version or derivative of this code cannot be changed... http://www.openssl.org/source/license.html I always assumed that publically available version meant an open source distribution and didn't apply to proprietary code where the source isn't made available at all. But now that you point it out, it's not clear at all exactly what that means. In any event, it doesn't compel you to make the source available, but it could mean that you can't prevent redistribution of the binaries. IANAL, but this is a fairly standard BSD-style license and such have always allowed proprietory derivative works. I see nothing here that forbids distributors from imposing additional terms on derivative works (unlike the GPL). --| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)865-5723 | --| __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: license question
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. I wholeheartedly disagree. You cannot violate the OpenSSL license by using OpenSSL. The end user is not creating a derivative work because he is not creating a work at all. For copyright purposes, you only create a work when you add creative input. Compiling and linking is not a creative process. IANAL, this is not legal advice. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: license question
Ryan Shon wrote: I work for nFocal, a company in Rochester, New York. We want to develop a variant of OpenSSL in which we optimize the cryptography library to run on a particular DSP. The other components of OpenSSL would remain unchanged except where needed to utilize our custom library. We might modify OpenSSL's cryptography library, or we may write our own from scratch. Could you please explain our licensing restrictions for these two scenarios? Just an observation, but if you left the OpenSSL core alone, and created your optimized module as a loadable engine for OpenSSL - I suspect you would have a win-win from licensing, distribution and code design views. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: related license question
Ted Mittelstaedt wrote: - Original Message - From: David Schwartz [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Tuesday, August 22, 2006 2:04 PM Subject: RE: related license question Certainly. Nothing in the OpenSSL licenses requires you to allow redistribution of any derivative works you create. Wrong. See the following: ...The licence and distribution terms for any publically available version ^^ The question is, what this word means. or derivative of this code cannot be changed... http://www.openssl.org/source/license.html Yes, the OpenSSL does not explicitly require you to allow redistribution of any derivitave works you create. However, it explicitly requires you to not change the distribution terms of the derivitave work that you create, and since the redistribution terms are open, that forces you to also use open redistribution terms. If someone adds *own* code to OpenSSL and forbids redistribution of *his* code, the resulting package is imho no longer publically available and therefore the sentence cited above would no longer apply. Am i wrong? If i am wrong, the OpenSSL license would be infectious like the GPL, and my impression is, that the sentence cited above has been added to the license for preventing such infectiousity, but i may be wrong. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: related license question
Certainly. Nothing in the OpenSSL licenses requires you to allow redistribution of any derivative works you create. Wrong. See the following: ...The licence and distribution terms for any publically available version or derivative of this code cannot be changed... http://www.openssl.org/source/license.html I always assumed that publically available version meant an open source distribution and didn't apply to proprietary code where the source isn't made available at all. But now that you point it out, it's not clear at all exactly what that means. In any event, it doesn't compel you to make the source available, but it could mean that you can't prevent redistribution of the binaries. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: related license question
- Original Message - From: Ryan Shon [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Tuesday, August 22, 2006 12:07 PM Subject: related license question Thank you for the clarification. What you have said makes sense, but I am still a little unclear on what is meant by redistribution and products derived from [OpenSSL]. redistribution means distribution by someone other than the copyright holder. Presumably, a program, e.g. a web browser, could be written which uses OpenSSL (whether through linking to the libraries or by including actual pieces of OpenSSL code), and this browser would not have to be licensed under the OpenSSL license. correct as long as the license on the browser does not deviate from the distribution terms that are in openssl, gives copyright attribution, etc. This would be a product derived from OpenSSL, yes and users could be forbidden to redistribute the browser in source or binary forms. no, not possible. The reason is that the openssl license distribution terms permit unrestricted redistribution in source or binary forms and since the new license must follow the distribution terms in the openssl license to be compliant, the new license must permit unlimited redistribution. Is this a correct interpretation of what a product derived is? yes If a person were to take a full OpenSSL distribution and completely rewrite some source files, but not all source files, of which libcrypto.a is composed, then compile and distribute the resulting libraries libssl.a and libcrypto.a, would libssl.a be a redistribution, and would libcrypto.a be a product derived or a redistribution? Both. If there's any openSSL code that makes up the resultant libssl.a or libcrypto.a, then the added code that this hypothetical person wrote would become part of the openssl toolkit, and thus subject to it's licensing. In other words, would the person be able to prohibit redistribution of their new libcrypto.a, even though it utilizes some unmodified OpenSSL code, and is part of a complete OpenSSL distribution? No, they can only follow the redistribution terms that are in the openssl license, those terms are unrestricted, so the person's license would have to be unrestricted as well. You simply cannot redistribute openSSL code with your own code mixed in, and have part of the openssl distribution that you are sending out be under the openSSL license, and part of the redistribution subject to your own license. The grant of redistribution rights you get from the openSSl license do not permit you to do this. If you want to distribute a replacement libcrypto.a under your own license terms, you must write from scratch all files that are used to build the libcrypto.a you cannot take any existing openssl files and use them in the build of the libcrypto.a, then redistribute this under a restricted license, as the openssl license does not give you that right. The only way you can do what you want to do is distribute the part you write separately from the openssl part, and license your part under your terms, and the openssl part under it's terms, and have the end-users combine the parts to a single result. Ted __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: related license question
- Original Message - From: David Schwartz [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Tuesday, August 22, 2006 2:04 PM Subject: RE: related license question Thank you for the clarification. What you have said makes sense, but I am still a little unclear on what is meant by redistribution and products derived from [OpenSSL]. The term redistribution means any distribution of OpenSSL or a derivative work of OpenSSL other than what you might have a right to do by law (say under first sale or fair use). The term products derived from OpenSSL means any work that would be considered a derivative work under copyright law. Note that calling something 'OpenSSL' might also be a considered fraud or violations of common law trademarks and the like. I'm talking only about copyright. Presumably, a program, e.g. a web browser, could be written which uses OpenSSL (whether through linking to the libraries or by including actual pieces of OpenSSL code), and this browser would not have to be licensed under the OpenSSL license. This would be a product derived from OpenSSL, and users could be forbidden to redistribute the browser in source or binary forms. Is this a correct interpretation of what a product derived is? If it included actual pieces of OpenSSL code, other than that permitted under exceptions to copyright laws (fair use, scenes a faire), then those who distribute it must comply with the OpenSSL license when they do so. That does not mean their product has to be licensed under a license identical to the OpenSSL license. Note that they cannot authorize distributions of their derivative under terms not permitted by the OpenSSL license unless their creation of the derivative works was pursuant to rights no acquired under the OpenSSL license. (That gets complicated. If you want a more detailed explanation, email me.) Basically, you cannot wrap OpenSSL and claim that by using that wrapped OpenSSL instead of OpenSSL itself, you only need to comply with the wrapper's license. This is not because OpenSSL's authors have the right to restrict the distribution of derivative works, this is because this is a condition of creating the derivative work in the first place. If a person were to take a full OpenSSL distribution and completely rewrite some source files, but not all source files, of which libcrypto.a is composed, then compile and distribute the resulting libraries libssl.a and libcrypto.a, would libssl.a be a redistribution, Yes. and would libcrypto.a be a product derived or a redistribution? It would either be OpenSSL itself (if insufficient creative effort were involved in the process of creating this file) or it would be a product derived (if sufficient creative effort were added to consider it a distinct work). In other words, would the person be able to prohibit redistribution of their new libcrypto.a, even though it utilizes some unmodified OpenSSL code, and is part of a complete OpenSSL distribution? Certainly. Nothing in the OpenSSL licenses requires you to allow redistribution of any derivative works you create. Wrong. See the following: ...The licence and distribution terms for any publically available version or derivative of this code cannot be changed... http://www.openssl.org/source/license.html Yes, the OpenSSL does not explicitly require you to allow redistribution of any derivitave works you create. However, it explicitly requires you to not change the distribution terms of the derivitave work that you create, and since the redistribution terms are open, that forces you to also use open redistribution terms. The above part is from the SSLeay part of OpenSSL and the OpenSSL license itself cannot change license terms, due to the above statement, the above statement is itself a license term, and is thus still in effect in the openSSL license. (And anyone who did so would be violating *your* rights, not those of OpenSSL or its authors since copyright law doesn't permit you to restrict distribution of derivative works, only creation.) However, if the thing you distributed was legally deemed to be OpenSSL itself, rather than a derivative work, you could not prohibit redistribution (under copyright law). You do not hold copyright to OpenSSL itself, so nobody can violate any of your rights by distributing it. (Merely compiling OpenSSL, for example, doesn't give you any copyright rights in the results. You must add creative effort to acquire copyright interest.) But, since you have to adhere to the OpenSSL licensing terms when you add your creative effort, copyright interest doesen't give you anything other than bragging rights. Ted __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager
Re: license question
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
license question
Originally I sent this letter to [EMAIL PROTECTED], as indicated by the license file, but I never got a response. Hopefully you in openssl-users can help. I work for nFocal, a company in Rochester, New York. We want to develop a variant of OpenSSL in which we optimize the cryptography library to run on a particular DSP. The other components of OpenSSL would remain unchanged except where needed to utilize our custom library. We might modify OpenSSL's cryptography library, or we may write our own from scratch. Could you please explain our licensing restrictions for these two scenarios? 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? Your help is greatly appreciated. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: license question
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? 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 -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
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? 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? 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? I hope that clarifies my question. Again, thank you for your help. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: license question
Ryan Shon wrote: 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? My first answer would have been plain no, but then i read the last sentences at http://www.openssl.org/source/license.html. I think (IANAL) that the answer depends on whether your product is regarded a derivative of OpenSSL. If you can put the main part of your code into a separate module and only modify OpenSSL to call your code then i assume that you can forbid the redistribution of *your* module. Whether you are allowed to forbid the redistribution of the modified OpenSSL may be questionable, but without your module this OpenSSL version is useless anyway. 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 (but you know, IANAL ;-)). Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: license question
In message [EMAIL PROTECTED] on Tue, 22 Aug 2006 18:47:12 +0200, Richard Koenning [EMAIL PROTECTED] said: Richard.Koenning Ryan Shon wrote: Richard.Koenning Richard.Koenning My boss hopes to sell this OpenSSL variant as a Richard.Koenning product. Because of this, he would not want Richard.Koenning customers who buy this product to be free to Richard.Koenning redistribute it on their own. If we were only to Richard.Koenning modify existing OpenSSL, then I assume our entire Richard.Koenning product would be subject to free redistribution by Richard.Koenning customers under the license. Is this correct? Richard.Koenning Richard.Koenning My first answer would have been plain no, but then Richard.Koenning i read the last sentences at Richard.Koenning http://www.openssl.org/source/license.html. I think Richard.Koenning (IANAL) that the answer depends on whether your Richard.Koenning product is regarded a derivative of OpenSSL. For all intents and purposes, yes, it would, at least if the modification is distributed in a package that otherwise looks like a full OpenSSL distribution. IANAL either, but I think I've read enough to be able to make that statement with certainty. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
related license question
Thank you for the clarification. What you have said makes sense, but I am still a little unclear on what is meant by redistribution and products derived from [OpenSSL]. Presumably, a program, e.g. a web browser, could be written which uses OpenSSL (whether through linking to the libraries or by including actual pieces of OpenSSL code), and this browser would not have to be licensed under the OpenSSL license. This would be a product derived from OpenSSL, and users could be forbidden to redistribute the browser in source or binary forms. Is this a correct interpretation of what a product derived is? If a person were to take a full OpenSSL distribution and completely rewrite some source files, but not all source files, of which libcrypto.a is composed, then compile and distribute the resulting libraries libssl.a and libcrypto.a, would libssl.a be a redistribution, and would libcrypto.a be a product derived or a redistribution? In other words, would the person be able to prohibit redistribution of their new libcrypto.a, even though it utilizes some unmodified OpenSSL code, and is part of a complete OpenSSL distribution? I appreciate your help. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: related license question
In message [EMAIL PROTECTED] on Tue, 22 Aug 2006 15:07:31 -0400, Ryan Shon [EMAIL PROTECTED] said: rshon Presumably, a program, e.g. a web browser, could be written rshon which uses OpenSSL (whether through linking to the libraries or rshon by including actual pieces of OpenSSL code), and this browser rshon would not have to be licensed under the OpenSSL license. This rshon would be a product derived from OpenSSL, and users could be rshon forbidden to redistribute the browser in source or binary forms. rshon Is this a correct interpretation of what a product derived rshon is? I'm actually unsure about that. Richard Stallman would probably interpret it that way, but I wouldn't. Using unmodified components from another package in your own package does not constitute derivation, in my opinion. But again, IANAL. rshon If a person were to take a full OpenSSL distribution and rshon completely rewrite some source files, but not all source files, rshon of which libcrypto.a is composed, then compile and distribute rshon the resulting libraries libssl.a and libcrypto.a, would rshon libssl.a be a redistribution, and would libcrypto.a be a rshon product derived or a redistribution? If we look at the separate libraries, then yes. However, I would assume that you would distribute this changed source in the same manner as the original is distributed, in one package. In that case, that package is a modified version of OpenSSL, and therefore a product derived from OpenSSL. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: related license question
Thank you for the clarification. What you have said makes sense, but I am still a little unclear on what is meant by redistribution and products derived from [OpenSSL]. The term redistribution means any distribution of OpenSSL or a derivative work of OpenSSL other than what you might have a right to do by law (say under first sale or fair use). The term products derived from OpenSSL means any work that would be considered a derivative work under copyright law. Note that calling something 'OpenSSL' might also be a considered fraud or violations of common law trademarks and the like. I'm talking only about copyright. Presumably, a program, e.g. a web browser, could be written which uses OpenSSL (whether through linking to the libraries or by including actual pieces of OpenSSL code), and this browser would not have to be licensed under the OpenSSL license. This would be a product derived from OpenSSL, and users could be forbidden to redistribute the browser in source or binary forms. Is this a correct interpretation of what a product derived is? If it included actual pieces of OpenSSL code, other than that permitted under exceptions to copyright laws (fair use, scenes a faire), then those who distribute it must comply with the OpenSSL license when they do so. That does not mean their product has to be licensed under a license identical to the OpenSSL license. Note that they cannot authorize distributions of their derivative under terms not permitted by the OpenSSL license unless their creation of the derivative works was pursuant to rights no acquired under the OpenSSL license. (That gets complicated. If you want a more detailed explanation, email me.) Basically, you cannot wrap OpenSSL and claim that by using that wrapped OpenSSL instead of OpenSSL itself, you only need to comply with the wrapper's license. This is not because OpenSSL's authors have the right to restrict the distribution of derivative works, this is because this is a condition of creating the derivative work in the first place. If a person were to take a full OpenSSL distribution and completely rewrite some source files, but not all source files, of which libcrypto.a is composed, then compile and distribute the resulting libraries libssl.a and libcrypto.a, would libssl.a be a redistribution, Yes. and would libcrypto.a be a product derived or a redistribution? It would either be OpenSSL itself (if insufficient creative effort were involved in the process of creating this file) or it would be a product derived (if sufficient creative effort were added to consider it a distinct work). In other words, would the person be able to prohibit redistribution of their new libcrypto.a, even though it utilizes some unmodified OpenSSL code, and is part of a complete OpenSSL distribution? Certainly. Nothing in the OpenSSL licenses requires you to allow redistribution of any derivative works you create. (And anyone who did so would be violating *your* rights, not those of OpenSSL or its authors since copyright law doesn't permit you to restrict distribution of derivative works, only creation.) However, if the thing you distributed was legally deemed to be OpenSSL itself, rather than a derivative work, you could not prohibit redistribution (under copyright law). You do not hold copyright to OpenSSL itself, so nobody can violate any of your rights by distributing it. (Merely compiling OpenSSL, for example, doesn't give you any copyright rights in the results. You must add creative effort to acquire copyright interest.) You could try to prohibit such things with contracts and the like. IANAL. My responses exlclusively assume United States law, other countries do definitely differ. Consult a lawyer if any of this matters to you. HTH. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: License question: What is considered promoting?
On Wed, Jul 02, 2003, [EMAIL PROTECTED] wrote: Hi, I have a question regarding the combination of phrases 3 and 4 of the OpenSSL license: * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit. (http://www.openssl.org/) * 4. The names OpenSSL Toolkit and OpenSSL Project must not be used to *endorse or promote products derived from this software without *prior written permission. For written permission, please contact *[EMAIL PROTECTED] Let's say I create a product which uses parts of the OpenSSL Toolkit, and I produce advertising material containing the acknowledgement sentence (according to phrase 3). Is this considered 'promoting products using the names OpenSSL Toolkit and OpenSSL Project' according to phrase 4? Do I need a written permission in this case? No you do not. I found that the Berkeley License (BSD), from which the OpenSSL license seems to be derived, has eliminated phrase 3 in 1999. In consequence my conflict described above wouldn't occur with the BSD license. Has phrase 3 of the OpenSSL license been left in effect with purpose? The SSLeay license (which is part of the OpenSSL license) has a similar phrase and we can't alter that part of the license. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
License Question
The last paragraph of the license says: * The licence and distribution terms for any publically available version or * derivative of this code cannot be changed. i.e. this code cannot simply be * copied and put under another distribution licence * [including the GNU Public Licence.] Could someone on this list explain what this is intending. For example if one were to put out a product which uses openSSL, and that product's license was a private license. Would one be precluded from providing service and support for openSSL under such a license... -- Steven A. Bade UNIX Network Security Cryptographic Strategy and Development Architecture [EMAIL PROTECTED] T/L 678-4799 (512)-838-4799 -- To convert from Hogsheads to Cubic Feet - Multiply by 8.4219 Two-way communication is necessary to proactively facilitate acceptance and involvement and to get insights about the journey it takes to get where we want this mess is so big and so bad and so tall, we cannot clean it up, there is no way at all (Cat in the Hat) he Hat) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: License Question
That part of the license doesn't actually add anything that wasn't already there under standard copyright terms. That part of the license is from the days when the codebase was SSLeay, the product of Eric and Tim. Years ago. AT the time, it was not uncommon for someone to rip off open source code and replace it with a similar copyright. We've all become smarter and more law-abiding, so this is less of a concern. But it's the original license for some openssl code, so the openssl folks can't change it. Fundamentally, as long as you provide appropriate credit, you can do what you want. /r$ -- Zolera Systems, Your Key to Online Integrity Securing Web services: XML, SOAP, Dig-sig, Encryption http://www.zolera.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Usage/License Question
My company is using OpenSSL in one of their applications. I cannot find the license(s) associated with OpenSSL at openssl.org. Can you point me in the right direction or email them to me. Thanks Brad Mock, Contracts Negotiator ADP - Dealer Services Division 2525 SW First Ave, Suite 450 Portland OR 97201-4702 (503) 294-5217 office; (503) 294-5292 fax [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]