Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-15 Thread Sean Whitton
Hello,

On Fri 10 Apr 2020 at 10:45PM +02, Guillem Jover wrote:

> On Tue, 2020-04-07 at 17:18:27 -0700, Sean Whitton wrote:
>> On Wed 08 Apr 2020 at 01:18AM +02, Guillem Jover wrote:
>> >> +The copyright information for files in a package must be copied
>> >> +verbatim into ``/usr/share/doc/package/copyright``, when
>> >   ^ Shouldn't this and other instances
>> > of "package" be marked as replaceable text?
>>
>> Possibly, though that's an issue with the existing Policy text not this
>> patch -- perhaps I should just find and replace after applying the patch
>> from this bug?
>
> Ah right, thought this was specific to this drafting. Sounds good.

Now done.

>> > I'm assuming the entire list is supposed to hold at the same time? If
>> > so perhaps adding an «and» here would make this completely unambiguous.
>>
>> Hmm, thanks for the feedback, but I don't think "a; b; and c" is
>> ambiguous in English, and "a; and b; and c" would be an irregular usage.
>
> I guess what I found ambiguous is that "; and" in English does not
> necessarily have a logic connotation. So one can read it as "item a;
> item b; and item c" where the and is just there to introduce the next
> item instead of specifying the content is ANDed. The “when” should
> make it somewhat clear, but on a quick read it just made me doubt.
>
> Take the example list in ch-source.rst
> “Main building script: ``debian/rules``”:
>
>   ,---
>   There are sometimes good reasons to use a different approach.  For
>   example, the standard tools for packaging software written in some
>   languages may use another tool; some rarer packaging patterns, such as
>   multiple builds of the same software with different options, are easier to
>   express with other tools; and a packager working on a different packaging
>   helper might want to use their tool.
>   `---
>
> Which I'd take it as an “and” for the list, not for its contents holding
> true at the same time. :)
>
> With the context I guess it is somewhat clearish, but I'd really like
> to see text that is completely unambiguous for stuff that is normative.
>
>> If this really does need clarification it would be better to add "all of
>> the following" or something before the list.
>
> Yes, clarifying before the list starts would work too, and I thought I
> mentioned it in my reply, but apparently not.

Now done.

Thanks again for the feedback.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-10 Thread Guillem Jover
On Tue, 2020-04-07 at 17:18:27 -0700, Sean Whitton wrote:
> On Wed 08 Apr 2020 at 01:18AM +02, Guillem Jover wrote:
> >> +The copyright information for files in a package must be copied
> >> +verbatim into ``/usr/share/doc/package/copyright``, when
> >   ^ Shouldn't this and other instances
> > of "package" be marked as replaceable text?
> 
> Possibly, though that's an issue with the existing Policy text not this
> patch -- perhaps I should just find and replace after applying the patch
> from this bug?

Ah right, thought this was specific to this drafting. Sounds good.

> > I'm assuming the entire list is supposed to hold at the same time? If
> > so perhaps adding an «and» here would make this completely unambiguous.
> 
> Hmm, thanks for the feedback, but I don't think "a; b; and c" is
> ambiguous in English, and "a; and b; and c" would be an irregular usage.

I guess what I found ambiguous is that "; and" in English does not
necessarily have a logic connotation. So one can read it as "item a;
item b; and item c" where the and is just there to introduce the next
item instead of specifying the content is ANDed. The “when” should
make it somewhat clear, but on a quick read it just made me doubt.

Take the example list in ch-source.rst
“Main building script: ``debian/rules``”:

  ,---
  There are sometimes good reasons to use a different approach.  For
  example, the standard tools for packaging software written in some
  languages may use another tool; some rarer packaging patterns, such as
  multiple builds of the same software with different options, are easier to
  express with other tools; and a packager working on a different packaging
  helper might want to use their tool.
  `---

Which I'd take it as an “and” for the list, not for its contents holding
true at the same time. :)

With the context I guess it is somewhat clearish, but I'd really like
to see text that is completely unambiguous for stuff that is normative.

> If this really does need clarification it would be better to add "all of
> the following" or something before the list.

Yes, clarifying before the list starts would work too, and I thought I
mentioned it in my reply, but apparently not.

Thanks,
Guillem



Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-10 Thread Sean Whitton
control: tag -1 +pending

Hello,

