Re: copyright precision

Andrey Rahmatullin writes: > On Tue, Aug 16, 2016 at 02:30:58PM +0200, Ole Streicher wrote: >> I always use this as one argument when it comes to "Why should be care >> about Debian? Our users use something else", that packaging includes a >> careful review and documentation of

Re: copyright precision

Quoting Andreas Tille (2016-08-17 10:55:01) > On Tue, Aug 16, 2016 at 10:13:30PM +0500, Andrey Rahmatullin wrote: > > On Tue, Aug 16, 2016 at 02:30:58PM +0200, Ole Streicher wrote: > > > I always use this as one argument when it comes to "Why should be care > > > about Debian? Our users use

Re: copyright precision

On Tue, Aug 16, 2016 at 10:13:30PM +0500, Andrey Rahmatullin wrote: > On Tue, Aug 16, 2016 at 02:30:58PM +0200, Ole Streicher wrote: > > I always use this as one argument when it comes to "Why should be care > > about Debian? Our users use something else", that packaging includes a > > careful

Re: copyright precision

Quoting Andrew Shadura (2016-08-16 19:57:05) > > > On 16 August 2016 at 14:32, Ian Jackson > <ijack...@chiark.greenend.org.uk> wrote: > > Jonas Smedegaard writes ("Re: copyright precision"): > >> Quoting Markus Koschany (2016-08-15 23:02:06) > &

Re: copyright precision

On Tue, Aug 16, 2016 at 02:30:58PM +0200, Ole Streicher wrote: > I always use this as one argument when it comes to "Why should be care > about Debian? Our users use something else", that packaging includes a > careful review and documentation of the copyright. Usually only for the initial upload,

Re: copyright precision

On Tue, Aug 16, 2016 at 03:25:24PM +0100, Ian Jackson wrote: > Normally what a potential user needs to know is the effective licence > of the whole thing. Note that we don't even try to declare the license of *binaries we are shipping* and, unless I'm mistaken, the license of a library you are

Re: copyright precision

Quoting Ian Jackson (2016-08-16 15:32:55) > Jonas Smedegaard writes ("Re: copyright precision"): >> Quoting Markus Koschany (2016-08-15 23:02:06) >>> So yes, copyright files are hard and unfun but why should we >>> continue to write them the way we do if w

Re: copyright precision

On 16/08/16 16:21, Jonas Smedegaard wrote: Quoting Ian Jackson (2016-08-16 15:32:19) Ghostscript packaged for Debian has a debian/copyright file with ~400 lines enumerating which source files are covered by which license (and then another ~800 lines covering the actual licenses verbatim).

Re: copyright precision

Jonas Smedegaard writes ("Re: copyright precision"): > Quoting Ian Jackson (2016-08-16 15:32:19) > > In the end up looked at the package's upstream web pages, which > > contained a clear answer to the question. > > How was the approach¹ not successful?

Re: copyright precision

Quoting Ian Jackson (2016-08-16 15:32:19) > Andreas Tille writes ("Re: copyright precision"): >> On Tue, Aug 16, 2016 at 10:59:09AM +0500, Andrey Rahmatullin wrote: >>> It's at least worth a discussion whether nitpicking at d/copyright >>> is really helping th

Re: copyright precision

Jonas Smedegaard writes ("Re: copyright precision"): > Quoting Markus Koschany (2016-08-15 23:02:06) > > So yes, copyright files are hard and unfun but why should we continue > > to write them the way we do if we are not legally bound to do so? > > Same reason

Re: copyright precision

Andreas Tille writes ("Re: copyright precision"): > On Tue, Aug 16, 2016 at 10:59:09AM +0500, Andrey Rahmatullin wrote: > > It's at least worth a discussion whether nitpicking at d/copyright is > > really helping the package quality at all, and if it's worth it. &

Re: copyright precision

