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

[Ximin Luo]

On 01/09/11 07:15, Ben Finney wrote:
> 
> Ximin Luo  writes:
> 
>> At the cost of some complexity in code, we can eliminate a lot of
>> complexity in our data.
> 
> There is redundancy, yes. Is that what you're calling complexity? Or is
> there some significant complexity in the data of the ‘debian/copyright’
> file that you've got in mind?
> 
>> With pointers, it is easier for maintainers to create simple
>> debian/copyright files.
> 
> At the cost of actually making the package more brittle: when taking
> parts of a package, it is easier to omit a file than to omit part of a
> file. So a reference is more complex, and prone to failure, than simply
> keeping all the license information in one place.
> 
> Now, we compromise that flexibility, in the case of *very* common
> licenses which are well-known. But I don't see you making a good case
> for allowing that complexity to increase.
> 

I don't see you or anyone else making a good case for not allowing that
complexity. It's all hand-waving.

Your "more brittle" point isn't true, it's easier for humans to check pointers
since they don't need to scroll through a huge swathe of text, and easier to
code a program to check original unformatted license texts since we don't need
to bother with parsing to a canonical form.

>> Since there are thousands of packages and there only needs to be a few
>> DEP-5 parsers (ideally, one), the choice seems obvious to me.
> 
> Another point of disagreement. I think that multiple competing parser
> implementations for a standardised data format is healthier and more
> robust than a single implementation.
> 
>> Sure, it's "easy" to format licenses into DEP-5 long-text format, but
>> each new maintainer needs to do this for themselves.
> 
> That formatting is no different from the formatting they must already
> learn for the ‘Description’ field in ‘debian/control’. Do you think
> using the same formatting for another field is a significant increase in
> complexity?
> 

License texts can be quite long. You don't want to have a standard that
requires humans to handle long pieces of text, especially widely-distributed
license texts.

Description fields are short paragraphs and each package has a different one.
License texts are the exact opposite.

>> In fact I might go write the tool I mentioned before and learn some
>> perl in the process... that's what a lot of Debian devscripts is
>> written in, right?
> 
> Formatting a passage of text to that format would be useful, I agree,
> since it could be used for the multiple metadata fields that have that
> format.
> 

That would be really really ugly pointless code and I'm not going to do that.
Much easier to cp $LICENSE and cat $LICENSE.

-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0



signature.asc
Description: OpenPGP digital signature

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

[Ben Finney]

Ximin Luo  writes:

> At the cost of some complexity in code, we can eliminate a lot of
> complexity in our data.

There is redundancy, yes. Is that what you're calling complexity? Or is
there some significant complexity in the data of the ‘debian/copyright’
file that you've got in mind?

> With pointers, it is easier for maintainers to create simple
> debian/copyright files.

At the cost of actually making the package more brittle: when taking
parts of a package, it is easier to omit a file than to omit part of a
file. So a reference is more complex, and prone to failure, than simply
keeping all the license information in one place.

Now, we compromise that flexibility, in the case of *very* common
licenses which are well-known. But I don't see you making a good case
for allowing that complexity to increase.

> Since there are thousands of packages and there only needs to be a few
> DEP-5 parsers (ideally, one), the choice seems obvious to me.

Another point of disagreement. I think that multiple competing parser
implementations for a standardised data format is healthier and more
robust than a single implementation.

> Sure, it's "easy" to format licenses into DEP-5 long-text format, but
> each new maintainer needs to do this for themselves.

That formatting is no different from the formatting they must already
learn for the ‘Description’ field in ‘debian/control’. Do you think
using the same formatting for another field is a significant increase in
complexity?

> In fact I might go write the tool I mentioned before and learn some
> perl in the process... that's what a lot of Debian devscripts is
> written in, right?

Formatting a passage of text to that format would be useful, I agree,
since it could be used for the multiple metadata fields that have that
format.