On Sun 05 Apr 2020 at 05:54PM -07, Sean Whitton wrote:

> Here's a patch for seconding, and for the FTP Team to approve.  Thanks
> to Scott for prompting the "all copies" amendation.

FTP Team approval happened at today's team meeting:
http://meetbot.debian.net/debian-ftp/2020/debian-ftp.2020-04-10-19.58.log.html

and we have enough seconds.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-07 Thread Sean Whitton
Hello,

On Wed 08 Apr 2020 at 01:18AM +02, Guillem Jover wrote:

>> +The copyright information for files in a package must be copied
>> +verbatim into ``/usr/share/doc/package/copyright``, when
>   ^ Shouldn't this and other instances
> of "package" be marked as replaceable text?

Possibly, though that's an issue with the existing Policy text not this
patch -- perhaps I should just find and replace after applying the patch
from this bug?

> I'm assuming the entire list is supposed to hold at the same time? If
> so perhaps adding an «and» here would make this completely unambiguous.

Hmm, thanks for the feedback, but I don't think "a; b; and c" is
ambiguous in English, and "a; and b; and c" would be an irregular usage.

If this really does need clarification it would be better to add "all of
the following" or something before the list.

> I'm don't think abbreviating debian/ as d/ is appropriate in policy?
> (Personally I fint it annoying also on debian/changelog, because then
> you need to search using multiple variants of the filenames, but meh. :)

Thanks for catching this error -- fixed in my local git branch.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-07 Thread Sean Whitton
Hello,

On Tue 07 Apr 2020 at 08:03PM -04, Scott Kitterman wrote:

> On Tuesday, April 7, 2020 7:18:42 PM EDT Guillem Jover wrote:
>> > +#. the distribution license for those files requires that copyright
>> > +   information be included in all copies and/or binary distributions;
>>
>> I'm assuming the entire list is supposed to hold at the same time? If
>> so perhaps adding an «and» here would make this completely unambiguous.
>
> Actually I think it would be the opposite.  If we had:

I think Guillem means adding an 'and' after the semicolon.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-07 Thread Scott Kitterman
On Tuesday, April 7, 2020 7:18:42 PM EDT Guillem Jover wrote:
> > +#. the distribution license for those files requires that copyright
> > +   information be included in all copies and/or binary distributions;
> 
> I'm assuming the entire list is supposed to hold at the same time? If
> so perhaps adding an «and» here would make this completely unambiguous.

Actually I think it would be the opposite.  If we had:

> +   information be included in all copies and binary distributions;

then I can see people claiming that since $LICENSE didn't explicitly require 
copyright information in both copies and binaries, they didn't have to do it.

Keep in mind the example license text that I used to frame this part of the 
proposed change:

> The above copyright notice and this permission notice shall be included in
> all copies or substantial portions of the Software.

I think what you are proposing would produce the opposite of the desired 
policy.  If you don't like and/or, then I think or is better:

> +   information be included in all copies or binary distributions;

Scott K

signature.asc
Description: This is a digitally signed message part.


Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-07 Thread Guillem Jover
Hi!

On Sun, 2020-04-05 at 17:54:01 -0700, Sean Whitton wrote:
> Here's a patch for seconding, and for the FTP Team to approve.  Thanks
> to Scott for prompting the "all copies" amendation.

> diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
> index b8ba081..4217dd4 100644
> --- a/policy/ch-archive.rst
> +++ b/policy/ch-archive.rst
> @@ -184,15 +184,32 @@ Copyright considerations
>  
[…]
> +The copyright information for files in a package must be copied
> +verbatim into ``/usr/share/doc/package/copyright``, when
  ^ Shouldn't this and other instances
of "package" be marked as replaceable text?

> +
> +#. the distribution license for those files requires that copyright
> +   information be included in all copies and/or binary distributions;

I'm assuming the entire list is supposed to hold at the same time? If
so perhaps adding an «and» here would make this completely unambiguous.

> +#. the files are shipped in the binary package, either in source or
> +   compiled form; and
> +
> +#. the form in which the files are present in the binary package does
> +   not include a plain text version of their copyright notices.
> +
> +Thus, the copyright information for files in the source package which
> +are only part of its build process, such as autotools files, need not
> +be included in ``/usr/share/doc/package/copyright``, because those
> +files do not get installed into the binary package.  Similarly, plain
> +text files which include their own copyright information and are
> +installed into the binary package unmodified need not have that
> +copyright information copied into ``/usr/share/doc/package/copyright``
> +
> +However, the copyright notices for any files which are compiled into
> +the object code shipped in the binary package must all be included in
> +d/copyright when the license requires that copyright information be

