David, On Sun, Jan 18, 2009 at 06:03:07PM +0100, David Paleino wrote: > However, I was planning the release of 1.7.3.1 in Debian and... luckily I > marked > my debian/copyright with big TODO marks, we avoided a sure REJECT ;)
Well, I think you could include 1.7.3.1 in Debian without the patches initially. You don't have to apply them. I wrote: > > The possibilities for contributed code, to be considered for inclusion, > > appear to be: > > > > - public domain statement (in this case, the author should be mentioned, > > but no copyright statement may be included; in fact, a copyright > > disclaimer may be included along with the "placed in the public domain" > > statement); > > Well, copyright statement is just saying "Hey, I did it, I have my rights > on it and can exercise those" -- A copyright statement says "I have my rights on it and can exercise those". It does not say "I did it" (copyright could also have been transferred to the person/entity). > but right after you release it in the "public domain". I have no idea what you mean by this. My point was that "public domain" and "copyrighted work" are mutually exclusive. So one can't meaningfully include both a copyright and a public domain statement on a file. > I don't consider files with missing statements as PD -- they're "All rights > reserved" in most countries. Correct. > > - a relaxed license compatible with GNU GPL v2+, but also allowing for > > proprietary derivative works - e.g., the license I use for popa3d or > > Matthew Kwan's micro-license found in nonstd.c in JtR; > > Yes -- I considered those free already (snippet from current > debian/copyright): ... Great. I mentioned nonstd.c to illustate a suitable relaxed micro-license for contributed code in general. I'd be happy if all contributions, short of those placed in the public domain (which I like best), were licensed like that. > > - dual-license: "GNU GPL v2 or later" > > This is because JtR is itself under GPL-2+, I suppose. Right now, JtR is GPL v2 only - but I want to retain the right to "upgrade" to "GPL v2 or later" or to GPL v3 or to a later version (if available at the time) if I choose to do so in the future. > > or a specific permissive license allowing for proprietary derivative works > > at > > the user's discretion; > > Clear. I quoted the above paragraph to not leave the "dual-license" quote out of context (otherwise, someone could think of "dual-license" as referring merely to different versions of the GPL, whereas it is referring to "GPLv2+ or a permissive ..."). > As you might have seen, the mails I sent generally lacked any statement. So, > let the authors decide the license they want -- if they choose BSD, I'll push > them towards BSD-2, if they choose a JtR-incompatible (yet free) license, I'll > warn them about the patches not being included upstream, and so forth. OK. I think most authors did not care about placing their code under a specific license, so it makes sense to suggest to them what licenses work best not only for Debian but also for inclusion upstream. That way, we'll avoid having them pick a "random" license at first, then have to re-license should I want to consider the code for inclusion later. You have essentially started to do it by including a reference to my first posting on this in your e-mails. Thank you! > > I previously touched on this issue in the following posting: > > > > http://www.openwall.com/lists/john-users/2007/03/19/4 > > Regarding the OpenSSL issue, ... I think you misunderstood me on this. My reference to OpenSSL in that posting was not in connection with licensing. > As far as I understand your requirements though, and the OpenSSL license [0], > probably point 3 is failing your "must not have specific requirements for > attribution" wish. Correct me if I'm wrong (I'm not a lawyer, after all). Currently, I include this in the JtR Pro license: "Some builds of John the Ripper Pro are statically linked against the SHA-1 code from OpenSSL libcrypto, by Eric Young and others." I hope this is sufficient. As to the very specific attribution text required by the OpenSSL license, I think it is actually inconsistent with different specific text found in the SSLeay license. Although the OpenSSL license also includes the "Original SSLeay License", I find it weird that it does not require those using OpenSSL in a product to use the attribution required by SSLeay. This is understandable, as the old attribution would no longer be 100% correct, but I think it highlights a problem with those specific attribution requirements. Disclaimer: IANAL. > Thank you for your mail. I'll point to it in further mails to add-on authors > :-) Thank you! Alexander -- Pkg-john-devel mailing list Pkg-john-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-john-devel