-- 
 \ “[W]e are still the first generation of users, and for all that |
  `\  we may have invented the net, we still don't really get it.” |
_o__)   —Douglas Adams |
Ben Finney


pgpmyREO3qwbO.pgp
Description: PGP signature

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

[Ximin Luo]

On 31/08/11 21:49, Russ Allbery wrote:
> Ximin Luo  writes:
> 
>> 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. "
> 
> "should" is documented at the beginning of Policy:
> 
>  In the normative part of this manual, the words _must_, _should_ and
>  _may_, and the adjectives _required_, _recommended_ and _optional_,
>  are used to distinguish the significance of the various guidelines in
>  this policy document.  Packages that do not conform to the guidelines
>  denoted by _must_ (or _required_) will generally not be considered
>  acceptable for the Debian distribution.  Non-conformance with
>  guidelines denoted by _should_ (or _recommended_) will generally be
>  considered a bug, but will not necessarily render a package
>  unsuitable for distribution.  Guidelines denoted by _may_ (or
>  _optional_) are truly optional and adherence is left to the
>  maintainer's discretion.
> 
>  These classifications are roughly equivalent to the bug severities
>  _serious_ (for _must_ or _required_ directive violations), _minor_,
>  _normal_ or _important_ (for _should_ or _recommended_ directive
>  violations) and _wishlist_ (for _optional_ items).
> 
> There are some circumstances involving packages with complex licensing
> where some maintainers like to maintain separate copyright files for each
> of the generated binary packages that contain only the information
> relevant to that package, and in those cases, the copyright file installed
> in binary packages may not be the same as debian/copyright.
> 
> In general, "should" means "this is what you do unless you know exactly
> what you're doing and what the implications of making another choice are."
> 
>> Right. Actually by "pointing" I meant more specifically "to another file
>> distributed along with the package", in the context of DEP-5 License:
>> blocks.
> 
> I'm really not sure I see much utility in doing that, honestly.  I know
> that some people, yourself apparently included, see that as a huge win,
> but to me the process of copying the license into debian/copyright is
> trivial, as is putting it in DEP-5 format if one chooses to use that
> format, and I don't really get why there's so much resistance to just
> doing that.  And it makes it much easier for, for example, ftp-master to
> review the package and be sure all the licenses are where they should be.
> 
>> 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.
> 
> See, now you've (to my mind) introduced considerably more complexity than
> just putting a copy of the license into debian/copyright like we're doing
> now.
> 

At the cost of some complexity in code, we can eliminate a lot of complexity in
our data. With pointers, it is easier for maintainers to create simple
debian/copyright files. Since there are thousands of packages and there only
needs to be a few DEP-5 parsers (ideally, one), the choice seems obvious to me.

Sure, it's "easy" to format licenses into DEP-5 long-text format, but each new
maintainer needs to do this for themselves. Once you've been doing it long
enough, you can just c+p it from other debian/copyright files that you know
already have this in. In the spirit of sharing, someone might publish DEP-5
formatted versions of license files, to save other people work. Then someone
else might write a tool to automate this copying into new packages. etc etc etc

Rather than allowing the current scheme evolve into an ugly solution, where
correctness is by implicit unwritten "convention", we can simply make a minor
change to DEP-5 to allow a much neater solution (direct use of license files in
their original format) where correctness is by specification.

In fact I might go write the tool I mentioned before and learn some perl in the
process... that's what a lot of Debian devscripts is written in, right?


-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0



signature.asc
Description: OpenPGP digital signature

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

[Russ Allbery]

Ximin Luo  writes:

> 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. "

"should" is documented at the beginning of Policy:

 In the normative part of this manual, the words _must_, _should_ and
 _may_, and the adjectives _required_, _recommended_ and _optional_,
 are used to distinguish the significance of the various guidelines in
 this policy document.  Packages that do not conform to the guidelines
 denoted by _must_ (or _required_) will generally not be considered
 acceptable for the Debian distribution.  Non-conformance with
 guidelines denoted by _should_ (or _recommended_) will generally be
 considered a bug, but will not necessarily render a package
 unsuitable for distribution.  Guidelines denoted by _may_ (or
 _optional_) are truly optional and adherence is left to the
 maintainer's discretion.

 These classifications are roughly equivalent to the bug severities
 _serious_ (for _must_ or _required_ directive violations), _minor_,
 _normal_ or _important_ (for _should_ or _recommended_ directive
 violations) and _wishlist_ (for _optional_ items).

There are some circumstances involving packages with complex licensing
where some maintainers like to maintain separate copyright files for each
of the generated binary packages that contain only the information
relevant to that package, and in those cases, the copyright file installed
in binary packages may not be the same as debian/copyright.

In general, "should" means "this is what you do unless you know exactly
what you're doing and what the implications of making another choice are."

> Right. Actually by "pointing" I meant more specifically "to another file
> distributed along with the package", in the context of DEP-5 License:
> blocks.

I'm really not sure I see much utility in doing that, honestly.  I know
that some people, yourself apparently included, see that as a huge win,
but to me the process of copying the license into debian/copyright is
trivial, as is putting it in DEP-5 format if one chooses to use that
format, and I don't really get why there's so much resistance to just
doing that.  And it makes it much easier for, for example, ftp-master to
review the package and be sure all the licenses are where they should be.

> 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.

See, now you've (to my mind) introduced considerably more complexity than
just putting a copy of the license into debian/copyright like we're doing
now.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Ximin Luo]

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

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

[Russ Allbery]

Ximin Luo  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.

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).

> 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).

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Ximin Luo]

On 29/08/11 17:48, Russ Allbery wrote:
> Jonathan Nieder  writes:
> 
>> Allowing debian/copyright to rely on files _other_ than the common
>> licenses in base-files would be a larger and different change, so
>> off-topic for this bug.  Unless done carefully, I don't think it's a
>> good idea.
> 
> It's important to remember that Debian has a basic legal requirement to
> provide the licensing terms with the packages that we distribute, and
> those packages are potentially independent of each other from a legal
> perspective.  Just because one package has a dependency on another doesn't
> mean that someone is required to download both packages, and when we
> distribute packages that do not include required legal texts, we're on
> shaky ground.
> 
> 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.

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.)

It would be less trouble if you could point to license files. Normally, those
files exist with the upstream source already, and also not re-formatted, so you
can verify their contents more easily.

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.

X

-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0



signature.asc
Description: OpenPGP digital signature

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

[Colin Watson]

On Mon, Aug 29, 2011 at 11:36:45AM -0500, Jonathan Nieder wrote:
> Allowing debian/copyright to rely on files _other_ than the common
> licenses in base-files would be a larger and different change, so
> off-topic for this bug.  Unless done carefully, I don't think it's a
> good idea.

And FWIW, since I haven't seen it stated in this bug thread as yet, the
reason I've always seen for that restriction is that allowing such
external references makes it more difficult for ftpmaster to review
licences of new packages, and it's in the project's interest to allow
them to do that efficiently.

-- 
Colin Watson   [cjwat...@debian.org]



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Jonathan Nieder  writes:

> Allowing debian/copyright to rely on files _other_ than the common
> licenses in base-files would be a larger and different change, so
> off-topic for this bug.  Unless done carefully, I don't think it's a
> good idea.

It's important to remember that Debian has a basic legal requirement to
provide the licensing terms with the packages that we distribute, and
those packages are potentially independent of each other from a legal
perspective.  Just because one package has a dependency on another doesn't
mean that someone is required to download both packages, and when we
distribute packages that do not include required legal texts, we're on
shaky ground.

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.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Jonathan Nieder]

Hi,

Ximin Luo wrote:

> I don't think disk space is an issue these days

I think that's the real point of disagreement here, for what it's
worth.

common-licenses is part of base-files, which is included on every
Debian installation.  Some do need to be small.

(No opinion on whether the MPL should be part of common-licenses,
personally.  It seems borderline.)

Allowing debian/copyright to rely on files _other_ than the common
licenses in base-files would be a larger and different change, so
off-topic for this bug.  Unless done carefully, I don't think it's a
good idea.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org