all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Greg Hogan <code@greghogan.com>
Cc: "Josselin Poiret" <dev@jpoiret.xyz>,
	"Simon Tournier" <zimon.toutoune@gmail.com>,
	"Mathieu Othacehe" <othacehe@gnu.org>,
	"Ludovic Courtès" <ludo@gnu.org>,
	"Tobias Geerinckx-Rice" <me@tobias.gr>,
	"Florian Pelz" <pelzflorian@pelzflorian.de>,
	"Ricardo Wurmus" <rekado@elephly.net>,
	71697@debbugs.gnu.org, "Christopher Baines" <guix@cbaines.net>,
	"Matthew Trzcinski" <matt@excalamus.com>
Subject: [bug#71697] [PATCH v3 2/2] scripts: lint: Honor package property to exclude checkers.
Date: Fri, 28 Jun 2024 23:12:39 -0400	[thread overview]
Message-ID: <87zfr48ms8.fsf@gmail.com> (raw)
In-Reply-To: <CA+3U0ZntOt+-gKcJ7Q_EJszY7TAgpcF6q+O_8uZAAO+3dHEuog@mail.gmail.com> (Greg Hogan's message of "Thu, 27 Jun 2024 12:38:26 -0400")

Hi Greg,

Greg Hogan <code@greghogan.com> writes:

> On Wed, Jun 26, 2024 at 3:28 PM Maxim Cournoyer
> <maxim.cournoyer@gmail.com> wrote:
>>
>> I don't think these exclusions should be committed in general to the
>> repo, except when we have for example the author of some software
>> explicitly requesting that SWH archival be disabled for it in Guix.
>
> Author requests are as problematic to a free software distribution as
> the earlier demands to modify historical data are to reproducibility.
>
> How do we authenticate authorship? Is it a single author, all authors,
> majority of authorship? How would the latter be measured and valued?
> Are author requests transitive? In which direction? Do the requests
> propagate to dependent packages, or must a request include author
> approval from all project dependencies? How do we handle cases where
> copyright has not been noted as carefully as in Guix? Must the request
> be made specifically to the Guix project? How do we monitor projects
> for new authors or changes to requests?
>
> We have a system for honoring author requests that resolves every
> single one of these issues: software licenses. And this is not some
> new issue, developers have been debating commercial use ("Micro$oft")
> of their work for decades, yet here we are writing free software and
> building a free Gnu/OS.

You raise good questions, for which I do not have immediate answers.

> These requests to turn free software non-free are simply the tip of
> the iceberg. We have always considered the artist (author) to be
> separate from the art (licensed software). Now we get (from the
> initiator of these demands) that "Not every political opinion should
> be respected." which is a clear contradiction of the Guix Code of
> Conduct's "Being respectful of differing opinions, viewpoints, and
> experiences". Which individuals or demographic subgroups will be next
> claimed problematic and need to have their contributions excluded?
>
>> It may also be useful e.g. for some project that really don't have a
>> home page, to avoid a spurious lint warning in this case.
>
> If this is the best use case for a spurious feature request then I
> find this a dangerous addition to the project. Those denigrading and
> demanding that Guix pressure partner projects to restrict the use of
> free software are unlikely to be content adding these flags to their
> private packages as may exist.

While I dislike the attitude/approach used, I think the essence of the
complaint was that Guix, via SHW, was somehow facilitating the
scavenging of free software sources to train large language models
(LLM), with the opinion that these models do not respect the licenses of
the sources ingested for their produced output (the work is considered
new work, not a derived work, or perhaps it's still legally a gray area,
I don't know).  In this perspective, the original poster was seeking to
have the free software more protected against what they see as a loop
hole in the LLM business, as explained above.

That's an interesting legal and moral challenge/problem, but I don't
think GNU Guix is the right venue to debate it; especially not in the
way it's been attempted here.

-- 
Thanks,
Maxim




  reply	other threads:[~2024-06-29  3:30 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-21 17:22 [bug#71697] [PATCH] guix: lint: Honor 'no-archival?' package property Simon Tournier
2024-06-21 18:33 ` [bug#71697] [PATCH v2] guix: scripts: lint: Honor package property to exclude chercker Simon Tournier
2024-06-21 21:09   ` Liliana Marie Prikler
2024-06-22 14:29   ` MSavoritias
2024-06-22 15:40     ` Simon Tournier
2024-06-24  8:21       ` MSavoritias
2024-06-22 15:27 ` [bug#71697] [PATCH v3 1/2] scripts: lint: Add 'dry-run' option Simon Tournier
2024-06-22 15:27   ` [bug#71697] [PATCH v3 2/2] scripts: lint: Honor package property to exclude checkers Simon Tournier
2024-06-23 23:51     ` Maxim Cournoyer
2024-06-25 15:14     ` Ludovic Courtès
2024-06-25 17:14       ` Greg Hogan via Guix-patches
2024-06-26  8:24         ` Ricardo Wurmus
2024-06-26 19:28         ` Maxim Cournoyer
2024-06-27 16:38           ` Greg Hogan
2024-06-29  3:12             ` Maxim Cournoyer [this message]
2024-06-30 14:48               ` Dale Mellor
2024-07-01 20:44                 ` Maxim Cournoyer
     [not found]                   ` <72a5f3c9d0523b29ed99afd5a551b411f4c0e7f5.camel@rdmp.org>
2024-07-02  1:39                     ` Maxim Cournoyer
2024-07-12 13:36                 ` Simon Tournier
2024-07-05  7:40             ` Ludovic Courtès
2024-07-12 14:16             ` Simon Tournier
2024-07-25 15:19               ` Greg Hogan
2024-07-12 17:20           ` Simon Tournier
2024-06-23 23:54   ` [bug#71697] [PATCH v3 1/2] scripts: lint: Add 'dry-run' option Maxim Cournoyer
2024-07-12 17:22 ` [bug#71697] [PATCH v4 " Simon Tournier
2024-07-12 17:22   ` [bug#71697] [PATCH v4 2/2] scripts: lint: Honor package property to exclude checkers Simon Tournier
2024-07-18  9:19   ` [bug#71697] [PATCH v4 1/2] scripts: lint: Add 'dry-run' option Ludovic Courtès
2024-07-18 11:00     ` Simon Tournier
2024-07-19 18:27 ` [bug#71697] [PATCH v5 0/3] Add dry-run to guix lint Simon Tournier
2024-07-19 18:38   ` [bug#71697] [PATCH v5 1/3] scripts: lint: Add 'dry-run' option Simon Tournier
2024-07-26  2:06     ` Maxim Cournoyer
2024-07-19 18:38   ` [bug#71697] [PATCH v5 2/3] scripts: lint: Honor package property to exclude checkers Simon Tournier
2024-07-19 18:38   ` [bug#71697] [PATCH v5 3/3] scripts: lint: Add hint for checker typo Simon Tournier
2024-07-26  2:26     ` Maxim Cournoyer

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=87zfr48ms8.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=71697@debbugs.gnu.org \
    --cc=code@greghogan.com \
    --cc=dev@jpoiret.xyz \
    --cc=guix@cbaines.net \
    --cc=ludo@gnu.org \
    --cc=matt@excalamus.com \
    --cc=me@tobias.gr \
    --cc=othacehe@gnu.org \
    --cc=pelzflorian@pelzflorian.de \
    --cc=rekado@elephly.net \
    --cc=zimon.toutoune@gmail.com \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.