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.