Andrey Rahmatullin writes: > It's at least worth a discussion whether nitpicking at d/copyright is > really helping the package quality at all, and if it's worth it. I see here another reason -- and an argument actually *for* Debian packaging (being different from, f.e. MacPorts

Re: copyright precision

Scott Kitterman writes: > Personally, I think the bulk of the reason we should care about > debian/copyright is to achieve license compliance. For this, IMO the licensing information is not just enough, since it does not document how our binaries are licensed. For

Re: copyright precision

On Tue, Aug 16, 2016 at 11:30:34AM +0200, Andreas Tille wrote: > > > Not because we are legally bound to do so, but because we want to do our > > > job as distributors properly. We appreciate good quality packaging! > > It's at least worth a discussion whether nitpicking at d/copyright is > >

Re: copyright precision

Quoting Andrey Rahmatullin (2016-08-16 07:59:09) > On Tue, Aug 16, 2016 at 01:10:42AM +0200, Jonas Smedegaard wrote: >>> So yes, copyright files are hard and unfun but why should we >>> continue to write them the way we do if we are not legally bound to >>> do so? >> >> Same reason that we

Re: copyright precision

On Tue, Aug 16, 2016 at 10:59:09AM +0500, Andrey Rahmatullin wrote: > > Not because we are legally bound to do so, but because we want to do our > > job as distributors properly. We appreciate good quality packaging! > It's at least worth a discussion whether nitpicking at d/copyright is >

Re: copyright precision

On Tue, Aug 16, 2016 at 01:10:42AM +0200, Jonas Smedegaard wrote: > > So yes, copyright files are hard and unfun but why should we continue > > to write them the way we do if we are not legally bound to do so? > > Same reason that we should continue to care about ability to install > multiple

Re: copyright precision

Quoting Markus Koschany (2016-08-15 23:02:06) > So yes, copyright files are hard and unfun but why should we continue > to write them the way we do if we are not legally bound to do so? Same reason that we should continue to care about ability to install multiple major versions of a library

Re: copyright precision

On 15.08.2016 21:50, Scott Kitterman wrote: > On Monday, August 15, 2016 05:59:43 PM Simon McVittie wrote: >> On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote: >>> The problem we're having here is clearly about *tooling*. If we had a >>> good toolchain to compile and audit

Re: copyright precision

On Monday, August 15, 2016 05:59:43 PM Simon McVittie wrote: > On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote: > > The problem we're having here is clearly about *tooling*. If we had a > > good toolchain to compile and audit machine-readable debian/copyright > > files without

Re: copyright precision

On Mon, Aug 15, 2016 at 05:59:43PM +0100, Simon McVittie wrote: > * If we had a good toolchain to compile and audit this stuff, people > and companies who want to know the copyright holders could just use > that to inspect the upstream source code and cut out the middle-man. I've comment on

Re: copyright precision

On Mon, Aug 15, 2016 at 10:53:53AM -0700, Nikolaus Rath wrote: > > * If we had a good toolchain to compile and audit this stuff, people > > and companies who want to know the copyright holders could just use > > that to inspect the upstream source code and cut out the middle-man. > > I think

Re: copyright precision

On Aug 15 2016, Simon McVittie wrote: > On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote: >> The problem we're having here is clearly about *tooling*. If we had a >> good toolchain to compile and audit machine-readable debian/copyright >> files without sweating,

Re: copyright precision

On Mon, 15 Aug 2016 at 18:17:52 +0200, Stefano Zacchiroli wrote: > The problem we're having here is clearly about *tooling*. If we had a > good toolchain to compile and audit machine-readable debian/copyright > files without sweating, nobody would complain. I have three slightly devil's-advocate

Re: copyright precision

On Fri, Aug 12, 2016 at 02:19:43AM +0200, gregor herrmann wrote: > AFAIK there are plans around sources.d.n to use the d/copyright files > in Copyright-Format 1.0. Currently they are browsable at > https://sources.debian.net/copyright/ but IIRC some more analysis is > planned. We do have

Re: copyright precision

Hi Joachim and Simon, On Thu, Aug 11, 2016 at 01:25:14PM -0400, Joachim Breitner wrote: > > I question the value of precise debian/copyright files, or at least > question the effort-to-value ratio. The legal situation is generally > not affected by whether we have course or fine copyright files,

Re: copyright precision

Simon McVittie writes ("Re: copyright precision"): > On Wed, 10 Aug 2016 at 22:51:47 +0100, Ian Jackson wrote: > > I certainly don't feel I personally want to put doing this > > work anywher enear the top of my personal Debian todo list list > > I think what you've

Re: copyright precision

On Fri, Aug 12, 2016 at 5:42 AM, Dmitry Bogatov wrote: > [2016-08-11 21:09] Moritz Mühlenhoff >> >> Simon McVittie schrieb: >> > In particular, if this thread comes to the conclusion that more needs to >> > be done than what maintainers currently do, then it should be something

Re: copyright precision

On Thu, 11 Aug 2016 13:25:14 -0400, Joachim Breitner wrote: > And to > the best of my knowledge, our copyright files are not used in any > systematic way. (If they were, this would add value and add motivation > to work on this, and with machine-readable copyright files, it might > happen some

Re: copyright precision

[2016-08-11 21:09] Moritz Mühlenhoff > > Simon McVittie schrieb: > > In particular, if this thread comes to the conclusion that more needs to > > be done than what maintainers currently do, then it should be something > > actionable; > > Or we could rather

Re: copyright precision

Simon McVittie schrieb: > In particular, if this thread comes to the conclusion that more needs to > be done than what maintainers currently do, then it should be something > actionable; Or we could rather automate the generation of debian/copyright entirely by letting fossology

Re: copyright precision

On Wed, 10 Aug 2016 at 22:51:47 +0100, Ian Jackson wrote: > Simon McVittie writes ("Re: copyright precision"): > > Self-imposed policy of documenting copyright information: > > Personally, I think it would be much better if binary packages had > accurate c

Re: copyright precision

there is something pleasing about a very written, detailed, elaborate, up-to-date, machine-readable debian/copyright file. Similar to how there is something pleasing about a extensive and well-sorted stamp collection. But if we discuss the kind of copyright precision we want, let us not only

Re: copyright precision

On Wed, Aug 10, 2016 at 5:21 AM, Paul Wise wrote: > On Wed, Aug 10, 2016 at 6:34 AM, Helmut Grohne wrote: > >> Other packages that don't build from source by default include bash, >> dash, debianutils, dpkg, e2fsprogs, findutils, fribidi, gmp, jemalloc, >> libatomic-ops, libbsd,

Re: copyright precision

Simon McVittie writes ("Re: copyright precision"): > I'm sure this is a very interesting academic exercise, but pragmatically, > why do we want to require ourselves to go to all that effort? For that > matter, is everything we require *now* necessary or desirable? Thanks

Re: copyright precision

On Wed, 10 Aug 2016 at 11:12:55 +0800, Paul Wise wrote: > The only possible way to solve this in general terms is, accurate > document the copyright/license of the source package using the > machine-readable format and during builds, track the transformation of > input files in the source package

Perl Configure mess (mostly) (Re: copyright precision)

Helmut Grohne writes ("Re: copyright precision"): > On Tue, Aug 09, 2016 at 06:37:37PM +0100, Ian Jackson wrote: > > Perl's Configure is not a very useful example and has IMO some > > justification. I think it's poor engineering to have edited the > > output f

Re: copyright precision

Helmut Grohne writes ("Re: copyright precision"): > On Tue, Aug 09, 2016 at 07:45:16PM +0200, Thorsten Alteholz wrote: > > So if there is a problem, shouldn't we start to solve it instead of just > > ignoring it? Wouldn't it be better to set high standards in

Re: copyright precision

Hi, Quoting Paul Wise (2016-08-10 05:12:55) > The only possible way to solve this in general terms is, accurate document > the copyright/license of the source package using the machine-readable format > and during builds, track the transformation of input files in the source > package to output

Re: copyright precision

On Wed, Aug 10, 2016 at 6:34 AM, Helmut Grohne wrote: > Other packages that don't build from source by default include bash, > dash, debianutils, dpkg, e2fsprogs, findutils, fribidi, gmp, jemalloc, > libatomic-ops, libbsd, libtasn1-6, lzo2, ncurses, nettle, patch, > readline6, and sed. I would

Re: copyright precision

On Wed, Aug 10, 2016 at 1:14 AM, Helmut Grohne wrote: > But it is actually worse than that. We don't even list copyright for > what is contained in binary packages. It isn't hard to do for packages that don't copy anything from other binary packages, I did this for libicns:

Re: copyright precision

On Tue, Aug 09, 2016 at 06:37:37PM +0100, Ian Jackson wrote: > > But it is actually worse than that. We don't even list copyright for > > what is contained in binary packages. For instance, libjs-sphinxdoc >^^ > Did you mean to write "source" ? Yes, thanks. > > It

Re: copyright precision

On Tue, Aug 09, 2016 at 07:45:16PM +0200, Thorsten Alteholz wrote: > So if there is a problem, shouldn't we start to solve it instead of just > ignoring it? Wouldn't it be better to set high standards instead of being > guided by convenience? Documenting problems only makes sense when there is a

Re: copyright precision

On Tue, 9 Aug 2016, Helmut Grohne wrote: Dropping most of the Cc list as we move to general handling of similar issues. On Tue, Aug 09, 2016 at 01:30:39PM +0100, Ian Jackson wrote: ISTM that in situations where Built-Using is arguably relevant, there is also often a requirement to make sure

Re: copyright precision

Helmut Grohne writes ("copyright precision"): > Dropping most of the Cc list as we move to general handling of similar > issues. > > On Tue, Aug 09, 2016 at 01:30:39PM +0100, Ian Jackson wrote: > > ISTM that in situations where Built-Using is arguably relev

copyright precision

Dropping most of the Cc list as we move to general handling of similar issues. On Tue, Aug 09, 2016 at 01:30:39PM +0100, Ian Jackson wrote: > ISTM that in situations where Built-Using is arguably relevant, there > is also often a requirement to make sure the copyright file(s) of the > .deb(s)