Git development
 help / color / mirror / Atom feed
From: "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>
To: "Scott Chacon" <schacon@gmail.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	"Scott Chacon" <scott@gitbutler.net>,
	git@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] SubmittingPatches: allow responsible AI assistance
Date: Thu, 08 Oct 2026 07:53:09 +0200	[thread overview]
Message-ID: <a54e82eb-1252-4d6b-8b4c-6e99da59252d@app.fastmail.com> (raw)
In-Reply-To: <CAP2yMa+kgphMe-cpcZSvPSqwm-npUDVp=HaNRW+MPmPzZ_aOXw@mail.gmail.com>

On Thu, Oct 8, 2026, at 06:49, Scott Chacon wrote:
> On Wed, Oct 7, 2026 at 11:42 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
>>[snip]
>
> I agree that generated output can reproduce material we don't have
> permission to distribute (though I think this is incredibly rare for
> anything complex). What I question is whether that possibility means
> knowing every source in the training set is necessary to make any DCO
> certification.
>
> Human contributors have also read code under many different licenses
> (and news articles and blogs) . We don't ask them to account for
> everything they've ever read before signing off on a patch.

Metaphors gone amok. You don’t regulate how submarines and human bodies
can operate in territorial waters based on the fact that they both swim.[1]

Corporations already have non-compete clauses in order to keep knowledge
workers from applying their braincraft to competing businesses.

>[snip]
>
>> I'm a distributor of Git and I don't want to be sued or arrested because
>> I end up distributing code that I don't have the right to distribute.
>>[snip]
>
>[snip]
>
>>[snip]
>
> I'm not saying that other projects haven't taken positions as
> conservative as Git's current policy. I'm saying that much larger
> projects with much larger legal surface area such as Linux have
> adopted more progressive ones. Linus is fine with it on a project with
> the same DCO, the same license, and honestly, a lot more legal
> scrutiny.

Honestly, if an individual wants to avoid the risk of getting sued over
copyright then that’s their prerogative.

>[snip]

[1] I’m not a lawyer so maybe one does.

  parent reply	other threads:[~2026-10-08  5:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-07 14:29 [RFC PATCH 0/1] SubmittingPatches: allow responsible AI assistance Scott Chacon
2026-10-07 14:29 ` [RFC PATCH 1/1] " Scott Chacon
2026-10-07 21:42   ` brian m. carlson
2026-10-08  4:49     ` Scott Chacon
2026-10-08  5:29       ` Luca Milanesio
2026-10-08  5:53       ` Kristoffer Haugsbakk [this message]
2026-10-08 16:15       ` brian m. carlson
2026-10-07 22:44   ` Junio C Hamano
2026-10-08 13:53     ` Scott Chacon
2026-10-09 10:22       ` Patrick Steinhardt
2026-10-09 20:39         ` Junio C Hamano
2026-10-08 18:10 ` [RFC PATCH 0/1] " D. Ben Knoble

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=a54e82eb-1252-4d6b-8b4c-6e99da59252d@app.fastmail.com \
    --to=kristofferhaugsbakk@fastmail.com \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.net \
    --cc=schacon@gmail.com \
    --cc=scott@gitbutler.net \
    /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