[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20151204204504.GA18503@openwall.com>
Date: Fri, 4 Dec 2015 23:45:04 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Cc: atom@...hcat.net
Subject: Re: Hashcat is now open source
On Fri, Dec 04, 2015 at 07:50:39PM +0100, magnum wrote:
> https://hashcat.net/forum/thread-4761.html
> https://hashcat.net/forum/thread-4882.html
> https://github.com/hashcat/
This is great news indeed! :-)
I've been thinking what this means (or would mean, before it happened,
since I expected it eventually would) for John the Ripper project.
On one hand, this is one reason less for us to spend effort on John the
Ripper. On the other hand, it's one reason more why we can do a good
job on John the Ripper while also helping hashcat.
What I think we should do in the immediate future is proceed to relax
John the Ripper licensing for more of our source code (hopefully,
eventually all of it) to be two-way compatible with hashcat license of
choice, which is MIT (and which, out of widespread licenses, is a choice
I like). hashcat's MIT license already permits us to reuse code in JtR,
but I'd like us to similarly permit for reuse of JtR code in hashcat (or
in its forks, if any). This is already possible for most of the code in
jumbo, but not for all of it. Our cut-down BSD license (with no
restrictive clauses at all) is compatible with MIT (meaning that hashcat
may integrate the code in the same project, or even re-license our code
under MIT), but GPL is not compatible in the GPL to MIT direction. We
should probably proceed further to re-license our GPL'ed portions under
cut-down BSD.
The MIT vs. cut-down BSD slight difference in wording is unfortunate,
as is (in my opinion) MIT's single restrictive clause (I prefer none),
and it may be something for us to discuss and try to address as well.
But the licenses are two-way compatible as-is, in the sense that we're
able to integrate MIT-licensed code (if we keep the MIT license on it)
and hashcat is able to integrate our cut-down BSD licensed code (and
optionally re-license it under MIT if they insist).
Another issue is source code quality. Frankly, jumbo is not quite on
par with hashcat. JtR core tree is more internally consistent than
jumbo, but its age shows. We should probably complete this summer's
john-dev discussion on source code style, now also avoiding whatever
differences with hashcat's we're comfortable to avoid, and actually
re-format our source code (including and starting with the core tree).
Indeed, this is just formatting rather than other aspects of quality,
but it is a (small) step towards better quality nevertheless. If the
code looks sloppy, as jumbo's does, that does not encourage other
aspects of quality on behalf of the contributors.
Alexander
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.
