[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20070319231117.GA754@openwall.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
