On 31/08/11 02:57, Russ Allbery wrote: > Ximin Luo <infini...@gmx.com> 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