I'm don't think abbreviating debian/ as d/ is appropriate in policy?
(Personally I fint it annoying also on debian/changelog, because then
you need to search using multiple variants of the filenames, but meh. :)

Thanks,
Guillem



Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-05 Thread Sean Whitton
control: tag -1 + patch

Hello,

On Thu 26 Mar 2020 at 09:57AM -07, Sean Whitton wrote:

> The relevant parts of Policy to update are §§ 2.3, 4.5 and 12.5.

Here's a patch for seconding, and for the FTP Team to approve.  Thanks
to Scott for prompting the "all copies" amendation.

There could probably be some useful re-organisation and deduplication
between §§ 2.3, 4.5 and 12.5, but as that's non-normative, let's get
this change committed first.

diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index b8ba081..4217dd4 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -184,15 +184,32 @@ Copyright considerations
 

 Every package must be accompanied by a verbatim copy of its
-distribution license in the file ``/usr/share/doc/package/copyright``.
-
-Every package must be accompanied by a verbatim copy of its copyright
-information, unless its distribution license explicitly permits this
-information to be excluded from distributions of binaries built from
-the source.  In such cases, a verbatim copy of its copyright
-information should normally still be included, but need not be if
-creating and maintaining a copy of that information involves
-significant time and effort.  [#]_
+distribution license(s) in the file ``/usr/share/doc/package/copyright``.
+
+The copyright information for files in a package must be copied
+verbatim into ``/usr/share/doc/package/copyright``, when
+
+#. the distribution license for those files requires that copyright
+   information be included in all copies and/or binary distributions;
+
+#. the files are shipped in the binary package, either in source or
+   compiled form; and
+
+#. the form in which the files are present in the binary package does
+   not include a plain text version of their copyright notices.
+
+Thus, the copyright information for files in the source package which
+are only part of its build process, such as autotools files, need not
+be included in ``/usr/share/doc/package/copyright``, because those
+files do not get installed into the binary package.  Similarly, plain
+text files which include their own copyright information and are
+installed into the binary package unmodified need not have that
+copyright information copied into ``/usr/share/doc/package/copyright``
+
+However, the copyright notices for any files which are compiled into
+the object code shipped in the binary package must all be included in
+d/copyright when the license requires that copyright information be
+included in all copies and/or binary distributions, as most do.  [#]_

 See :ref:`s-copyrightfile` for further details.

diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst
index b466304..3e797d6 100644
--- a/policy/ch-docs.rst
+++ b/policy/ch-docs.rst
@@ -181,10 +181,13 @@ maintainer's discretion.
 Copyright information
 -

-Every package must be accompanied by a verbatim copy of its copyright
-information and distribution license in the file
-``/usr/share/doc/package/copyright``. This file must neither be
-compressed nor be a symbolic link.
+Every package must be accompanied by a verbatim copy of its
+distribution license(s) in the file ``/usr/share/doc/package/copyright``.
+This file must neither be compressed nor be a symbolic link.
+
+A verbatim copy of the package's copyright information is often
+required to be present in ``/usr/share/doc/package/copyright``, too;
+see :ref:`s-pkgcopyright`.

 In addition, the copyright file must say where the upstream sources (if
 any) were obtained, and should include a name or contact address for the
diff --git a/policy/ch-source.rst b/policy/ch-source.rst
index 1a4e871..7644a27 100644
--- a/policy/ch-source.rst
+++ b/policy/ch-source.rst
@@ -211,9 +211,9 @@ Copyright: ``debian/copyright``
 ---

 Every package must be accompanied by a verbatim copy of its
-distribution license in the file ``/usr/share/doc/package/copyright``.
+distribution license(s) in the file ``/usr/share/doc/package/copyright``.

-This file is usually required to contain a verbatim copy of the
+This file is often required to contain a verbatim copy of the
 package's copyright information, too; see :ref:`s-copyrightfile` and
 :ref:`s-pkgcopyright` for details, and for further considerations
 related to copyrights for packages.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-04 Thread Scott Kitterman
On Sat, 04 Apr 2020 14:36:57 -0700 Sean Whitton  
wrote:
> Hello Scott,
> 
> On Thu 26 Mar 2020 at 03:01PM -04, Scott Kitterman wrote:
> 
> > On Thursday, March 26, 2020 1:31:31 PM EDT Scott Kitterman wrote:
> >> 4.  License requires copyright notice but doesn't specify anything about
> >> source or binary (didn't look for an example, but I can totally see this
> >> happening): I think this case is unclear with your revised wording.  With
> >> the current policy wording copyright notices would be required in
> >> debian/copyright and I think that's correct.  The current wording does 
seem
> >> harsh, so it could probably be better while not leaving an ambiguity.
> >
> > Here's a specific example I am looking at in New:
> >
> > The above copyright notice and this permission notice shall be included in 
>> all copies or substantial portions of the Software.
> 
> I agree with you that in such a case we would want the copyright notices
> in d/copyright, but I disagree that my text leaves any room for doubt.
> 
> The text you quote would seem clearly to "require that copyright
> information be included in all binary distributions".
> 
> Perhaps you could suggest an amendation to my text so I can better see
> what you mean about ambiguity.

Is a compilation a copy?  Literally, it's not.  It's a transformation based on 
the original, but the original is not there, so it's not a 'copy'.  

Currently, in the last paragraph, you are suggesting:

"... when the license requires that copyright information be included in all 
binary distributions."

As an alternative, I'd suggest:

"... when the license requires that copyright information be included in all 
copies and/or binary distributions."

Scott K

signature.asc
Description: This is a digitally signed message part.


Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-04 Thread Sean Whitton
Hello Scott,

On Thu 26 Mar 2020 at 03:01PM -04, Scott Kitterman wrote:

> On Thursday, March 26, 2020 1:31:31 PM EDT Scott Kitterman wrote:
>> 4.  License requires copyright notice but doesn't specify anything about
>> source or binary (didn't look for an example, but I can totally see this
>> happening): I think this case is unclear with your revised wording.  With
>> the current policy wording copyright notices would be required in
>> debian/copyright and I think that's correct.  The current wording does seem
>> harsh, so it could probably be better while not leaving an ambiguity.
>
> Here's a specific example I am looking at in New:
>
> The above copyright notice and this permission notice shall be included in all
> copies or substantial portions of the Software.

I agree with you that in such a case we would want the copyright notices
in d/copyright, but I disagree that my text leaves any room for doubt.

The text you quote would seem clearly to "require that copyright
information be included in all binary distributions".

Perhaps you could suggest an amendation to my text so I can better see
what you mean about ambiguity.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-01 Thread Sam Hartman
No, I missed this.
We're on the same page.



Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-01 Thread Sean Whitton
Hello Sam,

On Wed 01 Apr 2020 at 05:11AM -04, Sam Hartman wrote:

> I think there is another use of debian/copyright beyond just documenting
> what ends up in the binaries.
> I think that if I read debian/copyright in a source package, I should
> expect to understand the licenses I need to comply with when dealing
> with the source package.
>
> So for example  if the package requires GPL-3 code during its build, and
> by policy I don't want to deal with GPL-3 I should know I have a problem
> only from reading debian/copyright.
>
>
> So I think you need to talk about more than just binaries.

As I mentioned in my e-mail opening the bug, I do not believe that my
proposal changes anything at all about the requirements to document
licenses in d/copyright, only copyright notices.

Please take another look and let me know if my patch somehow changes the
requirements to document licenses in a way I did not intend.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-04-01 Thread Sam Hartman
I think there is another use of debian/copyright beyond just documenting
what ends up in the binaries.
I think that if I read debian/copyright in a source package, I should
expect to understand the licenses I need to comply with when dealing
with the source package.

So for example  if the package requires GPL-3 code during its build, and
by policy I don't want to deal with GPL-3 I should know I have a problem
only from reading debian/copyright.


So I think you need to talk about more than just binaries.

--Sam



Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-03-26 Thread Scott Kitterman
On Thursday, March 26, 2020 1:31:31 PM EDT Scott Kitterman wrote:
> 4.  License requires copyright notice but doesn't specify anything about
> source or binary (didn't look for an example, but I can totally see this
> happening): I think this case is unclear with your revised wording.  With
> the current policy wording copyright notices would be required in
> debian/copyright and I think that's correct.  The current wording does seem
> harsh, so it could probably be better while not leaving an ambiguity.

Here's a specific example I am looking at in New:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

Scott K

signature.asc
Description: This is a digitally signed message part.


Bug#955005: Relax requirements to copy copyright notices into d/copyright

2020-03-26 Thread Scott Kitterman



On March 26, 2020 4:57:12 PM UTC, Sean Whitton  wrote:
>Package: debian-policy
>Version: 4.5.0.0
>User: debian-pol...@packages.debian.org
>Usertags: normative discussion
>X-debbugs-cc: debian-de...@lists.debian.org, ftpmas...@debian.org
>
>Scott has provided a useful summary of what the FTP Team require when
>it
>comes to copyright information, and as another FTP Team member, I
>concur
>with his assessment of the consensus within the team:
>
>On Thu 26 Mar 2020 at 10:32AM -04, Scott Kitterman wrote:
>
>> I think you assume we're looking for more than we are.  We aren't
>asking
>> anyone to research and document undocumented but technically legally
>> assertable copyright claims.  From an FTP perspective we're after
>license
>> compliance.
>>
>> If debian/copyright includes all the copyright notices that upstream
>does (or
>> an equivalent), then that's all that's needed (there are exceptions,
>I have
>> reviewed packages where upstream literally wrote that they had copied
>a bunch
>> of code from some other location, changed the copyright owner to
>themselves,
>> and changed the license - that we had a problem with, but it wasn't
>like we
>> went looking for it).
>>
>> To pick one example, the Expat (MIT) license includes:
>>
>> The above copyright notice and this permission notice shall be
>> included in all copies or substantial portions of the Software.
>>
>> When we ask for listing copyright holders in debian/copyright, that's
>what
>> we're after.  I don't think complying with license requirements is an
>> unreasonable thing to ask.
>>
>> That said, if we can make it easier for everyone, then we should
>investigate
>> that.  As mentioned, policy does have a higher bar.  It says they all
>have to
>> be listed regardless of license requirements.
>>
>> To pick another example, Apache-2.0 includes:
>>
>>   (c) You must retain, in the Source form of any Derivative Works
>>   that You distribute, all copyright, patent, trademark, and
>>   attribution notices from the Source form of the Work,
>>   excluding those notices that do not pertain to any part of
>>   the Derivative Works; and
>>
>> For something that we distribute based on our rights in the
>Apache-2.0 license
>> and requirement to document all the copyright holders is strictly
>Debian
>> specific based on policy.  Personally, I think the policy should be
>changed so
>> we don't require everyone to go beyond the license requirements. 
>Currently I
>> think there is consensus within the FTP Team not to reject packages
>for this.
>
>Policy currently says:
>
>Every package must be accompanied by a verbatim copy of its
>copyright information, unless its distribution license explicitly
>permits this information to be excluded from distributions of
>binaries built from the source.  In such cases, a verbatim copy of
>its copyright information should normally still be included, but
>need not be if creating and maintaining a copy of that information
>involves significant time and effort.
>
>We wrote this based on [1], but I now believe it is too conservative,
>and does not reflect what the FTP Team require, nor the project's
>consensus on what should be in d/copyright.  I think we want something
>like this:
>
>The copyright information for files in a package must be copied
>verbatim into d/copyright when (i) the distribution license for
>those files requires that copyright information be included in all
>binary distributions; (ii) the files are shipped in the binary
>package, either in source or compiled form; and (iii) the form in
>   which the files are present in the binary package does not include a
>plain text version of their copyright notices.
>
>Thus, the copyright information for files in the source package
>which are only part of its build process, such as autotools files,
>need not be included in d/copyright, because those files do not get
>installed into the binary package.  Similarly, plain text files
>   which include their own copyright information and are installed into
>the binary package unmodified need not have that copyright
>information copied into d/copyright.
>
>   However, the copyright notices for any files which are complied into
>the object code shipped in the binary package must all be included
>in d/copyright when the license requires that copyright information
>be included in all binary distributions, as most do.
>
>The point of separating (ii) and (iii) is because the source form of a
>file need not be plain text, such as image files, and because even for
>plain text files the copyright information may not be included in the
>files themselves, but perhaps only in LICENSE.txt or similar.
>
>This is, I believe, the minimum required for license compliance when it
>comes to copyright notices.  It is significantly weaker than what
>Policy
>currently requires, but I think we have a project consensus