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
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
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 your
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 for
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
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
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
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 L
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 rul
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 w
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
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
/usr/share/common-l
On Thu, Aug 02, 2018 at 12:31:52PM +0200, Guillem Jover wrote:
> As has been mentioned before, you should not need to bump the version
> if you don't use the new format; if you do, you have aleady changed
> the file anyway and might as well change the version digit.
exactly.
I'm kinda surprised
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
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 liste
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
>>
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 hu
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.
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 libco
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 licensecheck/l
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 a
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
> P
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 p
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
> /usr/sh
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
> r
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 wi
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 doesn
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 t
>> 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 t
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 won'
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 c
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 s
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 #883950
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 I ssh into my machine
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 /u/s/common-licenses' type wording
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 pr
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:
>
> *
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
>
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 the end (and then th
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
r
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 ident
41 matches
Mail list logo
