Date: Sat, 4 Feb 2012 21:34:05 -0500 From: <jfoug@....net> To: john-dev@...ts.openwall.com Cc: Solar Designer <solar@...nwall.com> Subject: Re: copyright and license statements After getting a reply back from solar offlist, that he was waiting for my acceptance of this plan, I will take the time to do so now. I thought the works that i had done up until now, had satisfied these licensing arrangements. I will interject comments where i feel they need to be. ---- Solar Designer <solar@...nwall.com> wrote: > magnum, Jim, all - > > On Thu, Jan 05, 2012 at 04:20:50PM +0100, magnum wrote: > > I use the recommended wording in files like mskrb5_fmt. In files that > > someone else wrote and I just added stuff (these are the vast majority > > of my patches), I can't claim "the" copyright, can I? Or maybe I can > > claim a copyright for the few lines of mine, but then I'm not sure how > > to word it. Maybe I should just say "This and that added by magnum 2012" > > and nothing more? > > When you make non-trivial changes to source files that I or someone else > wrote, you become a copyright holder to those derived works. So, yes, > you can claim copyright, and I (and/or other authors) remain copyright > holders as well. You don't have to document what exactly your copyright > applies to (which portions of the source file), but doing so is helpful. > > I was not able to find a definitive answer on what constitutes a trivial > change (too trivial to be subject to copyright). I think this is what > would be called "a de minimis or insignificant contribution", but there's > no precise definition of that (and even if there were one, it may differ > by jurisdiction). I think we need to apply the same approach that most > others in the "industry" appear to use. It appears that the following > are examples of changes that don't make you a copyright holder: typo and > error corrections (unless correcting an error involves adding a > non-trivial amount of code - again, what is "non-trivial" is not > precisely defined), moving pieces of code around, adding information > that "is common property and containing no original authorship" (e.g., > character encoding translation tables). On the other hand, changes that > add functionality and contain your "original work" are likely subject to > your copyright. > > There's some information on this here: > http://www.softwarefreedom.org/resources/2007/originality-requirements.html > Section "6 Size and substantiality: affirmative defenses to infringement". > > There's also some more definitive information here: > http://www.copyright.gov/circs/circ1.pdf > (but this does not appear to touch the issue of triviality). > > For non-trivial changes to JtR source files where the contributor > becomes a copyright holder, my preference so far has been to re-license > the entire file under the permissive cut-down BSD license. This is what > we did for jumbo's revision of unique.c when Jim made non-trivial > contributions to that source file. We may (and probably should) do the > same for config.c in jumbo, which includes the non-trivial addition of > the .include directive support. > > However, for some other source files I think that would be problematic. > For example, I am uncomfortable about lifting the GPL restrictions from > rules.c for everyone at once because that file may be of (more) interest > to (potential) proprietary password cracker programs. I'd like to > retain the right to issue such non-GPL licenses to them explicitly. If > you simply add your copyright statement to that file, which you should > given your contributions to it in jumbo so far, then I am stuck with > GPLv2, not being able to re-license the file in the future (neither for > everyone at once nor for specific companies, etc.) without coordinating > with you (which may even involve paperwork each time we're talking > re-licensing for a specific company). I see the following ways to > resolve this for such source files: > > 1. Move your non-trivial contributions to separate (new) source files > such that you can unambiguously apply your copyright statement and our > standard permissive cut-down BSD license just to those. Modify the > original file (such as rules.c) in trivial ways only - e.g., adding > calls into functions found in your new file. The can be difficult. Take for instance mscash2. My CPU contributions to that were certainly non-trivial. That change ended up being about 50% total rewrite, and much of the orinal code and optimization attempts were scrapped (which made up about 75% of the original files. For some modules, adding external source can be achieved, but this may put us into a state where we start adding more and more globals, which for a open project like john, can be a very ugly way to go. > 2. Don't retain your copyright to your changes to shared files, but > instead transfer copyright either to me or to a legal entity that will > be the copyright holder for JtR - perhaps to Openwall, Inc. IIRC, this > is the approach that e.g. the Nmap project is using (with copyright for > contributions transferred to Insecure.Com LLC). You will continue to be > credited as an author of those files anyway, but not be a copyright > holder. (Authorship and copyright are distinct things.) This one, I am much more open to, and feel it should be easier to do. Could something like this be done with a blanket transfer statement, and then within source files, simply refer to that statement of transfer. I personally am not overly concerned about the copyright. Credit for being author is all I have ever really wanted anyway. The code I have produced for this project has been done so under my knowledge and consent that the ownership rights of the source was to be owned by the JtR project as a whole, in whatever way was necessary. > Are these acceptable for you and which one would you prefer? > > If we go with #2, then it would make sense to apply the same approach to > entirely new files as well - e.g., to new formats. (Jumbo now has so > many extras compared to the main JtR that those extras alone (such as > many of the formats) may be of value to a company developing a > proprietary password cracker.) This raises the issue of your own > ability to reuse your code without GPL restrictions, though. Maybe > Openwall should issue a license to each contributor with right to > sublicense that contributor's source files to third-parties if/when the > contributor chooses so. But this gets complicated. > > > There's also files like para-best.sh which is a new file but is a 95% > > copy of best.sh which is your file. Not sure how to word a statement > > there. > > If your changes made in para-best.sh relative to my best.sh are > non-trivial, then you're a copyright holder to this derived work. > I just took a look and I think the changes are non-trivial. In fact, I > think only trivial aspects of my original best.sh are left - the overall > structure of the script, but not any detail. My understanding is that > program structure is not subject to copyright. So I think that you're > the sole copyright holder to your para-best.sh. > > Not speaking of para-best.sh specifically, it would be nice to be able > to just place one's changes in the public domain, but it is unclear > whether this is possible. Some would argue that the law defines no > mechanism to do that. The same can be said of placing entire new works > in the public domain, but there's precedent to that, which may help. > I don't know if there's precedent to placing one's changes to an > existing work in the public domain - are you aware of such examples? > Yet I prefer a copyright statement with a permissive license in all > cases lately. > > I'd appreciate any comments. > > 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.