[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130420170852.GA29391@openwall.com>
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.
