Github messages for voidlinux
 help / color / mirror / Atom feed
From: ahesford <ahesford@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [RFC] vlicense hook
Date: Thu, 30 Apr 2020 13:37:02 +0200	[thread overview]
Message-ID: <20200430113702.BPZVxo6otawvp-x_IkFXNLEq2Sa_xLbTplTPMoWkppA@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-21272@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/21272#issuecomment-621778708

Comment:
> > Is license change a common enough problem that
> > it's worth adding a checksum? The point of `license_files` is
> > to simplify license installation, not increase the burden.
> 
> The point is: license should be changed _very_ rarely.
> If there's a change in LICENSE, we need to know and update the license field.
> Hence, I think adding a checksum makes more sense to me.

The rarity of relicensing militates against adding a checksum. Adding more burden on the packagers just to catch some corner cases doesn't seem to be worthwhile.

Furthermore, this would only be an issue if a project changed the license from something that shouldn't be installed (e.g., Apache-2.0 or one of the GPL versions) to something that should be installed. Most of those cases would be moving away from GPL (6933 templates in `void-packages` reference GPL; only 702 reference Apache; only 105 reference GFDL), but I suspect (based purely on anecdotes) that almost no projects that adopt the GPL tend to move away from it---license churn seems to happen more among other licenses.

If a package already requires `vlicense` and changes to another license, the package metadata may be wrong, but the package will still install the correct license on disk.

This seems like a practical non-issue to me.

  parent reply	other threads:[~2020-04-30 11:37 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-23 15:46 [PR PATCH] " sgn
2020-04-23 15:48 ` sgn
2020-04-23 16:17 ` pullmoll
2020-04-24  0:10 ` sgn
2020-04-24  1:34 ` ahesford
2020-04-24  1:38 ` ahesford
2020-04-24  3:05 ` Vaelatern
2020-04-24  9:53 ` leahneukirchen
2020-04-24 10:40 ` xtraeme
2020-04-24 10:47 ` leahneukirchen
2020-04-24 14:06 ` Vaelatern
2020-04-24 14:10 ` xtraeme
2020-04-24 14:18 ` Vaelatern
2020-04-24 14:21 ` ahesford
2020-04-24 16:40 ` Chocimier
2020-04-24 16:48 ` leahneukirchen
2020-04-24 17:59 ` sgn
2020-04-24 18:02 ` sgn
2020-04-24 18:02 ` ahesford
2020-04-24 18:06 ` ahesford
2020-04-24 18:17 ` Vaelatern
2020-04-24 18:23 ` ahesford
2020-04-24 19:02 ` Chocimier
2020-04-25  0:31 ` Chocimier
2020-04-26  1:17 ` sgn
2020-04-30  1:06 ` sgn
2020-04-30  3:38 ` ahesford
2020-04-30  4:59 ` Anachron
2020-04-30  8:08 ` sgn
2020-04-30  8:09 ` sgn
2020-04-30 11:21 ` travankor
2020-04-30 11:25 ` travankor
2020-04-30 11:37 ` ahesford [this message]
2020-04-30 11:44 ` ahesford
2020-04-30 11:44 ` ahesford
2020-04-30 11:46 ` travankor
2020-04-30 14:45 ` Vaelatern
2020-04-30 17:59 ` Chocimier
2020-04-30 18:02 ` Chocimier
2020-04-30 18:29 ` Chocimier
2020-04-30 18:37 ` Chocimier
2020-09-19  3:42 ` [PR PATCH] [Closed]: " sgn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200430113702.BPZVxo6otawvp-x_IkFXNLEq2Sa_xLbTplTPMoWkppA@z \
    --to=ahesford@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).