[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#487201: MPL in common-licenses and convenience of packaging mozilla extensions

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



Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: