Bug#883950: Next steps on "[GPL-3+]" proposal

On Wed, Aug 15, 2018 at 6:47 AM, Paul Hardy wrote: > it can be said that the package has made a good faith effort to I meant the "packager", not the "package", anthropomorphism aside! Thanks, Paul Hardy

Bug#883950: Next steps on "[GPL-3+]" proposal

On Tue, Aug 14, 2018 at 10:26 AM, Ian Jackson wrote: > Paul Hardy writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"): >> License: GPL-2 >> file:///usr/share/common-licenses/GPL-2 > > I'm late to this party, but one of the things that is w

Bug#883950: Next steps on "[GPL-3+]" proposal

Jonathan Nieder writes ("Re: Next steps on "[GPL-3+]" proposal"): > Ian Jackson wrote: > > Changing the version would involve parser changes in all parsers. > > I don't follow. Why wouldn't a non-validating parser be able to simply > ignore the Format field? I don't understand the intent of

Bug#883950: Next steps on "[GPL-3+]" proposal

Ian Jackson writes: > I am against the version number change. Version numbers, and particular > version number bumps, in protocols like this are a very heavy hammer. > Where present, they should be bumped only when necessary. They are > necessary only when a tool which is written to the old

Bug#883950: Next steps on "[GPL-3+]" proposal

Hi, Ian Jackson wrote: > Russ Allbery writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"): >> Currently, copyright-format >> 1.0 requires either that every License stanza in a Files paragraph contain >> so

Bug#883950: Next steps on "[GPL-3+]" proposal

Paul Hardy writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"): > License: GPL-2 > file:///usr/share/common-licenses/GPL-2 I'm late to this party, but one of the things that is wrong[1] with SPDX is that it implicitly encourages what I would call GPL-v

Bug#883950: Next steps on "[GPL-3+]" proposal

Russ Allbery writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"): > To be clear, I don't believe there's a way forward here that doesn't > require at least some rewriting of parsers. Currently, copyright-format > 1.0 requires either that every License stanza

Bug#883950: Next steps on "[GPL-3+]" proposal

Russ Allbery writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"): > Markus Koschany writes: > > I have a hard time to imagine what kind of breakage might occur with > > those non-Lintian parsers. > > It's pretty straightforward: currently, a Licens

Bug#883950: Next steps on "[GPL-3+]" proposal

On Sun, 12 Aug 2018 at 13:52:57 +0200, Wouter Verhelst wrote: > The obvious objection to that would be the fact that the SPDX > identifiers are not set in stone; a future update of the SPDX > identifiers might then conflict with one of the identifiers that we add. > Either we'd need [...], or a

Bug#883950: Next steps on "[GPL-3+]" proposal

Wouter Verhelst writes: > On Sat, Jul 28, 2018 at 01:51:12PM -0700, Russ Allbery wrote: >> One remaining question in my mind is whether we should take the >> opportunity of a format change to achieve a few other goals. The most >> obvious one would be to reconcile our short license identifiers

Bug#883950: Next steps on "[GPL-3+]" proposal

On Sat, Jul 28, 2018 at 01:51:12PM -0700, Russ Allbery wrote: > One remaining question in my mind is whether we should take the > opportunity of a format change to achieve a few other goals. The most > obvious one would be to reconcile our short license identifiers with SPDX > (probably by making

Bug#883950: Next steps on "[GPL-3+]" proposal

Just a couple of random thoughts... There are two recurring themes (among others) in this bug report: * How to make sure users know what "+" means, as in "GPL-2+" * How to make sure users know where to find a full license Suppose a tiny README file (uncompressed) is added to

Bug#883950: Next steps on "[GPL-3+]" proposal

Markus Koschany writes: > I have a hard time to imagine what kind of breakage might occur with > those non-Lintian parsers. It's pretty straightforward: currently, a License field must either contain an extended paragraph or references one elsewhere in the document. Therefore, whenever a parser

Bug#883950: Next steps on "[GPL-3+]" proposal

Hi, Markus Koschany wrote: > I personally dislike the trend in Debian to create more and more > complexity in our source packages. I find the Standards-Version field > unnecessary, VCS fields should not be part of a debian/control file, all > DFSG licenses approved by our ftp-team should be

Bug#883950: Next steps on "[GPL-3+]" proposal

Am 03.08.2018 um 00:59 schrieb Russ Allbery: > Markus Koschany writes: > >> You appear more concerned about one parser, Lintian, than about the >> human maintainers who have to update d/copyright again. You argue that >> the maintainers have to update d/copyright anyway, I say fixing the tool

Bug#883950: Next steps on "[GPL-3+]" proposal

Markus Koschany writes: > You appear more concerned about one parser, Lintian, than about the > human maintainers who have to update d/copyright again. You argue that > the maintainers have to update d/copyright anyway, I say fixing the tool > is far more efficient because it affects far less

Bug#883950: Next steps on "[GPL-3+]" proposal

On Thu, 2018-08-02 at 16:45:52 +0800, Markus Koschany wrote: > Am 02.08.2018 um 16:27 schrieb gregor herrmann: > > On Thu, 02 Aug 2018 15:13:26 +0800, Markus Koschany wrote: > >> Nothing will break because no tool besides Lintian checks > >> debian/copyright for copyright format 1.0 compatibility.

Bug#883950: Next steps on "[GPL-3+]" proposal

Am 02.08.2018 um 16:27 schrieb gregor herrmann: > On Thu, 02 Aug 2018 15:13:26 +0800, Markus Koschany wrote: > >> Nothing will break because no tool besides Lintian checks >> debian/copyright for copyright format 1.0 compatibility. > > This is not correct. > > There are at least cme (with

Bug#883950: Next steps on "[GPL-3+]" proposal

On Thu, 02 Aug 2018 15:13:26 +0800, Markus Koschany wrote: > Nothing will break because no tool besides Lintian checks > debian/copyright for copyright format 1.0 compatibility. This is not correct. There are at least cme (with libconfig-model-dpkg-perl), decopy, probably some of

Bug#883950: Next steps on "[GPL-3+]" proposal

Am 02.08.2018 um 12:43 schrieb Russ Allbery: > Markus Koschany writes: > >> Please keep it simple. I disagree that we would need a version bump of >> copyright format 1.0 which had to be documented in every >> debian/copyright file again by changing the Format field. A simple >> amendment would

Bug#883950: Next steps on "[GPL-3+]" proposal

Markus Koschany writes: > Please keep it simple. I disagree that we would need a version bump of > copyright format 1.0 which had to be documented in every > debian/copyright file again by changing the Format field. A simple > amendment would also do the trick which could be referenced by the >

Bug#883950: Next steps on "[GPL-3+]" proposal

First of all let me thank Sean for moving this issue forward. Let me also reiterate what the whole point of this bug report is again. The bug reporter, myself and others would like to reduce the unnecessary amount of boilerplate in debian/copyright. The brackets are not the important part of our

Bug#883950: Next steps on "[GPL-3+]" proposal

Stuart Prescott writes: > This is certainly true for validating parsers, which will need > modification to stop them complaining about the missing standalone > License stanza; that's a relatively simple modification to not complain > if the licence key is within the predefined list from >

Bug#883950: Next steps on "[GPL-3+]" proposal

Hi Russ, > > From my perspective, the brackets are only making work for people who > > will have to rewrite parsers because the license short names are not the > > opaque tokens originally given in copyright-format/1.0.* > > To be clear, I don't believe there's a way forward here that doesn't >

Bug#883950: Next steps on "[GPL-3+]" proposal

Hello, On Sat 28 Jul 2018 at 04:15PM +0100, Simon McVittie wrote: > On Sun, 29 Jul 2018 at 00:50:34 +1000, Stuart Prescott wrote: >> Let us consider this proposed syntax in terms of what someone unfamiliar >> with the format is going to see > > Along these lines, it might be helpful for people

Bug#883950: Next steps on "[GPL-3+]" proposal

Stuart Prescott writes: > From my perspective, the brackets are only making work for people who > will have to rewrite parsers because the license short names are not the > opaque tokens originally given in copyright-format/1.0.* To be clear, I don't believe there's a way forward here that

Bug#883950: Next steps on "[GPL-3+]" proposal

On Sun, 29 Jul 2018 at 00:50:34 +1000, Stuart Prescott wrote: > Let us consider this proposed syntax in terms of what someone unfamiliar > with the format is going to see Along these lines, it might be helpful for people with an interest in pushing this forward to convert some d/copyright files

Bug#883950: Next steps on "[GPL-3+]" proposal

>> We now know that we can go ahead with the main proposal to introduce the >> "[GPL-3+]" notation into our machine-readable copyright format. [...] > I can't contribute much to > the further discussion because I believe the quintessential points were > already discussed and approved and the only

Bug#883950: Next steps on "[GPL-3+]" proposal

Hello, On Thu 26 Jul 2018 at 08:47PM -0700, Russ Allbery wrote: > My preference there would be to add a README file to > /usr/share/common-licenses that explains this syntax. This is simple and > I think uncontroversial, but there's some concern that it will be too hard > to find and people

Bug#883950: Next steps on "[GPL-3+]" proposal

On Thu, Jul 26, 2018 at 08:47:08PM -0700, Russ Allbery wrote: > A set of files under the license GPL-3+ and [GPL-3+] are under exactly the > same license, so it is confusing and strange to use different identifiers > based on a technical point about what information is included elsewhere in > the

Bug#883950: Next steps on "[GPL-3+]" proposal

Sean Whitton writes: > We now know that we can go ahead with the main proposal to introduce the > "[GPL-3+]" notation into our machine-readable copyright format. I'm going to reiterate my objection to the brackets. I'm opposed to introducing this new syntax; I believe it serves no purpose. A

Bug#883950: Next steps on "[GPL-3+]" proposal

Hello, Am 29.12.2017 um 10:18 schrieb Sean Whitton: > user debian-pol...@packages.debian.org > usertags 883950 = normative discussion > thanks > > Hello, > > On Thu, Dec 28 2017, Markus Koschany wrote: > >> the Policy editors request your attention and a decision regarding >> Debian bug

Bug#883950: Next steps on "[GPL-3+]" proposal

On Sat, Dec 30, 2017 at 01:26:29PM -0800, Russ Allbery wrote: > Julian Gilbey writes: > > > Just a straw poll: who sees /etc/motd these days? My system (probably > > in common with many many users) boots into a graphical environment; I > > only see the motd in the case that

Bug#883950: Next steps on "[GPL-3+]" proposal

Julian Gilbey writes: > Just a straw poll: who sees /etc/motd these days? My system (probably > in common with many many users) boots into a graphical environment; I > only see the motd in the case that I ssh into my machine. So I'm > against removing the 'see

Bug#883950: Next steps on "[GPL-3+]" proposal

On Fri, Dec 29, 2017 at 07:29:48PM -0800, Russ Allbery wrote: > I agree that we should probably add /usr/share/common-licenses to the > default motd. Currently, we say: > > The programs included with the Debian GNU/Linux system are free > software; the exact distribution terms for each

Bug#883950: Next steps on "[GPL-3+]" proposal

Hello Stuart, On Sat, Dec 30 2017, Stuart Prescott wrote: > I find the proposal that we should use "[GPL-3+]" (#883950) and the > proposal that a "License-Grant" field be added (#786470) to be largely > contradictory. I think accepting (or even pursuing) one should mean > killing the other: > >

Bug#883950: Next steps on "[GPL-3+]" proposal

Hello, On Fri, Dec 29 2017, Russ Allbery wrote: > I agree that we should probably add /usr/share/common-licenses to the > default motd. Currently, we say: > > The programs included with the Debian GNU/Linux system are free > software; the exact distribution terms for each program are >

Bug#883950: Next steps on "[GPL-3+]" proposal

Stuart Prescott writes: > TL;DR: I'd prefer we didn't use the brackets or bump version numbers, > hence challenging this now before it becomes too entrenched. > * In copyright-format/1.0, the tokens specifying the licences are > entirely opaque with the exception of the + at

Bug#883950: Next steps on "[GPL-3+]" proposal

Hi Sean, On Friday, 29 December 2017 09:18:51 AEDT Sean Whitton wrote: [...] > We now know that we can go ahead with the main proposal to introduce the > "[GPL-3+]" notation into our machine-readable copyright format. My personal preference is for debian/copyright to record the facts Debian is

Bug#883950: Next steps on "[GPL-3+]" proposal

user debian-pol...@packages.debian.org usertags 883950 = normative discussion thanks Hello, On Thu, Dec 28 2017, Markus Koschany wrote: > the Policy editors request your attention and a decision regarding > Debian bug #883950: debian-policy: allow specifying common licenses > with only the