Re: Sponsorship requirements and copyright files
Joerg Jaspert <joerg@debian.org> writes:
> Also, keep in mind what Mark wrote elsewhere. He asked the DPL to let
> SPI get us some lawyers input on the question. Thats probably the best
> course.
Yes. I'm wholeheartedly in favor of this, and I think we should hold any
resolution of this discussion for the results of that. There are a
surprising number of gotchas hidden in licenses that people think are
straightforward and read past, and it would be nice to know what our basic
legal requirements are.
I agree that we need to duplicate the copyright statement that's written
above a BSD-style license that contains a clause like:
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
[...]
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
or:
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, [...]
subject to the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
If the license is stated in those files, then it applies to the copyright
notice in that file and hence we have to duplicate it.
I'd like to get an answer about what we have to do with GPL notices.
Hopefully we can get a legal evaluation for that. (I'm curious whether we
can safely combine copyright notices -- merging together ones with
disjoint dates, for instance -- and still satisfy this requirement.)
However, there are a lot of upstreams that stick copyright notices in
files but don't duplicate license terms or that just stick authorship
information in files without making it a copyright notice and then just
have a single license notice somewhere, like README. Those are the cases
where I don't see a legal need for duplicating the copyright statements.
> You do have to check every file anyway, otherwise you can't be sure
> about your copyright file listing all the licenses your package
> uses. And I sincerely hope noone will contest the need to list the
> various licenses a package uses?
Well, the one thing that I think we need to clarify here is whether we
need to list the licenses for files that aren't source code for what goes
into the binary distribution, such as the build system. The files from
Autoconf and Automake have a bunch of different licenses and documenting
them is a fair bit of work for each package.
Looking at one of mine where I did that work, I have four different
sections for every package using Autoconf and Automake: one for
Makefile.in and aclocal.m4, one for configure, one for config.* and some
Automake and libtool helpers, and one for install-sh. They all have
different licenses. If I had to include only the exact copyright notice
that's in each file, that would quickly turn into about ten different
sections since there are slightly different years listed. This is pretty
annoying work.
Clearly, all build support files have to be under a DFSG-free license.
But as long as that's the case, I'm not sure we should be requiring people
to document the licenses of files used only in the build system or in bits
of software that aren't included in the final binaries (such as the test
suite, which even in FSF software sometimes includes tons of different
copyright holders since the FSF doesn't always require copyright
assignment for test suites).
But I don't think anyone is contesting that we have to document the
license of every file that goes into the binary software that we're
distributing in the *.deb package.
>> If the argument in favor is just that Policy says something along those
>> lines, well, as discussed in this thread, I want to revise that Policy
>> section anyway.
> Feel free to. :)
Okay, I may propose some tentative text in the next few days, with the
caveat that it may change based on the resolution of the legal
investigation.
> Yes, thats definitely part of the reason. Also, if people would look at
> how NEW had been handled in the past up to now, instead of purely
> exaggerating and taking actions from there, they would have found out
> that we are usually pretty lenient with this enforcement. We do mention
> it when we see it and whenever we do have a reject anyway, like when
> people forgot to mention a license at all. Rejection solely based on
> missing (C) notices might (have) happen(ed), but should be seldom and
> when there are lots of them with a license requiring them.
> Also, if just a small set is missing and nothing else would block
> accepting the package, we quite often accept the package and send a
> comment to the maintainer saying that the following couple of lines
> should be added at the next upload.
I think part of the problem right now is that people aren't sure what to
expect and are feeling like this review is somewhat unpredictable. This
is what I'm hoping to be able to help with by revising the Policy section.
If we can break this down into must, should, and best practice, then
people can understand that they'll get a reject for breaking a must, maybe
a reject for being particularly sloppy about shoulds, and just get notes
about best practices, as with most of the other things in NEW review.
We also clearly have a problem with really large packages, I think even
with the license review. A good solution for that, I think, would be for
some of the people who are particularly concerned about licensing review
who aren't doing ftpmaster work to volunteer to do license review for some
of the large packages (and accumulate copyright statements if they feel
like it). There are several of those folks in this thread who have said
that they currently don't have any large packages, and the maintainers are
almost certainly happy to accept the work. Doing this review usually
doesn't require any other knowledge of the package or any special skills.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: