Date: Tue, 20 Mar 2007 02:11:17 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: patches not getting in On Mon, Mar 19, 2007 at 10:51:53PM +0100, Till Maas wrote: > > > why are the patches distributed apart from john? > On Mo M?rz 19 2007, Solar Designer wrote: > > You've identified one of the reasons - the quality is often inadequate. > > Other reasons include dependencies on external libraries (in this case > > it's libdes or OpenSSL) and licensing issues. > > What are the licensing issues? As far as I understand GPL, the patches > have to be GPL, too. This is almost correct, however: 1. Some older versions of JtR did not include an explicit LICENSE file with them (my fault). As a result, it is similarly non-obvious what licenses the patches for those versions of JtR were under (except in the few cases where GPL was mentioned explicitly). Some of the more recent patches continue to include code from those older ones. 2. No, the patches do not strictly have to be GPL'ed in their entirety. These patches add new source files. While those new source files have to be GPL'able in order to be linked into a GPL'ed program, they may also be dual-licensed (e.g., "BSD or GPL") or they may be placed in the public domain. This is not a problem; I am merely commenting on your assertion and I needed to make this point in order to get to the next one: 3. While I release JtR to the public under the GNU GPL v2, I am uncomfortable about incorporating GPL-only code back into the official JtR and investing my time into that code. I want to retain more freedom on how I can license future and derivative versions of JtR. I am already starting to make use of this freedom with JtR Pro, and I am hoping that the revenues will help me spend more time on JtR development in the future. So at this time in order for a patch to be a candidate for inclusion it will have to have the following properties: 1. Good code quality (or I need to be comfortable with investing my time into it). 2. No dependencies on external libraries (beyond the C library). No dependencies on uncommon build tools. 3. New source files either explicitly placed into the public domain or under a dual license. The two licenses have to be GNU GPL v2 and a license permitting for proprietary derivative versions; the license that I use for popa3d (a POP3 server) and for some other software that I wrote would be an example. Alternatively, copyright may be transferred to me. Currently, public domain is my preference for its simplicity, although I've heard some legal concerns around the ability (or lack thereof) to explicitly place something in the public domain. I will continue to give credit where it is due. As it relates to changes to existing source files in JtR, these are typically insignificant and not subject to copyright. However, in other cases I may be willing to explicitly license the affected source files under a license more permissive than the GPL in order to be able to get the same rights to the changes back, or I may re-implement the changes. So far, these licensing issues and the approaches suggested above are pure theory. There has been no occasion where I wanted to include a patch but couldn't do that for licensing reasons only. I have no desire to include the code in currently existing contributed patches into the official JtR anyway, or I would have attempted to clear the licensing issues up with the patch authors already. While I find much of the functionality added with the contributed patches desirable, I think that I'll need to re-code them anyway when/if I find/allocate my time for that. Finally, I am planning/hoping to make some changes to the JtR core before I add support for more hash and cipher types: http://www.openwall.com/lists/john-users/2006/03/24/11 Having that said, I and especially many others find it very helpful that those contributed patches are available! > Or are there patent issues, too? There might be some, but I don't think we've run into any yet. -- Alexander Peslyak <solar at openwall.com> GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15 http://www.openwall.com - bringing security into open computing environments -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