Date: Wed, 11 Jan 2012 08:36:12 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: copyright and license statements 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. 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.) 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.