[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
