Date: Sat, 20 Apr 2013 21:08:52 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: licensing On Sat, Apr 20, 2013 at 05:48:24PM +0200, Frank Dittrich wrote: > On 04/19/2013 10:37 PM, Solar Designer wrote: > > And yes, I also hate to spend time on this, but I also hated not being > > able to answer the question of "what source files from jumbo may I be > > able to reuse in a non-GPL'ed project or product" > > Which projects or products? These include my/our own JtR Pro (although right now it only uses my code and non-copyrighted code, mostly Alain's) and third-party commercial products, to which I might license JtR code for a fee. For JtR Pro, licensing it under GPLv2 is an option I may consider. I currently include the full source code as a bonus with JtR Pro for Linux anyway. For third-party commercial products, GPL generally won't work, yet I'd rather have the option to permit for such reuse of code from JtR. On one hand, having more code GPL'ed increases the incentive for those third-party commercial products to license code from JtR for a fee (rather than reuse only whatever portions they can for free), but on the other hand having too much GPL'ed code with multiple copyright holders complicates things. This is a reason why I am thinking of limiting use of GPL to a subset of JtR core files only. Also, some years ago I permitted to include the rules engine and config file parser from JtR in Stegdetect, which is BSD-licensed. I wouldn't be able to easily do this for revisions of these files in jumbo now, where the changes by others may have been implied to fall under GPLv2. http://www.outguess.org There may be other free software projects (besides Stegdetect) interested in reuse of code from JtR, too. Finally, another concern is that it may be preferable to re-license the whole thing under terms different than GPLv2 at some point (possibly now) - for example, if we (continue to) run into license conflicts that are not easily and convincingly solved by other means. We already have issues with GPL (in)compatibility with OpenSSL and unRAR licenses. Maybe re-licensing JtR under "GPL with OpenSSL exception and unRAR exception" (need to write those) will be sufficient, but for that we already need approval from all copyright holders on the GPL'ed files, so we already have a problem. I'd rather not have more of these problems in the future (be able to add exceptions or/and re-license on my own). Given this last point, a valid answer to your "which projects?" is even "JtR itself". > And why should we care? I think we/you should care at the very least about licensing of jumbo itself not being self-contradictory (no GPL/OpenSSL and GPL/unRAR conflict), so that e.g. Debian would be happy to redistribute it. Another relevant aspect is that some people, including me, are less willing to contribute to GPL'ed code (with copyright holders other than themselves), because by doing so they revoke rights to their own work (can't easily re-license and reuse their changes elsewhere since the changes get intermixed with the rest of GPL'ed code in the same source files). For this reason, I am already less willing to contribute substantial changes to some files in jumbo, and I wouldn't be surprised if some contributors are similarly less willing to modify GPL'ed files from JtR core (than they would be if those files were re-licensed under cut-down BSD, as I intend to do for some of the files). As to the rest of reuse possibilities, it's mostly a matter of preference ("do we, the contributors, want to permit for reuse of our code in non-GPL'ed free software projects?", "do we, the contributors, want to let the original author sell commercial licenses that would include our code, or would we rather force him to exclude or consider replacing our code?", "are we, the contributors, OK with letting third-party commercial products reuse portions of code without explicit re-licensing, as a side-effect of simplifying our other licensing?") Maybe a better way to address much or all of the above would be through licensing of contributions to me with right to sublicense, and with a license back from me to the contributor to sublicense the entire files (not only the contributor's changes), but this is uncommon and hence may raise concerns from redistributors like Debian. Yet we might in fact have to do things in this way for a handful of source files (I am thinking of e.g. rules.c, which may be part of the "JtR heart" yet is heavily modified in jumbo - or I may exclude it from "JtR heart" for licensing purposes because of the heavy modifications in jumbo). A more common way would be to require copyright assignment e.g. to Openwall. This is what the FSF does (requires paperwork) and what Nmap does (without paperwork? might not be good enough, per my reading of the US copyright law a couple of years ago). Also, this raises the question of letting contributors reuse their own code under different terms of their choosing (a license back?) I wish this stuff were simpler, but it does not appear to be, especially with the legacy we already have. For a brand new project, we'd probably choose some simpler model, but as I tried to explain above even then it might not be trivial and perfect. > Personally, I would only care about projects with a BSD-like license > which produced code that we incorporated into john. OK. I care about many other kinds of projects and even commercial products as well. > For everything else, I wouldn't mind third-party projects or products > having to live with GPL. In many cases, this would mean that they'd choose not to use our code rather than choose to license theirs under GPL. Why would we want to prevent them from using our code, if they're not GPL'ed? Do we view them as competitors? Even if so, does their success reduce that of JtR? Even if it does, are we working on JtR for its own success or/and for providing better tools in general or/and for advancing the field overall or/and for other reasons? Are we simply unhappy about someone else benefiting off of our work, and why? If we could otherwise get them to contribute back to JtR, with code (if they choose GPL too) or licensing fees, I would understand - but I doubt that we'd see any extra code contributions and much extra commercial licensing interest due to us keeping more than just the "JtR heart" GPL'ed. > But if the main contributors decide to relax the license of certain > files, I won't object. OK. Thanks. 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.