On 31/08/11 02:57, Russ Allbery wrote: > Ximin Luo <[email protected]> writes: >> On 29/08/11 17:48, Russ Allbery wrote: > >>> The project decided to say that our packages are intended for use on a >>> Debian system with the essential Debian packages installed and hence >>> not duplicate licenses that are in base-files, which I think is a bit >>> of a hand-wave, but which lets us avoid shipping 20,000 copies of the >>> GPL. The legal requirements are generally quite clear, and the ideal >>> legal position to be in is inclusion of relevant license texts in every >>> package so that the individual object that we distribute is legally >>> complete. > >> OK, this is understandable. I suppose we can't get around the fact that >> each source package should have the full text of a license. > > And every binary package. They're usually the same case as far as legal > requirements go, and it's definitely possible to download the binary > packages as independent distributions from the source packages. > >> However, this doesn't mean that we must include them in debian/copyright >> specifically - is this restriction really necessary for policy? (I know >> this is off-topic for the bug but it's a continuation of the >> discussion.) > > You don't need to include them in debian/copyright in the source package, > but you normally need to arrange for them to end up in the copyright file > in the binary package, and that's probably the easiest way. >
OK, thanks for clarifying. I take it then that "should" implies "not necessary"
in this policy quote:
"A copy of the file which will be installed in /usr/share/doc/package/copyright
should be in debian/copyright in the source package. "
> Now, this is not true of all licenses. Some licenses don't require
> inclusion of the licensing terms in the binary package; the MPL is one of
> them, in fact. But nearly all of them do, so it's a good default to stick
> with. I suppose we could have a separate discussion about whether to make
> special rules for the licenses like the MPL that don't require this.
>
>> It would be less trouble if you could point to license files.
>
> See, for example, the GPL v3:
>
> 4. Conveying Verbatim Copies.
>
> You may convey verbatim copies of the Program's source code as you
> receive it, in any medium, provided that you [...] give all
> recipients a copy of this License along with the Program.
>
> and:
>
> 6. Conveying Non-Source Forms.
>
> You may convey a covered work in object code form under the terms of
> sections 4 and 5, provided that [...]
>
> So it's up to a legal interpretation of the term "give all recipients a
> copy of this License along with the Program." Obviously, including the
> license in the package satisfies this trivially without requiring anyone
> to think about it or get a legal opinion. Debian has concluded that
> shipping a copy of the license in common-licenses and including a pointer
> to it in each package is sufficient in this case (although I'm a little
> leery of whether Debian really sought legal advice on this point before
> including additional licenses in common-licenses).
>
Right. Actually by "pointing" I meant more specifically "to another file
distributed along with the package", in the context of DEP-5 License: blocks.
>> It would also support more powerful automation tools. For example, we
>> can have a dh script dereference these pointers and install all the
>> license texts into the package's /doc/. And maybe have a licenses-helper
>> program which could detect dangling pointers, and fill the common ones
>> in automatically, to save the maintainer having to find them if they
>> weren't included with upstream.
>
> Note that there are some substantial advantages to having all legal
> information in a single file, not just in terms of complexity and possible
> bugs in not including the right files, but also for ease of extracting
> that file and displaying it alongside the package or making it available
> independently from the package, which we already do in some cases (for QA
> purposes, for instance).
>
What sort of advantages - what could be easier than just "cat $LICENSE" to
display it, and conversely a "cp $LICENSE" to import unincluded license files?
OTOH you need to write a parser/formatter for a DEP-5 License: long-text block.
If the pointing mechanism was well-defined, then lint could detect any "bugs".
For example, if we edit DEP-5 such: { a License: block can either have at least
1 paragraph of long-text, or it must include a Location: line that points to an
existing file in the same directory }, then it's trivial to detect missing
files.
X
--
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0
signature.asc
Description: OpenPGP digital signature
